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

[Dan Smith]

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

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

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.

Thoughts?

—Dan