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.
I am not sure I understand the "Not Quite Ready" comment. I have been using Eclipse as my main IDE for nearly a year and I love it. Eclipse is just the framework to build the IDE you desire. Eclipse is complete, there are just some pluggins that aren't ready yet, however they are comming along very fast. Just last night I started using the Lomboz J2EE pluggin and so far I have been pretty impressed. http://www.objectlearn.com/ Also, I get all my plugins from: http://eclipse-plugins.2y.net/eclipse/ I might not be up on all the politics of programming, but I know I didn't pay for Eclipse and no one has asked me for anything to use it. So it appears pretty damn free to me. I recommend Eclipse to everyone.
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.
Why is there a big deal about this, other than the promise by IBM and making good that promise? Anjuta DevStudio, which is one of the best GUI IDE's on Linux IMHO, supports Java. I personally havean't gotten into Java, so I could care less about this, but Anjuta is fully GPL'd already.
-- DuckWing
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!
...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 :) ....
Please tell me you don't use JBuilder's Designer. We had a developer who liked to use it a lot. He stopped a year and a half ago, and we're still mopping up the damage! Everything looks like
flowLayout1 = new FlowLayout();
label2 = new Label();
panel3.add(button8);
panel6.add(panel4);
label2.setText("Welcome!");
panel7.setLayout(borderLayout6);
and it goes on and on like this for a couple hundred lines! With not a single local variable in sight- JBuilder declares them all as instance fields! Oy! Unless you keep these window classes tightly segregated from the manually edited code, and ONLY touch them with the Designer, they become unmaintainable monstrosities. Adding a single button or textfield is inordinately painful. As for changing the layout- you might as well do a rewrite.
I've become good at deobfuscating JBuilder's crap. First remove the 30 BorderLayout fields, FlowLayout fields, etc. Then gradually rename the "panel8", "button3", to sensible names, and remove redundant ones as you find them. Then get some graph paper out, and go slowly through the jbInit() method until you see what's going on. This will let you get rid of 90% of the instance fields in the class.
Layout code is tedious, but there's no excuse for not doing it manually unless you're not worried about maintainability. In fact, one thing I like about IntelliJ IDEA is the lack of a GUI designer.
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.
"There was only one catch, it was build on top of the proprietary java platform. This made it useless for the Free Software community."
There is plenty of java code that has been released under the GPL and BSD licenses. The only way that java would be useless to someone is if they turned their nose up at it. Turning one's nose up at something for non-technical reasons is usually a bad idea.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
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.
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?
AWT/Swing doesn't have or need bindings because 1) they are 100% Java or 2) to the extent that they are not 100% Java and need to JNI down to something, that something is distributed with the Java VM that appears on each machine, so you don't need to distribute any platform specific AWT/Swing bindings with your app.
SWT needs separate bindings for each target platform -- it becomes like wxWindows or Qt in that regard. If you want to distribute an SWT app, you need to distribute those bindings, or tell your users how to install the right binding on their machine. But then you are into a bindings model rather than a true "write once, run everywhere" model.
My remark about J++ may not be completely off the mark. To the extent that C# is in reality J++, and that WFC was transformed to System.Windows.Forms, and to the extent the Mono is going down the bindings road to port System.Windows.Forms (to answer your question, 2002 - 1997 = 5 years to get Linux and Solaris versions of WFC), and to the extent that Miguel gets lambasted for doing what he is doing, why should Eclipse/SWT get a free pass for doing a similar thing with Java?
.NET is one of many things, depending who you talk to in Microsoft's marketing dept. First I'll define that. Forgive me if it's review.
.NET: C#, VB.NET, C++.NET, and JScript.NET. C# is first among equals, but VB.NET can do anything C# can do, again because the CTS/CLS is "the language". .NET just gives you a syntactical skin on top of this abstract language.
.NET good at?
.NET could be seen as the next step in evolving binary interop. I.e. in DOS, it was TSR's and interrupts, in Win 3.1/*nix it was DLL's and pointer-tables, in Win95+/Gnome/KDE it was COM or CORBA components, and in .NET, interop is at the CLASS level. They've basically learned the Java/JAR model of interoperability, then abstracted it to multi-languages (they just call JAR files "assemblies")
.NET makes all languages equal. This was painfully NOT TRUE in COM programming! Almost all of the plumbing underneath COM was to support Visual Basic's interoperability with C/C++ components. .NET levels the playing field here, and people can't pick on VB anymore (other than its cheesy syntax). Anyone can throw an exception in C# and catch it in VB, or define a class in C++ and inherit from it in C#. And debug across all these languages in a single session, if need be. Quite liberating for system architects dealing with a large, multi-team project with reusable components and potentially different skill-sets (hence different languages).
.NET DLL's that are better than traditional Win32 COM DLL's: .NET uses it, sing the praises!
.NET is CHILD'S PLAY compared to some other platforms. Especially with Visual Studio. They've really made distributed interoperability easy -- though of course none of this will scale or be bulletproof without real engineering work, but that's never been Microsoft's game -- let J2EE vendors do the dirty guinea pig work, they'll copy it into Windows/IIS eventually.
.NET really is about making Windows developer's lives A LOT EASIER. Which really was all that Visual J++ 6.0 was about before they decided to "break" features for political reasons. .NET is appropriate as a new standard for dynamic languages like Smalltalk, Lisp, Haskell, ML, etc.
.NET but you have to contort it into classes & methods if you want to interoperate with any other .NET language... this is what the C++ people have to do too! (i.e. no more templates, multiple inheritance, at least until .NET 2.0 :) .NET isn't the second coming, though many Missy-followers think it is because their intranet is locked to http://msdn.microsoft.com and really don't have a lot of exposure to the alternatives out there (i.e. J2EE or perhaps PHP, Python, Ruby, etc.)
Here's the things that it isn't (in reality):
- A new server platform (MIcrosoft marketed it as such, even though there really isn't anything new in their Windows 2000 lines of servers yet).
- A some new magic technology (i.e. the marketing idea that MS Passport became Passport.NET and thus was embued with a +6 long-sword)
Here's what it is:
- The common type system, language spec, and language interface. (CTS, CLS, and CLI). It's a way of getting several languages to interoperate through a virtual machine.
- The Common Language Runtime (CLR) for Win32. This is the Virtual Machine. It's as fast as Java 1.4 in some ways, slower in some ways, and over 2x faster at certain operations like object creation. Ya gatta hand it to Microsoft's x86 team, they know their stuff.
- The following languages are released by Microsoft for
- The Base Class Libraries (BCL), ASP.NET, COM+ (aka Managed Components), and ADO.NET are included.
- The ECMA standards body has been submitted the CLI, CTS, CLS, BCL, and C#. Mainly for show, but maybe something good may come from Miguel et al.
What's
- It's a much better way for binary module interoperability than COM was. Viewed this way,
The language-interop issue at first glance seems like a red herring feature, but in fact it's rather important from a programmer's sociological perspective. VB and C++ programmers are naturally opposed to each other in philosophy - their means and ends do not peacefully coexist.
Things you can do with
- The Windows Registry is NO LONGER NEEDED. Nothing in
- Easy and Flexible Side by side versioning. An app that links against a version stays with that version unless updated or a sysadmin coerces it to use a newer DLL version.
- No filename conflicts (i.e. no 2 vendors with MYSILLYLIBRARY.DLL overwriting each other -- each DLL has a public key stamp)
Other things... Making web services in
So -- you see,
The jury's still out as to whether
I say it's more about "syntax skin" than "flexibility". Certainly you can write Lisp onto
-Stu