First of all, think of whether you really need an installer. As mentioned in the comments, Java applications can be easily distributed as a single JAR (usualy a fat JAR with all of it's dependencies merged inside, check this: How can I create an executable JAR with dependencies using Maven?).
If you really need additional files besides your executable JAR, you can still avoid an installer by distributing a compressed binary package with some auxiliary file structure around your JAR. Anyone can extract it somewhere in their system and run the main file. If necessary, you can also provide a batch file/shell in the root folder of this structure to help launching your app.
If you still prefer to sound less technical for users, you can also wrap that JAR into an executable file with an charmy icon by using Launch4j (http://launch4j.sourceforge.net/). You can even embbed a JRE in your file structure so the user won't need to install Java.
Before diving into installers complexity, you can also use a self-extracting archive just to ask for the user where to put the files. A lot of famous solutions work like this. Maybe you can even hide the files extraction phase and do it in the background everytime the application is asked to be launched (check this: https://www.excelsiorjet.com/kb/35/howto-create-a-single-exe-from-your-java-application).
I can only see the real need for an installer if you: need to check for previous system conditions (space, memory, dependencies); grant permissions to special folders and users; install your program on the default O.S. program files folder; set environment variables or Windows registry entries; create desktop shortcuts or system's menu entries; and a bunch of other tricky details. In this case, consider using an existing installer solution, since there will be a lot of hardwork involved until you can successfully accomplish such task. You already have to put so much effort to control your aplication codebase, not least another bunch of code for it's installer!