The executive director of the Eclipse Foundation, Mike Milinkovich, recently told us that "We don't really have a relationship with Sun...I've made numerous entreaties to try to engage Sun with Eclipse, from Jonathan Schwartz down, and I've never had anything other than 'thanks for calling'."
Sun's Dan Roberts, director of marketing for developer tools, insists this is not the case. "We're always open to conversations with Mike, he knows that," he says. But he adds: "We're firmly committed to the Netbeans platform. It is the core piece of our development strategy for tools."
Now wind back to January 2004, when Sun appeared more interested in cooperation. In an open letter (here), Sun declared: "We hope in the near future to find a solution that benefits both the Eclipse and NetBeans communities in very visible, open ways, where Sun can be an open contributor to Eclipse, and Eclipse can do the same for the NetBeans platform."
So what went wrong? "At that time we were in deep conversations with them about ways we could work together, "says Roberts. "Unfortunately as with many business conversations you're not always able to reach a consensus on what would be amicable terms for both parties."
Clearly one of the issues was SWT, the windowing framework used by Eclipse. "We had hoped that we could get IBM to work with us on improvements of Swing," Roberts told us. "Back when they started SWT development Swing wasn't as fast as it is today, it didn't have easy integration with platform standard look and feel. We understood back then why they were thinking about other technologies for windowing kits, but we did feel that it was a little bit of a step back towards AWT."
AWT was the original windowing API for Java. Still, Roberts says SWT is no longer the issue it was. "We think that there are some technology advantages today to Swing, but we're certainly not in a situation now where our relationship with Eclipse is hung up over a particular technology choice made years and years ago."
We then asked Roberts why JSR 198 (here), a Java Community Process standard for extending Java IDEs with plug-ins, was completed without the involvement of Eclipse, the leading example of an extensible Java IDE. "If you look at the list of contributors to 198 you'll find quite a few core Eclipse partners," he says. "It was understood that those partners would ensure that there was compatibility with Eclipse. So Eclipse was included, maybe not by name directly, but it was included."
Still, the comments made by the Executive Committee in the final approval ballot for JSR 198 reflect some unease. "There is no technical reason why this API could not be implemented in Eclipse," said BEA, abstaining, "but I doubt that it will be, given current industry momentum and most people will see that as confrontational."
Today, Sun is comfortable with the status quo, according to Roberts.
"We're quite happy with the momentum and direction we have with Netbeans, and we're quite happy that Eclipse exists. Eclipse several years ago was relatively far ahead of Netbeans from a technology and functionality standpoint, and Eclipse really made Netbeans a lot better. The competition between us is a good thing for Java developers against the proprietary closed-source models that others are using to compete against the Java ecosystem," he says.
So, that's all clear then, isn't it? ®