Andrew Haley wrote: > Tom Tromey writes: > > >>>>> "Jeroen" == Jeroen Frijters <[EMAIL PROTECTED]> writes: > > > > Jeroen> * java/rmi/server/RMIClassLoader.java > > Jeroen> (loadClass(String, String)): Use > Class.forName() instead of > > Jeroen> directly calling ClassLoader.loadClass(), to > handle array > > Jeroen> types correctly. > > > > Andrew, didn't we run into code that expected ClassLoader.loadClass > > to handle array signatures? > > Yes, we did. This is what the other runtimes I tried do, and it > should be fixed in ClassLoader.loadClass() in order to be compatible.
I investigated this in detail (before I discovered the RMI "bug") and I found that Sun does not, in general, support loading array classes via ClassLoader.loadClass, however they become visible thru ClassLoader.loadClass() (actually, ClassLoader.findLoadedClass()) under specific circumstances: JDK 1.4: After a class has been loaded, all arrays of the class are also available thru ClassLoader.findLoadedClass(). JDK 1.5: After a Class.forName() has been done on an array type, the specific array type becomes available thru ClassLoader.findLoadedClass(). So this means that, in general, you cannot load an array type thru ClassLoader.loadClass(). In IKVM I've chosen to be compatible with the JDK 1.4 behavior and this is part of the reason why I added the VMClassLoader.findLoadedClass() hook. I think that we should ultimately leave it up to the VM to decide how to handle this, but it may be a good idea to special case arrays in the default implementation of VMClassLoader.findLoadedClass. (Testing done on 1.4.1-b21 and 1.5.0-b64) Regards, Jeroen _______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
