This is the mail archive of the email@example.com mailing list for the Mauve project. See the Mauve home page for more information.
> > 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