SUGGESTED FIX
A webrev of this fix is available at the following URL:
http://hg.openjdk.java.net/jdk7/tl/langtools/rev/abe992640c5a
|
|
|
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?
|
|
|
EVALUATION
One more:
class T6390045c {
Class<?> v = void.class;
}
|
|
|
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.
|
|
|
EVALUATION
Probably a problem with inference.
|
|
|
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
|
|
|
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; }
}
|
|
|