Slashdot Mirror
GNU Christmas Gift: Free Eclipse
Mark Wielaard writes "Your friendly neighbourhood GNU did
it again. A year ago IBM made much noise
about placing $40 million of its software tools under a free software
license. Technically these tools, called Eclipse, are great for developing
(java) software. There was only one catch, it was build on top of the
proprietary java platform. This made it useless for the Free
Software community. Luckily the GNU project has two projects that come
to the rescue. GNU
Classpath, core libraries for java, and gcj, the GNU Compiler for Java.
We are now able to run Eclipse on a completely free platform! It is
not yet complete, but you can already edit, compile and browse CVS
with it. And since Eclipse uses GTK+ it also looks very nice. I setup
a page with
instructions on how to get this working so you can help us make
it work even better or just so you can view a couple of nice screenshots."
If you define the "Free Software community" as the zealotous 5% of free software users who refuse to use software that hasn't been blessed by RMS, you're right.
For the rest of us, Eclipse has been useful (and free and open source) for over a year.
I've been following both of these projects for years.
The point that so many have missed is that this shows how close the GNU implementations are to be being a complete JDK replacement. Eclipse is a very complex beast that uses nearly all of the Java APIs. This achievement shows the quality of the years of work that has gone into these free projects. All of this work is now finally ready to pay off.
Congratulations to the whole ClassPath and GCJ teams!
-Avery Regier
I've written quite a few Swing & server-side applications myself.
.NET. And Visual Basic rules on the client Win32 side, and has for quite some time.
.NET first. WinForms.NET is effectively the next iteration of what was out in Visual J++ 6.0's WFC libraries.
"Microsoft and MFC rules on the client side (on Win32)".
MFC is dead, long live
"But now, Java needs to become a viable alternative to C++ based programming on the client-side."
Absolutely not. Java's only main competitor for Win32 client-side supremacy is VB.NET and C#.NET. C++/MFC is a dead-end.
On UNIX, I would suggest it's a toss-up between C++/Qt and C/GTK, and IMHO I think Java's more productive than either (though pre-1.4 X-windows Swing performance was unacceptable).
Sadly, this doesn't seem to be a battle that Java will win on Win32, even with SWT, for a couple of reasons. Microsoft has the industry's talent in developing high-performance Win32 GUI framewords, which will come out for
They also have the tools support with Visual Studio. The Java world currently has only *ONE* usable GUI building tool -- JBuilder. And that's not saying much. Eclipse won't have one for some time. The second major problem with Swing (besides performance) was this lack of tools support. I don't forsee a groundswell of tools support for SWT from multiple vendors.
Thirdly, there isn't a whole lot of impetus behind client-side "thick" GUIs in the industry. I don't foresee IBM throwing lots of money at making SWT general-use... the open source community will probably assist in this area, but I'm somewhat skeptical about how much adoption this will generate.
On the bright side, I'm not sure it really "matters". Windows peeps will write stuff with VB like they've always done, the C++'ers will switch to C# (they've really not much choice -- I worked at an MS shop as the Java junkie for 2 years, most C++/Windows programmers there took what MS has given them... there's a lot of shock and dismay when Borland/OWL is on one's resume). The 2nd most widely used GUI framework family will be (gasp) Carbon/Cocoa on Mac OS X. ANd rounding out the list, *nix peeps will continue head-butting between Qt and GTK+ (both of which are still gawdawfully ugly IMHO, quite apparent actually if you run a GTK+ app side-by-side with a Mac OS X application. But I digress).
"I can see them actually introducing more Java extension libraries for other things that Sun did a terrible job on. Collections. Better native threading model. Better I/O model. The list goes on and on."
Whoa, whoa! I disagree with each one of these. We are talking about J2SE 1.4, are we not? I'm quite happy with the collections framework (and I compare this to both stdc++ and the Smalltalk collections library), the java.nio.* package is very sophisticated, and IMHO the threading model is a matter of taste, not stemming from any particular technical disadvantage.
-Stu
The GNU folks had no hope of recreating a cleanroom AWT and Swing - it was just too bloody big and complicated. It would have taken at least 4 years to create a cleanroom Swing. Then along comes Eclipse/SWT which did all the hard bits for them in C. The result - a portable and very fast Java GUI. Now folks have a very good reason to work on GCJ because they can finally see some concrete results. Success breeds further success. .exe if you will) is a HUGE advantage for distributing applications. That 20 meg JRE is a complete pain in the butt for a client to download. It's much better to simply run a 5 megabyte GCJ-compiled application.
Compiling your application to a single binary (or
Java doesn't suck. Java's GUIs need not be slow. It was Swing that sucked. Finally people realize where to lay blame.
Sun - get rid of Swing once and for all! Swing is a poorly designed GUI tookit and a complete embarassment to Java.