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

[Chris Hegarty]

On 17/03/15 13:42, Alan Bateman wrote:
> On 17/03/2015 12:21, Peter Levart wrote:
>>
>> Hi Alan,
>>
>> I agree that not calling defaultReadObject() from readObject() and
>> having a final field is potentially a bug. But need not be in case
>> some other means of setting final fields was used (Unsafe or
>> reflection). Some readObject() implementations in base module that
>> Chris changed to use new API fall into this category. We can't track
>> those usages, so to keep backwards compatibility, this checking has to
>> be opt-in. Is there a more elegant way to opt-in? A
>> @CheckFinalsAssignment annotation on the readObject() method?
> I'm not sure that an annotation is right here. Instead then it might
> work as a method on FieldSetter to enable strict checking.

Peter suggested a method on FieldSetter to enable strict checking before 
too, and at the time I pushed back. After this discussion, I've come 
full circle, and maybe this opt-in style method is a reasonable 
compromise. Something like:

  /**
   * Checks that all final instance fields, declared by the class where
   * the {@code readObject} callback is being invoked, have been set.
   *
   * <p> This method is intended to be called as a final step after all
   * final instance fields have been set.
   *
   * @throws InvalidObjectException if one, or more, final instance
   *         fields have not been set
   */
  void checkAllFinalsSet() throws InvalidObjectException;


...and the user code would look similar to this, from java.io.File:

   s.fieldSetter().set("path", p)
                  .set("prefixLength", pLen)
                  .checkAllFinalsSet();

-Chris.