Eclipse

People are ‘attempting to use Eclipse modeling technology on the Netbeans platform.’

Jessica Thornsby
People-are-attempting-to-use-Eclipse-modeling-technology-on-the-Netbeans-platform

JAXenter spoke to member of the Eclipse Foundation Board of Directors, Chris Aniszczyk about the SWT/Swing debate, and what we can expect from Eclipse RCP.

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.

Author
Comments
comments powered by Disqus