Hi Olivier,
Olivier Jolly wrote:
Hi,
it seems to me that there is a missing/incomplete feature in the
VMClassLoader.
For now, the vm implementation are not encouraged, helped nor told to
define packages in which classes are loaded from when the boot class
loader is defining them. Notably, this makes such that java.lang package
is not defined (i.e. basically getPackage on the VMClassLoader for
"java.lang" is null)
Well the actual comment on the getBootPackages method are
/**
* Returns a String[] of native package names. The default
* implementation returns an empty array, or you may decide
* this needs native help.
*/
So if the VM implementer decides that he wants to return the strings
of all gnu-classpath + vm-specific packages, he has to redefine
getBootPackages.
We could force getBootPackages to be native though.
I spent my week end trying to hack cacao to call a new VMClassLoader
method (definePackageIfNeeded) in the native implementation of
VMClassLoader.loadClass. I had to skip this call when the loaded class
was coming from java.lang.** since the definePackageIfNeeded was using
java.lang.** classes and we would run into an infinite loop else. The
definePackageIfNeeded is taking a class name as parameter and extract
the package name and then defines the package using default values for
vendor and such (like the reference <clinit> of VMClassLoader) if it's
not defined yet.
Since java.lang.** packages can not be defined by this method, I
overrided the getBootPackages reference method to return the
java.lang.** packages (which are then defined by the <clinit>)
Please find attached the hack I did on my environment (which I do not
consider to be usable but a working proof of concept) as a support of my
explanations.
This looks complex compared to the (native - should be) getBootPackages
method.
Maybe I'm missing something, but all of this can be solved by implementing
the getBootPackages on the VM side.
Best,
Nicolas
