harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [build] Classlib is not buildable with the common javac. Is it correct?
Date Thu, 30 Nov 2006 13:32:48 GMT
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?

-- 
Stefano.


Mime
View raw message