pages enables browsers to launch the plug-in utility with the given applet as an argument,
bypassing the browser's internal JVM.
The Java Plug-In is intended for intranet users because of the size of the software itself that
ships with a JVM (Java 2 Standard Edition, the latest version) included. Indeed, the Plug-in is
included in Sun's J2SE JRE for Windows and is optional in J2SE SDK distributions for
Windows. Although the Java Plug-in solves most incompatibility problems between the two
main browsers, other issues still remain. The two major browsers have different extension
architectures, and therefore the Plug-in download experience for the enduser is different
depending on the browser used.
Apart from these minor deficiencies, the Plug-In enables applets to take advantage of all J2SE
features such as code signing applets and native methods but it does not solve the problem of
organizing different JREs on the same client platform. In fact, another limitation is the inability
of different versions of the JRE contained in the Plug-in to coexist on the same computer at the
The Sun Plug-in deserves a closer look because it represents a typical scenario in Java deploy-
ment techniques. Figure 1.4 shows in detail what happens with an illustration of the download
and execution of an object from a Web browser given the related application/MIME type. It is
a sequence diagram with some extra details. Optional steps are depicted with dashed arrows
(the download and installation of the Plug-In) while the processes involved with the applet exe-
cution on the client side are shown.
The Plug-In solution is typical for Java deployment because it makes use of an application-
helper (that is, a piece of software that helps the application to be launched). This helper takes
charge of installing and managing a JRE on its own. Given the problem with the deployment
of Java executables (the lacking of an up-to-date, standard and shared JRE already installed on
the client platform) this is currently the only way to go. The user must first install an applica-
tion helper that will then manage the download and execution of Java code locally.
Seen in this light, the release of the JNLP protocol should come as no surprise. It is the natural
evolution of the Plug-in initiative, and before that, as the extension of the applet idea by means
of a local application helper.
If asked how software was distributed before the Net, your reply would probably describe the
typical installer utility as a piece of code that handled all the installation while running on your
machine. In other words, a substitute for a human operator specialized in the installation of
software on client machines.