Eclipse and Sun, SWT and Swing
Tim: How do you characterise the relationship with Sun? Eclipse is not part of the JTC [Java Tools Community], and Sun is not part of Eclipse.
Mike: The JTC is not actually part of Sun. Usually the question is why aren’t we part of the JCP [Java Community Process]. The reason we are not part of the JTC is that it is established basically to be an influence on the JCP. Since we are not part of the JCP it makes no sense to join the JTC.
Tim: So why not join the JCP?
Mike: Let’s talk about Sun first. The relationship with Sun is large and complicated, because Sun has several different facets to it. I personally break down our relationship with Sun into three different areas. There’s our relationship with NetBeans; there’s our relationship with Sun as a software vendor; and there’s our relationship with the JCP. Our relationship with NetBeans is effectively competitive. We are trying to attract mindshare and adoption by developers in competition with NetBeans. In terms of Sun the software vendor, the relationship right now is surprisingly quiet. I think they should be doing more with Eclipse, because of Eclipse’s adoption rate, and because of Eclipse’s success in the market. To the degree that Sun wants to make its JavaOne platform more attractive to developers, I frankly think that they should be doing more with Eclipse than they are currently today.
By the way, every conversation that I’ve had with Sun since I joined Eclipse has been professional and cordial. The press consistently tries to portray the relationship with Sun as conflictual. In my experience in the job to date, it is not. It is just people doing different things in the market, following different strategies. It doesn’t mean that anybody’s mad at anybody. Anyway, the JCP. Right now, we implement JCP-based APIs on a regular basis. Part of the definition of the scope of our web tools project, of the J2EE sub-project within that PMC, is that we are implementing J2EE specs. So we regularly implement JCP specs, and that’s what we see part of our mission to be. We are in the Java world, we implement specs on a regular basis, but we’re an open source project not a standards organisation. I don’t see anything in any way competitive with the JCP and Eclipse. We support standards. Right now Eclipse has not joined any standards organisations. We’ve certainly talked about it. I expect that we will do so in the future. When we get to that point, the JCP is certainly on my list of standards organisations that we would consider joining when the time is right.
Tim: Clearly many of your members are in the JCP.
Mike. Absolutely. So I don’t see the relationship with Sun or the JCP as being in any way conflictual. When Sun decides the time is right for their business, they will I’m sure decide to do more work with Eclipse than they are today.
Tim: I guess one of the factors in the relationship with Sun is SWT [Standard Widget Toolkit] and the Rich Client Platform. Can you explain the benefits of adopting SWT, both in the tool itself and for developers considering it for their own applications?
Mike: Let’s focus this first on SWT. First and foremost, there’s been a lot of ink put into the SWT versus Swing, again trying to portray the thing as somehow conflictual. My view is that SWT – and I should mention, I was not involved in Eclipse at the time SWT was first created – I’ve been the executive director of Eclipse for roughly three months now. But my view is that SWT is trying to address quite a different set of requirements than what Swing was. So the first thing is you have to start with your viewpoint when you begin a project. When Sun did Swing that project was clearly about how do you build a user interface framework for Java, for people who write in Java, who knew that they were going to be using Java applications and wanted to leverage all of the write-once run-everywhere benefits of Java.
The design requirements that were the start of SWT was actually quite different. Since its inception Eclipse has always been about more languages and more platforms than Java. We write tools for embedded development, we write tools for C and C++, for Cobol, and that was part of the original vision of Eclipse. It’s always been about more languages and more platforms than Java. We happen to write in Java, but that’s a different thing. Given that different set of requirements, SWT was begun as a project because the feeling was that Swing did not provide the level of integration with the platform that non-Java developers would be happy with. So given that differing set of requirements, the logic for first of all creating SWT, and the logic for when developers would want to use SWT I believe becomes pretty clear. If you want to develop in Java but you want your runtimes to be clearly integrated with the underlying platform, and basically make it such that the end user in no way can tell that you had written this in Java, then it makes much more sense I believe to use SWT.
In any emulated platform, which is what Swing has done, unless you go to the detail of being bug-compatible, no emulation can be perfect, and we certainly don’t claim to be perfect. The much more logical implementation path was to actually leverage the platform, and that’s what gave birth to SWT.
So let’s move over to RCP (Rich Client Platform). This is one of the single most exciting things going on at Eclipse right now. One of the interesting points about the Rich Client Platform is that in Eclipse 3.0 we can now embed Swing-written user interface components in Eclipse. So in my mind the whole Swing versus SWT thing is no longer a very relevant conversation, it is not a versus scenario any more. Developers can pick the user interface framework they are comfortable with, or perhaps have a pre-existing investment in, or even more importantly the right one to meet their application requirements. If we go through what the RCP provides, obviously SWT and then JFace on top of it are part of that. But the really interesting things are the generic workbench, the help system, and the update manager.
So really the Rich Client Platform is about being able to provide a managed client-side environment for rich client applications which are not browser based. The update manager gives you a mechanism whereby you can manage the deployed applications from a specified server for a given desktop, which I think is a really rich metaphor for managing these kinds of applications. By “manage that desktop” I mean that users can have an environment whereby they can update the plug-ins that they have on their desktop. They can discover new plug-ins. And at runtime they can add, delete or modify the plug-ins that they have running in their environment.
Click here for the final part of the interview.
Copyright Tim Anderson Sept 06 2004