Name: nt126004 Date: 03/15/2002


FULL PRODUCT VERSION :
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

A DESCRIPTION OF THE PROBLEM :
1 Introduction
Some classes under Java 1.3, are "user classes", others are
"optional packages".
user classes are found in $CLASSPATH, whereas
"optional packages" are found in $JAVA_HOME/lib/ext and all
dirs from the "java.ext.dirs" property.
This is described in great detail at
http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.htm
l
In this article, I will show that JNLP 1.0 cannot handle
"optional packages", or only at the cost of doing very bad
things.
2 What are optional packages?
You have to write a optional package for example if you
want to write a subclass of java.awt.im.spi.InputMethod,
which adds custom input methods to an application.
"Optional packages" are either installed or downloaded.
Lets have a look at the two choices.
2.1 Installed "optional packages"
In order to install an "optional package", one has to use
an installer which copies the jar file into
$JAVA_HOME/lib/ext. This is unacceptable for the following
reasons:
? The JNLP-client is generally not able to later
remove archives from lib/ext. The reason: If any
application (including the JNLP-client) is using the JVM,
all the files under lib/ext are locked. Under Windows, the
only solution is to reboot. This is not an option.
? lib/ext offers no namespace. As the lib/ext
directory is one flat directory, there is no protection
against name clashes. This creates a dll-hell for Java.
? $JAVA_HOME may be write protected for the user.
Either the drive is read-only or you need
root/administrator privileges to write to it. Failing to
copy will result in a program failure.
? If an "optional package" is added to the lib/ext
directory, all Java programs using that JVM are affected.
It cannot be assumed, that this is the intention of the
developer. Even worse, a poorly written "optional package"
can lead to failure of other Java programs.
? A company that does not want other applications to
use their "optional packages", has to uninstall them from
the lib/ext each time the program terminates. This is not
possible (see first argument).
? JNLP 1.0 cannot set the property "java.ext.dirs".

I conclude that installed "optional packages" cannot
satisfactorily be used in JNLP 1.0.
2.2 Downloaded "optional packages"
Downloaded "optional packages" are specified as URL in the
Class-Path Manifest header of a Java-archive. JNLP ignores
the Class-Path Header of a Java-archive Manifest (See spec
4.3.1).
I conclude that downloaded "optional packages" are an
applet-only concept. In this regard, JNLP falls behind
applets.


Further clarification:
-------------------------------
(Concept 1)
The JNLP1.0-component extension, which is described in section 3.7 and 4.7
of the JNLP-Spec 1.0.
A JNLP1.0-extension can be a either component extensions or an installer
extensions.
Citing section 3.7: "A component extension is typically used to factor out
a set of resources [...]"
With regard to my proposal: A JNLP1.0-component extension is treated as a
regular class of the classpath.

(Concept 2)
The Java1.3-optional package (formerly known as standard extension), which
is described in.
http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.htm
With regard to my proposal, a Java1.3-optional package is a class which has
to be present in the JRE/lib/ext directory at startup of the JVM in order
to have an effect.
It is *not* sufficiant to use a (concept 1) JNLP1.0-component extension.

(Concept 3)
The JNLP1.0-installer extension, which is described in the same section as
concept 1.
Citing section 3.7: "The installer is intended to install a [...]
complicated setup [...], such as [...] device drivers."
With regard to my proposal: A JNLP1.0-installer extension itself has
nothing to do with concept 2.
-------------------------------

The JNLP1.0 spec states, and Rene confirmed several times, that the only
way to use a
Java1.3-optional package (Concept 2) in Network Launching, is to make use
of a JNLP1.0 installer extensions (concept 3):
Citing section 7.8: "This allows an [installer] extension to [...] update a
JRE by installing Jar files into [...] the lib/ext directory."

The above explains why this situation is unacceptable.


3 Proposal
I propose to introduce a new JNLP element
<optional-packages-desc> and a new property
"java.ext.jars", which is a list of jar files.
A future JNLP-client sets the proposed "java.ext.jars"
property to jars specified with <optional-packages-desc/>.
Without the proposed "java.ext.jars" property, the future
JNLP-client sets the "java.ext.dirs" property to
directories that contain classes from jars specified with
<optional-packages-desc/>. The developer has to keep in
mind that all jars in these directories are getting
"optional packages".

This proposal is completely analogous to the behaviour of
JNLP 1.0 -clients regarding native libraries.
There is a default directory for native libs, but one can
also mark jars as <nativelib>. A JNLP 1.0-client sets the
"java.library.path" property to directories containing jar
files marked as <nativelib>.
Native libraries are extracted from a jar and put into a
directory aside the jar file. Therefore, it make sense to
specify directories in the "java.library.path" property.
For "optional packages", on the other hand, it would be
easier to specify individual jar files in a proposed
"java.ext.jars" property, which would have the same effect
as the "java.ext.dirs" property for a set of jars.
The proposed "java.ext.jars" property reflects an
adaptation of "optional packages" to the network centric
model of JNLP.

3.1 Changes to the JNLP DTD
In the JNLP 1.0 protocol, a jnlp element can have one of
four types:
<application-desc/>
<applet-desc/>
<component-desc/>
<installer-desc/>

This proposal introduces a fifth type:
<!--
The optional-packages-desc element specifies a component
extension which is
treated as an optional package as described in
http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.htm
l
-->
<!ELEMENT optional-packages-desc EMPTY>

and adds it to the jnlp element
<!ELEMENT jnlp (information+, security?, resources*,
(application-desc |
applet-desc | component-desc | installer-desc |
optional-packages-desc))>



4 Conclusion
If nothing is done to rectify the problem of Network
Launching "optional packages", it could seriously diminish
the users perception and undermine stability of the Java
Network Launching Protocol.




This bug can be reproduced always.
(Review ID: 143713)
======================================================================