classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [cp-patches] RFC: RMI Class loader fix


From: Jeroen Frijters
Subject: RE: [cp-patches] RFC: RMI Class loader fix
Date: Tue, 26 Jul 2005 11:45:03 +0200

Andrew Haley wrote:
> Tom Tromey writes:
>  > >>>>> "Jeroen" == Jeroen Frijters <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]