is WebStart deployment of JME applications still a viable option?
I have not much experience with Java web deployment but I’ve heard several concerns. Also the SDK states that unsigned and self-signed webstart applications will be deprecated (I could live with buying a cheap certificate for future deployment though). Also for JME’s main contender Unity its custom web deployment is working well.
I think for my current game project it would be the most beneficial method of distribution for the following reasons:
All users will automatically run the same up-to-date version
Users are tied to my website
No un-authorized copying of the application
No installation necessary for end-users
Application can have same set of features as desktop version (inputs, networking,...)
What do you think? Is it still an option or will WebStart be dead in the near future?
Java Webstart has become a nightmare especially since the default security level has been increased and it has become less and less reliable. Recently, I had to delete C:\Users${USERS}\AppData\LocalLow\Sun\Java when updating Java (1.7 update 65) to make it work anew: applet - Issues with Java 7u65 - Stack Overflow
Certum.eu provides free of charge trusted certificates for open source projects.
Why doesn’t the documentation talk about those limitations (especially under OS X)?
@gouessej: Because thats inherent java limitations? I mean if we started doing this we could as well publish the version history of java each time a new version comes out.
Generally, we will try and add better / new desktop deployment options in the future that are compatible with the various store ecosystems (App Store, Windows Store, Whatnot Store). To a certain extent thats already the case in 3.0 actually.
None of the core devs really believes in games that run in a browser so we don’t put too much focus on that, really. Of course we do support the inherent java and lwjgl deployment options for the browser but as said, they are dependent on the base support which is as you say not exactly stellar.
@normen You’re right, we shouldn’t write a book about Java Webstart and Icedtea Webstart limitations I should have been more accurate. Actually, the problem under Mac OS X concerns .app files too, the same manipulation is necessary if and only if the file is unsigned. You can look at the screen capture that I use here if you don’t see what I mean.
I suggest to not use Webstart,
instead make a launcher, taking a look at getdown is recommended.
That way your users just download a small few kb launcher that more or less stays the same, and runs with normal priveleges instead of crippled webstart idioticy.
Btw webstart does not protect files at all,
you can look at the jnlp where the stuff is stored, and then just download directly from there the jar files. (Or alternativly rip them from the local cache) (Been there done that^^)
@Empire Phoenix I’m already going to drop Java Webstart after having used it for 7 years.
Actually, I’m going to use native packages for all supported platforms and they will use the system JVM only under GNU Linux whereas they will use a (possibly minimized) JVM packaged with the game under other operating systems. I have lost a lot of audience anyway, I’ll improve the automatic update later. I already looked at GetDown several times, I advise its use for those who are looking for a quick replacement for Java Webstart.
@gouessej said:
@Empire Phoenix I'm already going to drop Java Webstart after having used it for 7 years.
Actually, I’m going to use native packages for all supported platforms and they will use the system JVM only under GNU Linux whereas they will use a (possibly minimized) JVM packaged with the game under other operating systems. I have lost a lot of audience anyway, I’ll improve the automatic update later. I already looked at GetDown several times, I advise its use for those who are looking for a quick replacement for Java Webstart.
Actually Oracle themselves are cooking up some more extensive desktop deployment stuffs for JavaFX, it already works somewhat if you use their ANT targets but it only works for the platform you deploy on… Thats where I got the native stub for jME’s current OSX .app deployment.
@Empire Phoenix said:
^^ i'm so far that I dont even care anymore about the few 100mb for the full jvm :P
This is a bit my case. When I see the size of the meshes representing some parts of Paris suburbs, I just think that an unmodified JVM is quite small :p
@normen said:
Actually Oracle themselves are cooking up some more extensive desktop deployment stuffs for JavaFX, it already works somewhat if you use their ANT targets but it only works for the platform you deploy on... Thats where I got the native stub for jME's current OSX .app deployment.
It makes me think about that:
https://github.com/joshmarinacci/AppBundler
The problem is "it only works for the platform you deploy on". I prefer my solution: "write once, package anywhere, run anywhere". It's so cool :) I just run my script and that's all. It builds the project, create the distributables and upload them whatever the OS.
I tried out GetDown for this purpose and it worked well. The only catch is that it always writes to the install location so you can’t install to the windows program folder, you need to install to AppData or similar where the OS will allow you to write.
I should have been more accurate. Actually, the problem under Mac OS X concerns .app files too, the same manipulation is necessary if and only if the file is unsigned. You can look at the screen capture that I use 