Felipe Gaucho's Blog

February 2007 Archives

Netbeans sabotage

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:

	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.

This work is licensed under a Creative Commons License.