Re: packaging jars vs. classes
It seems to me this discussion would benefit from a re-statement of
the class loading ground rules (as specified by Sun).
There are 3 places that a Java class can be loaded from:
1. the boot-classpath
used only for core java.* classes (and the CORBA stuff and anything
else Sun or other JVM maintainers feel should come with their Java
platform)
2. the extensions classpath
used only for javax.* stuff, eg: JMF, JavaMail, Servlet API
3. the user classpath
used for everything else, can be used for extensions implementations
1 and 2 are fixed - they shouldn't change and should not be used for
general class loading.
Note that (as per Sun spec) 2 should NOT be used for things like
servlet engine implementations.
*And now some stuff about servlet engines
This gets more complicated when you consider servlet engines. Servlet
engines should have their code (jars or classes) specified on the
classpath (ie: 3).
The classes and jar files that define applications (eg: servlets and
so forth) go in an application archive called a WAR which could be
dumped anywhere (but tends to go into a specific directory that the
servlet engine understands) but *shouldn't* go on the user classpath
(for security reasons).
Versioning complicates this even more because as a developer you want
to be able to specify that your application depends on a particular
version of a package and not load more than one class into memory if
the version is available.
eg: a servlet engine archive delivers a webmail solution - the WAR
contains the documents and images needed to deliver the app. It also
contains (in it's libraries directory) a copy of the javamail.jar. The
servlet engine wants it's classloader to be able to confirm that any
javamail.jar on the *extension classpath* is used before it's own
copy. It's own copy will only be used if there is a difference in
versions.
*And now for my analysis of the real problem
The real problem IMHO is that you can't specify the "extension"
directories on the classpath (remember that the extension directory is
for official extensions only).
Debian could solve that in 3 ways:
1. ignore the "extensions for javax.*" only rule and put all libs in
the extensions directory
2. allow the user-classpath to contain directories with some marker
that signifies they're extension directories and alter the real
classpath provided to the JVM before hand.
eg:
classpath=/home/tomcat/classes:/home/tomcat/libs/:/home/lisp/
might be converted to:
classpath=/home/tomcat/classes:/home/tomcat/libs/tomcat.jar:/home/tomcat/libs/jasper.jar:/home/tomcat/libs/xml.jar:/home/lisp/kawa.jar
That would be fairly easy to script, it's just establishing which
directories in the "source-cp" end with a "/" and doing an "ls -lad
*.jar" on those directories.
3. provide a SystemClassLoader that did the searching dynamically
This might be tricker since it would have to replace existing VM
class loaders (I'm not sure how well that would fit with gcj for
example) but it would be possible in traditional VMs.
The package would have to move and rename the existing VMs System
Class Loader and call that to deal with stuff on the boot classpath
and extension classpath.
Nic Ferrier
GNU-Paperclips
(which I'm going to be debainizing soon you'll be indifferent to
hear)
Reply to: