On 03/12/2015 11:24 PM, Peter Levart wrote:
So if a readObject calls fields() without calling defaultReadObject()
then it has to set every final field. On one hand that ensures that
every final field is set, on the other hand it is a bit odd because
omitting the call to fields() means they all get their default value.
If fields() is not called, we must be backwards-compatible.
But yes, this constraint is questionable. On one hand it tries to
mimic the assignment to final fields in constructors, but it can't go
all the way, as read access to final fields in readObject() is not
limited to just those that have already been assigned (like it is in
constructor with definitive assignment rules). We could add get()
methods to FieldAccess that would constraint the reads of final fields
to those that have already been assigned, but that is just like
"advisory locking" - we can only advise users to use FieldAccess to
read fields in readObject() but we can't prevent them from reading
them directly.
So if this doesn't have much sense and brings confusion, it can go away.
...or it can stay in part where we check that a final field is not set
more than once, which can help especially when use of FieldAccess API is
combined with defaultReadObject(). The final check that all finals have
been assigned can be made optional by an explicit call to a method
(FieldAccess.checkAllFinalsSet() for example).
Regards, Peter