Sun and Eclipse part 3: Who's eclipsing whom?

Sun and Eclipse part 3: Who's eclipsing whom?

Summary: This is the last of a three-part series on the possibilities of Sun joining the Eclipse Foundation. In this part I'll discuss the two remaining "conditions" that Sun had for joining, analyze reactions to this possibility, talk about reasons a partnership would be a good idea, and provide some predictions for the future.

SHARE:
TOPICS: Oracle
5

This is the last of a three-part series on the possibilities of Sun joining the Eclipse Foundation. See parts one and two for background information. In this part I'll discuss the two remaining "conditions" that Sun had for joining, analyze reactions to this possibility, talk about reasons a partnership would be a good idea, and provide some predictions for the future.

#2: Eclipse compiler vs. javac

Javac is Sun's implementation of the Java compiler."If [the Eclipse compiler] were vastly superior, I’d consider that". There are other implementations, most notably the open source Eclipse compiler. Eclipse's compiler has a batch mode where it behaves exactly like javac so in many cases it can be a drop-in replacement. It takes the same Java source code, passes the same compatibility tests, and produces equivalent byte codes. It also supports incremental compilation, has good diagnostics, speed, and hooks for syntax analysis.

There are some who are concerned that two different Java compilers might have small differences, leading to subtle portability or compatibility problems. Sun's director of Java Tools Tim Cramer is apparently one of these people, because he would prefer to see everyone settle on a single standard compiler, preferably Sun's. Tim writes:

Sun has a perfectly good compiler and it has hooks, etc... in it as well.  Why would we throw it away for a different one?

One problem is that Sun's javac is not open source, so it cannot be used in certain places. For example Tomcat ships with the Eclipse compiler in order to help translate .jsp files into byte codes for execution. Let's suppose that Sun changed the license so that problem went away. Which code base should be used then?

How about evaluating the compilers objectively and picking one on its technical merits? This might be an option, according to Tim. "If [the Eclipse compiler] were vastly superior," he says, "I'd consider that." I think the Eclipse compiler group would probably feel the same way. Anyone up for a compiler shoot-out?

#3: The name

It turns out the name "Eclipse" came from a meeting in January 2000. It was picked because it started with an "e" (e-business what the buzzword of the day) and because the team wanted to "eclipse" Visual Studio. Everybody involved has said repeatedly that it wasn't intended to be a slight against Sun. But both sides have been trying to "eclipse" each other since then.

The name issue was raised in 2003 and an offer was made at that time to change the name if that's what it would take for Sun to join. Of course, now Eclipse has 3 more years of marketing and name recognition behind it, some of it in arenas where they're making .NET vs. Java decisions now. All kidding aside, would it really do a service at this point to the Java community to change it?

The reaction 

After I wrote the first two parts of this series, EclipseZone came out with a story on it optimistically called "Sun ready to join Eclipse. Pigs fly, news at 10". From the comments we found out that Tim Cramer circulated an internal email responding to the article and indicating "We're not joining Eclipse Foundation". Presumably this was to settle any fears about big changes in the group.

Many people seem to be under the impression that joining Eclipse means losing one's competitive advantages, or being forced to adopt certain platforms and technology, or having to wait for Eclipse release schedules to come out with new software. In fact, members are free to use whatever technology on whatever schedule they want to. A company can be as involved or uninvolved as it wants to be, with membership ranging from free (nonvoting) to $250K/yr with a seat on the board and leadership of at least one project.

Why bother?

So what could Sun bring to the table that the Eclipse Foundation needs? In Tim Cramer's words:

  1. Uniting the java and eclipse communities.
  2. Plenty of innovation including:
    • Java Studio Creator capability
    • SOA tools
    • Business integration
    • Matisse
    • Profiling
    • etc....

EclipseZone editor Riyad Kalla writes:

If the real goal here is to combat .NET adoption, having fragmented Java is a real problem.

And then there's the question of user focus. NetBeans evangelist Roman Strobl writes:

I still wish all the best to Eclipse and hope the project can get back it's focus on building productive tools for developers.

Perhaps within the Foundation, Sun could act as a champion for the user tools to counterbalance the platform focus of many of the members.

Conclusion

Will Sun join Eclipse? When I first started writing this series I was hopeful, but judging by the reactions on both sides I'd say now we're as far away as ever from this happening. I think the main reason is that most people are not affected by the negative effects of the ongoing rivalry and are happy with the status quo. As Riyad puts it:

If the last 2 years is indicative of how Sun is going to play and how the JDK is going to get enhanced as long as they have a mortal enemy, I would almost suggest that we prevent Sun and the Eclipse foundation from ever joining.

People see things like Swing improvements and Matisse that were arguably a direct response to Eclipse, and they don't see all the duplication, inefficiency, and lost opportunities that are the darker side of this competition.

History is replete with examples of "mortal enemies" becoming fast friends. And in a world with Microsoft, Ruby, PHP, Linux, Web2.0, and other forces knocking on the door, these two need all the friends they can get.

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.

Talkback

5 comments
Log in or register to join the discussion
  • Sun's Fears

    I think the real problem is not the competition between Eclipse and Sun but the fearful handling of IP by Sun. If Sun would open the access to their source code, a lot of the duplicated work could be reduced without sacrificing the competition.

    As is, Sun sees how fast Eclipse evolves but can't match the speed because they just don't have the same magnitude of manpower.
    digulla
  • Not Enemies...

    Hi Ed,

    Mike beat me to the punch:
    http://milinkovich.blogspot.com/2006/05/no-enemies-there.html

    I'm not sure the Ecosystem would completely agree with the last statement inferring (unless I've misread) that PHP, Ruby, Linux and Web2.0 are "mortal enemies" with Eclipse and SUN. There's lots of great stuff going on with Eclipse and PHP, Ruby, Linux, AJAX, etc. The Eclipse platform benefits and these newer technologies benefit by having an open and ready-to-go platform on which to start development. It's win-win and I'm always looking for more of this.

    - Don
    DOSmith
  • Good series

    Ed,

    Congratulations on the good series. I think you made a very good point that Sun (and others) can join Eclipse but not lose their competitive advantange. Lots of ISVs do this today and it is a model the we like to encourage.

    I think there are a lot of people that would like Sun to join Eclipse, but I do have to agree that I can't see this happening soon. However, I know we at the Foundation would welcome Sun joining if they want to participate.

    Ian Skerrett
    Director of Marketing
    Eclipse Foundation
    IanSkerrett
  • RE: Sun and Eclipse part 3: Who's eclipsing whom?

    I know i'mn late to this but here goes. When it comes to swt vs. Swing, who or what dictates that you have to use one or the other, why not use both? Get the best of both worlds, swt for those parts of your app that you want to look native to the OS and swing in those parts that swt doesn't provide the fuctionality you require?

    As a java developer with no religious views on the subject I want to just use what I need to get the job done even if it means mixing and matching and possibly having some things lok a little out of place.
    sysop-dr
  • RE: Sun and Eclipse part 3: Who's eclipsing whom?

    In case you'a propos belief considered for <a href="http://auedtabs.com/">viagra</a> happiness later <a href="http://auedtabs.com/">viagra</a>, subsequently <a href="http://nzedpills.com/">buy viagra</a> is absolutely the thing you chief <a href="http://edPillenLaden.com">viagra deutchland</a>|<a href="http://maigrir-beau.com/">phentermine</a>
    viagra good