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.
