Skip to main content

Netbeans sabotage

Posted by felipegaucho on February 22, 2007 at 8:21 AM PST

Some months ago I adopted Netbeans as the default IDE for my Open Source
projects. The main reason for changing from Eclipse to Netbeans was the adoption
of the recent technologies like SOA and JEE5 - technologies not officially supported
by Eclipse before the middle of 2007
[1,
2]. During this IDE migration,
I couldn't convince my office colleagues about the benefits of my choice and I also detected a strong
resistance against Netbeans in open source communities and other groups
traditionally motivated about new techs. Discussing the role of Netbeans in the
Java market with colleagues, foruns and JUG mailing lists I collected some
interesting points:

  1. The market sees Netbeans more as a technology issue than a productive tool:
    launched few years ago as an innovative platform, Netbeans still pays some consensum about its
    preliminary overheads, like it is too heavy to be used...
    and it is also a too complicated tool. From my point of view it is not fair anymore and these are
    assertions with no technical support.
  2. A good development process should not depend on IDE: conceptually it is perfect.
    ANT, MAVEN and other authomated project management tools gave us a confortable feeling about portable
    artifacts like line commands and configuration files. The idea of creating projects that can be
    edited by any interface - from textpad to websphere - is a core belief in the Java community. Even
    with the most popular IDEs supporting ant and maven as a default feature, developers and project
    managers hate the idea of using the built-in features to configure it through the IDE. It is very hard
    to find a real Java developer that uses the ANT editor of Eclipse to modify the tasks of a project. Usually
    the ANT tasks are part of the standards in the companies and even if the IDE offers a better way
    to manipulate it, few people are motivated to innovate in this subject.
  3. Netbeans-based tutorials are odd: several good technologies are suffering
    sabotage due to the fact that their manuals and tutorials are based on Netbeans. The classical example is JEE5 and
    Glassfish - several times I wrote about the wonderful JEE5 new features and almost everytime I receive
    the same response: hum.., it uses Netbeans.. do you know how to do that in Eclipse?
  4. Good to avoid dependency of Big companies:: everyone who already worked with the
    IBM suite of Java development tools knows how difficult it is to mix the IBM tools and other vendors tools.
    In fact, the most common scenario is that or you adopt IBM RAD tools, or you don't!. The new
    generation of SUN tools, including the open source efforts, suggests something in the same way. Every time
    I read a blog or a tutorial saying it is easy, you must click here, click there and everything runs
    ok
    I feel a tide coupling between the technology being produced under SUN Labs umbrella and Netbeans.
    Like the Websphere family, we are observing Netbeans family being born. I observed also that
    people who usually like the IBM way to do businnes, also like the idea of an integrated development
    platform based on Netbeans. On the other side, companies oriented to
    light-weight-open-source-eclipse-like tools are trying to avoid Netbeans and also
    loosing/ignoring a lot of good oportunities of using
    SUN nice technologies.

My real world experience

During the last few weeks I made an evaluation of JBI/ESB products - specially focusing
on Open Source projects because the JBI is just part of a bigger solution for one of our enterprise
clients. After reviewing the documentation of three or four projects it was clear for me that OpenESB
was a strong candidate for supporting our project. Well documented, SUN support and several positive
testimonials from companies using that. Just one weak point: all documentation is based on Netbeans.
For me, another good feature since Netbeans 5.5+ is a productive and easy tool to use IDE, but I couldn't
sell this idea to my project manager. I tried to discuss the usage of Eclipse in the OpenESB forum and
also made some local evaluation about how to adapt OpenESB to our company standards - including the
impact on training, documentation changes and the risk of Netbeans adoption. At the end I was
forced to choose other ESB framework simply because Netbeans is not part of the company standards.

I suppose Open Source projects could be more flexible than commercial companies with a established
development process. But, for now, my feeling about my recent experience is that OpenESB suffered a
Netbeans sabotage ;(

The SUN strategy to avoid the sabotage

During the time I was editing this blog entry, I had several interesting discussions with people
inside SUN and also with Netbeans and Eclipse users. I cannot remember all names
and foruns that helped me in figure out the Netbeans role in the nowadays Java market -
but I appreciate and thanks all their valuable opinions. One of these answers comes from
Gregg Sporar,
a Netbeans evangelist that give me some glimpse about how SUN is planning to retrieve
the developers confidence on Netbeans and also how they are planning the integration with other
IDEs and the most popular management tools. Below is a fragment of the Sporar mail:

cellpadding="2" cellspacing="2">

With respect to the promotion of technologies such as Java EE 5 and JBI
via NetBeans, I have a few comments:

1. The reference implementation for Java EE 5 is GlassFish and the
GlassFish team has built plugins for other IDEs (including Eclipse)
besides NetBeans.  This is because Sun recognizes that there are other
IDEs.  :-)

2. We try to provide with NetBeans a superior development experience for
building Java EE applications and part of our focus is to make those
tools available at the *same time* that the Java EE reference
implementation (GlassFish) becomes available.  The other IDE
products/projects do not necessarily have the same focus.  The end
result is that even with the addition of a plugin provided by the
GlassFish team, the development tools provided in Eclipse for Java EE 5
development might not always be as good as what we provide in NetBeans.
But it is important to note that the situation is changing.  The Eclipse
Web Tools Platform project continues to make progress and the GlassFish
team provides help in the form of some testing and bug reports.
IntelliJ IDEA now has pretty good Java EE 5 tools too and I think
Oracle's JDeveloper is making progress as well.  The point I am trying
to make is that while NetBeans might have been the first IDE to provide
support for certain Java EE 5 features, we are no longer the only one.
And that will help increase the adoption of Java EE 5.

3. The situation with JBI/Open ESB is a bit more complicated.  As I
indicated in the comment to my blog entry, I see two issues here:
deployment and design.  We need to do a better job of providing
deployment tools for developers who use other IDEs.  The design tools
are a much more difficult problem.  For now, I do not think we have the
resources to provide plugins for other IDEs.  One interesting
possibility is that we might end up seeing some companies adopt the
usage of the NetBeans IDE for integration projects only.  This is
similar to the way some developers today use NetBeans *only* for Swing
GUI development projects because of its Matisse GUI builder tool.  Our
hope is that by providing a quality tool for building applications that
are deployed to Open ESB we can entice some developers to give it a
try.  If that happens, I think there is a possibility that other
companies will help us solve the problem of support for other IDEs.

* Gregg was not talking officially in name of SUN, he was just taking a
friendly discussion with me about Netbeans and about arguments pro Netbeans.
I quote some words of Gregg here just in a hope to offer the most fair
overview about the Netbeans in the software market, including the SUN
effort to offer the community a high-quality open source IDE.

Related Topics >>