You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nataly Naumova <na...@gmail.com> on 2006/11/30 12:56:16 UTC
[build] Classlib is not buildable with the common javac. Is it correct?
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
Re: [build] Classlib is not buildable with the common javac. Is it
correct?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Can you offer a patch that makes it work on both?
geir
Nataly Naumova wrote:
> Hi again,
>
> On 12/1/06, Nathan Beyer <nb...@gmail.com> wrote:
>> What version of the JDK RI compiler are you using?
>
> I'm using javac's from:
> SUN's one:
> 1.5.0_06
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
> BEA's one:
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
> BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
> R25.0.0-75, G
> tegy singleparpar))
>
> There is the same error with SUN 1.5.0_08.
> I think it's rather ecj.jar bug than javac's one.. Such situations
> shouldn't be compiled, I'm sure that it's possible to find an exact
> place in java spec to show it.
>
> Thanks.
Re: [build] Classlib is not buildable with the common javac. Is it correct?
Posted by Nataly Naumova <na...@gmail.com>.
Hi again,
On 12/1/06, Nathan Beyer <nb...@gmail.com> wrote:
> What version of the JDK RI compiler are you using?
I'm using javac's from:
SUN's one:
1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
BEA's one:
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75, G
tegy singleparpar))
There is the same error with SUN 1.5.0_08.
I think it's rather ecj.jar bug than javac's one.. Such situations
shouldn't be compiled, I'm sure that it's possible to find an exact
place in java spec to show it.
Thanks.
--
Nataly Naumova,
Intel Middleware Products Division
Re: [build] Classlib is not buildable with the common javac. Is it correct?
Posted by Nathan Beyer <nb...@gmail.com>.
What version of the JDK RI compiler are you using? I know that there
were changes between update 7 and update 8 which fixed a compiler bug
that ECJ did not have.
I'm pretty sure it was this particular bug, as I've run into the
ReferenceQueue problem with Sun's compiler before.
-Nathan
On 11/30/06, Nataly Naumova <na...@gmail.com> 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?
>
> Thanks.
>
> --
> Nataly Naumova,
> Intel Middleware Products Division
>
Re: [build] Classlib is not buildable with the common javac. Is it
correct?
Posted by Tim Ellison <t....@gmail.com>.
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
<snip>
> The question is: Is such situation applicable for Harmony? If no -
> should we file a bug against Eclipse compiler?
No, we should be able to build with either compiler, so the difference
should be resolved. I've raised an issue(166355) with the Eclipse folk.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [build] Classlib is not buildable with the common javac. Is it
correct?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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 :
[snip]
> 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 :
>
[snip]
>
> These sources are successfully compiled by ejc.jar, but cause the
> compile-time error with SUN or BEA javac -
(because they are the same, IIRC)
>
> ####
> 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?
Yes, I think we should file a bug, but more importantly, I'm not
comfortable with being unable to build with javac - which javac were ou
testing with? There was a bug in Javac a while back, which is why we
switched over to use ECJ, IIRC.
If this is the case - that it's reflective of a bug in Javac - then we
should probably simply note which versions of sun javac to avoid.
geir
Re: [build] Classlib is not buildable with the common javac. Is it
correct?
Posted by Paulex Yang <pa...@gmail.com>.
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
Re: [build] Classlib is not buildable with the common javac. Is it
correct?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.