[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpathx-discuss] Re: LibxmlJ formalities

From: Julian Scheid
Subject: Re: [Classpathx-discuss] Re: LibxmlJ formalities
Date: Thu, 27 Feb 2003 01:57:47 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126

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
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
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]