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

Startup sure, but how fast does it run?

[iamacat]

From what I heard so far, gcj has problems with garbage collection and doesn't generate very good code. Did I miss any dramatic improvements recently? Also, how complete is the class library?

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.

load times

[khuber]

I still don't understand why load times are such a big deal. Do people sit there and start and exit applications continuously?

I leave stuff like mozilla, eclipse, and xemacs running for weeks on end.

Modified GCJ Required (for now)

[SilentMajority]

I found this info at http://gcc.gnu.org/java/

"A team of hackers from Red Hat has released RPMS for a version of Eclipse, a free software IDE written in Java, that has been compiled with a modified gcj. You can find more information here. We'll be integrating the required gcj patches into cvs in the near future."

ps

Slashdot preview is buggy today...can't do HTML format preview and links one or more spaces get embedded in URLs (like the one below).

---
My most underrated Slashdot post is http://slashdot.org/comments.pl?sid=68610&cid=6276 748

What is yours?

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:Total GCJ performance

[Anonymous Coward]

The intriguing idea behind JIT compilers is that the result can be optimized for your exact configuration (AMD vs Intel, particular kinds of RAM, etc.) It can even (conceptually) optimize the same program differently at different times depending on usage. At, of course, a startup penalty and runtime compilation overhead.

Oh, but there are a few fallacies associated with that.

The first and bigggest one, a pet peeve of mine, is that people claim that they can reoptimize the application repeatedly on the fly to make it run faster (your It can even (conceptually) optimize the same program differently at different times depending on usage). yes, while this is theoretically possible, the end result will be slower than a normal compilation. Why? Because since you want to check that the usage hasn't changed, you basically have to be running a profiled version all the time. Yes light-weight profiling exists, but it'll be slower than a fairly generic optimized version with no profiling.

Second, You don't need JIT to optimize for your specific setup. Think Gentoo. You can use all of the GCC optimization flags with GCJ and optimize for whatever flavor of processor you have. Of course, that makes hardware upgrades a pain, as you have to recompile everything, but whatever.

Third, I doubt any JIT compilers nowadays do anything different for different processor families, simply to keep complexity down. Heck, I'd be surprised if they used any streaming instructions or anything like that.

Fourth, how much time are you willing to give the JIT compiler to do its thing? With a compile-once system, you can let the compiler crunch on your large a pplication for hours if you want, and then distribute the binary to your clients. That is just not feasible in a JIT context, so the optimizations that can be done are limited (unless you do it in parallel with the app, which introduces profiling (see 1), and adds complexity to the JIT compiler (see 3).

Fifth, the only two situations where you care about speed are
- Batch programs, where theprogram runs continuously and you want it to finish quickly, so you don't want to waste any time on profiling and/or reoptimizing anyway.
- GUI responsiveness, where optimization is not as important as the desing of the GUI toolkit (For some reason every java app I've ever touched seems more sluggish than a similar (or any) windows app).
The third place where speed is important is games, but we're talking java here :-)

Sixth, if you're interested in optimizing towards your personal usage style (which loops will be executed more often depends of which features you use, and how, etc) you still don't need JIT. Look up information on profiled-directed optimization. Basically you build a version of the app with -fprofiler-arcs and use it for a while (it'll be slow) then recompile by feeding those profiles to the compiler (I forget the flag) and voila. The compiler knows the real probabilities of each branch being taken and can optimize accordingly. This works on gcc and g++, but I'm not sure whether gcj can do it yet (last time I tried using -fprofile-arcs with gcj it crashed because internally the profiling code in the back end tried to add a function with a variable parameter list (...), which java doesn't have, so the front end crashed).

There are more objections I had to the whole "JIT is the best ever" mentality, but this rant has grown too long, and I forgot the rest already.

(oh, yeah. Seventh, every program has bugs, and some only show up under certain very specific circumstances (using system.identityHashCode() will make the program depend on the memory layout to the point that some bugs will appear only some times. also race conditions and resource leaks). If you have a different version of your executables, you will hve bugs appearing only under certain configurations of processor, memory, etc. and dissapear suddently as the program reoptimizes, which makes it hell to track down or even come up w

Why JVM?

[be-fan]

I never really understood the whole point of the JVM. Why load this big program at every application launch? JIT still has more overhead than AOT compilation, in the real world, and most importantly, the huge memory footprint of the VM wreaks havoc on your caches.

What's the purpose of the JVM?

Dynamicity? No. Java is a aggressively static language. Meanwhile, highly dynamic languages like Lisp, Dylan, and Scheme (among others) can be efficiently compiled to native code.

Speed? While in theory a JIT can be faster, its not the case in practice. In the "Great Computer Language Shootout" (which isn't bad, as far as these things go) Java has an average CPU rank of 14, behind other static languages like C, C++, Ocaml, and SML, and behind dynamic languages like Scheme and CL as well! In reality, Java can only get within 90% of the speed of C for inner-loop numeric-type stuff (which lends itself to JIT optimization).

Flexibility? Java is highly inflexible. Its almost as as inflexible as C. It requires you to manually specify pretty much everything. You even have to do manual boxing/unboxing! Java is so highly structured, it should be compilable to native code that hits 90% the speed of C, without a very smart optimizer at all.

Safety? Given Java's lack of pointer types, it shouldn't need a JVM monitoring it to be safe. Again, there are lots of safe languages (Haskell, Clean, and the aforementioned dynamic languages) that don't require a runtime monitor.

Actually, I don't see much of a point in Java at all. Its got statically typed, but can't use that advantage to be as fast as C++. It runs in a VM, but can't use that advantage to be as dynamic as Python. Its syntax isn't any easier to use than something like Dylan (kinda like Lisp with a Pascal syntax) or Python. It doesn't have the development environment advantages of Smalltalk. Heck, its not even a very good compromise language ---- Dylan is as easy, often faster, and more powerful, Python is much easier (and thanks to Psyco) often as fast, C++ is much more powerful, as well as much faster, etc.