Slashdot Mirror
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."
GCJ aka "native Java" now really seems to be ready for its day under the spotlights.
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.
Sheesh, evil *and* a jerk. -- Jade
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?
if(!cool) exit(-1);
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.
I don't know how much of this potential is actually realized in JITs (it's insanely hard to do) and how much of a difference it makes in the end. How substantial would the difference between a specialized AMD vs Intel optimziation be, for example (which would presumably depend on the task)?
I suppose the best possible world would be to have the optimization run exactly once, the first time you install a program. (Yeah, you could conceptually move the same installation to a different CPU, or add more RAM, or some such, but let's not make an already messy issue even messier.)
I doubt such things are easy to benchmark, and the best test may well be something like this (gcj'd Eclipse), where the end result to the user is "which one feels faster?" and "which one actually runs faster?"
From your comments it's apparent you're not a Java programmer then, because you merely repeat old complaints that are no longer valid. Ok, sure, the JRE takes up a bit of space but compared to the size of hard drives today the amount is trivial. Having the JRE on disk is like installing the MS or Borland libraries (or Linux counterparts) that some applications use - once it's there other applications don't have to include the code as part of the executable.
Swing suffers from obesity - what does that mean?
I've been developing Java applications for years (including a stint as project lead on a weather satellite imagery analysis program) and I know firsthand how much Java has improved. Spend some time writing applications in Java, using Swing (I use Netbeans for my IDE)...you'll see how sporty applications can be. Also check out Sun's Java Games community for some links to games that really exhibit excellent performance.
And [Java] continues to be hyped, and is being used less and less, as the speed continues to hamper it.
Java is still some 40 times faster than Python. As hardware speed continues to obey Moore's law, performance per clock cycle becomes less important. (For many areas of computing anyway.)
Thanks to the expected slashdotting, this is just one more eclipse I can't look directly at.
I wrote a simple JVMPI method tracer. It's mind-blowing what all happens before your code is actually run. Here's a method trace I just ran with 1.4.2 for a simple program.
-Kevin
Of course, I don't see myself as a "Java programmer" or a "carpenter" or a "brick layer". I wouldn't take any pride in that. I have a degree in computer science...
To further extend your knowledge in computer science, look into the Internet tool called "Google". Using it can save you from ridiculing yourself by publicly posting uneducated statements:
Embedded Java
But seriously, would it kill the poster to include the tiny little fact that gcj stands for "Gnu Compiler for Java?"
Probably not. Nor would it have kill him to explain that a compiler turns source code into a binary executable for a particular architecture, or that IDE stands for Integrated Development Environment, or that a JVM is a Java Virtual Machine, or that RPM stands for Redhat Package Manager, or that GTK+ stands for GIMP ToolKit, or that now it is now used for far more than just GIMP, or that GIMP stands for GNU Image Manipulation Program, or that the included acronym stands for Gnu's Not Unix, or that GNU is a project to write free implementations of operating system components derived around the POSIX model, or that POSIX is a collection of operating system standards based around tradional Unix interfaces.
Doing all of these at once, however, would probably piss everyone off. Explaining just the particular missing piece of information that a specific reader is going to need would be better, but would require Slashdot readers to be more homogenous and Slashdot posters to be more psychic than they are.
The compromise, wherein the word "gcj" is linked to a web page entitled "The GNU compiler for Java", seems to be hard to improve upon.
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.
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.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
For those who start up their IDE in the morning and close it down in the evening (or at the end of the week, whatever), then long startup times are just a minor cost of doing business.
For someone like me, however, who is ambivalent about this IDE or that IDE, and whose fingers are too hard-wired for one particular editor to use the brain-damaged editors foisted by most IDEs, startup time IS a big issue. When you are going in and out of tools all day long, it becomes a major annoyance to have to wait for the darned thing to start up.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
Often the JVM will out-perform GCJ with a factor of 3. Check out the numbers on this page.
I fail to see why people want to run a GCJ compiled evrsion of a development tool and run at at one third of the speed of the JVM, just in order to save a few seconds of startup time.
A quick test (using an Eclipse 2.1.1 from eclipse.org):
:)
Eclipse 2.1.1 with JVM
- Second start: 13 seconds
- Memory Eclipse: 80 MB
- Memory JVM: 65 MB
Eclipse 2.0.1 without JVM
- Second start: 9 seconds
- Memory: 96 MB
The download page seems to indicate you're downloading an Eclipse 2.1.0 version, but the about dialog says 2.0.1. Which one is it?
Cheers,
Thimo (back to coding in Eclipse 2.1.1
Avoid the Gates of Hell. Use Linux!
Dynamicity? No. Java is a aggressively static language.
Static types perhaps, but very dynamic when it comes to linking. Java has a lot of support for things like dynamic class loaders that lead to a very nice plug-in architecture, and extreme flexibility when it comes to deployment of code updates to a running application. Not to mention fun with diddling bytecodes on the fly.