People are 'attempting to use Eclipse modeling technology on the Netbeans platform.'
Following Netbeans technical writer Geertjan Wielenga's assertion that NetBeans' Swing UI toolkit has an edge over Eclipse's Standard Widget Toolkit (SWT,) we spoke to Chris Aniszczyk about the SWT/Swing debate, and found out whether there are any plans for Eclipse to provide Netbeans tooling...
JAXenter: Geertjan Wielenga recently suggested that Eclipse RCP's Standard Widget Toolkit (SWT) is a barrier for new developers getting to grips with Eclipse. Is the SWT learning curve significant?
Chris Aniszczyk: I don't know what Geertjan meant by SWT being a barrier for developers getting involved in Eclipse. I mean, there's books out there and many examples out there discussing how to use SWT. I thought we were over the point of arguing over which widget toolkit is better; it's very similar to the Emacs vs. Vi debate. I mean, any programming language you pickup is going to have a set of widget toolkits that you'll need to learn. How different really is a Swing JLabel from an SWT Label? I think both widget toolkits are mature at this point. Swing doesn't suffer from as many performance issues as it did from the past which was one of the reasons SWT came to exist. If you're looking for a native look and feel, SWT does a better job of providing that for Java applications than Swing in my opinion. In the end, my stance on this is use what is best for your project based on the requirements.
JAXenter: What does SWT bring to Eclipse RCP, that it couldn't get from the Swing UI toolkit?
Chris Aniszczyk: I don't think this question is really fair if you're trying to compare Eclipse RCP and Netbeans RCP. I don't think you can look at it just at the widget toolkit level... that's not a proper comparison given my sentiments in the previous question. In terms of feature parity, the widget toolkits are very similar (Swing may have a slightly larger set of widgets available since its been around longer,) however, I would look at things at the ecosystem level. The Eclipse ecosystem has 200+ projects ranging from runtimes, reporting, modeling, persistence and so on. If your RCP application needs reporting, you can simply use the Business Intelligence and Reporting Tools (BIRT) project at Eclipse.
If you need persistence, we have EclipseLink which can help you easily. These technologies are generally tightly integrated with each other if they ship as part of the simultaneous Eclipse release.
On top of that, there are a couple of things going on at Eclipse that is enhancing what is available to Eclipse RCP developers. The first is the EclipseRT initiative which is giving Eclipse RCP developers a lot more options when it comes to choosing what runtime technology to deploy within their applications... client or server side. The second is the e4 project which essentially is a rewrite, modernization and simplification of the core set of Eclipse RCP technologies. If you look at the history of Eclipse RCP, the technology first came out about 7 years ago when J2SE 1.4 was in its prime. A lot has changed since then but it was difficult to move up to newer technologies due to the double edged sword of backwards compatibility (e.g., if you had API that was based on J2SE 1.4, moving up to J2SE 6.0 would be considered a breaking change if you introduced something like generics.) The e4 project will simplify Eclipse RCP application development for many developers out there. I'm confident Netbeans RCP will face this problem in the future soon... it happens with any mature technology that has to evolve while keeping existing clients happy.
JAXenter: What are your thoughts on the announcement that NetBeans 6.9 will support the OSGi standard?
Chris Aniszczyk: I think this is great news. This would mean all three major Java IDEs(Eclipse, Netbeans and IntelliJ) providing OSGi tooling support. On top of that, I believe Netbeans is even allowing you to run OSGi bundles within their custom module system which is really cool. I would be curious to see if Netbeans ever makes the switch to using OSGi bundles as their main module format instead of their custom module system. That's probably too drastic of a change though given that the current system works. In my opinion, that would be great as that would allow more code reuse between the major Java IDEs. It's a bit unfortunate there isn't more sharing due to politics within the communities.
In the end, who can safely say that OSGi isn't mainstream now?
JAXenter: Do you foresee Eclipse platform providing support for the NetBeans platform, at some point in the future?
Chris Aniszczyk: Sure, I definitely think it's a possibility. The great thing about the Eclipse community is that if someone has an 'itch' or sees a demand, they can step up to the plate and make it happen. I'm sure as soon as someone in the Eclipse community cares enough about developing applications for the NetBeans platform we will start seeing great tooling for it at Eclipse. By the way, a good example of this is Eclipse tooling around JavaFX. There are actually two solutions for tooling JavaFX being built within the Eclipse community at the moment!
The point here is that if there's demand for it, people will build it on Eclipse. By the way, it goes the other way around. For example, there are people attempting to use Eclipse modeling technology (e.g., EMF) on the Netbeans platform. If there's a will, there's a way. The will is the important part. The Eclipse community is definitely open to making it happen if people from the Netbeans community step up.