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."
As someone who has written several Swing based applications, I can say that Java sorely needs this kind of a shot in the arm for the client-side to be even remotely feasible.
Up to this point, Sun has ignored the client-side, and rightly so. Because Microsoft and MFC rules on the client side (on Win32). Sun exploited the server-side breach that Microsoft had ignored.
But now, Java needs to become a viable alternative to C++ based programming on the client-side. And the only way this is going to happen is for Java to have some kind of a native GUI presence on each platform it runs on. This is where IBM and the SWT libraries come in.
Currently, the SWT libraries are still immature. The Eclipse platform itself is still immature. But they will get better and better. I predict that the SWT libraries will not only get quite expansive... but include things other than GUI widgets/toolkits.
If IBM plays their cards right (and so far they have)... 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.
Personally, I would have no problem with writing a Java application that only imported IBM extension libraries. As long as they were well-written, and performed well.
Sun really needs to get on the ball here. The time has come to open-source Java. Let the developers do with the language what needs to be done to bring it to the next level.
Otherwise... companies like IBM are going to do it anyways. Just using extension libraries. If Microsoft was smart, they'd have done five years ago what IBM is doing now. Microsoft would own Java on the client-side if they would have played it right.
Well, why do you use Emacs instead of vi? Or ed? Or writing to disk using very, very small magnets?
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
I think that the Java libraries will be very difficult to control fully by Sun, because they do not have IBM and Oracle to push around. IBM will absolutely not be backed into a corner by one of their main competitors in hardware, Sun. Because of that, I'm not worried about the Java APIs turning into a controlled arena, as Microsoft has done with Windows.
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. GCJ could used to make a just-of-time optimizer. With C# and dotNet, I think there's an ahead-of-time compiler instead of a just-in-time compiler that can optimize the byte code for the target machine. Using GCJ/GCC, one could get that sort of performance boost, almost for free, if it were plugged into a compliant Java VM, meaning that it could integrate with DLL/DSOs using the Java Native Interface.
Anyway, I, for one, would probably not waste my time using a slightly out-of-date API, on a slightly behind-the-curve VM or compiler. (BTW, I'm a heavy user of emacs, perl, mozilla, etc.) The java API, language and VM still has a LOT of room for improvement. I hope developers would rather innovate and improve the java standard than to fork off a clone.
Eclipse is an IDE without all the crap you usually associate with an IDE. JDE isn't bad, but it's nothing like Eclipse. Eclipse's debugging support in particular is way better than JDEs (which took me some hours to configure properly). Not to mention that Eclipse let's you do really neat things, like stop the debugger right before an exception was thrown, fix the bug, and continue with the debugging as if nothing had happened!
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.
People authoritively claim that Microsoft will use patents to kill these efforts if they become competitive, but there is no evidence to support this paranoia, and in-fact Microsoft does not have a histroy of abusing patents in this manner
.Net:
.NET framework, Ballmer announced that there would certainly be a "Common Language Runtime Implementation" for Unix, but then explained that this development would be limited to a subset, which was "intended only for academic use". Ballmer rejected speculations about support for free .NET implementationens such as Mono: "We have invested so many millions in .NET, we have so many patents on .NET, which we want to cultivate."
Incorrect in every regard.
Microsoft has already used patents to attack open source projects, and has also used patent licenses to attack the GPL. Microsoft's highest executives have also stated publically that they intend to use patents against certain open source projects.
Examples
- no translation of ASF, WMA and WMV files to any other format.
- patent licenses granted only to non-GPL software
CIFS implementations
- royalty fees on file sharing extensions to SMB in Win2K and WinXP
- Nasty letters to certain Linux kernel developers working on NTFS support.
The Halloween documents also mention the possibility that Microsoft may use Patents to attack OS endeavors.
We also have comments from Mr. Ballmer regarding
Responding to questions about the opening-up of the
And we also have this:
Asked by CollabNet CTO Brian Behlendorf whether Microsoft will enforce its patents against open source projects, Mundie replied, "Yes, absolutely." An audience member pointed out that many open source projects aren't funded and so can't afford legal representation to rival Microsoft's. "Oh well," said Mundie. "Get your money, and let's go to court."
Any statement that Microsoft has not and is not likely to enforce patents in these areas is just not backed up by the history, or by public statements by MS senior executives.
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
Could one, for instance, now compile a Java program using the SWT library to a native binary using GCJ, so it could be run without using a JVM?
Yes.
SWT takes a middle ground between the extremes of AWT and Swing, and abandons a sacred cow of Sun's- the idea that the same binary must run on all platforms without any modifications. This attitude has really been an albatross around Java's neck and is the reason everyone thinks that Java applications have to be cheesy- because Sun demands that they must be equally cheesy everywhere!
AWT takes the approach that ALL widgets are drawn by the native layer. This isn't a bad idea, except that if no native widget is available (like a slider, or tree), AWT refuses to improvise one at the Java level. This is why there are no sliders or trees in AWT, even on platforms like Windows where native widgets for both are present, because there's some platform out there somewhere that doesn't have them. Maybe AIX or something, who knows. AWT is strictly lowest-common-denominator and that's why everyone hates it.
People bitched and moaned. So Sun went straight to the opposite extreme with Swing, which refuses to even consider the native widgets. Instead, it uses Java level methods to draw pictures of them to fool you. This means that Swing can offer you a "pluggable look and feel", so you can have Motif buttons on Windows, or "Metal" buttons on the Mac! Except nobody cares. Microsoft promptly kicked Swing in the nuts by introducing skins with XP, so it becomes obvious what is really Windows and what is pretending to look like Windows but can't keep up. And Swing suffers greatly from the second system effect- it's overengineered as hell. A Hello World in Swing gobbles up 20 MB of overhead- mostly classes loading and initializing themselves. In fact, Swing is why AWT is still alive. AWT sucks, but you can run a program that lasts for more than a couple minutes with it. Writing stable applications with Swing is a real art. (It is in AWT too, but only because Sun has pretty much left AWT flapping in the wind with minimal improvements, maintenance, or bug fixes. Since Swing came along, AWT has been treated like a red-headed stepchild by Sun.)
SWT is much more like AWT than Swing, except that it takes a practical middle ground- something Sun doesn't seem capable of doing at all! It offers you a nice set of native widgets. If a slider or a tree isn't available on some platform, they draw a picture of one for you. This might make sliders and trees look funny on platforms that lack sliders and trees, but you would expect things to look funny on those platforms. People using Windows (i.e. most of them) aren't bothered by any of this.
This sacrifices binary compatibility. Each platform has its own version of the SWT library. For example, there is a Windows specific swt.jar and a swt.dll that goes with it, and there is a Solaris version of swt.jar and a native swt.so library that it uses. Even though the libraries are implemented completely differently, the public interfaces are the same. So if you develop a program against the Windows version of the SWT library, you won't have any problem compiling against the Linux version. (Although I've heard that SWT blows on Linux, but that was a while ago and I don't know what the current state is.)
SWT doesn't abstract much away from you, unlike AWT, where you are separated from the low level GUI details by a leaky abstraction. In SWT you have to write the frigging event loop yourself! (Which is not a big deal- it's a while loop, usually two lines.) There are a few other gotchas, and you absolutely have to test a SWT program on all platforms you're releasing for, but in practical terms the same was always true for AWT because of the leakiness of its abstraction. SWT at least doesn't pretend that you don't have to worry about this stuff.
This means you have to compile and test a program three times before releasing it, once for Windows, once for Linux, once for Mac. This violates Sun's sacred cow of binary compatibility. But when you're releasing a Java application, you're going to make separate installers for each platform anyway, because you have to bundle a JVM for everybody. So it's not really a big deal, unless you're writing an applet- and applets went the way of the dodo long ago in no small part because of AWT and Swing!
With SWT, you can make really nice, professional looking programs. The layer between you and the OS is very thin (JNI). If your program looks silly or stupid, it's YOUR fault. When the user changes the skin in XP, your SWT programs will pick up the change right away. In fact, it isn't even obvious that you're not using C! You can write your stuff in Java and actually get away with it! So that's why I think SWT is the future (if there is any future left anymore) of Java on the client, and why I will be junking AWT/Swing completely when starting new projects.
For more info see the SWT FAQ. There is some GCJ and SWT info available here.