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) 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. So basically, I'm asking about your thought on how to make the boot class loader (which is out of range of classpath) defines packages as it load classes. TIA, cheers +Olivier P.S: the signature of definePackageIfNeeded is a String[] instead of a String because I did not manage to call the String version from cacao code, but it should be a simple String. -------------- next part -------------- A non-text attachment was scrubbed... Name: boot_class_loader.patch Type: text/x-patch Size: 3467 bytes Desc: not available Url : http://developer.classpath.org/pipermail/classpath/attachments/20060313/fe1c0a22/boot_class_loader-0001.bin
