Fast Native Eclipse with GTK+ Looks

Mark Wielaard writes "The gcj team created a natively compiled build of the Eclipse IDE. The resulting binary starts up faster then with any traditional JVM since there is no virtual machine to initialize or slow byte code interpreter or just in time compiler involved. This means that gcj got a lot better since the last Slashdot story in December about gcj and Eclipse. Red Hat provides RPMs for easy installation. Footnotes has screenshots by Havoc Pennington of the Eclipse IDE with GTK+ widgets."

Comments

Another FOSS IDE.

[Black Parrot]

There is another FOSS IDE called gps. They call the unsupported version the "academic edition", but you can download the source, and a peak at a few files shows that it's GPL'd. (Their economic model is to give it away for free and sell support for those who need it.)

It's a cross-platform IDE, with binaries available for Linux, Solaris, and various versions of Windows, and in principle you should be able to build it on any *n*x system where you can get GTK2 to run.

The bad news is that language support is still limited. It has full support for Ada and partial support for C and C++, which are lower priorities for the authors. It comes with instructions for setting up support for your language, but that looks like a non-trivial task.

I've just started playing with it so I can't give a good review, but so far it has been very helpful. The features listed at their Web site are:

• Language-sensitive editor
  
• Automatic generation of body files
  
• Source code reformatting
  
• Intelligent source code navigation
  
• Context-sensitive search and replace
  
• Application builder
  
• Automatic code fixing
  
• Version control (CVS, ClearCase, etc.)
  
• Visual file comparison
  
• Graphical source-level debugger
  
• Project and program entities explorer
  
• Project wizard
  
• Types and program entities graphs
  
• Call graphs
  
• File dependency graphs
  
• Project dependency graphs

You can use the built-in editor or make it pop up your favorite editor. If you use the gnuclient Emacs interface you get the same kind of language-sensitive pop-up menus you get with the built-in editor.

Screenshots are available at the link above.

Plugins?

[connsmythe96]

The eclipse IDE is supposed to be extremely pluggable. How does natively compiling it affect that? Do you have to compile the plugins with the IDE? Or can you still just drop the .class files somewhere?

Re:Plugins?

[Per Bothner]

That was the case last time I looked at GCJ about a year ago. I ended up being unable to use it because of lack of windowing toolkit support. Anyone know the status on all that?

Eclipse uses its own SWT toolkit, which works well under GCJ. SWT is a combination of native code and Java, and is said to both be fast and integrate well with other window systems, as it uses native widgets when available.

The implementation of AWT (including applets) is coming along very quickly, but it isn't complete yet.

Re:Startup sure, but how fast does it run?

[iapetus]

I have a degree in computer science. The day you will get a college degree, or at least some formal qualification, you won't need to go around saying: I am a "Java programmer".

What utter garbage. I'd describe myself primarily as a Java programmer, and I've got a college degree, a masters degree and a bucketful of professional qualifications.

Who are you that you can say what can be important in someone else situation?

I don't know. Who are you that you can say the same? There are plenty of cases where Java can be used in shell scripts, or where the same functionality can be achieved using a tool such as Ant (which is very widely used these days). Startup time isn't always the be all and end all of what people need from their programs. If it is, then obviously there are better tools than Java. I'd have hoped that at some point they'd have taught you in your college degree that there are plenty of tools out there and that there's such a thing as picking the right tool for a given job. That tool may be Java, it may be perl, it may be lovingly hand-crafted assembly code.

The fact that you seem to ignore that means that you also ignore the things that you can do with the JDK that you can't do with gcj, and ignore the requirements people may have that your preferred way of working doesn't address. And also, it seems, the fact that some people don't agree with your blanket generalisations.