Re: thoughts: boot classloader/classpath

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jakob" == Jakob Praher <jpraher@yahoo.de> writes:

Sorry I didn't reply to this earlier.

Jakob> in the current libjava implementation, if a ClassLoader bypasses its
Jakob> parent ClassLoader, by setting it to null, the only universally
Jakob> accessible classes are those that are already in the Cache.

Yes.

Jakob> also it is currently not possible to add classes to the a kind of
Jakob> endorsed path (allthough I saw that rhug had support for a
Jakob> $PREFIX/share/java/ext stuff).

You can LD_PRELOAD classes or link them into a new executable (and
with libgij this can be an "interpreter-like" executable).
But yes, for interpreted classes you are correct.

You can use java.ext.dirs, but these are loaded by the system loader
(which is bypassed if a ClassLoader has a null parent).  (We get a
detail here wrong, in that there should probably be a separate
extensions loader -- and more importantly, that extensions should be
searched before the class path, not after.)  (I filed a PR for these.)

Jakob> * Add bootclasspath options to the gij file

I'm not so sure about this, since it would be similar to the 'java'
option but would actually not be capable of doing the same thing.

Jakob> * Add support for endorsed shared-objects / jar files

Isn't this just java.ext.dirs?  Which won't do what you want, as I
understand it.

Jakob> * Add support for Precompiled boot classes.

FWIW I'm planning to install some of our libraries in a special
"versioned directory", so that we can automatically load them even
when library_control=never.  For instance the AWT peer code will fall
into this category.  Users could conceivably install other libraries
in this directory as well.

This is most likely my next task after the jaxp thing.

Tom