RFR 8159751: ObjectStreamClass: hide 'final' flag for anonymous classes

[Roger Riggs]

Hi Dan,

On 6/23/2016 2:53 PM, Dan Smith wrote:
>> On Jun 23, 2016, at 11:37 AM, Roger Riggs <roger.riggs at oracle.com> wrote:
>>
>> Hi Dan,
>>
>> I was concerned about inter-operation between versions because serialized objects
>> are passed between Java runtimes with different versions and both need to compute
>> the same serial version uid (if it is not explicitly declared). The older java runtimes will
>> compute the serial version uid without regard to your change.
>>
>> If javac always turns on the ACC_FINAL bit and using -target 8 and then the class file
>> is executed in a Java 8 runtime, it seems like it would compute a different value
>> which would be in compatible change.  It might be safer to introduce this change
>> only with the new class file version number.
> Ugh, this is a good point.  Hadn't thought about that use case.
>
> How should we compare these two compatibility risks?:
>
> (1) Using identical class binaries on two sides of a pipe, but running different JDK versions, a class has different UIDs on the two sides.
Go back to the rationale for not including ACC_FINAL in the modifiers 
used in SUID?
I'm not clear on that part (other than its a current bug, not spec 
compliant).
Reflection could report final based on the 'implicitly' final spec for 
anonymous classes.
Or reflection needs to be classfile version aware.

It is simpler to just hash whatever bits are there and not modify them.
It won't break because of compiler changes or re-compiles.

>
> (2) Using class binaries compiled from different versions of javac on two sides of a pipe, but running the same JDK versions, a class has different UIDs on the two sides.
>
> Your suggestion to use "-target" helps to reduce the likelihood of (1).  But there may still be classes that are broken in this scenario.  Some examples:
> - Really old classes that had ACC_FINAL set (it has been turned on and off once or twice in javac over the years)
> - Classes that target 9, but a bytecode rewriter converts to run on 8, without tweaking ACC_FINAL
Not your problem, different rules apply to different class file 
versions, tools need to respect/ deal with it.
> - Classes generated by other compilers (Eclipse doesn't use ACC_FINAL for anon inner classes at the moment, but what about, e.g., other languages?)
>
> As for (2), fixing this javac bug without touching ObjectStreamClass will impact all Serializable anonymous inner classes -- a much wider net.  Then again, they've received fair warning: "the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations"; and my understanding of common practice is that users who serialize anonymous classes understand that they should have identical binaries on both sides.
And javac warns about missing SerialVersionUID fields with avoids the 
problem entirely.

And its not just a javac bug, it appears that class files can vary, 
either it is allowed or
it should be/should have been a verification error.
>
> So (1) is a much narrower problem, but also more serious: users can reasonably consider a failure to serialize/deserialize with identical class binaries to be a bug; they can't really complain about a new compiler version spitting out different bytes.
I would suggest javac to produce the same ACC_FINAL bits as it did 
before for each -target version.
(I know it looks like a hack, but a compatible one).
Correct it for 9 and leave the SUID computation alone.

Consider if classes should fail verification if the bit is wrong, so 3rd 
party tools get corrected.

Roger

>
> Thoughts?
>
> —Dan