Re: mauve comparison with tgolem

[Mark Wielaard]

Hi Edwin,

On Mon, 2005-11-28 at 14:54 +0100, Edwin Steiner wrote:
> On Sat, Nov 26, 2005 at 02:01:53AM +0100, Mark Wielaard wrote:
> > If it is in addition to what there is now already just the plain FAIL
> > lines would be ideal to have. No extras, just the facts! :)
> 
> You can now get a text-only list of common mauve fails at:
> 
>     
> http://www.complang.tuwien.ac.at/cacaojvm//tgolem/latest/mauve_common_fails.txt

Very interesting list. Thanks.

Quick analysis for those test that I know why they fail. Maybe others
can take a look at the failures and quickly see whether there is a
simple explanation or not for these failures.

FAIL: gnu.testlet.java.io.File.newFile: getname returns the argument (number 3)

Strange... I highly suspect that PlatformHelper is to blame since it
tries to bridge any windows vs posix style file path issues. In practice
is seems to fail miserably however...

FAIL: gnu.testlet.java.lang.Character.classify12 (number 1)
FAIL: gnu.testlet.java.lang.Character.getType (number 11)
FAIL: gnu.testlet.java.lang.Character.getType (number 20)
FAIL: gnu.testlet.java.lang.Character.getType (number 22)

These fail because GNU Classpath provides Character based on a newer
version of Unicode then what is being tested in Mauve.

FAIL: gnu.testlet.java.lang.Package.getPackage: checking package for 
'java.lang' (number 1)

Needs runtime support. See NEWS file:

* Changed implementation of VMClassLoader.getPackage(s) : new method
  VMClassLoader.getBootPackages should be implemented by the vm, and sould
  return a string array of boot package names ("java.lang", "java.net", ...).
  Feedback from vm implementors for usability and relevance of the
  getBootPackages method would be greatly appreciated.

FAIL: gnu.testlet.java.nio.channels.FileChannel.map (number 1)

Seems like a real bug, but fixing it (throwing the right exception)
seems to trigger another bug. Needs investigation.

FAIL: uncaught exception loading gnu.testlet.java.lang.Class.pkg.test1:
java.lang.IllegalAccessException: gnu.testlet.java.lang.Class.pkg.test1
has an inaccessible constructor
FAIL: uncaught exception loading gnu.testlet.java.lang.Class.pkg.test3:
java.lang.IllegalAccessException: gnu.testlet.java.lang.Class.pkg.test3
has an inaccessible constructor
FAIL: uncaught exception loading gnu.testlet.java.lang.Class.pkg.test4:
java.lang.IllegalAccessException: gnu.testlet.java.lang.Class.pkg.test4
has an inaccessible constructor

These are not tests and should be marked as such.
I'll submit a patch.

FAIL: uncaught exception loading gnu.testlet.java.lang.Number.NewNumber:
java.lang.IllegalAccessException: gnu.testlet.java.lang.Number.NewNumber
has an inaccessible constructor
FAIL: uncaught exception loading gnu.testlet.java.lang.reflect.Other:
java.lang.IllegalAccessException: gnu.testlet.java.lang.reflect.Other
has an inaccessible constructor

Likewise.

Hopefully we can analyze the others also in the near future. Comments
and suggestions appreciated.

Cheers,

Mark