Mark Wielaard | 25 Dec 17:06 2006

Mauve vs 1.5

Hi,

Here is the Christmas riddle for you all.

Going through the mauve diffs between GNU Classpath 0.93 and current CVS
which switched to full 1.5 language support I noticed some compilation
errors. There are 2 main failures:

When compiling mauve without the 1.5 flag there is the following issue
with anything extending java.io.Writer. e.g.:

1. ERROR in gnu/testlet/java/io/CharArrayWriter/ProtectedVars.java  line 30:
        public class ProtectedVars extends CharArrayWriter implements Testlet
                     ^^^^^^^^^^^^^
  The return type is incompatible with Writer.append(CharSequence, int, int),
CharArrayWriter.append(CharSequence, int, int)

jcf-dump shows the issue. CharArrayWriter implements Writer which
extends Appendable, but makes the return type of some methods more
specific:

Method name:"append" public Signature: (char)java.io.Writer
Method name:"append" public bridge synthetic Signature: (char)java.lang.Appendable

Without -1.5 the bridge method for the covariant return type is ignored.
Meaning that the compiler thinks that the class isn't implementing
public Appendable append(char c) as defined by the super interface
Appendable.

Now this is of course easily fixed by using -1.5 so the compiler knows
(Continue reading)

Audrius Meskauskas | 25 Dec 21:36 2006
Picon

junit.framework.Assert

Today I have discovered that junit.framework.Assert seems not 
compileable, because it twice calls the non existing methods of the 
TestHarness:
check(double, double, double).

It seems trivial to implement the workaround. Should we fix this?

Audrius.

Tom Tromey | 25 Dec 22:23 2006
Picon

Re: Mauve vs 1.5

>>>>> "Mark" == Mark Wielaard <mark@...> writes:

[ CharArrayWriter and Appendable ]
Mark> Now this is of course easily fixed by using -1.5 so the compiler knows
Mark> about covariant return types and makes all these tests that define
Mark> classes that extend some Writer class compile again.

Yes, let's do that...

Mark> But now we have another problem. Shown by anything that has implements a
Mark> retrofitted Comparable<T> interface like Integer:

Mark> 1. ERROR in gnu/testlet/java/lang/Integer/compareTo.java  line 98:
Mark>         harness.check(zero.compareTo(o) == 0);
Mark>                            ^^^^^^^^^
Mark>   The method compareTo(Integer) in the type Integer is not applicable for the arguments (Object)

In this code, 'o' is just 'zero' cast to an Object.

You could just change it to use compareTo(zero), but that doesn't test
the same thing...

You could change it to:

harness.check(((Comparable) zero).compareTo(o) == 0);

This will check using the raw Comparable and preserve the meaning of
the test, more or less.

Tom
(Continue reading)

Mark Wielaard | 27 Dec 16:31 2006

Re: junit.framework.Assert

Hi Audrius,

On Mon, 2006-12-25 at 21:36 +0100, Audrius Meskauskas wrote:
> Today I have discovered that junit.framework.Assert seems not 
> compileable, because it twice calls the non existing methods of the 
> TestHarness:
> check(double, double, double).
> 
> It seems trivial to implement the workaround. Should we fix this?

Yes, please. I just noticed this today. I assume this class isn't
compiled in the default Makefile/Harness implementation. But it is bad
to have non-compilable classes in the tree (makes some IDEs like Eclipse
really unhappy).

Cheers,

Mark

Mark Wielaard | 27 Dec 16:46 2006

Re: Mauve vs 1.5

Hi Tom,

On Mon, 2006-12-25 at 14:23 -0700, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@...> writes:
> 
> [ CharArrayWriter and Appendable ]
> Mark> Now this is of course easily fixed by using -1.5 so the compiler knows
> Mark> about covariant return types and makes all these tests that define
> Mark> classes that extend some Writer class compile again.
> 
> Yes, let's do that...
> 
> Mark> But now we have another problem. Shown by anything that has implements a
> Mark> retrofitted Comparable<T> interface like Integer:
> 
> Mark> 1. ERROR in gnu/testlet/java/lang/Integer/compareTo.java  line 98:
> Mark>         harness.check(zero.compareTo(o) == 0);
> Mark>                            ^^^^^^^^^
> Mark>   The method compareTo(Integer) in the type Integer is not applicable for the arguments (Object)
> 
> In this code, 'o' is just 'zero' cast to an Object.
> 
> You could just change it to use compareTo(zero), but that doesn't test
> the same thing...
> 
> You could change it to:
> 
> harness.check(((Comparable) zero).compareTo(o) == 0);
> 
> This will check using the raw Comparable and preserve the meaning of
(Continue reading)

Roman Kennke | 28 Dec 16:39 2006

Re: junit.framework.Assert

Hi there,

Am Montag, den 25.12.2006, 21:36 +0100 schrieb Audrius Meskauskas:
> Today I have discovered that junit.framework.Assert seems not 
> compileable, because it twice calls the non existing methods of the 
> TestHarness:
> check(double, double, double).
> 
> It seems trivial to implement the workaround. Should we fix this?

Ugh. Seems like I forgot to check this bit in when I implemented the
JUnit API in Mauve. A wonder that nobody stepped over this so far,
especially since I already checked in a bulk of tests based on the JUnit
API. Here comes the fix...

2006-12-28  Roman Kennke <kennke@...>

	* gnu/testlet/TestHarness.java
	(check(double,double,double)): New method. Tests two double values
	with a certain threshold.

/Roman

Attachment (patch.diff): text/x-patch, 2255 bytes

Gmane