Re: mauve results posted nightly
Hi, On Wed, 2002-11-13 at 22:58, Stuart Ballard wrote: Brian Jones wrote: Stuart Ballard [EMAIL PROTECTED] writes: The only problem I recall is that you can't use Collections with a 1.1-only JVM due to the use of non-1.1 functionality in other packages. In my case it turned out you can run japize with any Java 2 JVM to inspect bytecode. I'm looking forward (not) to figuring out what needs improving in Kissme's reflection support so that it (a) passes all those Mauve tests and (b) can help me test Classpath's serialization compliance. Oh, so you can run japize with kissme+classpath? (japize doesn't use reflection at all any more, and I think mostly even avoids the situations where jode would use it as a fallback...) I just tried that and it seems to run with Kissme. But gij gave the following exception: Exception in thread main java.lang.RuntimeException: The SHA algorithm was not found to use in computing the Serial Version UID for class java.awt.CardLayout at net.wuffies.japi.JodeClass.getSerialVersionUID() (Unknown Source) I might have a fix for that from Raif Naffah that I will try tomorrow. (It is already in my Classpath tree so that might explain why Kissme doesn't suffer from it). The only cotcha with compiling is the referencee to org.omg.CORBA.BAD_OPERATION in JapiSerialize which seems to be save to comment out. Compiling with gcj to a native executable failed since the jode jar references some javax.swing classes. Will try to get the sources of jode later to see if they can be stripped out easily since they don't seem to be used during runtime anyway. Kissme did throw a OutOfMemoryError when trying all the java. packages. But taking a smaller subset seems to work fine. Do you have a japize example classes/arguments/output file to which I can compare my results? Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Hi, On Thu, 2002-11-14 at 21:07, Tom Tromey wrote: Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark Exception in thread main java.lang.RuntimeException: The SHA algorithm Mark was not found to use in computing the Serial Version UID for class Mark java.awt.CardLayout Markat net.wuffies.japi.JodeClass.getSerialVersionUID() (Unknown Source) Fixed in cvs :-) Thanks Tom. It was different bug then I had thought after all. It is also very fast compared with Kissme. Kissme took 1 minute and 50 seconds for only the java.util package and subpackages. gij took just 25 seconds for ALL java.* and subpackages! This is with the gij interpreter, I really want to see this when I can compile from source with -O2 :) The uncompressed results of the kissme and gij version are completely the same. But the compressed file that kissme produces seems to contain a lot of trailing garbage (gunzip complains about it but still manages to uncompress it). I haven't looked into this yet. Comparing results of a run of japizise INTERPRETER -cp \ share/java/JSX1.0.5.6.jar:share/java/jode-1.1.1.jar:share/java/japitools.jar \ net.wuffies.japi.Japize as gnu-classpath apis \ /usr/share/classpath/glibj.zip +java +javax +org (where INTERPRETER == gij || Sun j2sdk 1.4 java) produced almost identical files but there were a few small differences. I also haven't looked into this yet. (diff attached) But this is probably one of the runtimes picking up a constant from its own runtime library and not from the GNU Classpath glibj.zip file. Cheers, Mark --- gij.out 2002-11-14 22:18:50.0 +0100 +++ j2sdk.out 2002-11-14 22:18:26.0 +0100 @@ -640,7 +640,7 @@ java.lang,Compiler!wait(J,I) Pcif V*java.lang.InterruptedException java.lang,Double! Pcif class#-9172774392245257468:java.lang.Number:java.lang.Object*java.lang.Comparable*java.io.Serializable java.lang,Double!#MAX_VALUE Pcsf D:1.7976931348623157E308 -java.lang,Double!#MIN_VALUE Pcsf D:5.0E-324 +java.lang,Double!#MIN_VALUE Pcsf D:4.9E-324 java.lang,Double!#NEGATIVE_INFINITY Pcsf D:-Infinity java.lang,Double!#NaN Pcsf D:NaN java.lang,Double!#POSITIVE_INFINITY Pcsf D:Infinity @@ -757,7 +757,7 @@ java.lang,ExceptionInInitializerError!wait(J,I) Pcif V*java.lang.InterruptedException java.lang,Float! Pcif class#-2671257302660747028:java.lang.Number:java.lang.Object*java.lang.Comparable*java.io.Serializable java.lang,Float!#MAX_VALUE Pcsf F:3.4028235E38 -java.lang,Float!#MIN_VALUE Pcsf F:1.4012985E-45 +java.lang,Float!#MIN_VALUE Pcsf F:1.4E-45 java.lang,Float!#NEGATIVE_INFINITY Pcsf F:-Infinity java.lang,Float!#NaN Pcsf F:NaN java.lang,Float!#POSITIVE_INFINITY Pcsf F:Infinity @@ -24520,7 +24520,7 @@ java.security,Signer!getInfo() Pcin Ljava/lang/String; java.security,Signer!getName() Pcif Ljava/lang/String; java.security,Signer!getPrivateKey() Pcin Ljava/security/PrivateKey; -java.security,Signer!getPublicKey() Pcin Ljava/security/PublicKey; +java.security,Signer!getPublicKey() Pcin +Ljava/security/PublicKey;*java.security.KeyManagementException java.security,Signer!getScope() Pcif Ljava/security/IdentityScope; java.security,Signer!hashCode() Pcin I java.security,Signer!identityEquals(Ljava/security/Identity;) pcin Z @@ -24531,7 +24531,7 @@ java.security,Signer!setKeyPair(Ljava/security/KeyPair;) Pcif V*java.security.KeyException java.security,Signer!setPublicKey(Ljava/security/PublicKey;) Pcin V*java.security.KeyManagementException java.security,Signer!toString() Pcin Ljava/lang/String;*java.security.KeyManagementException -java.security,Signer!toString(Z) Pcin Ljava/lang/String; +java.security,Signer!toString(Z) Pcin +Ljava/lang/String;*java.security.KeyManagementException java.security,Signer!wait() Pcif V*java.lang.InterruptedException java.security,Signer!wait(J) Pcif V*java.lang.InterruptedException java.security,Signer!wait(J,I) Pcif V*java.lang.InterruptedException
Re: mauve results posted nightly
Mark Wielaard [EMAIL PROTECTED] writes: Kissme did throw a OutOfMemoryError when trying all the java. packages. But taking a smaller subset seems to work fine. Do you have a japize example classes/arguments/output file to which I can compare my results? Kissme from CVS segfaulted on me during java.io... no idea if was out of memory or not. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark It is also very fast compared with Kissme. Mark Kissme took 1 minute and 50 seconds for only the java.util package and Mark subpackages. gij took just 25 seconds for ALL java.* and subpackages! I suspect that the program spends a lot of time in the class library. That gives gij an advantage since the library is compiled. I haven't looked at Kissme's implementation. I'd be surprised if it was much slower than gij. gij is a fairly straightforward direct-threaded interpreter. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Stuart == Stuart Ballard [EMAIL PROTECTED] writes: Stuart Okay, I've posted experimental and incomplete HTMLified Stuart comparisions of Classpath vs JDK1.1, JDK1.2 and JDK1.3, linked Stuart from http://rainbow.netreach.net/~sballard/japi and Stuart regenerated nightly at around 3. Nice. Are you taking feature requests? I'd like it if the package name for a given comparison linked to detailed information about the differences in the package. I'm thinking that easy bugs (e.g., missing final, wrong protections, etc) can be fixed immediately if there is an easy way to see them. Stuart It would be really nice to get JDK1.4 in there too (I'm not Stuart sure if the big purple bar on java.sql is a false result due Stuart to adding 1.4's features or whether it's real) It's more work, but you could eliminate false problems by reading all the APIs at once and only mentioning something as an error if it disagrees with 1.4. Stuart Anyone with connections in the libgcj camp, you're welcome to Stuart post a libgcj.japi.gz file somewhere nightly and I'll do the Stuart same... It will take some time, probably a long time, but eventually I'll do this. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Mark Wielaard [EMAIL PROTECTED] writes: Kissme did throw a OutOfMemoryError when trying all the java. packages. But taking a smaller subset seems to work fine. Do you have a japize example classes/arguments/output file to which I can compare my results? Kissme from CVS segfaulted on me during java.io... no idea if was out of memory or not. Mark: Kissme will not expand the size of its heap beyond its initial size. [It is on the list of things to fix.] If you experience OutOfMemoryError exceptions, try giving it a bigger heap. The built-in help should tell you how ... Brian: How long ago did this happen? If it was within the last week, do you have time to try to reproduce the segfault and email me a stack trace? -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark Exception in thread main java.lang.RuntimeException: The SHA algorithm Mark was not found to use in computing the Serial Version UID for class Mark java.awt.CardLayout Markat net.wuffies.japi.JodeClass.getSerialVersionUID() (Unknown Source) Fixed in cvs :-) Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Finding .security files
Today I fixed a buglet in libgcj relating to finding the .security files. The current code looks like this: loadProviders(System.getProperty(java.home), System.getProperty(java.vm.name)); loadProviders(System.getProperty(gnu.classpath.home), classpath); Now, we define java.vm.name as GNU libgcj, which we'd really rather not use as a directory name (and which we'd rather not change). So one idea I had here was to change this code to remove everything up to and including the first space. This is sort of ugly, but will get us what we want. Also, for some installs of libgcj it would be more appropriate not to look for a file at all. For instance an embedded system may not have a filesystem. One thought here was to have a way to provide Classpath with a base URL to which the appropriate names could be added. Then for embedded systems we could use a libgcj-style core:/ URL to find the security providers. Any comments here? Other ideas? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
build failure
Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've appended the build log. Tom Making all in lib make[1]: Entering directory `/home/tromey/gnu/classpath/build/lib' top_builddir=.. /bin/sh ./gen-classlist.sh standard top_builddir=.. /bin/sh ./gen-classlist.sh standard /usr/bin/jikes +F -bootclasspath '' -extdirs '' -sourcepath '' -classpath ../../classpath:../vm/current:.: -d . @classes Found 1 semantic error compiling ../../classpath/java/nio/channels/FileChannel.java: 70. public abstract MappedByteBuffer map(MapMode mode, long position, int size) -- *** Error: Type java/nio/channels/MappedByteBuffer was not found. Found 4 semantic errors compiling ../../classpath/gnu/java/nio/FileChannelImpl.java: 51. public class FileChannelImpl extends FileChannel - *** Error: The abstract method long write(java.nio.ByteBuffer[] srcs);, inherited from type java/nio/channels/GatheringByteChannel, is not implemented in the non-abstract class gnu/java/nio/FileChannelImpl. 51. public class FileChannelImpl extends FileChannel - *** Error: The abstract method long read(java.nio.ByteBuffer[] srcs, int offset, int length);, inherited from type java/nio/channels/ScatteringByteChannel, is not implemented in the non-abstract class gnu/java/nio/FileChannelImpl. 51. public class FileChannelImpl extends FileChannel - *** Error: The abstract method long read(java.nio.ByteBuffer[] srcs);, inherited from type java/nio/channels/ScatteringByteChannel, is not implemented in the non-abstract class gnu/java/nio/FileChannelImpl. --- 165. public MappedByteBuffer map(java.nio.channels.FileChannel.MapMode mode, . . . 167. int size) throws IOException - *** Error: The return type of method java.nio.MappedByteBuffer map(java.nio.channels.FileChannel$MapMode mode, long position, int size); does not match the return type of method java.nio.channels.MappedByteBuffer map(java.nio.channels.FileChannel$MapMode mode, long position, int size); inherited from type java/nio/channels/FileChannel. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/ByteBufferImpl.java: 48. this.cap = cap; -- *** Error: The field cap contained in class java/nio/ByteBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/ByteBufferImpl which is in a different package. 55. this.cap = array.length; -- *** Error: The field cap contained in class java/nio/ByteBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/ByteBufferImpl which is in a different package. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/DoubleBufferImpl.java: 47. this.cap = cap; -- *** Error: The field cap contained in class java/nio/DoubleBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/DoubleBufferImpl which is in a different package. 54. this.cap = array.length; -- *** Error: The field cap contained in class java/nio/DoubleBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/DoubleBufferImpl which is in a different package. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/FloatBufferImpl.java: 47. this.cap = cap; -- *** Error: The field cap contained in class java/nio/FloatBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/FloatBufferImpl which is in a different package. 54. this.cap = array.length; -- *** Error: The field cap contained in class java/nio/FloatBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/FloatBufferImpl which is in a different package. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/LongBufferImpl.java: 47. this.cap = cap; -- *** Error: The field cap contained in class java/nio/LongBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/LongBufferImpl which is in a different package. 54. this.cap = array.length; -- *** Error: The field cap contained in class java/nio/LongBuffer has default access. Therefore, it is not accessible in class gnu/java/nio/LongBufferImpl which is in a different package. Found 2 semantic errors compiling ../../classpath/gnu/java/nio/IntBufferImpl.java: 47. this.cap = cap; -- *** Error: The field cap contained in class java/nio/IntBuffer has default access.
Re: mauve results posted nightly
(where INTERPRETER == gij || Sun j2sdk 1.4 java) produced almost identical files but there were a few small differences. I also haven't looked into this yet. (diff attached) But this is probably one of the runtimes picking up a constant from its own runtime library and not from the GNU Classpath glibj.zip file. --- gij.out 2002-11-14 22:18:50.0 +0100 +++ j2sdk.out 2002-11-14 22:18:26.0 +0100 @@ -640,7 +640,7 @@ java.lang,Compiler!wait(J,I) Pcif V*java.lang.InterruptedException java.lang,Double! Pcif class#-9172774392245257468:java.lang.Number:java.lang.Object*java.lang.Comparable*java.io.Serializable java.lang,Double!#MAX_VALUE Pcsf D:1.7976931348623157E308 -java.lang,Double!#MIN_VALUE Pcsf D:5.0E-324 +java.lang,Double!#MIN_VALUE Pcsf D:4.9E-324 This diff is a result of bugs in Double.toString() within the VM. It is the underlying double value in both VMs, but a different string representation. The correct string is 4.9E-324. Perhaps japize should use Double.doubleToLongBits() to compare the bitwise value of double constants (likewise Float.floatToIntBits()). -java.lang,Float!#MIN_VALUE Pcsf F:1.4012985E-45 +java.lang,Float!#MIN_VALUE Pcsf F:1.4E-45 Likewise. The correct string should be 1.4E-45. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've been seeing similar errors with Jikes 1.16 for the last few days. [I wish people would compile with Jikes or javac before checking in changes. Gcj's error checking is very lax.] Brian: would it be possible to extend your nightly regression stuff to build the Classpath sources with various compilers and report any compilation errors? -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Eric == Eric Blake [EMAIL PROTECTED] writes: --- gij.out 2002-11-14 22:18:50.0 +0100 +++ j2sdk.out2002-11-14 22:18:26.0 +0100 -java.lang,Double!#MIN_VALUE Pcsf D:5.0E-324 +java.lang,Double!#MIN_VALUE Pcsf D:4.9E-324 Eric This diff is a result of bugs in Double.toString() within the VM. It Eric is the underlying double value in both VMs, but a different string Eric representation. The correct string is 4.9E-324. Eric, since you seem to know about this, would you mind submitting a PR against gij? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Perhaps japize should use Double.doubleToLongBits() to compare the bitwise value of double constants (likewise Float.floatToIntBits()). That would be a bit safer, considering that even JDK 1.4.x has minor bugs in its implementations of double - string translation! However, even comparing the bits returned Double.doubleToLongBits() is not strictly correct, because the Java VM spec says that VMs are allowed to use a range of bit patterns to represent NaN values. The safest way for for japize to compare Java doubles (and floats) is to do the following: double d1, d2; ... boolean sameValue = (Double.isNaN(d1) Double.isNaN(d2)) || (d1 == d2) Note: you have to test NaNs separately because the Java VM spec says that (NaN == NaN) always gives false!! -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Stephen == Stephen Crawley [EMAIL PROTECTED] writes: Stephen [I wish people would compile with Jikes or javac before Stephen checking in changes. Gcj's error checking is very lax.] Yeah. Please feel free to submit bug reports against gcj whenever you run into a problem like this. I can't promise quick turnaround, since nobody is working full-time on the front end right now, but bugs still do get fixed from time to time. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Stephen Crawley wrote: Perhaps japize should use Double.doubleToLongBits() to compare the bitwise value of double constants (likewise Float.floatToIntBits()). That would be a bit safer, considering that even JDK 1.4.x has minor bugs in its implementations of double - string translation! However, even comparing the bits returned Double.doubleToLongBits() is not strictly correct, because the Java VM spec says that VMs are allowed to use a range of bit patterns to represent NaN values. Double.doubleToLongBits is specified to flatten all doubles to the canonical version of NaN, 0x7ff8L. You're thinking of Double.doubleToRawLongBits where NaN can be from a range of values. Mauve tests whether an implementation actually obeys this rule. Of all the compilers and VMs I have seen for Java, the only one that currently gets double-String and float-String conversion 100% correct is jikes, version 1.16 or later. There are several tests in the Jacks test suite for corner cases of string conversion; but I ought to port them to Mauve as well, to have runtime as well as compile-time tests. (BTW, Sun JDK 1.4.x also has bugs in the string - double translation, and I know at least one string which sends Sun's Double.parseDouble, and thus javac, into an infinite loop). The safest way for for japize to compare Java doubles (and floats) is to do the following: double d1, d2; ... boolean sameValue = (Double.isNaN(d1) Double.isNaN(d2)) || (d1 == d2) Note: you have to test NaNs separately because the Java VM spec says that (NaN == NaN) always gives false!! Not just the JVM - IEEE 754 also specified this relation! But your test above does not work for 0.0 vs. -0.0. The best comparison is (Double.compare(d1, d2) == 0), added in JDK 1.4; or (new Double(d1).compareTo(new Double(d2)) == 0) in JDK 1.2. If you want japize to work with JDK 1.1, just copy the implementation of these methods from Classpath or libgcj. These methods are tested by mauve. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Stephen Crawley wrote: Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've been seeing similar errors with Jikes 1.16 for the last few days. [I wish people would compile with Jikes or javac before checking in changes. Gcj's error checking is very lax.] Jikes 1.17 is much better than 1.15 or 1.16 in terms of producing correct bytecode in several situations. But that version also fails on the current tree; it looks like some import problems in the java.nio package, but I haven't tried to fix it yet. I'm not sure about compiling the tree with javac; and even if that works, I won't recommend it since it is not a free compiler. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Finding .security files
Tom Tromey [EMAIL PROTECTED] writes: Now, we define java.vm.name as GNU libgcj, which we'd really rather not use as a directory name (and which we'd rather not change). So one idea I had here was to change this code to remove everything up to and including the first space. This is sort of ugly, but will get us what we want. Perhaps relying on the VM name is a poor choice, things like this are too easily changed by marketdroids. Also, for some installs of libgcj it would be more appropriate not to look for a file at all. For instance an embedded system may not have a filesystem. One thought here was to have a way to provide Classpath with a base URL to which the appropriate names could be added. Then for embedded systems we could use a libgcj-style core:/ URL to find the security providers. I would assume the use of URL makes sense here, and it could be a file URL, network URL, jar URL, etc... Brian -- Brian Jones [EMAIL PROTECTED] http://www.haphazard.org/~cbj/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Stephen Crawley [EMAIL PROTECTED] writes: Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've been seeing similar errors with Jikes 1.16 for the last few days. [I wish people would compile with Jikes or javac before checking in changes. Gcj's error checking is very lax.] Brian: would it be possible to extend your nightly regression stuff to build the Classpath sources with various compilers and report any compilation errors? I just changed the scripts to use jikes, was apparently using gcj 3.2 before which doesn't report any error. Brian -- Brian Jones [EMAIL PROTECTED] http://www.haphazard.org/~cbj/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Stephen Crawley [EMAIL PROTECTED] writes: Brian: How long ago did this happen? If it was within the last week, do you have time to try to reproduce the segfault and email me a stack trace? This week, last night, from early morning build yesterday. I'll try. Brian -- Brian Jones [EMAIL PROTECTED] http://www.haphazard.org/~cbj/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
