Re: packaging jars vs. classes

["Cris J. Holdorph" <holdorph@home.com>]

On Wed, Nov 08, 2000 at 12:58:31PM -0800, Aaron Brashears wrote:
> I think that only has to do with standard extensions to java, such as
> java3d or java media framework. I've been using blackdown's 1.3 jdk
> from debs recently, and the script appear to do autodetection of jars,
> but does set the classpath to:
> 
> CLASSPATH="/usr/share/java/repository:${CLASSPATH:=.}"
> 
> The comments around that statement indicate the author is trying to
> conform to the debian java policy, but thinks that the repository
> should be added to java.ext.dirs. If the java policy collapsed the
> /usr/share/java/repository into /usr/share/java and /usr/share/java
> was added to java.ext.dirs, java should autodetect everything.

One thing to consider with respect to the jdk 'ext' subdirectory is
that it has a separate class loader from the CLASSPATH.  And more
specifically the CLASSPATH class loader will chain to the 'ext'
class loader, but **NOT** vice versa.  This was a problem at
my company when we had placed all of our tools, such as XML utilities
in the 'ext' directory.  Well when doing certain XML'y type things
the 'ext' loaded utilities were using reflection to load some of
our local (CLASSPATH) classes and would fail.  Said simpler, things
in the 'ext' directory can *NOT* access classes in the CLASSPATH.
For this reason, the 'ext' directory takes on a much more limited use.

---- Cris J H

-- 
Cris J. Holdorph
holdorph@home.com