Hi,
thanks for your information that confirms what we have seen already.
We have noted that VMClassLoader was the root Class with native method
signature and almost understand the mechanisms/links with our VM
(jamvm).
However as a first constraint we do not want to code our thing in a
native method but rather in Java. So we cannot add features to our
native loadClass that links with VMClassLoader.loadClass().
I remind our goal: load classes from glibj.zip remotely and only have
the minimum classes stored locally to do this.
As far as we understood, when the bootstrap is called (i.e. current
ClassLoader.parent==null), the method VMClassLoader.loadClass() is
called . When method is loaded from the classpath, i.e. by
SystemClassLoader, findClass() method is called, which does a lot of
things to get the Class bytes and finally call the root class
VM.defineClass() to set some parameters on the class, including name &
security etc., if I am right.
Current behavior acts like this, macro-algorithm:
Class loadClass(String className){
if (bootstrap) {
c= VMClassLoader.loadClass(className);
if (c!=null){
return c;
}
c= RemoteClassLoader.loadClass(className);
if (c!=null){
return c;
}
}
//not bootstrap
else {
c = parent.loadClass(name)
}
// then if this have failed tries to load from classpath as usual
Basically all we have done is add a step at bootstrap. Normally all
classes to perform a RemoteClassLoader.loadClass() can be loaded with
the first step VMClassLoader.loadClass(). In the end we want to have
only these classes in the local core API and the rest of the API
distant.
RemoteClassLoader extends ClassLoader. RemoteClassLoader.loadClass()
get bytes from a URL and then call the parent defineClass() (parent in
sense of Java inheritance, not ClassLoader delegation, this is also a
bit confusing, thus ClassLoader.defineClass()).
ClassLoader.defineClass() finally calls VMClassLoader.defineClass().
Keep in mind that this RemoteClassLoader.loadClass() is aimed at
loading the core API classes.
We have done some basic tests and this seemed to work. However, when
trying with a more complete program, it appears that it throws
IllegalAccessException making me think that some security is added
when using the defineClass() on core API. Normally when calling
VMClassLoader.loadClass(), which is the method that should be used for
bootstrap classes, defineClass() is never called.
I have read (Component Development for Java Platform, Stuart Dabbs
Halloway), that code is the core API or extension will have the
suppresAccessChecks permission whereas code loaded via URLClassLoader
will not have this permission. Another thing is the ProtectionDomain
used by defineClass(). We have investigated this without succes at the
moment...
Thanks for any help and hope I was clear enough in my explainations.
martin
2007/5/1, Tom Tromey <tromey@xxxxxxxxxx>:
>>>>> "Martin" == Martin Schlienger <m.schlienger@xxxxxxxxx> writes:
Martin> - Is there any place where I can find something like a UML sequence
Martin> diagram of classloading mechanisms.
Nope, sorry.
Martin> It seems there is a lot of back and forth between
Martin> URLClassLoader, ClassLoader, VMClassLoader and all is a little
Martin> bit confusing.
Most of this is delegation. ClassLoaders are arranged in a dynamic
hierarchy and each delegates loading to its parent before trying to
load itself. This chain is rooted in VMClassLoader, which is not a
standard class but rather the way we've chosen to represent the
bootstrap loader inn Classpath .
Martin> - Any suggestion to make a class loaded by another loader to have the
Martin> same rights as the ones loaded with the bootstrap (
Martin> VMClassLoader.loadClass() ). Since we are loading some of the classes
Martin> from glibj.zip with another loader that can access a remote file, but
Martin> ATM we have some IllegalAccessException with some of these. Since we
Martin> use the default ClassLoader's defineClass(), we may have to hack this
Martin> one (no success ATM).
The VM* classes in Classpath are a bit funny. They define an API but
they don't use inheritance for implementations -- instead a given VM
can replace one of the classes entirely and it is simply expected to
conform to the defined API.
So, you can change VMClassLoader to do whatever you like. For
instance, in libgcj we delegate some operations to a URLClassLoader
that we construct after VM startup.
I'm not really sure what you mean about IllegalAccessException and the
default defineClass. As I recall, ultimately all classes are defined
via a method on VMClassLoader.
Tom
