eclipse and gcj

Tom Tromey tromey@redhat.com
Sun Oct 13 11:04:00 GMT 2002


Recently I did some work on trying to get Eclipse working with gcj.
Mark Wielaard suggested I post a note about it here.  Eclipse is an
open-source java-based IDE from IBM; see http://www.eclipse.org/

I think there are 3 ways to approach eclipse+gcj:

* Compile Eclipse from source with gcj (I didn't try this at all)
* Compile Eclipse from bytecode with gcj
* Run Ecilpse bytecode using gij


Compiling from bytecode seemed like a promising first step: we can
avoid bugs in the gcj front end, and we don't have to touch Eclipse's
build process (which until recently wasn't even available).

We're missing some packages that parts of Eclipse need: javax.net
(including javax.net.ssl), javax.management, javax.mail.  Ant,
included in Eclipse, also references some classes in com.sun.tools
:-(, so probably upstream changes to Ant would be required.

Some of these dependencies probably aren't really required and could
be worked around.  For instance the jakarta-regexp package requires
GridBagLayout -- but as Eclipse uses SWT and not AWT, this class won't
in fact be used at runtime.  What to implement and what to omit is
definitely worth looking into.

I was trying to do a full link when I looked into this stuff; I didn't
try building each library separately and then letting Eclipse use
class loading to load the libraries.  So what I did was just remove
libraries until I could get a full link.

The result tried to start up, but failed.  As I recall the problems
start because Eclipse relies on the ProtectionDomain for a class being
set to something sensible; it uses the CodeSource in the domain to
look for other files it needs at runtime.  Gcj-compiled native classes
don't have this information set the way Eclipse expects, so problems
ensue.  This is another area that could use careful investigation.


The other thing I tried was running Eclipse with gij.  This seemed
like a promising idea since it would let us see problems in our
runtime coverage.  Unfortunately the problems come rather quickly.

First, Eclipse makes heavy use of ClassLoaders and expects them to
work properly.  We've always been a bit weak here.  In the end Andrew
wrote a patch to let us handle ClassLoaders properly.  This required
some gcc changes that I think he's still negotiating to get checked
in.  Once his patches go in, I have some supplementary patches to fix
a few related problems in libgcj.  (This means that more work down
this avenue would probably be blocked pending these patches.)

Second, there are still unfixed bugs in the libgcj bytecode verifier.
One of these is already a PR; the others I found during this process
are basically variants of the PR.  Quick fixes failed; in the end I
just disabled the verifier in an attempt to make progress :-(.

At this point I ran into a memory corruption problem.  It looks to me
like a premature object collection or perhaps a heap overwrite.  I
spent some time looking into it, but not enough time, and then the
clock ran out.

What I found when taking this approach was that we never got out of
the Eclipse startup; every bug in libgcj would cause Eclipse to halt.
However, the startup has gotten progressively further.  I suspect we
aren't too far from being able to start a minimal Eclipse under gij --
but this is mere suspicion and I have little evidence.

Tom



More information about the Java mailing list