JDK-8159751 : ObjectStreamClass: hide 'final' flag for anonymous classes
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2016-06-16
  • Updated: 2016-07-07
  • Resolved: 2016-07-07
Related Reports
Blocks :  
JDK-8129576 - Anonymous classes are not final according to reflection API
Description
Anonymous inner classes are supposed to be marked ACC_FINAL, but have not been for many years. See JDK-8129576.

The main reason the compiler behavior has not been fixed is due to concern that doing so will change the serialization UIDs for all anonymous classes, and this is an unnecessary incompatible change.

After discussion, the proposal is to modify the serialization spec, and its implementation in ObjectStreamClass, so that the flags for anonymous classes (per Class.isAnonymousClass) always exclude ACC_FINAL, regardless of its actual setting. This will allow compiler behavior to be corrected without perturbing UIDs.
Comments
Per the previous discussion, closing as Won't Fix. An incompatible change to the serialization spec is not viable.
07-07-2016
An additional complication: when serialization uses identical class files, but different *JDK versions* on the two sides, this change will produce incompatible serialVersionUIDs. The use case is somewhat narrow, but a serious concern when it occurs: the binary class must be anonymous (per Class.isAnonymousClass) and have ACC_FINAL set in 'inner_class_access_flags'. Most classes will not look like this -- javac hasn't been setting ACC_FINAL -- but there are reasonable, valid cases: - Anonymous classes compiled by javac before JDK 1.3 - Classes modified by tools that decide to add ACC_FINAL - Classes generated by other Java compilers (though recent Eclipse matches javac), or other languages' compilers It's probably not tolerable to blow up on these classes when identical binaries are present on both sides of serialization. (For example: some users who archive objects on disk with serialization also archive the binaries. They could reasonably expect to load these classes and read in the objects using a 9 JDK.) Generalizing, the serialVersionUID algorithm is a contract between Java SE versions, and so can't really change between versions (unless the change only applies to unique features of class files in the new version).
24-06-2016
Proposed change to the Java Object Serialization Specification, Section 4.6: "The serialVersionUID is computed using the signature of a stream of bytes that reflect the class definition. ... The values input to the stream are defined by the Java Virtual Machine (VM) specification for classes. Class modifiers may include the ACC_PUBLIC, ACC_FINAL, ACC_INTERFACE, and ACC_ABSTRACT flags; other flags are ignored and do not affect serialVersionUID computation. ***If the class is an anonymous class, as defined by java.lang.Class.isAnonymousClass, then the ACC_FINAL flag is also ignored.*** Similarly, for field modifiers, ..."
21-06-2016
Tested Eclipse behavior (recent versions): it, too, leaves ACC_FINAL unset for anonymous classes.
16-06-2016