Problems building kawa on rawhide with ecj-on-gcj

[Anthony Green]

I can't build kawa on rawhide (gcj 4.1.2) due to errors like the 
following....

     [javac] 1. ERROR in 
/home/BUILD/kawa-1.9.1/gnu/lists/PrintConsumer.java (at line 9)
     [javac]     public class PrintConsumer extends PrintWriter
     [javac]                  ^^^^^^^^^^^^^
     [javac] Exception IOException in throws clause of 
Writer.append(CharSequence, int, int) is not compatible with 
PrintWriter.append(CharSequence, int, int)

And, indeed, our PrintWriter.append methods don't throw IOException.

Is this a bug?

AG

[Andrew Haley]

Anthony Green writes:
>  I can't build kawa on rawhide (gcj 4.1.2) due to errors like the
>
>  following....
>  
>       [javac] 1. ERROR in 
>  /home/BUILD/kawa-1.9.1/gnu/lists/PrintConsumer.java (at line 9)
>       [javac]     public class PrintConsumer extends PrintWriter
>       [javac]                  ^^^^^^^^^^^^^
>       [javac] Exception IOException in throws clause of 
>  Writer.append(CharSequence, int, int) is not compatible with 
>  PrintWriter.append(CharSequence, int, int)
>  
>  And, indeed, our PrintWriter.append methods don't throw IOException. 
The PrintWriter.append methods in OpenJDK don't either.
PrintWriter.append(c) calls out.write(c), which catches IOException
and doesn't re-throw it.

>  Is this a bug? 
IMO no.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Anthony Green]

Andrew Haley wrote:
>  The PrintWriter.append methods in OpenJDK don't either.
>  PrintWriter.append(c) calls out.write(c), which catches IOException
>  and doesn't re-throw it.
>  
>   > Is this a bug?
>  
>  IMO no. 
So it's a compiler bug?  Something must be wrong somewhere...

AG

[Andrew Haley]

Anthony Green writes:
>  Andrew Haley wrote:
>  > The PrintWriter.append methods in OpenJDK don't either.
>  > PrintWriter.append(c) calls out.write(c), which catches IOException
>  > and doesn't re-throw it.
>  > 
>  >  > Is this a bug?
>  > 
>  > IMO no.
>  
>  So it's a compiler bug?  Something must be wrong somewhere... 
It's a bug in kawa.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Andrew Haley]

Andrew Haley writes:
>  Anthony Green writes:
>   > Andrew Haley wrote:
>   > > The PrintWriter.append methods in OpenJDK don't either.
>   > > PrintWriter.append(c) calls out.write(c), which catches IOException
>   > > and doesn't re-throw it.
>   > > 
>   > >  > Is this a bug?
>   > > 
>   > > IMO no.
>   > 
>   > So it's a compiler bug?  Something must be wrong somewhere...
>  
>  It's a bug in kawa. 
 
Sorry, misspoke.  Perhaps a bug in ecj.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Mark Wielaard]

Hi Anthony,

On Mon, 2007-10-15 at 07:28 -0700, Anthony Green wrote:
>  Andrew Haley wrote:
>  > The PrintWriter.append methods in OpenJDK don't either.
>  > PrintWriter.append(c) calls out.write(c), which catches IOException
>  > and doesn't re-throw it.
>  > 
>  >  > Is this a bug?
>  > 
>  > IMO no.
>  
>  So it's a compiler bug?  Something must be wrong somewhere... 
I suspect this is a 1.4/1.5 issue. PrintWriter extends Writer which
implements Appendable in 1.5 which is has return type Appendable (which
means Writer in Writer itself). Which means that it has a covariant
return type. In the case of PrintWriter there are actually 3 methods,
one that returns type PrintWriter and two "invisible" bridge methods
with return types Appendable and Writer. If you look with jcf-dump you
will notice that the bridge method does throw the IOException, while the
variant that returns an Appendable doesn't. The compiler, in 1.4
compatibility mode, doesn't know about covariant return types and checks
your code against the wrong variant.

Bottom line, your source code is not compatible with the 1.5 core
classes (the change is binary compatible though, so if you don't
recompile things should work - which I expect isn't an option for a
Fedora package). You might have to compile with an explicit -1.5 to get
the compiler to handle the bridge methods correctly and pretend your
code is 1.5 source code (hoping that doesn't trigger some other source
incompatibility).

Cheers,

Mark

[Anthony Green]

Mark Wielaard wrote:
>  Bottom line, your source code is not compatible with the 1.5 core
>  classes (the change is binary compatible though, so if you don't
>  recompile things should work - which I expect isn't an option for a
>  Fedora package). You might have to compile with an explicit -1.5 to get
>  the compiler to handle the bridge methods correctly and pretend your
>  code is 1.5 source code (hoping that doesn't trigger some other source
>  incompatibility). 
I just compiled it all with "gcj -C" and all appears to be good.

Thanks,

AG

[Mark Wielaard]

On Tue, 2007-10-16 at 14:42 -0700, Anthony Green wrote:
>  Mark Wielaard wrote:
>  > Bottom line, your source code is not compatible with the 1.5 core
>  > classes (the change is binary compatible though, so if you don't
>  > recompile things should work - which I expect isn't an option for a
>  > Fedora package). You might have to compile with an explicit -1.5 to get
>  > the compiler to handle the bridge methods correctly and pretend your
>  > code is 1.5 source code (hoping that doesn't trigger some other source
>  > incompatibility).
>  
>  I just compiled it all with "gcj -C" and all appears to be good. 
O, that is good. In that case my analysis is either wrong or ecj has a
bug. The interaction between 1.5 covariant return types and 1.4 source
code is a little tricky. Maybe if you have time and have icedtea
installed then maybe you could also try compiling with the included
javac in that package. Then we might know which compiler is right.

Cheers,

Mark

[Anthony Green]

Mark Wielaard wrote:
>   Maybe if you have time and have icedtea
>  installed then maybe you could also try compiling with the included
>  javac in that package. Then we might know which compiler is right. 
I forgot to mention that I had tried that and the IcedTea javac compiles 
it as well.

AG