JDK-6390045 : Unexpected error "cannot access java.lang.Void" with '-target cldc1.0' with -source >=1.5
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6u1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2006-02-24
  • Updated: 2014-02-27
  • Resolved: 2012-01-13
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 b70Fixed
Related Reports
Relates :  
JDK-6548418 - Fatal Error: Unable to find method initCause
Description
javac -J-fullversion
java full version "1.6.0-rc-b69"

javac -target cldc1.0 -bootclasspath ./j2me_cldc1.1_classes.jar -d trash src/Tester_15505.java
src/Tester_15505.java:40: cannot access java.lang.Void
class file for java.lang.Void not found
        Object var_14 = var_7 == (6505230139759204352L + (short)(-var_5 % 1256671249)) % (~5915668766487726080L + var_5) | true ? (new Object[var_5][var_5])[var_5][var_2] : (new short[var_5][var_2][var_2])[var_2 >>= 1320245342179237888L]; /* 14 */


OK with '-source 1.3' or '-source 1.4'

Attached: Tester_15505.java  and j2me_cldc1.1_classes.jar
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/abe992640c5a
11-08-2009
EVALUATION As suggested by Peter, the problem is that for javac void is a type that can be boxed (this has nothing to do with the JLS); because of that, Symtab puts void into the boxedName table, so that Types.boxedClass will complete java.lang.Void at the first attempt of boxing (not necessarily regarding void - the code in type iterates over all the entries in Symtab.boxedName). In order to fix this, we could remove void from the boxedName table. This works in most cases, however the fix doesn't help in the following case: class Foo { Class c = void.class; } I guess that, since almost nobody uses 'void.class', this issues has never been discovered - however I cannot think of a solution that would prevent an error when the above code is compiled against the cldc classes - javac generate the same patterrn for 'void.class' since jdk 1.1 (!!) that is: 5: getstatic #5; //Field java/lang/Void.TYPE:Ljava/lang/Class; 8: putfield #6; //Field c:Ljava/lang/Class; And this does require java.lang.Void in order to function properly - perhaps java.lang.Void should be added to cldc?
27-11-2008
EVALUATION One more: class T6390045c { Class<?> v = void.class; }
27-02-2006
EVALUATION Nothing to do with inference. Problem is autoboxing, while not as defined in the JLS, the compiler creates a boxing conversion from void to java.lang.Void and thus tries to read it.
26-02-2006
EVALUATION The compiler crashes on this example: class T6390045 { short s; Object o; Object p = choose(o, s); <T> T choose(T t1, T t2) { return t1; } }
24-02-2006
EVALUATION Here is a smaller example: class T6390045 { boolean b; short s; Object o; Object p = b ? o : s; } $ javac -XDfailcomplete=java.lang.Void T6390045.java T6390045.java:5: cannot access java.lang.Void user-selected completion failure by class name Object p = b ? o : s; ^ 1 error
24-02-2006
EVALUATION Probably a problem with inference.
24-02-2006