RFR [9] 8071472: Add field access to support setting final fields in readObject

[Chris Hegarty]

Alan,

Thanks for taking the time to try this out.

On 12/03/15 22:24, Peter Levart wrote:
> ....
> Hi Alan,
>
>> I've spent some time looking at this and trying it out. It's very
>> simple, doesn't impact any existing readObject implementations, and
>> provides a way to set final fields without restoring to Unsafe.
>
> That was the plan. :-)

Yes, it works well.

>> 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.

Right. I think we should avoid get(..). Let's keep it simple.

> So if this doesn't have much sense and brings confusion, it can go away.

If we have consensus then I can remove this, artificial, restriction. 
Objections?

>> I think serialization types with final fields that aren't in the
>> serialized form will really like this. To help developers then it
>> might be useful to put an example in the javadoc with final &&
>> transient field to show the usage.

I added an example to the class description.

>> One other thing is naming as OIS.FieldAccess in the current patch
>> hints that it provides general access. It feels like it should be
>> something like ObjectFieldSetter with fields() changing to something
>> like fieldSetter() to make that clearer too.
>
> Or just ObjectInputStream.FieldSetter (like it is now an inner
> interface) and fieldSetter() for method. I agree, it sounds better.

I updated the sandbox based on these names.

An alternative to setter: FieldUpdater ?

    ObjectInputStream.FieldUpdater updater = in.fieldUpdater();
    updater.set(...)
           .set(...)

-Chris.