Fast Native Eclipse with GTK+ Looks 300
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."
Startup sure, but how fast does it run? (Score:4, Interesting)
load times (Score:3, Interesting)
I leave stuff like mozilla, eclipse, and xemacs running for weeks on end.
Re:Looks great! (Score:2, Interesting)
Modified GCJ Required (for now) (Score:4, Interesting)
"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=627
What is yours?
Another FOSS IDE. (Score:4, Interesting)
There is another FOSS IDE called gps [act-europe.fr]. 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:
Screenshots are available at the link above.
Hmm, slow (Score:1, Interesting)
Plugins? (Score:4, Interesting)
Re:Looks great! (Score:3, Interesting)
Unfortunately one of the reasons IntelliJ has got more expensive is because of its success. Its about 100$ more expensive now than when I purchased it. If you are doing a lot of Java development and dont have a compelling requirement for a GUI builder then I strongly recommend IntelliJ.
Where the **** is the Gentoo Ebuild for this? (Score:1, Interesting)
Seriously tho, I use VS.NET and Eclipse all the time. I find that both are extremely powerful when understood, both of their limitations and of their features.
For my java work, there's not really any point in using anything else 'cause Eclipse is what java IDE's are supposed to be.
JVM still a good idea. (Score:1, Interesting)
To stay on topic, Eclipse is very usable if you have enough RAM and CPU power.
On the company where I work we use Eclipse running on Pentium IV 2.4 with 1 Gb RAM, six developers can use it thought LTSP.
Re:Total GCJ performance (Score:2, Interesting)
That's not nearly as interesting as using runtime feedback to further optimize code. Static optimizing compilers need to make guesses about things, like how often loops are expected to run and which branches to to be taken more often. I don't expect to see a dramatic difference in Pentium IV vs. Athlon optimizations.
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 can tell you that it's not insanely difficult to do. Conceptually, compilers are compilers and optimization isn't that tough to do. JIT is just a tradeoff task, you set hard limits on how long optimizations can take and that changes the set of optimizations you can do. Pretty simple really, if you know how to build an optimizer you can probably build a JIT compiler and then you just tune the sets of optimizations to fit your task, ie run really fast. Bigger problem is we know a ton more about static optimization and compiling than dynamic so there are far more sophisticated static optimizations. We're just now doing things like exploring lowpower optimization, building research compilers to select instruction sequences that result in lower power consumption and stuff like that; I think that people also need to understand that optimization isn't a panacea. There is only so much that you can really expect no amount of optimization is going to make java code perform like C++ code right now, you need to make it take a lot less memory first, make it fit in to caches, etc... the -O20 flag isn't going to do that. Then there is marketing. I wouldn't expect a huge difference between 2 classes of x86 processors, x86 optimization is kind of a joke, there could be dramatic difference on PowerPC and other registery RISCy architectures but 90% of the market runs x86.
Re:Total GCJ performance (Score:3, Interesting)
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
Re:Startup sure, but how fast does it run? (Score:5, Interesting)
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 [sun.com] don't agree with your blanket generalisations.
Re:Startup sure, but how fast does it run? (Score:3, Interesting)
Gee whiz, you're a raving spastic.
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".
Right, and the day you get around to pulling your head out of your own ass - or at least do something to stop you talking so much shit all the time - you won't need to go around pompously saying, "I have a degree in computer science."
Who are you that you can say what can be important in someone else situation?
Has it ever occurred to you that not everybody needs the speed? Anyway, it's you yourself who is trying to say what's important for everyone else.
Because of the startup time issues you can't use Java programs in shell scripts.
Think Bash, think Perl, think Python, think Ruby. You'd use any of the former before you'd think about using Java OR C++. At least, being a CS grad, I hope you would - unless you had good reason to do otherwise.
And just to be picky, it's only the larger Java applications that will noticibly kill your startup times (Tomcat springs to mind).
Because of the size and footprint issues, you can't do embedded with Java. Now you're probably going to say that embedded applications are not important ...
GOOGLE FFS [google.com.au]
Couple of hits, couple of misses. (Score:3, Interesting)
Well...no. I believe that embedded environments are a rather stripped down form of Java, but Java isn't all that uncommon in embedded systems. Take a look at Javacard -- you'd use it in environments where you typically have less than 64KB of memory.
That being said, I *still* think Java is a terrible language for most people to be using. There's something to the argument that there's "not much better out there".
Problem: C sucks for general application development. A lot of people know it really well, but the whole point of C is that you get a lot of control over exactly what's going on [Disclaimer: I like C, and use it for my application development.
Problem: C++ is a *huge* language. I thought I knew it once, after a while using it, and then bought Stroustrop's book, and discovered all sorts of things, like autopointers, that I'd never heard of. C++ has a lot of syntactic overhead.
Problem: C# is made by Microsoft.
Problem: Pascal has vanished into obscurity.
Problem: Perl/Python/Ruby aren't as fast as their traditionally compiled equivalents.
Problem: Nobody uses eiffel.
Problem: Nobody wants to use functional languages, so ocaml and friends are out of the question.
So Java gets used.
I'm firmly of the opinion that Java has a good use -- distributed development.
The problem is that Java was built to make Sun (a hardware company whose primary claim to fame is easy "scalability" by buying higher end machines or more machines) money. Sun's big problem is that most people don't use their SPARC architecture. Java works for Sun by doing two very simple things. It's hideously resource-intensive, from a CPU and memory standpoint. It also is an easy language to easily speed up by throwing more machines into the mix. It doesn't make life a pain if you're using x86 clients with a SPARC server, like rpc can.
Oh, and finally, it has a lot of sexy features to draw people in. It's also a bit easier to learn and work with than C++.
So despite the fact that Java is incredibly slow and RAM-hungry, people bill it as the next big language, the replacement for C++. Frankly, I think Java should stay precisely where its strengths are -- it makes a hella nice language for doing distributed work (especially if you have a client with a front end), and lightweight networking. It's a lousy general purpose language, though.
Why JVM? (Score:3, Interesting)
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.
Re:Plugins? (Score:5, Interesting)
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:Why JVM? (Score:3, Interesting)
If I understand the myth/history correctly, it was made to run arbitrary code from an arbitrary source in an arbitrary environment, in a safe manner.
Sun needed something to load up additional code within a program which the original programmer didn't know anything about, get it from somewhere in the network at runtime, then run it in anything from a toaster to a cable-box to a PC to a cell-phone to a refrigerator.
And then somehow control the risk in that situation.
Dynamicity? Depends on what you mean with that word. Java is very strict about its static typing. When people talk about Java being "dynamic", I think they usually talk about dynamic class-loading.
Speed? I don't think speed has ever been a case for Java, except in the web-development community where it competes with Perl and PHP, and even then it lags behind other features.
Flexibility? Once more, it's not about the type-system. It's about loading arbitrary code into your application server without shutting it down, or worrying too much that the code will crash your system. It's about then taking that code and running it somewhere else, in other hardware, without making any changes.
Safety? The JVM is not there to check you're not messing up your pointers. It's there to check your bytecode is valid, has permission to do what it's supposed to do, and doesn't mess with anything it shouldn't.
It's there so that class you downloaded from an unknown source in Ukraine doesn't steal your credit info and reformats your hard drive because hey, it doesn't have permissions to do so!
Java is a language for a hostile (network) environment, where your code cannot trust other code any more than it has to. The main role of the JVM is not to be a portable interpreter for a friendly programmer language, it's to be a protective paranoid Big Brother for a bureaucratic programming language.
Re:GCJ performance is a myth. Benchmarks inside. (Score:2, Interesting)
(2) "Let's assume for a second that you are correct, and Java limits the platforms you can distribute to. Tell me again exactly how GCJ improves on that?"
Because GCJ runs on all the platforms gcc does, which is pretty much everything out there. Java officially doesn't run on all kinds of platforms. Linux is only supported on x86 and ppc, IIRC, not to mention the various BSD's...
Also, GCJ is free software, so that means that it if there's the will, people can and will port it.
Re:Startup sure, but how fast does it run? (Score:3, Interesting)
So do perhaps 90% of the people reading Slashdot. IMO it's not much to be proud of.
You're a pompous ass. He probably has better qualifications than you do.
Umm... no (Score:3, Interesting)