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
