Sun ready to join Eclipse, part 1

Sun ready to join Eclipse, part 1

Summary: By any measure, Eclipse and Sun's NetBeans have both been wildly successful. But from the beginning, Sun and Eclipse have had a strange and interesting relationship; sometimes friendly but sometimes not. Now the opportunity is greater than ever for the two to join forces to fight the powers arrayed against Java in the software industry. Recently I talked with Tim Cramer, director for Java Tools at Sun Microsystems, about this possibility.

TOPICS: Oracle

By any measure, Eclipse and Sun's NetBeans have both been wildly successful. But from the beginning, Sun and Eclipse have had a strange and interesting relationship; sometimes friendly but sometimes not. Now the opportunity is greater than ever for the two to join forces"If that’s on the table, I’d be willing to discuss it." to fight the powers arrayed against Java in the software industry. Recently I talked with Tim Cramer, director for Java Tools at Sun Microsystems, about this possibility.

In particular, I asked Tim what it would take for Sun to join as an equal partner in the Eclipse Foundation and collaborate with the other members. Up to now, the stock answer has been that it wasn't an option, but his reply was encouraging:

#1: Change the name :^)
#2: Stop fracturing the java platform
    - Don't use your own compiler, use the standard!
    - Don't augment the runtime with SWT
If that's on the table, I'd be willing to discuss it.

A little background is required in order to understand this answer.

Eclipse was the result of years of commercial and research work by a Canadian company called OTI, which was bought by IBM. NetBeans started as a student project in the Czech Republic called Xelfi, went commercial, and was bought by Sun. Independently, both IBM and Sun decided to make their software open source in order to gain developer mindshare; Sun in June 2000 and IBM in November 2001.

The problem has always been, and continues to be, IBM and Sun are fierce competitors. I can relate to that. I live in North Carolina at the nexus of three powerful college basketball rivalries: NC State, Duke, and Carolina. Since I graduated from State, naturally I have to root for my team and talk trash about the others at every opportunity. Except... when one of the other teams is the only one from our region to make it to the final 4 or the finals. Then, I'm in there rooting for Duke or Carolina with the best of them.

Now technically, IBM spun off Eclipse into its own Foundation 3 years ago. IBM has a seat on the board, but it's not a permanent seat nor do they have veto on anything - all the strategic members are equal. When Eclipse started, IBM accounted for 100% of the developers working on it, but now that's down to under 50%, especially on the peripheral projects. Most Eclipse projects are not lead by IBM employees anymore. But still, they play a major role and that has always made team Sun a little wary of the Eclipse team. 

The last time that bringing these two teams together was seriously discussed was in 2003. The proposal on the table at that time was that Sun would drop NetBeans and that Eclipse would change its name to something more "Sun friendly". However negotiations broke down and the idea was dropped.

Meanwhile the software industry continued its innovations. Ruby on Rails ascended, and PHP started getting more attention as a serious alternative for back-end servers. Microsoft finally came out with a new version of Visual Studio and is trying its best to dominate every aspect of development. Suddenly, the areas of disagreement between the two Java teams doesn't seem quite as important as they used to.

In my next installment I'll break down the conditions Tim lists to see if they're actually possible or not. After that I'll discuss the benefits of such a collaboration.

Related articles:

Topic: Oracle

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Are SWT and Swing Really Enemies?

    This is a copy of my (slightly off-topic) post to an Eclipse bug report:

    I used to think about the SWT versus
    Swing debate as a scenario of conflict. Supporting evidence here is the name
    choice ("eclipsing the Sun") and that some parts of the Eclipse API duplicate
    standard Java functionality (example: the file/resource API) instead of trying
    to fit in and extend it. But the more I reflect on this issue, the more I think
    there is tremendous potential for cooperation:

    - AWT is very limited: SWT could become a logical extension of AWT, its
    "migration path".

    - SWT has custom controls: which feels weird, because I always thought that SWT
    disliked custom controls and wanted native widgets. Here it might make more
    sense to migrate SWT's custom controls to Swing.

    - Layouts: Why can't layout managers be shared between SWT and AWT?

    - Data binding: this is such a fundamental GUI programming mechanism and yet
    there are competing standards being developed in both camps.

    - Less confusion: the partitioning outlined above would make it very clear
    which toolkit to use in which situation. Much like the Linux desktop APIs KDE
    and Gnome currently realize that it makes sense for them to work together.


    - Social hurdles: My guess is that the competition from SWT actually helped
    improve Swing; who knows if SwingLabs would have happened without it. Some of
    the current debate *sounds* like it is about cooperation, but I'm not sure that
    it actually is: If JFace binding invites Sun to join, it must feel to Sun like:
    "Give up your stuff, come to us and do it our way". I'm not sure how one can
    get out of this dilemma, but it is worth trying. A successful, brilliant
    example is the Annotation Processing API being adopted by Eclipse.

    - Technological hurdles: I do not know if SWT and AWT/Swing can (technically)
    be made work together in a more integrated fashion, but it sure would be nice
    if this were possible.
    • SWT and Swing

      I'll have more on SWT and Swing in the next part and I'll try to address most of the issues you raised there. Thanks for the feedback.
      Ed Burnette
  • Sun and Eclipse

    Part of me wonders how serious Tim is with his comments. That
    being said... I don't see the point about SWT. In comparison the
    compiler comment has some validity. Efforts could be merged
    to enhance one compiler instead of two. SWT versus AWT/Swing
    is too far to just drop and make nice by everyone using Swing
    however. What is done is done. Each architecture has pluses
    and minuses. A better response from Tim if Sun really wanted
    to cooperate would be to concede and just offer SWT as a part of
    future releases of JSE as "AWT 2.0" with the engineering support
    coming from Eclipse. A similar example would be JEE and
    Hibernate. Hibernate became a clearly established technology.
    Sun could not say Hibernate "go away". A large part of the JEE
    API looks like Hibernate as a result. I'm not saying Swing
    development should stop either. There if fantasy "SWT go away"
    and reality "SWT is too established" to go away however.
    Scott Delap
  • Choice is good!

    Sun readily acknowledge that the main reason they devoted so much effort to improving NetBeans was the competition from Eclipse. Now Java developers have a choice between two great open source IDEs, which is two more than .NET developers have.

    So why is it necessary to limit the choice of compilers to one (javac) and the choice of graphical toolkits to one (Swing)? There are valid reasons for giving developers a choice in these areas.

    Furthermore, javac is not open source and therefore cannot be freely redistributed in open source projects that need to do Java compilation (eg JSP containers).

    Many such projects are moving to the JDT compiler for exactly this reason, so if Sun want their compiler to be the "One True Java Compiler", they MUST open source it.
  • I really like SWT and the compiler

    I must say I really like SWT because it gives me features Swing doesn't (anti-aliasing on Windows, native dialogs with all shell extensions) - yeah, I know, it's supposed to be in Java 6 but I won't adopt a brand-new JDK anytime soon. And I really like the incremental compiler in Eclipse - just thinking that I have to kick off an Ant build to see what's wrong in the code (Netbeans) is painful.

    At this point, I rather have Eclipse competing with Netbeans and pushing each other forward than losing SWT and the incremental compiler.
  • The SWT API and it's look and feel

    For all of Swing's faults, I've seen more Swing apps that blend better with the Look and Feel of the platform than SWT.

    Look at Writely, it looks just like an Office 2k3 app. Can you do this with SWT? Where are the 3rd party SWT widgets for me to buy when I don't find what I'm looking for?

    Disposing of colors and fonts also just seems like it doesn't belong in a Java toolkit! I know there's good reasons for this, but even with those, it just doesn't fit the Java model to manage things like Colors at that level.

    I really like the Eclipse RCP, and I'm willing jump into SWT programming, but the lack of components and the API is really making me hesitate!
    Augusto Sellhorn