JDK-8161013 : Never treat anonymous classes as 'final'
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u60,9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-07-07
  • Updated: 2016-08-10
  • Resolved: 2016-07-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b128Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Per JDK-8161009, an assertion in JLS that anonymous classes are 'final' is incorrect, due to inconsistency with longstanding behavior.  Anonymous classes should not be considered 'final'.

javac generally does not do so, but there are two bugs:
- In an attempt to conform to the old JLS without fully doing so, JDK-6219964 and JDK-6520152 set the 'final' flag during checking, then unset it.  Wanted behavior is to simply leave it unset.
- The logic to unset ACC_FINAL during code gen accidentally leaves it set on 'access_flags' (but not 'inner_class_access_flags') for anonymous classes in static contexts.

Example of the first bug:

    interface I {}
    
    Object o = new Object() {
        I i = (I) this; // expected: ok; actual: cast error
    };

Example of the second bug:

    class C {
        static Object o = new Object() {};
    }

    javac C.java
    javap -verbose C\$1

    final class C$1 <--- expected: not 'final'
      minor version: 0
      major version: 52
      flags: ACC_FINAL, ACC_SUPER <--- expected: not ACC_FINAL
    ...
    InnerClasses:
         static #2; //class C$1 <--- as expected: not 'final'

Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/22e5938706c2 User: amurillo Date: 2016-07-20 16:26:21 +0000
20-07-2016

URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/22e5938706c2 User: dlsmith Date: 2016-07-14 18:08:05 +0000
14-07-2016

There should be no source incompatibility in the fix for cast checking, because this only has the effect of expanding the set of legal casts. This suggests that it's safe to make the change a pure bug fix, rather than treating it as a language change guarded by "-source".
07-07-2016