GNU Christmas Gift: Free Eclipse 320
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."
Keep the zealotry to yourself (Score:2, Informative)
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 (unlike another company I could mention [xml.com]).
Not Ready? Its all about the plugins. (Score:4, Informative)
Old news (Score:2, Informative)
Nevertheless, this is the best tool I've used, and really, thanks IBM for doing such a great and generous job. My point is - this is not really news, and have nothing to do with Christmass.
Cheers.
Re:Why should I use Eclipse instead of Emacs + JDE (Score:5, Informative)
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!
Re:I'm glad... (Score:3, Informative)
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.
Re:Keep the zealotry to yourself (Score:5, Informative)
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.
Re:I'm glad... (Score:2, Informative)
also, apart from being slow, jbuilder just generally comes across as bloaty to me. i mean, i'm sure _someone_ wants all that stuff, but it goes too far for me. while i was using it, i seemed to spend almost as much time wading through the docs as i did working.
aaalso.. it's really doesn't seem to like most open source stuff. unsuprisingly it's heavily biased toward the commercial appservers (i work with j2ee).
eclipse however, is fast (relatively), simple in terms of interface and finding the actual functionality you need, and has superb support for open and closed type plugins. cvs works nicely, ant works nicely, junit integration is great, and so on.
to me jbuilder is everything that CLI junies hate about GUIs, whereas eclipse is how it should be, minimum bloat, maximum functionality.
Re:SWT binaries? (Score:2, Informative)
Yes, absolutely. Get ftp://sources.redhat.com/pub/rhug/swt-gcj-green-s
Run configure/make/make install, and you'll en up with lib-org-eclipse-swt.so.
People are also building for Win32 using gcj for Windows (or a cross compiler from Linux)
AG
Re:SWT binaries? (Score:5, Informative)
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 [sun.com] 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. [eclipse.org] There is some GCJ and SWT [gnu.org] info available here. [ibm.com]
.NET in a nutshell (Score:4, Informative)
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