FYI: Before Harmony build file set ecj as default compiler, there was
some discussion in the list related to ReferenceQueue generics issue for
javac here:
http://www.mail-archive.com/[email protected]/msg16132.html
Stefano Mazzocchi wrote:
Nataly Naumova wrote:
Hi all!
Recently I've found out that our classlib is not buildable with the
common javac's. I've tested with SUN and Bea ones, and the result was
negative. The log is :
-compile:
[javac] Compiling 3075 source files to
D:\nsnaumov\test\Harmony-classlib-src_20061129_0000\build\classes
[javac]
D:\nsnaumov\test\Harmony-classlib-src_20061129_0000\modules\awt\src\main\java\common\org\apache\harmony\awt\gl\font\FontManager.java:805:
inconvertible types
[javac] found : java.lang.ref.Reference<capture of ? extends
java.awt.peer.FontPeer>
[javac] required:
org.apache.harmony.awt.gl.font.FontManager.HashMapReference
[javac] while ((r = (HashMapReference)queue.poll()) != null) {
[javac] ^
[javac]
D:\nsnaumov\test\Harmony-classlib-src_20061129_0000\modules\swing\src\main\java\common\javax\swing\text\html\StyleSheet.java:818:
reference to removeAttributes is ambiguous, both method
removeAttributes(javax.swing.text.AttributeSet,java.util.Enumeration<?>)
in javax.swing.text.StyleContext and method
removeAttributes(javax.swing.text.AttributeSet,javax.swing.text.html.StyleSheet.NameConverterEnumeration)
in javax.swing.text.html.StyleSheet match
[javac] return removeAttributes(old, new
NameConverterEnumeration(old, rem));
[javac] ^
[javac]
D:\nsnaumov\test\Harmony-classlib-src_20061129_0000\modules\swing\src\main\java\common\javax\swing\text\html\StyleSheet.java:823:
reference to removeAttributes is ambiguous, both method
removeAttributes(javax.swing.text.AttributeSet,java.util.Enumeration<?>)
in javax.swing.text.StyleContext and method
removeAttributes(javax.swing.text.AttributeSet,javax.swing.text.html.StyleSheet.NameConverterEnumeration)
in javax.swing.text.html.StyleSheet match
[javac] return removeAttributes(old, new
NameConverterEnumeration(names));
[javac] ^
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 3 errors
It seems that there is a bug in Eclipse compiler. If we bring the
second situation to the simplier one there will be a small testcase
here :
A.java:
interface A<T> {
}
B.java:
class B {
void remove(A<?> x) {
}
}
C.java:
class C extends B {
void test() {
remove(new D());
}
void remove(D x) {
}
private static final class D implements A {
}
}
These sources are successfully compiled by ejc.jar, but cause the
compile-time error with SUN or BEA javac -
####
C.java:3: reference to remove is ambiguous, both method remove(A<?>)
in B and method remove(C.D) in C match
remove(new D());
^
1 error
###
The question is: Is such situation applicable for Harmony? If no -
should we file a bug against Eclipse compiler?
I'm sure the eclipse compiler people would be interested to know this
difference in behavior not matter what.
What does jikes say?
--
Paulex Yang
China Software Development Lab
IBM
