This is the mail archive of the mauve-discuss@sourceware.cygnus.com mailing list for the Mauve project. See the Mauve home page for more information.


[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: Character test (incomplete)



> 
> I think Godmar has run the testsuite against the Kaffe implementation
> (is that right?), but I don't know if he had to do anything special to
> the make files in order to get it to run.

Yes, I'm running the unchanged CVS tree (as of yesterday, I'm not on the
CVS submit mailing list) against Kaffe.  All I needed to do was to ensure
Kaffe's java & javac are first in my path.  Other than that, it just runs.
The only problem I had was with the .save-keys file, I pointed that already
out.  The other thing is that the echoing of shell command is somewhat
annoying, but I'm sure this will be fixed at some point.

1.0b3 fails 136 out of 505 tests, all of which are in the following
areas. That is, it passes everything with this TAGs file:

!java.beans
!java.lang.Character
!java.lang.Integer
!java.lang.Double
!java.lang.Long
!java.lang.Float
!java.lang.Math
!java.util.Random
!java.util.ResourceBundle

I ran the -debug flags (very nice) and noticed that many of these
problems are benign and might not get fixed any time soon.  For instance, 
when it says:	"got 3.1415926 expected 3.14159254" or some such
nonsense, or when it says "got 3.141e+1 expected 3.141E1".

Kaffe uses different moduli for its util.Random, so that explains the
Random failures.  The Math failures are in rint(), where I need to look
up the JLS (since Kaffe's code claims to do the right thing according
to the JLS, but it's probably wrong).

About the math stuff though:  apparently, Java defines certain output
formats that are different from what you'd get with printf's "%f".
In other words, you're forced to write your own output/conversion routines
in Java, like Sun did in 1.1 (and probably still does in Java2).  Clearly,
this adds to cross-platform compatibility.  However, it also bloats the
size of the run-time libraries, and IMO unnecessarily so.  We'll see what
happens.  Are classpath & libjava implementing their own conversion & output
routines for floating point numbers?

About the beans stuff: does this really test java.beans or does it test
certain properties of the specific classes (like java.lang.Object) that are 
used as test cases?  If the latter, placing the test in java.beans might
be misleading.

Oh, and Kaffe fails those parts of the Unicode stuff which requires unicode 
tables;  this is not yet implemented.  This seems to be pretty separable,
I might use steal classpath's implementation for my personal use should that
ever become a necessity for me.

	- Godmar