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

[Alan Bateman]

On 17/03/2015 09:57, Chris Hegarty wrote:
> Peter, Alan,
>
> After further thought I think that requiring all final fields to be 
> set is reasonable behaviour. Since there is no compile time checking, 
> this is a reasonable runtime effort to catch what is likely to be 
> developer errors. To address Alan’s comments, I beefed up the API docs 
> and added examples to typical usage.
>
> Updated specdiff (and webrev):
> http://cr.openjdk.java.net/~chegar/8071472/01/ 
> <http://cr.openjdk.java.net/%7Echegar/8071472/01/>
>
> This version also includes a number of changes to readObject 
> implementations in the base module, to replace unsafe usage with this 
> field setter API.
>
>
The rename to FieldSetter looks good, also good to have an example in 
the javadoc.

It is good to catch cases where final fields aren't set but the issue is 
the surprising behavior that the check is tied to whether the 
FieldSetter has been obtained or not. The other thing is that 
fieldSetter's javadoc doesn't make this clear, you need to read 
FieldSetter's javadoc to learn about this enforcement. It's hard to know 
what the right thing to do here as ideally this enforcement would be 
enabled by default. If my class with final fields has an empty 
readObject, or it has code paths that don't call defaultReadObject for 
example, then it's a bug that I'd like to know about. I realize there is 
potential compatibility, maybe performance, impact of doing this but it 
does feel like something that I should be able to opt-in or get for free 
rather than it being a side effect.

One other thing that I wonder about is the exception and whether it 
might be better to bend InvalidObjectException instead.

-Alan