JDK-8021339 : Compile-time error during casting array to intersection
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-07-25
  • Updated: 2013-12-17
  • Resolved: 2013-10-01
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 8
8 b112Fixed
Related Reports
Relates :  
JDK-8030660 - Compile-time error in the case of ((Integer[] & Serializable)new Integer[1]).getClass()
Relates :  
JDK-8027738 - Lambda Spec: Disallow arrays in intersection cast targets
Description
The spec (jck8-jsr335-0.6.2) says:

"If S is an array type SC[], that is, an array of components of type SC:[jls-5.5.1-600]
    - If T is an intersection type, T1 & ... & Tn, then it is a compile-time error if there exists a Ti (1 <= i <= n) such that S cannot be cast to Ti by this algorithm. [jsr335-5.5.1-600-E]"

Actual behavior doesn't conforms the spec: check the following case:

	Object obj1 = (Integer[]) new Integer[1]; 

	Object obj2 = (Serializable) new Integer[1];

no compile-time errors appear in that case. Following above-mentioned assertion It's legal to use casting array to intersection:

	Object obj3 = (Integer[] & Serializable)new Integer[1];

it doesn't work and the compile-time error appears:

    java: unexpected type
    required: class
    found: java.lang.Integer[]


The following JCK tests fail due to this issue:

lang/LMBD/lmbd118/lmbd11803m341/lmbd11803m341.html
lang/LMBD/lmbd118/lmbd11803m3/lmbd11803m3.html
lang/LMBD/lmbd118/lmbd11803m141/lmbd11803m141.html
lang/LMBD/lmbd118/lmbd11803m0/lmbd11803m0.html
Comments
Per JDK-8027738, we've concluded that it is best for the specification to _not_ support arrays in intersection cast targets. So the patch for this bug should be rolled back, and this is no longer a bug.
05-11-2013
A patch has been prepared which addresses Maurizio's test, and also passes all JPRT tests. We should discuss the advantages of changing the spec vs pushing the change.
19-09-2013
Attempting to fix the failure of Maurizio's inference test suggests that implementing this properly will involve some rather nontrivial changes to the type checker logic. Given that allowing this case is of very dubious value, I think we should examine other options.
19-09-2013
Initial implementation developed and out for review
13-09-2013
Reclassifying as an enhancement, as it involves adding new functionality.
13-09-2013
Brian, It's an implementation issue. See the notes from Maurizio. javac has limited support for intersection types, which previously did not need to include arrays. Now, we are seeing situations where an array can be present in an intersection type.
03-09-2013
Dan, is this a spec issue or an implementation issue?
01-09-2013
This is a conformance issue causing JCK test failures - raising priority to P2
26-07-2013
This program also fails for very same reason (missing support for arrays in intersection types): import java.util.*; class Test { <T> T m(List<? super T> t) { } void test(List<char[]> lc) { Runnable r = m(lc); //inference fails here } }
25-07-2013
Javac does not support arrays as components of an intersection type - hence the error. Adding this kind of support would require changes to several critical javac routines, such as Types.isSubtype, Types.asSuper etc.
25-07-2013