Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of natalya.s.naumova@gmail.com
 designates 64.233.184.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=oWCyiH6zQdMzGVW+e3ab6cBmVYpfWhF6u5eFqwtcsRox8hO5w+d2FxlHk7T96Z8UOoEAVspujTm/DSKX3Sfr395SKh6AQ7JL9LyxVyOMvYkVb0rp7ka4wDeMLMFvkj54k6z2PxlYxgJk9zqChSZQfhSDtvS3vIQAMmWPzXjxBpI=
Message-ID: <2c1cfe8b0611300356g39fc2d77oad6c53816711923c@mail.gmail.com>
Date: Thu, 30 Nov 2006 14:56:16 +0300
From: "Nataly Naumova" <natalya.s.naumova@gmail.com>
To: dev@harmony.apache.org
Subject: [build] Classlib is not buildable with the common javac. Is it
 correct?
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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?

Thanks.

-- 
Nataly Naumova,
Intel Middleware Products Division