Re: Object serialization and final fields

[Guilhem Lavaux]

Mark Wielaard wrote:
> Hi,

Hi Mark !

> On Thu, 2004-03-25 at 21:19, Guilhem Lavaux wrote: 
>
> > Some people has reported failures in kaffe with applications trying to 
> > deserialize objects containing final fields. Apparently it is authorized 
> >  in the serialization spec but we cannot rely on 
> > java.lang.reflect.Field to set them. So our only solution is to bypass 
> > the protection in java.lang.reflect.Field by creating new native calls 
> > in ObjectStreamField.
> >
> > I am proposing the following changes for ObjectStreamField.
>
>
> It is a bit sad that serialization needs a couple of things that clearly
> should have been standard reflection methods/options. Sigh.
>
> I like the idea in general.
> Couple of comments/questions.
>
> - ChangeLog entry is missing...
Well, it was not a final patch but just to open up the discussion.

> > @@ -64,7 +65,7 @@
> >   {
> >     this (field.getName(), field.getType());
> >     this.field = field;
> > -    toset = !Modifier.isFinal(field.getModifiers());
> > +    //toset = !Modifier.isFinal(field.getModifiers());
> >   }
>
>
> Either remove this or make it a real comment explaining why we don't
> test this anymore.

Ok, will do it asap.

> >   /**
> > @@ -353,11 +354,14 @@
> >     return "ObjectStreamField< " + type + " " + name + " >";
> >   }
> >
> > +  final private native void setBooleanNative(Object obj, boolean val) 
> > +    throws IllegalAccessException;
> > +
>
>
> This and the other setXXXNative methods should be moved to
> VMObjectStreamClass. You should also provide sample JNI implementations
> for this in native/jni/java-io/java_io_VMObjectStreamClass.c
> (Note that VmSystem.c has examples for this. See VMSystem
> setIn/Out/Err())
>
> Maybe make them static and also provide the field object?

I'll do as requested but concerning java_io_VMObjectStreamClass.c I 
would like to propose something else.
After more experimentation, I would have preferred to have some private 
internal methods in java.lang.reflect.Field which we could call directly 
from native code. These calls should not check whether a field is final 
or not but just try to set it. The other usual methods of Field 
(get/set) should check the final bit and call the internal methods 
afterwards.

If it's not possible I will borrow some code from native Field 
implementation.

> >   final void setBooleanField(Object obj, boolean val)
> >   {
> >     try
> >       {
> > -       field.setBoolean(obj, val);
> > +       setBooleanNative(obj, val);
> >       }
> >     catch(IllegalAccessException x)
> >       {
>
>
> Do we want to use the new method unconditionally or only when the field
> is final?

Would it be useful ? I think it would only eat CPU as we always need to 
set fields.

Cheers,

Guilhem.