Eclipse, Java 1.5 and StringBuffer

Hello,

Java 1.5(for whatever reason) has added covariant return types ie

C:\>javap java.lang.StringBuffer
Compiled from "StringBuffer.java"
public final class java.lang.StringBuffer extends
java.lang.AbstractStringBuilder implements
java.io.Serializable,java.lang.CharSequence{
...
public synchronized java.lang.StringBuffer append(char);
...
public java.lang.AbstractStringBuilder append(char);
...
public java.lang.Appendable append(char) throws
java.io.IOException;
....
}

The eclipse compiler chooses the last one of these meaning the code
will not compile if it does not catch the IOException.

Does anyone have a workaround?

- Robert

On Mon, 29 Mar 2004 09:30:08 GMT, Robert Colquhoun <rjc@trump.net.au>
wrote:

>Does anyone have a workaround?
Upgrade to Eclise M8

Robert Colquhoun wrote:

> C:\>javap java.lang.StringBuffer
> Compiled from "StringBuffer.java"
> public final class java.lang.StringBuffer extends
> java.lang.AbstractStringBuilder implements
> java.io.Serializable,java.lang.CharSequence{
> ...
>     public synchronized java.lang.StringBuffer append(char);
> ...
>     public java.lang.AbstractStringBuilder append(char);
> ...
>     public java.lang.Appendable append(char) throws
> java.io.IOException;
> ....

I can't suggest a workaround (other than not trying to use 1.5 classfiles wi
th
a pre-1.5 compiler ;-).

I'm more interested in *why* the compiler has generated that third method at
all.  I can see why it'd generate the first two, but the third seems
unnecessary.

Presumably it's something to do with the fact that it has generated a simila
r
method for AbstractStringBuilder, but I can't see why it's done *that*
either...

A bug ?

-- chris

Hello Brian,

On Mon, 29 Mar 2004 15:24:51 +0200, Brian Skaarup
<brian@nocannedmeat.skaarup.org> wrote:

>On Mon, 29 Mar 2004 09:30:08 GMT, Robert Colquhoun <rjc@trump.net.au>
>wrote:
> 
>Upgrade to Eclise M8

I have been trying to, all yesterday tried to download it from sole
australia mirror but it kept dropping out around 50mb or so.

I think i need  a download manager of some sort.

Currently i am using 2.1.3 which was only released a couple of ws
ago obviously they are not going to add 1.5 support to the 2.1 series.

- Robert

Hello Chris,

On Tue, 30 Mar 2004 10:30:03 +0100, "Chris Uppal"
<chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
>Robert Colquhoun wrote: 
>
>I can't suggest a workaround (other than not trying to use 1.5 classfiles w
ith
>a pre-1.5 compiler ;-).

Yes also might need careful if using a 1.5 compiler targetted for
older jvms.

>I'm more interested in *why* the compiler has generated that third method a
t
>all.  I can see why it'd generate the first two, but the third seems
>unnecessary.

The first is StringBuffer original method(the one i want to link to.

The second is to implement the AbstractStringBuilder interface.

The third is to implement the java.lang.Appendable interface which is
pulled in via AbstractStringBuilder.


>Presumably it's something to do with the fact that it has generated a simil
ar
>method for AbstractStringBuilder, but I can't see why it's done *that*
>either...
>
>A bug ?

No i think they are trying to post-fix problems in the orginal
StringBuffer class ie synchronized methods not fitting being able to
substitute another class instead of StringBuffer implementation(no
interface).

It is kind of looking a bit of a mess now though.

- Robert

Robert Colquhoun wrote:
 
>
> The first is StringBuffer original method(the one i want to link to.
>
> The second is to implement the AbstractStringBuilder interface.
>
> The third is to implement the java.lang.Appendable interface which is
> pulled in via AbstractStringBuilder.

But the last is unecessary.  At least, *I* don't understand why the compiler
thinks it needs to generate it (or even why it thinks it is *allowed* to
generate it).


> It is kind of looking a bit of a mess now though.

I agree -- though I suspect we are talking about slightly different things ;
-)

-- chris