On 03/25/2015 05:55 PM, Peter Levart wrote:
On 03/25/2015 04:49 PM, Chris Hegarty wrote:
I have been thinking about this and I see several solutions:
1. provide protected final methods
ObjectInputStream.checkPersistentFinalsNotSet() and
markPersistentFinalsSet() that just delegate to FieldSetterContext for
ObjectInputStream classes to call as part of their own overriden
defaultReadObject() method. We should make sure those methods are
called
in JDK's corba InputStreamHook and document they should be called in
3rd
party subclasses.
Yes, I think I agree with this, but since the FieldSetterContext is
constructed in OIS private readSerialData, there is nothing to
delegate to, unless InputStreamHook/IIOPInputStream creates the context.
Ah, I see. Let me look at this in some more detail...
Regards, Peter
Huh, this is tricky! IIOPInputStream does invoke readObject/writeObject
methods on an object being (de)serialized, but it does it on it's own.
So any classes using FieldSetter API will get an exception when
attempted deserialization with corba...
We could fix IIOPInputStream to do the right thing at the right time
(like ObjectInputStream) and provide a FieldSetter instance, but what
about any 3rd party ObjectInputStream subclasses that might do the same?
Suddenly classes using FieldSetter API will become incompatible with 3rd
party OIS implementations until those implementations catch-up.
Providing a factory for FieldSetter instance to subclasses of OIS is
giving write access to private fields of any object. Would have to be
protected by some permission. Is this acceptable?
Regards, Peter
