Author: Kevin 
As you probably know by now, back in January, Java 7 update 51 made it harder for people to use applets or webstarts. More info can be found here, but the gist is that if you (the developer) don't pay for a certificate, then end-users (the players) won't be able to run your game as an applet or webstart. There are ways around this (described here), but changing your security settings just to run a game isn't an option for a lot of people.
That's why one of my first goals this year was to figure out a way to deploy Java games as packaged executables. After trying out a bunch of different options (JWrapper, launch4j, JarSplice), none of them quite worked out exactly how I wanted them to. So I decided to come up with my own solution.
I've called that solution SvgExe (I know, I'm bad at naming things), and it can be found HERE. Basically, you give SvgExe a collection of classes, jars, native files, and external files (via a hopefully user-friendly GUI), and SvgExe will give you a self-extracting jar file that you can send to your friends (or upload here!).
Hopefully the process is relatively straightforward, but I've also written a set of tutorials to go along with SvgExe. So far I have examples for a basic Processing sketch, an advanced Processing sketch with images and third party libraries, and a LWJGL example that uses OS-specific native files.
I also snuck in support for uploading arbitrary executable files. This feature is available on the left-hand menu of the game editor/uploader. Yes, this means that Static Void Games now supports non-Java games!
If any of the games you've uploaded here rely on applet or webstart to be played, I strongly suggest you use SvgExe to create a standalone, self-extracting runnable jar. This might mean going back and converting all of your games to a runnable jar (which actually isn't that painful, trust me, I just did it myself), but that's much better than players not being able to play your game.
I got my first goal of the year accomplished, and it only took me three times as long as I thought it would! Next up I'm going to focus on overhauling the backend, with the hopes to have that done by July (which by my estimates means I'll be done by December). That opens the door for a lot of exciting changes, so stay tuned!
So, basicly, this is a way to contain everything in one .jar file right? This is all I wanted! Time to code!
Seriously, how did you did you manage that?
This is great, since now it will be possible to have other files, for highscores, saves and such! Besides we get VM arguments, permiting the use of Vsync and stuff like that...
Downside: I'll be losing my time to exploit EVERYTHING!
I've updated SvgExe to fix a bug on Mac OS X!
And I don't want to disappoint you, but SvgExe doesn't take care of save files for you. In fact, any files it extracts are deleted after your program exits. It's just a way to package any files you need to *load* from (not save to) into one jar. Although, I could think about adding that feature! SvgExe does allow VM arguments though.
I'm thinking about opening up a little github project or something to keep better track of updates and requests. More thought is required on that!
Thanx for this tool. It's very practical and convenient to have one selfcontained file for all platforms.
I think adding feature to leave saved files would be very very useful for processing developers.
I've tryed exporting one such app. I see the files beeing saved in the temp folder, and then erased after exit, so I guess this feature shouldn't be too hard to add.