Shibboleth Developers

["Howard Gilbert" <>]

> -----Original Message-----
> If you search the Sun site for "javac target source" you'll find some
> interesting discussion regarding this topic.  The documentation
> suggests that the -target option be accompanied by other options,
> namely, -bootclasspath and -extdirs.  This could be contributing to
> the problems I'm seeing.

Unlikely.

When you reference a class for the first time, Java tries to load it. To
load a class, Java uses the current chain of ClassLoaders starting with the
one most recently added. Every class is loaded by a ClassLoader. However,
java.lang.ClassLoader is a class. It is a member of rt.jar and is a bunch of
bytes on disk. So, if every class is loaded by ClassLoader, how does
ClassLoader itself get loaded?

The answer is that there is a bootstrap ClassLoader built into the JVM, and
it resolves classes from the -bootclasspath. It is used to load in all the
initial classes needed to get anything running at all. You can tell when a
Class object is loaded by the bootloader, because when you ask it for a
reference to its ClassLoader object, the method call returns a null.

The -bootclasspath provides an option to load these fundamental classes from
an alternate source. Generally speaking, it is only interesting when you are
cross-compiling (and since Java is Write Once Run Everywhere, this doesn't
mean cross-compile to a different hardware architecture, but rather from
Standard Edition to Micro Edition for code that will run on a cell phone or
PDA) or when you want to run a non-standard JVM with, say, a special Garbage
Collector or profiling instrumentation. 

Extdirs then specifies an alternate extensions directory just as -endorsed
specifies an endorsed directory. Extdirs could not be involved in an error
of the form:

java.lang.ClassFormatError: Illegal field name "has inconsistent hierarchy"
in class
edu/uiuc/ncsa/shibboleth/plugins/X509SubjectNameNameIdentifierMapping
        java.lang.ClassLoader.defineClass1(Native Method)
        java.lang.ClassLoader.defineClass(Unknown Source)
        java.security.SecureClassLoader.defineClass(Unknown Source)
        
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLo
ader.java:1626)

Because the proximate cause of the error in the traceback is
java.lang.ClassLoader which has to come from the -bootclasspath and cannot
come from extdirs because extension directories come after the normal rt.jar
and not before it.

I suppose you could create the problem by specifying a -bootclasspath to a
JDK 1.3 system while running a JDK 1.4 system, but you would have to work
hard to create such an error. While it is possible that the previous message
means "you have succeeded in loading a non-standard copy of
java.lang.ClassLoader", my money is still on a bug in the compiler or
runtime.