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

[Chris Hegarty]

Just an update on this...

Checking of final fields aside, the Field Setter API, in its current 
form, has become stuck. It falls foul of the fact that ObjectInputStream 
is subclass-able, and contains almost no final methods, or at least no 
implementation that can be counted on, or appropriate hooks that can be 
used.

In its current form, the FieldSetter context is created just before the 
readObject callback, and subsequently rendered effectively useless after 
the callback. This is an important part of the design as it limits the 
ability to setting final fields to the object currently being 
deserialized, and just during the execution of the readObject method. 
There is no, straight forward, way to create the FieldSetter context if 
a subclass of ObjectInputStream were to override all its overridable 
methods and not invoke the equivalent superclass method. This is what 
[IIOP]InputStream[Hook] does, and is a realistic possibility for any 
external third party ObjectInputStream implementation.

So, without any modification a third party ObjectInputStream could not 
retrieve the FieldSetter. The API would have to return null, or throw 
UOE ( or similar ). Therefore the API becomes optional, and cannot be 
reliable used in readObject implementations, that need to be 
reconstructible by any ObjectInputStream.

Note: it is possible to add a suitably protected mechanism to allow 
subclasses to create the FieldSetter context, but again that would be 
opt-in ( it would require third party ObjectInputStream implementations 
to change their code ).

Peter and I are still investigating other, more exotic, possibilities, 
but nothing concrete so far.

-Chris.


On 25/03/15 22:24, David M. Lloyd wrote:
> ....
>
> I think this is a sign that this extra check isn't really appropriate,
> or maybe isn't in the appropriate place.  Having a run time check here
> is just "weird", for lack of a better word, given that the equivalent
> constructor check is compile-time.  The author of a class can already
> determine whether they are setting all the fields they want to set; it's
> not like there's generally going to be a confluence of multiple players
> contributing to the set of final fields, or some other complex situation
> like that.
>
> Put another way - the FieldSetter API doesn't *need* this extra check in
> order to justify its existence, especially given these complications. If
> we're just looking for something to replace using reflection to hack in
> final field values, then just having a proper API to do it is already
> enough of an improvement in my mind that I believe that the extra check
> can (and should) be considered as a separate enhancement on top of it,
> if it *must* be considered at all.
>