harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [build] Classlib is not buildable with the common javac. Is it correct?
Date Thu, 30 Nov 2006 13:52:51 GMT
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/harmony-dev@incubator.apache.org/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



Mime
View raw message