Re: mauve results posted nightly

[Stuart Ballard]

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/