This is the mail archive of the eclipse@sources.redhat.com mailing list for the gcj-compiled eclipse project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Recognizing gcj as default StandardVM (JRE System Library)


>>>>> "Jan" == Jan Schulz <jasc.usenet@gmx.de> writes:

>> It took me some time to convince eclipse to recognize gcj/gij/libgcj as
>> standard vm.

Jan> Does this mean that eclipse will run with a (patched?) gcj as
Jan> '*/bin/java' (not native, but in the VM)?

What Mark is talking about is using the JDT with gcj.  Right now that
is not easy to set up.

Note that once you have it set up, it still isn't perfect.  There is
no way to debug this setup with the JDT debugger.  One idea to make a
gdb wrapper that can speak JDWP.  I'm not sure if we're going to do
this or not.

Jan> [running natively]
Jan> What will happen with all the plugins? Are they still recognised when
Jan> eclipse is started as native binary? Are they still runable? 

We compile all the plugins we can, but not all of them are compiled.
In some cases libgcj is missing a needed package.  (And in some of
these cases we could remove a class or two and make it work -- e.g.,
sharing with the precompiled ant and tomcat is on our to-do list...)

So, we can still interpret the plugins that are not compiled.

One thing we'd like to do is modify the PDE to teach it about gcj.
Then it would be really easy to compile your own plugins.  This would
probably speed up compilation as well, since right now we just stick
everything on the class path for each compilation -- ugly.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]