X
Business

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

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.
Written by Ed Burnette, Contributor

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.

Editorial standards