Java Web Start: Difference between revisions

Revision as of 00:16, 19 November 2009

Revision as of 11:42, 22 November 2009

Line 25:

Any computer user can use JNLP by simply installing a JNLP client (most commonly Java Web Start). The client installation can occur automatically, so that the end users can see the client launcher downloading and installing before the Java application the first time they launch the latter.

JNLP works in a similar fashion to how HTTP/HTML works for the web. For rendering a HTML [[webpage]], after the user clicks on a weblink, the browser submits a URL to a [[webserver]], which replies with an HTML file. The browser then requests the resources referred to by this file (images, [[cascading style sheets | css]]), and finally renders the page once it has received enough information. Page rendering usually starts before all resources have downloaded; some resources not critical to the layout of the page (such as images), can follow on afterwards — or on request if the "Load Images Automatically" browser-setting remains unset.

JNLP mirrors this process; in the same way that a Web browser renders a webpage, a JNLP client "renders" a [[Java application|Java app]]. After the user clicks on a weblink the browser submits a URL to a webserver, which replies with a JNLP file (instead of a HTML file) for the application. The JNLP client parses this file, requests the resources specified (jar files), waits for the retrieval of all required resources, and then launches the application. The JNLP file can list resources as "lazy", which informs the JNLP client that the application does not need those resources to start, but can retrieve them later on when/if the application requests them.

Line 44:

Some of problems with JNLP are:

* Developer has to write server URI in JNLP file, so it is not possible to use same JNLP descriptor file in production and testing environment. Developer cannot just drop .jnlp file into server shared directory, he or she has to edit it. This problem could be solved if .jnlp file opened directly by web browser plugin (as for [[Java Applet|applets]]), or by introducing jnlp: URI scheme, so .jnlp file descriptor opened by URL like jnlp:http://my-site/app.jnlp. jnlp: URI scheme may be handled by JNLP handler.{{citationCitation needed|date=November 2009}}

* Developer has to sign with certificate all jar files used by JNLP. Although it is not a problem for serious production applications, it complicates learning and small applications development. Certificate may be self-signed, so this does not really solve security issues.{{citationCitation needed|date=November 2009}}

* Bad user experience: user downloads .jnlp file into temp directory or Downloads folder. Browser may ask user, if he really wants to save that .jnlp file, and then has have to open downloaded manually. This again could be solved by browser plugin, or by introducing jnlp: URL scheme.{{citationCitation needed|date=November 2009}}

* Permission checking is too simple. Developer hardcodes required permissions into .jnlp descriptor (for example, developer may request "all permissions"), and user has to confirm permissions once at application start. It would be better if jnlp had no permission specifications at all, but on unsafe operation JNLP engine asked user questions like "Application My Demo requests to read file 'preferences.txt', allow?" with answers like "Allow once", "Always allow this file", "Always allow read anything". JVM SecurityManager is capable of performing such checks, but JNLP does not utilize such capabilities.{{citationCitation needed|date=November 2009}}

* 64-bit Windows support added only in Java 6<ref name="win64">[http://bugs.sun.com/view_bug.do?bug_id=4802695 Bug ID 4802695, Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64]</ref>.