RFR [9] 8071472: Add field setter API for setting final fields in readObject

[Peter Levart]

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