Re: mauve results posted nightly
Mark Wielaard wrote: Hi, 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 snipped since you seem to have a good handle on figuring that one out...) That's great news: I'll add to the readme in the next version that Kissme is able to run Japize in at least a limited way (ie not over the whole API). The only cotcha with compiling is the referencee to org.omg.CORBA.BAD_OPERATION in JapiSerialize which seems to be save to comment out. In fact it's safe to comment out the whole of JapiSerialize: it's entirely independent from the rest of Japitools and in fact written by a different person :). Of course, ideally you want to be able to *use* serialize as well as japize, and you'll need to compile it for that :) 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. I know of no reason that shouldn't be possible. I've been intending to try to strip down jode to only the subset I need anyway: I only use the jode.bytecode package directly as far as I can remember, so jode.bytecode plus its dependencies should be all that's needed. 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? An OutOfMemoryError might indicate a problem in weak references, since Jode apparently relies on them to release classes (it has no explicit way to completely unload a class). Alternatively it might indicate a memory leak in GZipOutputStream - you could rule that out by specifying the unzip option. Those are, of course, just the first things that come to mind - it could be something entirely different. You can find a whole bunch of example japi files in http://rainbow.netreach.net/~sballard/japi/htmlout/. The most interesting/useful for comparison is probably classpath.japi.gz which is the nightly one I download from Brian. The only one I know for sure how to generate is jdk11.japi.gz which is generated by: $ japize as jdk11 packages /path/to/classes.zip +java -java.awt.peer -java.text.resources (that's all one line, of course). The other jdkxx.japi.gz files there are ones I've accumulated over time and updated to the latest file format version using japifix. They should be identical to what you'd get if you run japize with appropriate arguments against the JDK, but I can't tell you what those arguments are, except for 1.1. To be absolutely sure you're getting the right results, your best bet is to compare against using the JDK to run the same thing... Brian, what are the arguments you're giving Japize to generate the nightly classpath.japi.gz file, and to generate the jdkxx.japi.gz files? -- Stuart Ballard, Programmer NetReach - Internet Solutions (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Mark Wielaard wrote: Hi, 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 :) Sounds like an argument in favor of, or against, native java.util.zip ;) Or does this performance difference apply regardless of compression? 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. Presumably a java.util.zip bug. (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. See below for my comments... 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,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 These look like they could well be floating-point output bugs. Sun has a very complex and highly specified algorithm for exactly what significant figures should be printed for any given floating point number: it's entirely possible that Classpath doesn't implement that algorithm perfectly. (I think I commented in the source code that this also tests toString() on floating point numbers or something to that effect). 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!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 These are more interesting as they boil down to the question of is KeyManagementException a subclass of RuntimeException?. If it is, it should be excluded from the throws clause; if not, it should be included. I'm curious as to why jode is giving different results depending on which JVM is running it... Stuart. -- Stuart Ballard, Programmer NetReach - Internet Solutions (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build failure
Brian Jones [EMAIL PROTECTED] writes: I just changed the scripts to use jikes, was apparently using gcj 3.2 before which doesn't report any error. And there is a reason why I didn't use jikes to begin with... japize barfs (jode actually) in java.applet with an ArrayIndexOutOfBoundsException. Processing package java.applet,:=Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 38 at jode.bytecode.BytecodeInfo.read(BytecodeInfo.java:843) at jode.bytecode.MethodInfo.readAttribute(MethodInfo.java:56) at jode.bytecode.BinaryInfo.readAttributes(BinaryInfo.java:146) at jode.bytecode.MethodInfo.read(MethodInfo.java:84) at jode.bytecode.ClassInfo.read(ClassInfo.java:342) at jode.bytecode.ClassInfo.loadInfo(ClassInfo.java:614) at jode.bytecode.FieldInfo.getConstant(FieldInfo.java:170) at net.wuffies.japi.JodeField.init(JodeField.java:32) at net.wuffies.japi.JodeClass.addFields(JodeClass.java:238) at net.wuffies.japi.JodeClass.addFields(JodeClass.java:243) at net.wuffies.japi.JodeClass.addFields(JodeClass.java:243) at net.wuffies.japi.JodeClass.getFields(JodeClass.java:251) at net.wuffies.japi.Japize.japizeClass(Japize.java:667) at net.wuffies.japi.Japize.processPackage(Japize.java:446) at net.wuffies.japi.Japize.processPackage(Japize.java:455) at net.wuffies.japi.Japize.processRootSet(Japize.java:375) at net.wuffies.japi.Japize.doJapize(Japize.java:355) at net.wuffies.japi.Japize.main(Japize.java:283) 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
It's probably the same bug in Jode as is causing problems with jdk1.4 class files. I wonder what jikes is doing that Jode can't handle... Brian Jones wrote: And there is a reason why I didn't use jikes to begin with... japize barfs (jode actually) in java.applet with an ArrayIndexOutOfBoundsException. Processing package java.applet,:=Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 38 at jode.bytecode.BytecodeInfo.read(BytecodeInfo.java:843) ... -- 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: Synchronization in java.util.Collections
Dalibor Topic wrote: Hi, I've looked over Classpath's implementation of synchronized* methods in java.util.Collections, and I don't understand why the synchronized wrapper classes sync on their own specific mutex field instead of syncing on themselves? i.e. why not have all the wrapper methods synchronized and drop the mutex field? That's how kaffe does it. They sync on the specified mutex so iterators (which are different instances) can sync on the same mutex. It is also essential for correctly implementing things like Map.subMap(), where the sub-map must synchronize on the original map. -- 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: package private static equals and hash methods in java.util
Dalibor Topic wrote: Hi, a couple of classes in java.util have the same implementation of a static final equals and hashCode method taking two arguments. What is the reason why not all the calls are delegated to a single implementation, say AbstractCollection.equals/hashCode instead of duplicating the code ? Because I was lazy - using inheritance, I could just type equals(a, b), instead of the full Collections.equals(a, b) if the helper methods lived in a single file. Feel free to change that if you want. -- 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
Hi, On Sat, 2002-11-16 at 15:46, Brian Jones wrote: Brian Jones [EMAIL PROTECTED] writes: I just changed the scripts to use jikes, was apparently using gcj 3.2 before which doesn't report any error. And there is a reason why I didn't use jikes to begin with... japize barfs (jode actually) in java.applet with an ArrayIndexOutOfBoundsException. Thanks. Great datapoint. When I recompile Classpath glibj.zip with gcj (3.2) then Kissme run japi is able to process java.io nicely. But this is strange since it does not explain why running with gij does not give this exception when Classpath is compiled with jikes. I still cannot process everything with Kissme since I am unable to set the heap size with --heap (it will crash). Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
