United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6390045 Unexpected error "cannot access java.lang.Void" with '-target cldc1.0' with -source >=1.5
JDK-6390045 : Unexpected error "cannot access java.lang.Void" with '-target cldc1.0' with -source >=1.5

Details
Type:
Bug
Submit Date:
2006-02-24
Status:
Closed
Updated Date:
2014-02-27
Project Name:
JDK
Resolved Date:
2012-01-13
Component:
tools
OS:
solaris_9
Sub-Component:
javac
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u1
Fixed Versions:

Related Reports
Relates:

Sub Tasks

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
EVALUATION

Probably a problem with inference.
                                     
2006-02-24
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
                                     
2006-02-24
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; }
}
                                     
2006-02-24
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.
                                     
2006-02-26
EVALUATION

One more:

class T6390045c {
    Class<?> v = void.class;
}
                                     
2006-02-27
SUGGESTED FIX

A webrev of this fix is available at the following URL:
http://hg.openjdk.java.net/jdk7/tl/langtools/rev/abe992640c5a
                                     
2009-08-11
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?
                                     
2008-11-27



Hardware and Software, Engineered to Work Together