Re: [cdt-dev] Natively Compiled Eclipse Snapshot Available

[Tom Tromey <tromey@xxxxxxxxxx>]

>>>>> "John" == John Camelon <jcamelon@xxxxxxxxxx> writes:

John> Out of interest, what changes have you had to make to Eclipse to
John> make this happen?

Not many, actually.  For bug fixes I think we only needed one.  See

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=40972

There's also

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=29564

This one is only arguably a real bug.  libgcj has some minor
differences from the JDK in some places...


To make everything work all we really did is change the plugin class
loaders to look for a `.so' file and put it into the list of urls.  In
one place we had to change the API a little.  I'll put these patches
in bugzilla a bit later; first I want to get all the gcj/libgcj
patches in (there's some discussion of the names of things, which
would mean changes to the eclipse patches).


John> I understand that the patches are forthcoming, but I'm curious
John> if there are particular constructs that you could perhaps advise us to 
John> stay away from in an effort to maintain gcj compliance?

The biggest limitation of gcj is that the class library is limited.
There's no general rule for determining what can/cannot be used,
though.  So far we haven't had any major problems with this.  There
are some plugins we can't compile right now (e.g., ant has tasks that
use all kinds of crazy stuff, and I haven't had the time to strip out
the tasks that really aren't needed); that's ok, though, since we can
always interpret the plugins that we can't compile.  This works as
long as those errant classes are actually not used.

There are some oddities relating to the current gcj ABI; I had to add
a workaround for this in one place.  However, that's really our
problem, and we're planning to address it by changing the ABI a little
so that the compiled code will be fully compliant with java binary
compatibility requirements.

Tom