Sun Drops Bid To Join Eclipse
ilovestuff writes "According to ZDNet, Sun Microsystems has decided not to join the Eclipse open-source tools effort backed by rival IBM. In addition to dropping the plan to join Eclipse, Sun said Wednesday that it will no longer try to merge the Sun-sponsored NetBeans.org open-source Java tools project with Eclipse. The Eclipse open-source project, founded by IBM in 2001, is an IBM-owned consortium which has gained the membership of several development tools companies over the past year."
What the original poster neglects to mention is SWT only works on a fairly limited number of platforms, whereas Swing works wherever you can get a modern Java VM running.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
Swing depply depends on presence of working AWT implementation, it just does not use widgets defined by AWT but rather render them on its own. On the other hand SWT does not need anything from java.awt.
There are many clean room implementations of JVM (kaffe, gcj and a few proprietry projects) that do not provide working AWT and it is simpler to implement SWT for them then the AWT subset required for Swing. That is why one can already uses gcj to compile SWT applications but not Swing ones.
Check out Subclipse. I haven't tried it myself (since I don't use subversion yet). It looks fairly feature complete though.
The difference is significant, actually. For example, the Aqua look and feel has been considered one of the most complete Swing L&F engines. However, the file chooser dialog looks the same in a Swing application running in Panther as it did running in Jaguar. And in fact, it does not resemble neither Jaguar nor Panther's file open dialog.
The new implementation of tabs (NSTabView/JTabbedPane) in Panther is a row of buttons instead of tabs. The buttons do appear in a Swing application using JTabbedPane, _but_, the inside of the tabbed pane is only partially shaded when it's supposed to be entirely. This looks terrible since it's partially native but not-quite-there.
Eclipse's SWT has neither of these problems, nor does it have dozens of other problems that Swing has in Aqua.
A lot of the points you make have been (somewhat) solved with the JDK 1.4.2.
With the GTK+ and Windows XP look 'n feels, Swing programs look like native programs, and adjust themselves to whatever theme you have set up (it only supports the Bluecurve engine for GTK though).
There's more info on it at GnomeDesktop.org
The integration problems you talk about unfortunately still exist, but at least it can look better than plain old metal look 'n feel.
If only I could come up with a good sig
in my biased perspective, SWT is a much better set of API and the framework is well thoughout. I've written GUI's to use either one, but it is usually easier with SWT. One noticeable different is tree and treenodes. to get a custom looking tree, you have to write a custom tree model, whereas in SWT it is much easier. Most of the companies that I know of are choosing to use SWT and most of the momentum is with SWT these days. Swing is becoming less popular. Eventually, Sun will have to migrate to SWT and eclipse, but by then most of the stuff will already have been ported by the community. Sun isn't stupid, and they do have to support their existing products written in Swing and for NetBeans.
VB projects are painful to maintain, impossible to port, and don't follow logically (at least to me). I use a custom-hacked pure python editor to edit python. It runs wherever python does. Python runs everywhere.
What are the most useful features do you think VB provides which Eclipse lacks? Especially with new Visual Editor Project(VEP), I don't think Eclipse actually falls behind VB even it's VB.NET. On the other hand, I think strong refactoring support and variety of third party plugins (which counts over 400 already) are what made Eclipse popular today. And both of these are non-existent in any of the VS.NET products.
I know SWT is not yet ready for prime yet. And surely any Java IDE can't compete with VS in making desktop applications running on Win32. But, I believe the whole point of the original post is whether Eclipse as an IDE is superior to VB or not. It's not the question of if SWT-Java is more suitable to ActiveX-VB in developing win32 desktop applications. All of the features you've mentioned are of ActiveX, not VB and not VS. And while I admit language independence is a nice thing, I don't think it's more important than platform independence in most of the cases. You can easily find some successful cross platform softwares, but you won't find too many successful projects which are built by 2 VB programmers, 1 Cobol programmers, 3 C programmers, and etc. - It won't affect customers at all, while being complete disaster in management aspect . And as far as cross platform capability is concerned, VB.NET won't help you much. Anyway, even in end user desktop applications, I believe Java/SWT/Eclipse/GCJ combination have tremendous potential than you might expect. Current VEP is for Swing only as you've mentioned, but SWT version will arrive at the 1st quarter of next year. And with these combination, you can easily build cross platform native applications. Third party SWT/JFace components maeket is non-existent yet, but you should consider there're much more high quality opensource third party non-GUI Java libraries than MS counter part. And to return to the original point, I think Eclipse is far superior to VB as long as features as IDE are concerned.