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."

Comments

Should have been under: Science - Astronomy

[Domini]

Perhaps Sun has a problem with the name ' Eclipse', fearing they may lose out?

-grin-

Real reason

[jsse]

Can be found in the last paragraph of the article:

Apart from the technical differences between Eclipse and NetBeans, Sun had some concerns that Eclipse was dominated by IBM, Green said. In September, Eclipse set out to restructure its membership model to gain independence from IBM and established a board.

Sad, but no surprise

[jtheory]

I think almost everyone involved agreed (and still agrees) that it would be cool for NetBeans and Eclipse to share a plug-in architecture, and even underlying framework code. It would allow a great leap in pooling OSS development resources, and would be a boon for plug-in developers, which in turn would help to make Java with *free* tools a better platform than competing MS technologies.

I wrote a version control plugin for JBuilder -- yet another IDE with its own plugin architecture -- and I'm currently learning the Eclipse plugin architecture so I can port it... yes, it sure would be nice if I could just deploy it as is to other IDEs!

But... I suspect that the whole merging idea was mostly conceived by management types who got a rude awakening when they started talking to the tool developers and found out what kind of effort it would take to actually do it.

The work involved would be mind-boggling... and it's not the sort of thing that would draw open-source developers. It definitely scratches an itch to implement that feature you've been longing for in your IDE of choice (which is why it's often easy to get lots of contributors to a good IDE; look how quick the Eclipse community grew!). But I'll be damned if I'm going to reimplement the same thing two years later for free.

The next version of any tool after it's been ripped apart and reassembled is usually much worse than the last version, too. I remember when JBuilder first switched to a version written in Java (3.5)... it hurt to see how many important features were broken or removed. Sure, you understand that this will help in the long run, but you don't want to be around while it fights it way back to mature status.

So would Sun and IBM be willing to pay what it would really take to get there? It would have been nice, but I'm not surprised the answer was no.

Why the hell haven't they just bought IntelliJ?

[GOD_ALMIGHTY]

Seriously, JetBrains can't be much. It's a company with one product that is based in the Czech Republic with offices in Russia and Boston.

IntelliJ is light years better than Eclipse or Netbeans. Why is Sun still putzing around? Buy JetBrains and call IntelliJ NetBeans.

Not to mention that Eclipse has got a hell of a better chance of competing with IntelliJ than NetBeans. They really need to move NetBeans into something more complete. MS is running so many circles around Sun in dev tools it's not funny. The goal of 10 mil Java developers ain't happenin until Sun pulls it's head out of it's ass and makes sure that the Java platform has top notch tools that can compete for novice developers with MS.

No loss

[Earlybird]

Eclipse doesn't need Sun. Eclipse has, all on their own, managed to create an incredible piece of engineering that brings Sun's technology work to shame.

As an Eclipse user and plug-in developer, I would rather see Eclipse evolve freely than see it encumbered by the huge porting effort required to merge it with Sun's technology.

The fact that SWT (Eclipse's GUI toolkit) and Swing (Sun's) are incompatible as far as philosophy and vision are concerned is also significant.

SWT lets Eclipse and users develop portable programs that look and behave exactly like native applications: on Windows my app will look like a Windows app, on Linux it will look like a GTK+ app, and so on. Swing, on the other hand, is a platform in itself; it does provide some hooks for native technologies (printing, mouse wheels, etc.), but it will never adapt to changes of the local platform. SWT apps, since they use native APIs, do; for example, on Windows 2000 Eclipse looks like a Win 2000 app; on XP it looks like an XP app, with no additional theming support needed in the toolkit.

Re:No loss

[Lao-Tzu]

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.

Re:No loss

[Earlybird]

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.

Yes, Swing runs wherever you want, but the problem is that (a) it looks like crap, and (b) it doesn't integrate fully with the parent operating/windowing system. The former is less important if you only care about functionality; the latter is extremely important, period.

Non-native-looking/-behaving apps alienate users. Swing apps aren't affected by native themes, for example. I remember back when Swing didn't support the mouse wheel on Windows. Swing apps don't use Windows' native file dialogs. Consider accessability; Windows, Mac and GTK2 all have extensive APIs and technologies for screen reading and so on. Does Swing support them?

SWT already runs on a wide variety of platforms, and it's "driver" is small enough that adding support for new platforms isn't that much work. And the benefits are enormous.