Jeroen Frijters writes: > 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().
All of this is fairly ill-specified. ClassLoader.loadClass() can to cope with "[I", for example, and there is extant application code that requires it. That's how I discovered the same incompatibility that you've found. This may be a bug, or perhaps just a side-effect of a particular implementation. Is there a strong reason to prefer fixing all the clients of loadClass() ? There doesn't seem to be any strong specification reason to do so. Andrew. _______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
