JDK-7005095 : Cast: compile reject sensible cast from final class to interface
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2010-12-07
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 7
7 b123Fixed
Related Reports
Relates :  
JDK-6932571 - Compiling Generics causing Inconvertible types
Relates :  
JDK-6557279 - Tweak provable distinctness
Relates :  
JDK-6270073 - Specification of casts involving final type is too strict
Description
After fix of 6932671 the compiler rejects the following code:

class JavaApplication6 {

    public static <T extends CharSequence> Foo<T> createDeclarationUID(T declaration) {
        return (Foo<T>) new FooImpl();
    }

    public interface Foo<T> {
        
    }
    
    public static final class FooImpl implements Foo<String> {
        
    }
}
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/build/langtools/rev/5ef88773462b
25-12-2010
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5ef88773462b
09-12-2010
WORK AROUND Drop 'final' from the class declaration.
07-12-2010
EVALUATION The program is now rejected as per JLS 5.5 - in a cast from S to T: "If T is an interface type: [...] If S is a final class, then S must implement T or a compile-time error occurs" The compiler used to be a bit non-deterministic when compiling such things - now the behavior is more regular (and compliant with the JLS). If 'final' is removed, the compler accepts the program again. Despite the compiler now conforms to the JLS, I think that the stricter implementation is not desirable, as that the JLS is at fault here by being too restrictive (as pointed out in CR 6270073). Therefore, the old compiler behavior should be restored to minimize migration risk.
07-12-2010