Just throwing this out there… jar files are great for enthusiast sites like this one. If you ever want to release something for “general consumption” by the rest of the world, that’s when you’d start thinking about launchers and embedded JVMs and so on.
Cas 
Is there anything better? Because I don’t really like how you can only add jars and not class files so I have to convert it to a jar first…
Also I want to be able to set an icon if I wanted to…
JarSplice isn’t open source as far as I know, you can use JarMatey or One-Jar. BurntPizza suggested PackR which is very good and very simple to use.
My own tool (free software, under GPL v2, in TUER) goes further as it is able to create .icns icons for Mac without a Mac, DEB and RPM packages without GNU Linux and probably in several weeks or months MSI packages without Windows. It’s composed of several Ant tasks, it allows to embed a JVM, it uses a native launcher (PackR’s launcher) or a script.
I don’t use “runnable” JARs because:
Please make an effort, put your class files into a JAR, it’s not very difficult. You should learn how to use a build tool (Grale, Ant, …).
Where?
What I do is keep the jar as another distribution, but have an .EXE as a quickplay option and download as well. It's just a matter of preference I suppose.I haven’t found any JAR for your game on Gamejolt.
It’s supported by PackR.
Just two questions about packr (Yep, more questions):
Yes, it does. I don’t use LibGDX in TUER but I use a small part of PackR.
It’s just plain Java code. I call it in Ant. You can make your own GUI tool but in my humble opinion, it is a bad idea because you shouldn’t spend most of your time in creating tools and a GUI tool would be harder and more time consuming to improve than a script using a build tool. You can automate your whole build with a build tool (Ant, Gradle, …) or a build system (Maven, …). In my case, I run run “ant dist” and it does everything for me except guessing my passwords ;), it compiles my classes, it creates the temporary directories, it creates the JARs, the scripts, the native application bundles, it signs the JARs, it creates the ZIP archive and it uploads everything on the server. If you really want a GUI tool, just make it simple and switch to a real build tool when it becomes more complicated.
Sorry to insist but my own tool goes a bit farther than PackR under GNU Linux, it provides a better integration (except maybe for the window icon).
I hid it for now, I’m using it to test the GameJolt API to add achievements and a High score board.
+1 for JarMatey, hehehe…
I think that part of the problem is that you’re arguing with people who mostly agree with you. We’re Java developers, so sure, we can agree that jars are easy. If your audience is Java developers, jars are a great option. If your audience is guaranteed to care enough (friends, family) to make sure Java is installed and to fix any problems they have running a jar, then jars are a great option.
However, you’re vastly overestimating the average user. For a jar to work, Java (the correct version of Java) has to be installed, the system path has to be configured correctly, and the OS has to associate jars with Java instead of an archive manager.
The above is fine in most cases, let’s say 75% (that’s probably a high estimate) of the time. But what happens the other 25% of the time? If it’s somebody you know personally, or a fellow programmer, then fixing the above is no problem. But what about your average user (who can’t tell you the difference between an operating system, a web browser, the internet, and facebook)?
You say that all you have to do is tell them to install Java and give them a link, but 90% of users won’t follow a link. Most of them won’t even bother contacting you or reading any FAQ or troubleshooting guide if your game doesn’t “just work” in the first place. And then to walk them through installing Java, possibly setting up their path, possibly changing the file association… it’s just not going to happen. Sad, but true.
But again, that’s fine for most cases, because chances are you aren’t dealing with the general public like that. But if you want to get into “real” game development, then exporting as a packaged executable (or exporting as html5/javascript) is the way to go.
I still prefer to deploy my programs as jars, but that’s because I’m not very worried about the general public (I have Android for that). I still think most people should deploy as a jar, because they shouldn’t be worried about the general public either, at least until their game is at a point where the general public would play it anyway.
JarMatey (which I created and is completely open-source) does export other jars, native libraries, external files, and class files as a self-extracting runnable jar, so that might be worth checking out. Another option is JWrapper, which exports platform-specific executables.
When they decide to make a native application bundle containing a script or an executable, it would be better for them to find fully reliable (on the long term) tools to do that instead of spending time to do it themselves. How many developers have already tried to create tools to make runnable fat JARs? I know that there are less people under GNU Linux than under Windows but JWrapper has a worse support for GNU Linux than my tool:
[quote]On Linux this means a native exe inside a double-click extractable tar
[/quote]
I provide RPM and DEB packages. Moreover, JWrapper seems to use Oracle Java and unlike what its creator claims, I’m not 100% sure that it respects Oracle’s redistribution terms unlike PackR and my tool which use OpenJDK.
I’m not really trying to espouse JWrapper over your tool, even though every time I mention it you say that people should use your tool instead. I’m simply trying to list some options.
Your tool might very well be awesome, I have no idea because I’ve never tried it. (Like I said, I prefer deploying as a jar anyway.) I have used JWrapper in the past and I enjoyed it (it has a simple gui and supports optionally downloading the JRE instead of packing it), which is the only reason I’m mentioning it. I’m not trying to debate whether your tool is better than JWrapper.
“Here is my game”
“what is this ?”
“its a jar”
“how do I use it ?”
“you have to install java”
“oh. what a hassle. Also I heard java is dangerous for your pc. and also slow”
(person installs it, also Ask.com toolbar, which is included. Person gets angry)
“ok now double click the jar”
“winrar opens.”
People dont have java installed and even if they dont want no shitty jar.
You are supposed to hide technicalities from the user. A user on windows uses an exe. What language was used to code it should never reach the user.
Or “Oh I have Java, but when I double-click your jar, nothing happens. You must be a horrible programmer.”
Half an hour of debugging later and you realize the person has Java 1.4 installed…
That’s why you tell them to give you the output of [icode]java -version[/icode]. Let’s you check it’s installed properly and if it’s the right version.
^ this is the exact reason why Retro-Pixel Castles now has a bundled JRE, I got really, really exhausted telling people to reinstall Java. Even though I do use executables, they’re just glorified command-line launchers. All the action is still happening on Core.jar (the main jar)
Haha, yeah, I know. That half hour of debugging was getting the person to open up a command prompt…
Just a few notes:
)PackR takes a fat JAR in input, you have to be able to create a single JAR with (optionally) some resource files.
I can’t confirm because I use JogAmp. NEWT (JOGL) sets its own icon by default, I have to use one of its properties to set it. Some other APIs have the same behaviour. I can just confirm that both PackR and my tool support icons for executable at least under Mac. My tool supports the icon in the start menu under GNU Linux and in its equivalent at the bottom of the desktop under Mac. My tool is a bit more robust than PackR because it gives you an alternative option if the native launcher doesn’t work.
Ant isn’t mandatory for PackR but in my humble opinion, it is very useful and powerful.
If a finished game requires any kind of effort just to open, it is (rightly) dragged straight to the trash can by 99% of people. A double click is the maximum effort that should be required. There is so much software to try out, life is too short to start messing around with tech for an unknown amount of time just to use a program which will probably stink. If the dev can’t even streamline for me something as easy as opening the program it doesn’t bode well for the rest of the experience.