Posted by gouessej on Jan 10, 2018; 3:52pm
URL: https://forum.jogamp.org/Here-is-how-to-do-multi-platfrom-deployment-tp4038517p4038521.html

Hi

Thank you for sharing your findings and explaining in details how you use Java Webstart. Actually, it was possible to point to our JNLP files in order to use JogAmp without having to handle all our files but I don't know whether it still works.

In my humble opinion, there isn't only one solution to solve all deployment problems. Java Webstart fits into your need, that's fine. It's suitable when you want to test something without having to (explicitly) download and install. However, Let's Encrypt can't be used for code signing, all providers of free of charge trusted certificates expect some compensations and trusted certificates have become mandatory to use Webstart whereas they only give a false feeling of security. A Russian programmer stole such a certificate and illegally used my only registered trademark to provide a fake version of my game full of crapwares (viruses), it shows that blindly trusting "trusted" certificates is stupid and can lead to install dangerous softwares. The best security suite is an educated person who accepts to understand a bit the technology (s)he uses. Encouraging Java Webstart now means encouraging this vision of security. Sorry but I can't agree with it and it excludes the developers who can't afford such certificates. I'm fed up with re-intermediation. In other words, the corporations selling those certificates just put tolls to make money with no additional value in term of security. This problem concerns some other means of deploying softwares too but Java Webstart wasn't concerned by this before some changes done in Java 1.7.

Moreover, when a developer needs a more complete way of installing a software, IzPack is a viable alternative (obviously there are other solutions). When we need much more control on what has to be installed on the end user's machine, Java Webstart can't be the right answer as it doesn't support all JVM options for security reasons, its class loader doesn't behave exactly like the one of a Java software launched without it and it's not possible to install another JRE for your program with Java Webstart. Numerous professional softwares on which I worked required a particular update of Java to work, it doesn't make a lot of sense to use Webstart to run this kind of software without relying on the JRE installed on the system.

Finally, there are lots of ways to fail to deploy a software with Java Webstart, that's why explaining how to use it has become increasingly complicated. Some manifest attributes were (are?) mandatory under some operating systems but not on others, including "Application-Name". As the support of "Trusted-Only" and "Trusted-Library" has changed several times, it's impossible to make a single JNLP file working with all updates of Java 1.7. The parsing of some options was partially broken for years, for example in "java-vm-args" in Java 1.7 update 45. I think that a developer should know the pitfalls of Webstart before choosing it as a deployment solution even though I admit that some alternatives are cumbersome to use, their main lack is the update management, some just don't work at all (I have never succeeded in using GetDown). Webstart has a huge history of major bugs and limitations. Do you remember when it caused a deadlock when showing a window at the beginning? Its caching system is far from perfection too. I strongly disagree with your title, it should be "Here is how to do multi-platform deployment with Java Webstart" as it's not the only mean of doing multi-platform deployment and claiming it is leads to ignoring what I've just written above, it doesn't fit into all needs...

By the way, the desktop shortcuts can't be created on all operating systems supported by Java with Webstart, I had to reimplement this feature by myself and mine did a far better job especially under GNU Linux with KDE.