Java Network Launch Protocol (JNLP) is the designed way by Sun Microsystems to make it easy for any user to launch java applications without having to think much about dependencies and how to setup the java application. In just one click of a browser link, the java installed by your browser reads what you call a jnlp config file that contains the link to the app artifact, its dependencies, and the app sets up and launches itself. It's really a bright idea solution.
<a href="/path_to_the_jnlp_file/somefile.jnlp">Launch Application</a>
What are the amazing uses of this?
You can now call java applications and launch them from the browser. That's the original idea. JNLP was created to adopt to web technologies. But, you can actually use JNLP from anywhere that you have an installed java and where you can make an http request; for example, on your command line. Java Web Start (JavaWS) library run JNLP.
$ javaws http://www.somesite.com/somefile.jnlp
Other benefits of using JNLP is that out of the box, it can manage the update process of your application. It also manage your taskbar icon launcher.
So now you say, "Wow, letting my friend know about my java app is as easy as sending them a link!" Well, that might be true, but NOT for a lot of scenarios.
When you execute your application through JNLP, your application will be put in a sandboxed state. That means javaws will put your application in an isolated environment and you only have limited control over it. You can only play by the tools in the sandbox state javaws gives you. Your application files are cached. Your application launcher behavior is at the mercy of javaws. Limitations and bugs inherent to the sandboxed state will affect your app and the experience of your users.
Why do they have to put your app in a sandboxed state?
Well, they have to. Remember that your link that launches the app can be opened to any operating system (OS). And different OSes have different ways of administering the folder tree, it's access rights and permission to the file systems which java have no control of. JavaWS has to put your app in an environment that it can control.
Inherent to that sandboxed state are limitations and bugs that until now, weren't resolved by the Sun Microsystems:
1) Your app won't be able to update the Java Runtime Environment (JRE).
That is an obvious consequence. Java in a particular version manages your application. It cannot upgrade itself (cyclic dependency), shutdown and use the new JRE by itself. It needs another "worker" to do that switching.
2) It is not compatible with the Content Delivery Network (CDN) system.
JNLP can update your app when you specify on your jnlp that your app changed version. The update will then reinstall, remove the cached state and re-caches your updated application. But javaws also checks for the location of your resources over the internet. When any of those change, it updates your application.
The problem now is when you have resources put in CDN. CDN loves to randomly give you server locations in a specific geographical area near you. So your resources will have varying ip addresses when requested through javaws and this will trigger its update mechanism EVERY TIME. Every time you open the app, you will always have an overhead of downloading the whole app. It will really be annoying especially if downloading takes 30 seconds! Very unproductive.
3) Your icon launcher will have limited functionality.
The icon launcher is within JavaWS control. So whatever functionality JavaWS hands you over, you have no choice over it.
Sometimes, you want to put right click functionality to your icon. Put tooltip messages. None of those are offered by JavaWS.
4) The sandboxed state is buggy.
JavaWS gives you a control panel or what they call cache viewer to manually remove/restart the caching of your application. There were a lot of times that we removed the application already from the panel but the application seems to be running elsewhere. We cannot start a new state for the app because we have to find the process id and shut down the "lost state" of the app. In short, the caching mechanism cannot be trusted.
The javaws icon launcher as well is buggy. We tested our app in different OS; mac, linux and windows. To all of those, the icon launcher sometimes don't get the app icon we specified in jnlp. Also, the behavior of your icon on the taskbar is unpredictable.
5) Stale caches and other issues.
Just refer to this article and this forum post.
Now, going back to the thesis title of this article, how useful is the java network launch protocol. How useful? It's only for Proof of Concept type of projects; you want to show in a one time fashion that your application works. If you use JNLP beyond that, it's very possible that your user will bump into any one of these issues.
For production releases, or for scalability and long term engagement with your users, NEVER use jnlp or javaws.
In my observation as well, these problems are not being resolved actively by oracle.
No comments:
Post a Comment