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."
A development tool that is built upon a non-open architecture is "useless" for the free software community? But a sort-of-working substitution remedies the problem?
Hmm.
Well, SWT is cool, really cool, and fast. (java it's just a wrapper for the native objects (gtk, motif,windows,etc.)), but , although I've worked with eclipse from some time now (6 months almost) I think that Borland's Jbuilder IDE it's the best so far. It's slower than eclipse, but it offers much more features. And ... i'm so used to it :) ....
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.
.NET resolves many of the features that are inherently lacking in java imho.
.NET specs before you flame people for not providing a comprehensive list to supplement everything they say, instead of hiding in your anti-ms hole.
Take a look at a comparative analysis of c# to java and c++.
some features I particularly liked: delegates (and resulting event support), properties and indexers, and collection management.
Perhaps you should look at the c# and
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 predict that the SWT libraries will not only get quite expansive... but include things other than GUI widgets/toolkits
;)
SWT library already does include GUI widgets/toolkit.
You are right though, saying that it is immature. We've been doing some serious development on SWT trying to convert full featured application from AWT to SWT. So far it's been going great.
However, here's a warning for all of you Java developers: there's quite a few things you still can't do. All Table work is a terrible hassle, there's no easy way of changing colors in single table cells and table functionality is very, very limited. We were able to improve some of that, but that actually ment implementing our own widgets for table. Anyways, it is pretty bad. Hopefully in 2.2 version (next year) they will solve some of the problems.
If anyone from Eclipse development community is reading, please, focus more not on the new features (cheat lists, wizards and stuff), but try to actually make SWT a reacher platform, there's a lot of work that needs to be done.
At the end, I wanted to summarize my opinion of SWT, which is not really what this topic is about. But here it goes: it is a great platform and a great concept (using native libraries and not drawing everything like Swing does). And you are correct - this will/could be Java's savior on the client. But anyone who would want to write a serious application in SWT should think twice before that, wheigh down all pros/cons and also try writing a prototype to make sure that it you can implement anything that you want.
One of the biggest innovations of SWT is a library called JFace, which hides a lot of basic/low level GUI functionality under an interface that is sort of a Model-View-Controller framework. This idea is brilliant, and this framework is just a pleasure to work with.
Anyways, enough with the rambling.. Happy Christmass, everybody!
http://dtum.livejournal.com
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.
SWT seems like a cool idea, but with its close coupling to Windows (Windows is the farthest along -- the other bindings seem to be "under construction"), how is this different than (gasp, choke, gag) J++?
Oh come on! At least SWT bindings for Linux and Solaris exist, they can exist in the first place, and you can assist in their development. How long do you think you would have to wait for Microsoft to release Linux and Solaris versions of the Windows Foundation Classes?
Basically, I think the effort of the Open Source community, of those that like Java, would be much pretty spent on making GCJ integrate seemlessly with a compliant Java VM using JNI.
I doubt that it would be practical. JNI does a lot of bookkeeping and is doomed to be far slower than whatever internal calling convention a JVM uses. You'd lose whatever advantages native compilation may have.
I hope developers would rather innovate and improve the java standard than to fork off a clone.
How can they innovate that for which they have no source code? The free implementation must come first. First they make it complete, then make it fast, then make it better.