JDK-8013843 : 15.10.3: Array access for array-bounded capture variable
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 5.0,7,8
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-04-04
  • Updated: 2016-09-20
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.
Other
tbd_majorUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version  " 1.7.0_07 " 
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Darwin Chriss-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

A DESCRIPTION OF THE PROBLEM :
Direct array element access (within a single line) of a wildcard generic type with an array typed upper bound fails with the following compilation error:

GenericTest.java:6: error: array required, but CAP#1 found
return foo.call()[0];
                 ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object[] from capture of ? extends Object[]
1 error

The fails for me on latest 1.7, 1.8 (recent lambda build) and 1.6 but compiles correctly in 1.5:
java version  " 1.5.0_30 " 
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_30-b03-389-11M3811)
Java HotSpot(TM) Client VM (build 1.5.0_30-161, mixed mode, sharing)


REGRESSION.  Last worked in version 5.0

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Attempt to compile the source code included with this report.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A successful compilation.
ACTUAL -
Compilation fails with a non-sensical error message.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
GenericTest.java:6: error: array required, but CAP#1 found
return foo.call()[0];
                 ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object[] from capture of ? extends Object[]
1 error

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.concurrent.Callable;

public class GenericTest {
  
    public Object foo(Callable<? extends Object[]> foo) throws Exception {
return foo.call()[0];
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The following class does compile successfully in all my versions of javac (1.5, 1.6, 1.7, 1.8 (recent lambda branch build):

import java.util.concurrent.Callable;

public class GenericTest {
  
    public Object foo(Callable<? extends Object[]> foo) throws Exception {
Object[] array = foo.call();
return array[0];
    }
}
Comments
Need to be careful with the null type: it would be wrong to allow these operations on it, even though it is a subtype of Object[].
20-09-2016

If we fix the for-each case, then javac can get rid of this unspecified widening occurring in Attr.visitForEachLoop: Type exprType = types.cvarUpperBound(attribExpr(tree.expr, loopEnv))
14-12-2015

Relevant spec text from 15.10.3 in JLS 8: "The type of the array reference expression must be an array type (call it T[], an array whose components are of type T), or a compile-time error occurs." This fails to account for the possibility that the expression has a type variable type with an array upper bound. Other potentially-sensitive areas: member access (length, clone); enhanced for loop.
30-07-2014

We think that the compiler is doing the correct thing here as the type of the expression is not Array type. If the compiler should accept this code then the spec most be modified. In other case the bug can be closed, right?
23-08-2013

Reproducible with jdk8-b93
11-06-2013