Re: Re: LibxmlJ formalities

Tom Tromey wrote:
> Julian> But meanwhile I learned that gcj generally doesn't work well when fed
> Julian> jars, and generally _does_ work well when fed only .java source codes.
> 
> That's interesting.  Do you remember what problems you've had?

Only class interdependency problems. Let's say I have a1.class, a2.class,
b1.class and b2.class, wrapped into a.jar and b.jar and interdependent in
some way (a1/a2 uses b1/b2, or vice versa.) Now, saying
   gcj -o ab_app a1.java a2.java b1.java b2.java
will work (only for me?), but saying
   gcj -o ab_app a.jar b.jar
won't, at least if a.jar and b.jar's classes have been compiled with a
non-gcj compiler. Also, the following won't always work:
   gcj -classpath includes/every/class -o a1.o -c a1.java
because it would bitch about not finding classes a2, b1, b2 - though they
are on the classpath - even if you put both the source and the classes on
the classpath.

This essentially means that I end up with a single gcj invocation in
which I specify all files individually on the same command line. Works,
but isn't particularly elegant - and leads to awful turnaround cycles,
given gcj's overall performance.

As for Xalan.jar, I use the binary distribution. Don't know with what
they compiled it.

> Usually I find that compiling from .java is worse, since the parser
> (well, really the analysis phase) has a lot of bugs and oddities.  I
> know there are some bugs reading bytecode, though.  I'm wondering if
> you ran into those, or if you've found new ones...

Funny, it really turned out the exact opposite for me. Hmm. Well, gcj's
compile-time behaviour is not very predictable, but at least the
run-time behaviour of the stuff produced by it is...

 > Also it depends a lot on how the .jar was made.  Recently I've
 > discovered that both jikes and the Eclipse java compiler generate
 > bytecode that gcj's verifier erroneously rejects :-(.  The Sun (and
 > IBM) javac seems not to do this.  (I'm more or less actively working
 > on fixing this set of bugs.)

I noticed that too in 3.2. But this doesn't really hold true for 3.3,
which I found very compatible with a variety of class files. I'd be
surprised if 3.3 would eat each and every class, but for me it works
decently in this regard. It's just the interdependency or perhaps better
classpath issue that keeps me from feeding jars and classes to gcj.

> There's really only the stuff in gcj.texi.  Here's what I found:

I didn't know these, but sadly they aren't very telling either...
thanks for your help, anyway.

> Anyway, just because xalan exists, it doesn't affect your work, I
> think.  A high performance implementation is cool, especially since it
> wraps a library that every Linux distro is already going to ship.

Right, but gcj is an interesting topic. Its a beast, but I'm amazed at
just how flawlessly it does its job - as long as you know how to work
around it's little quirks.

Julian