Re: Loader in ObjectStreamClass.readClassDescriptor

[Mark Wielaard]

Hi Nicolas,

On Tue, 2005-08-02 at 14:08 +0200, Nicolas Geoffray wrote:
> Hi everyone,
> 
> sorry for the typo, it was ObjectInputStream.readClassDescriptor that 
> misbehaves.
> 
> Shortly, when a reading a given class descriptor CL, it loads the class 
> of a field from CL with the currentClassLoader on the stack. But in RMI, 
> the currentClassLoader is null, so loading the fields' classes won't 
> work for classes that are not in the bootclasspath (glibj.zip). The 
> algorithm with RMI will however succeed to load the class CL itself 
> because it uses the method resolveClass from 
> gnu.java.rmi.server.RMIObjectInputStream. The patch given fixes the 
> problem by loading the fields' class of CL with CL's classloader.

I agree it looks like we are doing something dodgy here. Using the class
loader of the class itself to resolve the field classes seems better
then using the current class loader if resolveClass() is overridden.

Do you happen to have a little testcase for this?
Either using rmi or some other class that overrides
ObjectInputStream.resolveClass(). Then we can put that in Mauve.

> While we're at it, there might also be something to change in, this 
> time, ObjectStreamClass.setClass. In the method it tries to compare the 
> serial uids bewteen the local class and the stream class. It does it for 
> all classes, even for array classes, which is wrong because array 
> classes do not have serial uids.

An array class does have a serial uid. But it is calculated slightly
differently because we have to pretend an array class does not implement
any interfaces.

> I'm also interested to know how compatible are the algorithms between 
> java and gnu classpath for computing the serial version uid? When I 
> tried to communicate a sun vm with mine, it says that my HelloWorld 
> class isn't compatible between the vms. Is that
> normal or are the algorithms compatibles and I did something wrong?

The algorithms should be compatible. But since compilers can generate
different class members (like synthetic methods or inner class names) a
class compiled with different (versions of) compilers might not have the
same serial version uid. See also:
http://www.gnu.org/software/classpath/docs/hacking.html#SEC18

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part