Re: mauve results posted nightly
Brian Jones wrote: No, not forgotten but not started yet. Won't have a decent response back to you for a week I guess. Planning to send a patch... is there a way to combine two or more japize runs into a single file (non-overlapping packages)? Hmm... not a trivial way, but it can be done. gunzip file1.japi.gz file2.japi.gz cat file1.japi file2.japi | sort combined.japi vi combined.japi dd (strip off the duplicate first line) :wq gzip combined.japi Of course, since the first line contains things like creation date, there's slight dataloss in combining two files with different creation dates. Oh, and I think this technique requires japi files created by japitools 0.9.2, because the code that made sort give the right order was only added in that version. This also won't work if any of the same classes are included in both japis, but you said non-overlapping packages so you should be okay on that front. Out of interest, since you seem to have a handle on solving the problem, what exactly turned out to be causing 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: mauve results posted nightly
Brian Jones wrote: It's not a new problem, but I was able to ignore it before. Now japize stops dead in its tracks. Because I know Classpath has this $ClassFactory and JDK 1.4 does not... Jode must be reading something in Classpath's .class files referencing this and trying to use reflection to load it which fails under the JDK. Again I used to see this (and I ignored it) but it didn't cause japize to die as it does now. Did you ever get a chance to take a look into this? I have a few japicompat fixes that I'd like to make a release out of, but I don't want to make one with this problem still outstanding. There are two approaches that I think may be worth pursuing here: 1) Email me the classfile(s) that are a problem (I guess java.lang.reflect.Proxy*.class) and I'll forward them to the Jode maintainer and see whether he has any ideas. A UTFDataFormatException suggests to me that the classfile itself is corrupted, or that the low levels of Jode's classfile reading are confused and expecting UTF data where there isn't any. 2) Try compiling Classpath, or perhaps just java.lang.reflect.Proxy, with a different java compiler. If it *is* an invalid classfile, it seems unlikely that two different compilers would both exhibit the same incorrect behavior. Thanks, 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: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes: Brian Jones wrote: It's not a new problem, but I was able to ignore it before. Now japize stops dead in its tracks. Because I know Classpath has this $ClassFactory and JDK 1.4 does not... Jode must be reading something in Classpath's .class files referencing this and trying to use reflection to load it which fails under the JDK. Again I used to see this (and I ignored it) but it didn't cause japize to die as it does now. Did you ever get a chance to take a look into this? I have a few japicompat fixes that I'd like to make a release out of, but I don't want to make one with this problem still outstanding. No, not forgotten but not started yet. Won't have a decent response back to you for a week I guess. Planning to send a patch... is there a way to combine two or more japize runs into a single file (non-overlapping packages)? Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Brian Jones wrote: It's not a new problem, but I was able to ignore it before. Now japize stops dead in its tracks. Because I know Classpath has this $ClassFactory and JDK 1.4 does not... Jode must be reading something in Classpath's .class files referencing this and trying to use reflection to load it which fails under the JDK. Again I used to see this (and I ignored it) but it didn't cause japize to die as it does now. Looking at the stacktrace you provided, I'm not convinced that this is a reflection issue at it's root. First off, we can disregard the fact that it happens when reading java.lang.reflect - that's irrelevant to what it's actually doing to read the classes, of course. The stack traces refer to java.io.UTFDataFormatException - that sounds like a classfile format problem because I know that the classfile format contains a lot of UTF-formatted data. Does this continue to happen if you compile Classpath (or even just java.lang.reflect.Proxy) with a different Java compiler? (I have no idea whether this is Jode misinterpreting perfectly valid information, or the compiler emitting an invalid classfile). I suspect that what's happening is that due to this UTFDataFormatException in the classfile, Jode is falling back to trying to read the class another way, and the only other way it has is Reflection. When Japize asks the class whether it's deprecated, then, it has no way to find out, because reflection doesn't carry that information - so even if you *were* using a Java implementation that included the class, it still wouldn't solve the problem. I think we need to figure out whether the root cause of this UTFDataFormatException is due to a malformed class file (in which case the compiler needs to be fixed) or a Jode bug (in which case, of course, we need to fix that). To that end, would you like to mail the offending class file(s) to the Jode maintainer and ask for an informed opinion (unless you happen to know the internals of the classfile format yourself, which I certainly don't ;) )? Or would you like to email the classfile to me, and I'll contact the Jode maintainer myself? Thanks, 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: mauve results posted nightly
Brian Jones wrote: Brian Jones [EMAIL PROTECTED] writes: Sadly it appears I'm having trouble producing a classpath.japi. Jode appears to use reflection to load some classes during class reading which is making it difficult to use something like Sun's JDK to produce the files and I don't have enough RAM to use Kissme on the whole thing. Do you have evidence that the reflection codepaths are actually being used? I know that Jode contains code to do that, but as far as I know it shouldn't actually ever happen when making a japi of java.*, as long as all the java.* classes are in the zipfiles that you pass to japize on the commandline. (there is a good reason for keeping it there, though: consider the case when you're japizing, say, javax.servlet. You only want to pass the servlet jar on the commandline, but Jode still needs to be able to find all the superclasses, including java.lang.Object, a bunch of stuff from java.io, etc. In those cases it's legit to use reflection, because the classes you're loading by reflection are irrelevant to the API you're japizing) Incidentally, that code in Jode hasn't changed ever since I first started using Jode back in 0.8 or so - so if there's a problem, it's been in every version of japitools since then (including 0.9 which you're already using... :) ). 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: mauve results posted nightly
Brian Jones wrote: The -java.text.resources is already there, re-read above. Oops, yes, I noticed that shortly after sending that message, but didn't want to spam the list with an oops message ;) I produced a jdk14.japi after your changes. I also remade all the other files as well. Would be useful for japize to look at multiple .jar/.zip files... dealing with jce.jar required making a new .jar file with rt.jar and jce.jar combined. Can you elaborate on the trouble you're having? I was able to produce jdk14.japi just fine with a japize line like: japize as jdk14 packages .../rt.jar .../jce.jar .../jsse.jar +java -java.awt.peer etc etc etc (that's all on one line, and of course ... and etc need to be replaced with real arguments) The latest japi files for all JDK versions from 1.0 to 1.4 are available in jdkjapis.tar linked from the japitools homepage. 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: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes: Can you elaborate on the trouble you're having? I was able to produce jdk14.japi just fine with a japize line like: japize as jdk14 packages .../rt.jar .../jce.jar .../jsse.jar +java -java.awt.peer etc etc etc That's what I wanted... didn't think it worked. I should have tried it I guess. -- 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
Stuart Ballard [EMAIL PROTECTED] writes: Do you have evidence that the reflection codepaths are actually being used? I know that Jode contains code to do that, but as far as I know it shouldn't actually ever happen when making a japi of java.*, as long as all the java.* classes are in the zipfiles that you pass to japize on the commandline. (there is a good reason for keeping it there, though: consider the case when you're japizing, say, javax.servlet. You only want to pass the servlet jar on the commandline, but Jode still needs to be able to find all the superclasses, including java.lang.Object, a bunch of stuff from java.io, etc. In those cases it's legit to use reflection, because the classes you're loading by reflection are irrelevant to the API you're japizing) Incidentally, that code in Jode hasn't changed ever since I first started using Jode back in 0.8 or so - so if there's a problem, it's been in every version of japitools since then (including 0.9 which you're already using... :) ). It's not a new problem, but I was able to ignore it before. Now japize stops dead in its tracks. Because I know Classpath has this $ClassFactory and JDK 1.4 does not... Jode must be reading something in Classpath's .class files referencing this and trying to use reflection to load it which fails under the JDK. Again I used to see this (and I ignored it) but it didn't cause japize to die as it does now. Processing package java.lang.reflect,:=++Can't read class java.lang.reflect.Proxy$ClassFactory, types may be incorrect. (java.io.UTFDataFormatException)java.io.UTFDataFormatException at java.io.DataInputStream.readUTF(DataInputStream.java:615) at java.io.DataInputStream.readUTF(DataInputStream.java:551) at jode.bytecode.ConstantPool.read(ConstantPool.java:94) at jode.bytecode.ClassInfo.read(ClassInfo.java:310) at jode.bytecode.ClassInfo.loadInfo(ClassInfo.java:628) at jode.bytecode.ClassInfo.getModifiers(ClassInfo.java:759) at net.wuffies.japi.JodeClass.getModifiers(JodeClass.java:69) at net.wuffies.japi.Japize.japizeClass(Japize.java:621) at net.wuffies.japi.Japize.processPackage(Japize.java:445) at net.wuffies.japi.Japize.processPackage(Japize.java:454) at net.wuffies.japi.Japize.doJapize(Japize.java:331) at net.wuffies.japi.Japize.main(Japize.java:281) Can't read class java.lang.reflect.Proxy$ClassFactory, types may be incorrect. (java.io.UTFDataFormatException) java.io.UTFDataFormatException at java.io.DataInputStream.readUTF(DataInputStream.java:615) at java.io.DataInputStream.readUTF(DataInputStream.java:551) at jode.bytecode.ConstantPool.read(ConstantPool.java:94) at jode.bytecode.ClassInfo.read(ClassInfo.java:310) at jode.bytecode.ClassInfo.loadInfo(ClassInfo.java:628) at jode.bytecode.ClassInfo.getOuterClasses(ClassInfo.java:807) at net.wuffies.japi.JodeClass.getModifiers(JodeClass.java:74) at net.wuffies.japi.Japize.japizeClass(Japize.java:621) at net.wuffies.japi.Japize.processPackage(Japize.java:445) at net.wuffies.japi.Japize.processPackage(Japize.java:454) at net.wuffies.japi.Japize.doJapize(Japize.java:331) at net.wuffies.japi.Japize.main(Japize.java:281) Exception in thread main java.lang.NoClassDefFoundError: java.lang.reflect.Proxy$ClassFactory at jode.bytecode.ClassInfo.loadInfo(ClassInfo.java:634) at net.wuffies.japi.JodeClass.isDeprecated(JodeClass.java:84) at net.wuffies.japi.Japize.japizeClass(Japize.java:663) at net.wuffies.japi.Japize.processPackage(Japize.java:445) at net.wuffies.japi.Japize.processPackage(Japize.java:454) at net.wuffies.japi.Japize.doJapize(Japize.java:331) at net.wuffies.japi.Japize.main(Japize.java:281) 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
Stuart Ballard [EMAIL PROTECTED] writes:
Brian Jones wrote:
as classpath packages ${CLASSPATH_CVS}/build/lib/glibj.zip +java
+javax +org -java.awt.dnd.peer -java.awt.peer -org.apache
-org.w3c.dom.css -org.w3c.dom.events -org.w3c.dom.html
-org.w3c.dom.stylesheets -org.w3c.dom.traversal -org.w3c.dom.views
-java.text.resources
This is what I use nightly on Classpath. I may need to regenerate
the
jdk stuff just to be sure it uses the same thing.
On the JDK you also need -java.text.resources - it's never been in any
of the releases' documentation, but it's in every JDK version since
1.1. It currently shows up as 100% missing (and bright red) in the
nightly HTML comparison, because the 1.2 and 1.3 japis I have still
include it...
The -java.text.resources is already there, re-read above.
If anyone feels like figuring out enough of Jode to get a jdk14.japi
out of it, now would be a very good time; this is something I
certainly can't do because my primary machine can barely even japize
1.1.
I produced a jdk14.japi after your changes. I also remade all the
other files as well. Would be useful for japize to look at multiple
.jar/.zip files... dealing with jce.jar required making a new .jar
file with rt.jar and jce.jar combined.
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
Brian Jones [EMAIL PROTECTED] writes: I produced a jdk14.japi after your changes. I also remade all the other files as well. Would be useful for japize to look at multiple .jar/.zip files... dealing with jce.jar required making a new .jar file with rt.jar and jce.jar combined. Sadly it appears I'm having trouble producing a classpath.japi. Jode appears to use reflection to load some classes during class reading which is making it difficult to use something like Sun's JDK to produce the files and I don't have enough RAM to use Kissme on the whole thing. 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
It's working now, it's really great! John On Mon, 2002-11-25 at 16:55, Stuart Ballard wrote: John Leuner wrote: Okay, I've posted experimental and incomplete HTMLified comparisions of Classpath vs JDK1.1, JDK1.2 and JDK1.3, linked from http://rainbow.netreach.net/~sballard/japi and regenerated nightly at around 3. This link doesn't seem to work? Hmm, I just noticed the timestamp on your email and I'm surprised that it still wasn't working at that time. I thought it would have been up by about 10am EST today. Are you still having problems accessing it? Thanks, 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 signature.asc Description: This is a digitally signed message part
Re: mauve results posted nightly
Okay, I've posted experimental and incomplete HTMLified comparisions of Classpath vs JDK1.1, JDK1.2 and JDK1.3, linked from http://rainbow.netreach.net/~sballard/japi and regenerated nightly at around 3. This link doesn't seem to work? John Leuner signature.asc Description: This is a digitally signed message part
Re: mauve results posted nightly
John Leuner wrote: Okay, I've posted experimental and incomplete HTMLified comparisions of Classpath vs JDK1.1, JDK1.2 and JDK1.3, linked from http://rainbow.netreach.net/~sballard/japi and regenerated nightly at around 3. This link doesn't seem to work? Sorry, power cut over the weekend at my company (this is hosted on my workstation rather than anything on a UPS). 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: mauve results posted nightly
John Leuner wrote: Okay, I've posted experimental and incomplete HTMLified comparisions of Classpath vs JDK1.1, JDK1.2 and JDK1.3, linked from http://rainbow.netreach.net/~sballard/japi and regenerated nightly at around 3. This link doesn't seem to work? Hmm, I just noticed the timestamp on your email and I'm surprised that it still wasn't working at that time. I thought it would have been up by about 10am EST today. Are you still having problems accessing it? Thanks, 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: mauve results posted nightly
Brian Jones wrote: Stuart Ballard [EMAIL PROTECTED] writes: I debugged the 1.4 problem earlier and posted about it I think, ie the line of source and what file throws the exception... but I'm not a class file expert and I don't know what else was added in 1.4 that should result in additions to Jode other than this version check. Good news - the just-released experimental japitools-0.9.1 appears to be able to japize 1.4 just fine. I imported the source for jode.bytecode and jode.util into the japitools source itself, removed the jode jarball, converted the .java.in files into plain java by hand, and removed the version check, and it seems to work (I made all the changes blind and untested on my crappy personal computer and just ran it once on my work computer). Results of comparison will be up shortly and it will be added to the nightlies from tonight onwards. This also means, btw, that the html output is now available for people to play with a bit. The documentation is pretty non-existent but there's some hints in the changelog at the top of the webpage. Basically it's $ japicompat -v jdk1x.japi.gz classpath.japi.gz | japiohtml For old-style text output use japiotext instead of japiohtml, although this doesn't quite have all the information the old text output used to have. That will be fixed in a later version. 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: mauve results posted nightly
Brian Jones wrote:
as classpath packages ${CLASSPATH_CVS}/build/lib/glibj.zip +java +javax +org -java.awt.dnd.peer -java.awt.peer -org.apache -org.w3c.dom.css -org.w3c.dom.events -org.w3c.dom.html -org.w3c.dom.stylesheets -org.w3c.dom.traversal -org.w3c.dom.views -java.text.resources
This is what I use nightly on Classpath. I may need to regenerate the
jdk stuff just to be sure it uses the same thing.
On the JDK you also need -java.text.resources - it's never been in any
of the releases' documentation, but it's in every JDK version since 1.1.
It currently shows up as 100% missing (and bright red) in the nightly
HTML comparison, because the 1.2 and 1.3 japis I have still include it...
Btw, I have added the errors themselves to the HTML output, and
linkified them from the summary table. It needs a bit more tidying up
and some per-package summaries, but it's useful enough to be worth
trying to use the HTML output for bugfixing. The only thing that worries
me is that in the absence of a jdk14.japi, some of the things that are
listed as errors might be actually attempts at 1.4 compatibility - just
as there are quite a few errors against JDK1.1 that don't appear in the
output for JDK1.3, suggesting that these are places where Sun themselves
broke compatibility.
If anyone feels like figuring out enough of Jode to get a jdk14.japi out
of it, now would be a very good time; this is something I certainly
can't do because my primary machine can barely even japize 1.1.
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: mauve results posted nightly
Stuart == Stuart Ballard [EMAIL PROTECTED] writes: Stuart Btw, I have added the errors themselves to the HTML output, Stuart and linkified them from the summary table. It needs a bit more Stuart tidying up and some per-package summaries, but it's useful Stuart enough to be worth trying to use the HTML output for Stuart bugfixing. This is very nice. Thanks! Stuart The only thing that worries me is that in the absence of a Stuart jdk14.japi Yes. It is especially difficult since I think we're targeting 1.4 right now. (We certainly have a lot of 1.4 code in the tree.) Differences against 1.[123] are therefore less interesting. Still, what exists right now is definitely useful. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes: Tom Tromey wrote: This is very nice. Thanks! It's great fun working on it and making pretty colored output :) Yes. It is especially difficult since I think we're targeting 1.4 right now. (We certainly have a lot of 1.4 code in the tree.) Differences against 1.[123] are therefore less interesting. Still, what exists right now is definitely useful. I don't think it should take long for someone with the Jode source code (jode.sourceforge.net) and a computer capable of running it to diagnose exactly where Jode is failing and why, and fix it. I think it's just a classfile-version check which needs the number to compare against upped. But since my computer can't even run it, I can't do that work myself :( I debugged the 1.4 problem earlier and posted about it I think, ie the line of source and what file throws the exception... but I'm not a class file expert and I don't know what else was added in 1.4 that should result in additions to Jode other than this version check. 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
Tom Tromey wrote: This is very nice. Thanks! It's great fun working on it and making pretty colored output :) Yes. It is especially difficult since I think we're targeting 1.4 right now. (We certainly have a lot of 1.4 code in the tree.) Differences against 1.[123] are therefore less interesting. Still, what exists right now is definitely useful. I don't think it should take long for someone with the Jode source code (jode.sourceforge.net) and a computer capable of running it to diagnose exactly where Jode is failing and why, and fix it. I think it's just a classfile-version check which needs the number to compare against upped. But since my computer can't even run it, I can't do that work myself :( 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: mauve results posted nightly
Hi,
On Mon, 2002-11-18 at 04:42, Stephen Crawley wrote:
This is probably how it happened. Loading Collections$SynchronizedSet
has triggered loading of another class Y, and Y's static initialisation
code has tried to use something in Collections$SynchronizedSet. This
has caused the class loader to FindOrLoad Collections$SynchronizedSet
a second time, and the initialisation has run. Finally, the class
loader call that originally tried to load Collections$SynchronizedSet
notices that the copy of the class the CPList is not the one it loaded,
and panics.
I am using the following as a temporary workaround at the moment:
--- vm/classloader_tuple.c 23 Oct 2002 13:26:54 - 1.25
+++ vm/classloader_tuple.c 18 Nov 2002 10:48:44 -
@@ -312,8 +312,9 @@
pstClass-uidName, pstClass, pstClass-classLoader);
}
else {
- panic(Class %s %p (%p) loaded twice,
+ eprintf(Class %s %p (%p) loaded twice,
pstClass-uidName, pstClass, pstClass-classLoader);
+ return pstTempClass;
}
}
else {
Hope that helps you get further with your tests for now.
Cheers,
Mark
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Stephen Crawley wrote: 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). AFAIK, weak references don't work in Kissme. Certainly, the Mauve weak reference testcases have been commented out of the regression tests. I also suspect that class unloading won't work either. If weak references don't work then I'm not surprised that you get an OOM error, because you're probably attempting to load a full representation of every class in the API into memory simultaneously! When I referred to unloading classes, I meant Jode's representation of classes in regular old Java data structures; as far as I know, Jode doesn't rely on VM class unloading. 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: mauve results posted nightly
Hi Brian, On Wed, 2002-11-13 at 22:34, Brian Jones wrote: 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. What specific support do you need? Steven and I have recently hacked a lot on the reflection support in Kissme and it now passes simple Mauve serialisation tests like the gnu.testlet.java.util.ArrayList.serial test. Kissme is certainly not perfect with respect to reflection, but I believe that I fixed most bugs related to reflection. If there is a specific reflection method that currently doesn't work maybe I can help fix it. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Hi, On Mon, 2002-11-11 at 07:04, Tom Tromey wrote: Brian == Brian Jones [EMAIL PROTECTED] writes: Brian Please let me know if posting this information in this way is useful. Brian Perhaps other JVMs could be added. Does Gcj do this? Mark Wielaard posts nightly test results to the gcc test mailing list. As I recall he does this for a couple platforms. I usually just glance over these; a mailing list isn't that great of a format for detecting regressions. I only post results of the stable (3.2.x) and development (3.3) branches on powerpc (and sometimes for x86, if I feel like it, but that is not automated). The nice thing of posting to the gcc-testresults mailinglist is that you have an archive of when what test passed/failed. This has helped me figuring out when something broke and what patches to suspect. If the Mauve Classpath+Kissme results could also be archived somehow that would be really helpful for figuring out when what broke. ftp://alpha.gnu.org/pub/gnu/classpath/nightly/tests/kissme-mauve-report.txtIt seems that standard out and standard error are somehow mixed up, which seems to put the lines in the wrong places. You might want to use the recently introduced -resultsonly flag to only generate PASS or FAIL lines. What would be really helpful is when our xfails and mauve-libgcj files are completely correct and when we know for certain that the failing tests in Mauve are real bugs in the implementation. Now the number of false positives is a bit to high. My plan for after the gcj 3.3 code freeze is to go over all the (x)failing (and commented out) Mauve tests in libgcj and figure out if it is a real bug and file a bug report or to fix the Mauve test. Last time we did that ,for gcj 3.1, we really cleaned up a lot of bad mauve tests. Hopefully this time we can clean up Mauve completely. Ben Elliston is working on a Tinderbox-like system. It will include gcj test results. Ideally it will also send out email when someone introduces a regression (like Geoff's old tester, but it will include libgcj). That would be really great to have! Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes:
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 :)
Yes, it is safe to comment that out. I need to think about it a bit
more. Essentially I determined some exceptions thrown from
instantiating or serializing various classes were 'OK', in order to
reduce the number of errors one might look at later.
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?
as classpath packages ${CLASSPATH_CVS}/build/lib/glibj.zip +java +javax +org
-java.awt.dnd.peer -java.awt.peer -org.apache -org.w3c.dom.css -org.w3c.dom.events
-org.w3c.dom.html -org.w3c.dom.stylesheets -org.w3c.dom.traversal -org.w3c.dom.views
-java.text.resources
This is what I use nightly on Classpath. I may need to regenerate the
jdk stuff just to be sure it uses the same thing.
--
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
Mark Wielaard [EMAIL PROTECTED] writes: Hi Brian, On Wed, 2002-11-13 at 22:34, Brian Jones wrote: 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. What specific support do you need? Steven and I have recently hacked a lot on the reflection support in Kissme and it now passes simple Mauve serialisation tests like the gnu.testlet.java.util.ArrayList.serial test. Kissme is certainly not perfect with respect to reflection, but I believe that I fixed most bugs related to reflection. If there is a specific reflection method that currently doesn't work maybe I can help fix it. What is this about? Kissme Panic: Class java/util/Collections$SynchronizedSet 0x8203248 ((nil)) loaded twice Attempting to dump core Aborted Think it happens when trying to use gnu getopt. 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
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). AFAIK, weak references don't work in Kissme. Certainly, the Mauve weak reference testcases have been commented out of the regression tests. I also suspect that class unloading won't work either. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Hi Brian, On Wed, 2002-11-13 at 22:34, Brian Jones wrote: 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. What specific support do you need? Steven and I have recently hacked a lot on the reflection support in Kissme and it now passes simple Mauve serialisation tests like the gnu.testlet.java.util.ArrayList.serial test. Kissme is certainly not perfect with respect to reflection, but I believe that I fixed most bugs related to reflection. If there is a specific reflection method that currently doesn't work maybe I can help fix it. Thanks for offering Mark. It would be really good to knock over the remaining reflection bugs in kissme. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Mark Wielaard [EMAIL PROTECTED] writes: What is this about? Kissme Panic: Class java/util/Collections$SynchronizedSet 0x8203248 ((nil)) loaded twice Attempting to dump core Aborted Think it happens when trying to use gnu getopt. What has happened is that the VM has detected that it has accidentally loaded the same class twice with the same class loader. This is probably how it happened. Loading Collections$SynchronizedSet has triggered loading of another class Y, and Y's static initialisation code has tried to use something in Collections$SynchronizedSet. This has caused the class loader to FindOrLoad Collections$SynchronizedSet a second time, and the initialisation has run. Finally, the class loader call that originally tried to load Collections$SynchronizedSet notices that the copy of the class the CPList is not the one it loaded, and panics. This is a manifestation of the class loading problems that John Leuner mentioned in his last email before he went on holiday. I believe that the root cause is that kissme is incorrectly trying to combine linking and initialisation into one pass. But I don't really understand that part of the code base. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
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: mauve results posted nightly
Hi, On Fri, 2002-11-15 at 14:18, Brian Jones wrote: 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? ~/mauve/kissme/useful_scripts/kissme -cp \ /home/autotest/japitools-0.9/share/java/japitools.jar:/home/autotest/japitools-0.9/share/java/JSX1.0.5.3.jar:/home/autotest/japitools-0.9/share/java/java-getopt-1.0.9.jar:/home/autotest/japitools-0.9/share/java/jode-1.1.1.jar \ net.wuffies.japi.Japize as classpath-kissme packages \ /home/autotest/mauve/classpath/build/lib/glibj.zip +java +javax +org \ -java.awt.dnd.peer -java.awt.peer -org.apache -org.w3c.dom.css \ -org.w3c.dom.events -org.w3c.dom.html -org.w3c.dom.stylesheets \ -org.w3c.dom.traversal -org.w3c.dom.views -java.text.resources This is the command, in case that helps before I can get a stacktrace to you. Interesting, it gives the following exception (when processing java.io): java.lang.ArrayIndexOutOfBoundsException: 251 at jode.bytecode.BytecodeInfo.read (BytecodeInfo.java:843) at jode.bytecode.MethodInfo.readAttribute (MethodInfo.java:56) at jode.bytecode.BinaryInfo.readAttributes (BinaryInfo.java:149) at jode.bytecode.MethodInfo.read (MethodInfo.java:85) at jode.bytecode.ClassInfo.read (ClassInfo.java:339) at jode.bytecode.ClassInfo.loadInfo (ClassInfo.java:614) at jode.bytecode.FieldInfo.getConstant (FieldInfo.java:171) at net.wuffies.japi.JodeField.init (JodeField.java:32) at net.wuffies.japi.JodeClass.addFields (JodeClass.java:238) at net.wuffies.japi.JodeClass.getFields (JodeClass.java:252) 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:376) at net.wuffies.japi.Japize.doJapize (Japize.java:356) at net.wuffies.japi.Japize.main (Japize.java:284) Need to find the Jode sources now (only the binary jar comes with japi...) Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
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
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: 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: 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: 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
Re: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes: Eric Blake wrote: What's wrong with TreeSet.subSet? Let's get that fixed! I don't know, but whenever people try to run Japize on free VMs that's the one people point out as being a problem. I can't remember exactly who mentioned it but I do remember hearing it about Classpath as well as Kaffe. Stuart. 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. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Brian Jones wrote: Stuart Ballard [EMAIL PROTECTED] writes: http://www.gnu.org/philosophy/gif.html If this web page is correct, GIF will be free next year. It also mentions libungif which produces patent-free uncompressed gifs. apt-cache search led me to libungif-bin (debian package, may use other names elsewhere) which includes tools to convert normal gifs to patent-free ones. A 1x1.gif produced by one of these libungif-bin programs should be safe. So far I haven't been able to figure out which, if any, of them is capable of producing a 1x1 pixel gif from scratch where the single pixel is transparent, but presumably something there is. The documentation seems a little lacking, and the choices of programs to include seems very random... 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: mauve results posted nightly
Brian Jones wrote: Don't use GIF due to licensing problems. I think JPEG recently became problematic as well. Well I can't use PNG since Netscape 4.x compatibility is the whole point of using an image in the first place (decent browsers know how to display an empty cell...) I believe that the GIF format doesn't *require* the patented (and therefore problematic) LZW compression, but I don't know for sure. I also don't know if there are any tools that will create patent-free gifs, but it would be nice if there were. I don't think LZW or any other compression would buy a huge amount on a single pixel anyway ;) Or is there something other than the compression that's bad about gifs? 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: mauve results posted nightly
Eric Blake wrote: What's wrong with TreeSet.subSet? Let's get that fixed! I don't know, but whenever people try to run Japize on free VMs that's the one people point out as being a problem. I can't remember exactly who mentioned it but I do remember hearing it about Classpath as well as Kaffe. 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: mauve results posted nightly
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'm sure being able to run serialize is a bit further off, but I don't think japize has any requirements that should be particularly tough for kissme+classpath to meet (apart from my mistaken recollection that subSet was non-functional - that must be just Kaffe). It'd be great to be able to document at least one free VM that can run Japize... 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: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes: You'll notice there are some important things still missing, like the actual errors themselves :) The bar graphs work in Mozilla, look wrong in NS4.x due to my not having yet figured out a good way to get NS4 to display a 1px wide table cell, and are untested in all other browsers. Why not use GD, http://search.cpan.org/author/LDS/GD-2.041/GD.pm, to create a real image? -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Brian Jones wrote: Why not use GD, http://search.cpan.org/author/LDS/GD-2.041/GD.pm, to create a real image? Cause I'm lazy ;) I realized that there is in fact an easy way to get the results I want: td class=bad-bar width=1 img src=1x1.gif width=1 height=1 /td Finding or creating a transparent 1x1.gif shouldn't be hard :) 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: mauve results posted nightly
Brian Jones wrote: Stuart Ballard [EMAIL PROTECTED] writes: Couple of requests regarding the japitools output: 1) Could you modify your scripts to use the -q option to japicompat to turn off progress indicators, and redirect only stdout, not stderr, to the file that you publish? Done. Looks much better :) 2) Would you consider publishing the classpath.japi.gz file that's generated nightly? Done. Cool, I'll see if I can throw together an experimental nightly HTML-generating script in the next couple of days... You can see the kind of output I'm currently getting at http://rainbow.netreach.net/~sballard/japi/htmlout/h-jdk11-kaffe.html and http://rainbow.netreach.net/~sballard/japi/htmlout/h-jdk12-kaffe.html . NOTE: This is not an accurate representation of the state of Kaffe - not only is my kaffe.japi well out of date, it was also generated by a japitools version that had some bugs resulting in bogus errors. I expect the results with current kaffe would be much, much better. You'll notice there are some important things still missing, like the actual errors themselves :) The bar graphs work in Mozilla, look wrong in NS4.x due to my not having yet figured out a good way to get NS4 to display a 1px wide table cell, and are untested in all other browsers. Adding something like this to classpath should allow the japitools output to be generated on a machine with no non-free code installed. I would suppose that eventually a VM + classpath could run it anyway. Well, that was my point - my understanding is that it currently fails due to the fact that neither Classpath nor Kaffe have a working implementation of TreeSet.subSet(). I proposed a hacky implementation of subMap (which subSet depends on) that would be sufficient to give Japize a fighting chance of running. I think that subSet is the only part of *my* code that free VMs can't currently handle; I'm not sure whether they can handle Jode or not though. 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: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes: Brian Jones wrote: Why not use GD, http://search.cpan.org/author/LDS/GD-2.041/GD.pm, to create a real image? Cause I'm lazy ;) I realized that there is in fact an easy way to get the results I want: td class=bad-bar width=1 img src=1x1.gif width=1 height=1 /td Finding or creating a transparent 1x1.gif shouldn't be hard :) Don't use GIF due to licensing problems. I think JPEG recently became problematic as well. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes: Or is there something other than the compression that's bad about gifs? http://www.gnu.org/philosophy/gif.html If this web page is correct, GIF will be free next year. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
What's wrong with TreeSet.subSet? Let's get that fixed! Stuart Ballard wrote: Well, that was my point - my understanding is that it currently fails due to the fact that neither Classpath nor Kaffe have a working implementation of TreeSet.subSet(). I proposed a hacky implementation of subMap (which subSet depends on) that would be sufficient to give Japize a fighting chance of running. I think that subSet is the only part of *my* code that free VMs can't currently handle; I'm not sure whether they can handle Jode or not though. Stuart. -- 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: mauve results posted nightly
Stuart Ballard [EMAIL PROTECTED] writes: Couple of requests regarding the japitools output: 1) Could you modify your scripts to use the -q option to japicompat to turn off progress indicators, and redirect only stdout, not stderr, to the file that you publish? Done. 2) Would you consider publishing the classpath.japi.gz file that's generated nightly? Done. Also, what time does the script run (so I can set up my script to run later, so I get the latest japi file)? Currently involves two stages, stage one some user other than myself obtains source via anoncvs, does stuff, runs tests, makes results available to me. I publish them myself. Results currently posted at 2:00 AM EST. Adding something like this to classpath should allow the japitools output to be generated on a machine with no non-free code installed. I would suppose that eventually a VM + classpath could run it anyway. -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Hi Brian, So barring accidents of nature or human error I'll hopefully be able to post nightly Mauve results for Kissme/Classpath starting today. The Classpath homepage, http://www.classpath.org/, has been updated with links. I have added japicompat results against 1.1 and updated to japitools-0.9. Please let me know if posting this information in this way is useful. I think that this is VERY useful. Perhaps other JVMs could be added. Does Gcj do this? Maybe a Sun JDK 1.4.x for reference? If you have time to work on this, it would be a good idea if the web page and results defined the testing methodology, to aid people in reproducing the test results. * The log report should include datestamps for the latest sync with Classpath, Kissme and Mauve CVS repositries. * the web page should document the hardware and OS platform/version, the C Java compilers and versions, and versions of key libraries used (e.g. glibc). * The Mauve keys file used should be linked to the page, or available some other way. It should be version controlled, as it will surely change over time. Here are some other suggestions: * The web page could explain that there are many possible causes of test failures; e.g. Classpath bugs or incomplete feautures, Kissme bugs, Mauve test case bugs, and (even) Sun JDK bugs and incompatibilities. [Also, note the possibility of network failures, and failures caused by non-atomic CVS commits.] * The nightly test results should be archived, with the archive ideally accessible via the web page. It would be very nice if the web page could graph the numbers of tests passing and failing over time!! But that could be a lot of work to set up. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Stephen Crawley [EMAIL PROTECTED] writes: Maybe a Sun JDK 1.4.x for reference? It's possible, if it helps. I may set this up under tinderbox. If you have time to work on this, it would be a good idea if the web page and results defined the testing methodology, to aid people in reproducing the test results. Yes, I have the scripts if anyone wants them... but they aren't refined enough to checkin to cvs I think. * The log report should include datestamps for the latest sync with Classpath, Kissme and Mauve CVS repositries. Basically the date on the comparison files represents the approximate time of the CVS sync. * the web page should document the hardware and OS platform/version, the C Java compilers and versions, and versions of key libraries used (e.g. glibc). My home box, Red Hat 8.0 GNU/Linux, jikes 1.17, glibc 2.2, linux 2.4.18. I don't have anything else but Windows. I think if I get tinderbox setup then people with other configurations could run a client there to report those results. * The Mauve keys file used should be linked to the page, or available some other way. It should be version controlled, as it will surely change over time. It's in Classpath CVS, mauve-classpath. Here are some other suggestions: * The web page could explain that there are many possible causes of test failures; e.g. Classpath bugs or incomplete feautures, Kissme bugs, Mauve test case bugs, and (even) Sun JDK bugs and incompatibilities. [Also, note the possibility of network failures, and failures caused by non-atomic CVS commits.] It could, but this (nightly Mauve) is an end product for developers, not users. You already know these things and I don't have to explain it to you. * The nightly test results should be archived, with the archive ideally accessible via the web page. It would be very nice if the web page could graph the numbers of tests passing and failing over time!! But that could be a lot of work to set up. Yeah, I think of lot of what you want is tinderbox. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: mauve results posted nightly
Brian Jones wrote:
So barring accidents of nature or human error I'll hopefully be able
to post nightly Mauve results for Kissme/Classpath starting today.
The Classpath homepage, http://www.classpath.org/, has been updated
with links. I have added japicompat results against 1.1 and updated
to japitools-0.9.
Couple of requests regarding the japitools output:
1) Could you modify your scripts to use the -q option to japicompat to
turn off progress indicators, and redirect only stdout, not stderr, to
the file that you publish? That'll give much cleaner output - for 0.9 I
specifically tweaked the output so that doing this would give all the
output you need, and none you don't (that's why the 0.9 output looks
worse than 0.8.x with what you're doing now, because all the summary
information goes to both stdout *and* stderr, so it gets into your
output twice, and I removed all attempt to flush the streams in a
coordinated fashion to get a nice order, because it's unneeded if you're
only using one stream).
(When running manually, redirecting only stdout and *not* giving the -q
option will give you the usual pretty progress indicator while still
giving the exact same output file).
2) Would you consider publishing the classpath.japi.gz file that's
generated nightly? I'm working on HTML output and probably within a
couple of days I'll be able to set up a script to pull down the japi
file and publish an experimental HTML-ified comparison nightly. Later,
if other projects do the same thing, it'll provide a useful way to
experiment with side-by-side comparisons of, say, Kaffe's compatibility
versus Classpath's (which is a future feature I want to add to the HTML
output, although it might take a while). Also, what time does the script
run (so I can set up my script to run later, so I get the latest japi file)?
By the way, it occurs to me that japize could probably be freed from its
JDK dependency by even an extremely naive implementation of
TreeSet.subSet (or the dependency TreeMap.subMap). I'm thinking as
simple as:
SortedMap subMap(Object from, Object to) {
TreeMap result = new TreeMap();
for (Iterator i = entrySet().iterator(); i.hasNext(); ) {
Entry e = (Entry) i.next();
if (((Comparable) to).compareTo(e.getKey()) = 0) break;
if (((Comparable) from).compareTo(e.getKey()) = 0) {
result.put(e.getKey(), e.getValue());
}
}
return result;
}
(untested code, but you get the idea). Japize doesn't depend on anything
complicated like being able to modify the subset and having it reflect
on the original set, and its use of subset isn't performance critical,
so this implementation should be just fine. Adding something like this
to classpath should allow the japitools output to be generated on a
machine with no non-free code installed.
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: mauve results posted nightly
Brian == Brian Jones [EMAIL PROTECTED] writes: Brian Please let me know if posting this information in this way is useful. Brian Perhaps other JVMs could be added. Does Gcj do this? Mark Wielaard posts nightly test results to the gcc test mailing list. As I recall he does this for a couple platforms. I usually just glance over these; a mailing list isn't that great of a format for detecting regressions. Ben Elliston is working on a Tinderbox-like system. It will include gcj test results. Ideally it will also send out email when someone introduces a regression (like Geoff's old tester, but it will include libgcj). Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
