When it rains, it pours…

Hot on the heels of the official Eclipse 3.5 codebase release, heralded primarily by the “Galileo” tool set, the NetBeans group has announced the official release of its latest version, NetBeans 6.7.

Developer’s Perspective

The layout for NetBeans and its overall usability arguably has a lower ramp-up and learning curve than Eclipse, particularly with the latest “Galileo” launch, which further fragments the tool selection process. While NetBeans has a variety of packagings based upon programming language preference, most people tend to select the “All” feature in order to have the widest selection of languages supported (in the event that your shop needs to manage multiple languages, which is a common scenario). 

Integration to Project Kenai, Hudson (CI), and Maven have been long-awaited features. Hudson and Maven support have been available for NetBeans for some time, but as add-on modules, and there were issues with the integration aspects with the rest of the IDE.

Loss of JavaFX 1.2

This is a serious concern for developers who have been working with JavaFX: it is not shipped with this version of NetBeans, so if you were hoping for a single, unified IDE to support everything you’ve been working on, you’re currently out of luck. DO NOT UNINSTALL YOUR NETBEANS 6.5/6.5.1!

You may install NetBeans 6.7 alongside 6.5/6.5.1, so you will not be out of options, and if you are using a larger dev rig (for instance, like a 8-core Mac Pro with 16 GB RAM ), this should not be a serious concern. But if you are somewhat memory/resource constrained in terms of your workstation, you may find yourself switching in and out of the different versions.

There are additional gotcha’s associated with this release, particularly with “less glamorous” features that are not delivered in the downloaded installers. You will have to force them to download separately via the module updater feature in the IDE, post-installation. Also, there are certain caveats about some of the features being delivered in NetBeans 6.7. We definitely high recommend reading the release notes accompanying this version. The install instructions will be beneficial to those of you who only previously installed a single version of NetBeans at a time; and a lot of you recent Mac users will find some of the info applicable in your case as well, particularly with uninstallation and coexistence of previous versions (however brief the info is…).

Management Perspective

If your developers have unified on NetBeans 6.x to this point, there is most likely very little need to jump ship to a competing product; and if you have been dealing with a variety of extra modules beyond the core NetBeans IDE to handle your Hudson and Maven integrations, you’ll be very interested in bumping up to NetBeans 6.7.

On the other hand, if you recently fetched Eclipse “Galileo”, or even the base Eclipse 3.5 IDE, because you’ve been a staunch Eclipse dev group, you may be interested in allowing some of your developers to use NetBeans 6.7 to see if the different development flow works better for your team.

But, as above, if you’re managing active JavaFX projects, you will want to postpone upgrading en masse. Instead, you may opt to wait for an update to NetBeans 6.7 (like, perhaps 6.7.1 or 6.8, even) that contains JavaFX SDK support; or just continue using NetBeans 6.5/6.5.1 in your group.

DevPal’s (and Javamancy’s) Stance

It’s a bit too quick to pass judgment on a fresh release, particularly with Eclipse having recently begun its way through the evaluation cycle. However, since DevPal already uses NetBeans as part of the development workflow, there is a parallel on-ramp cycle for NetBeans 6.7 to replace the NetBeans 6.5 instances currently deployed for primarily Java-based projects. In the meantime, our NetBeans 6.5.1 instances will remain as-is, since we do use them for JavaFX activities. It is an odd situation, and it causes a spawning of additional user configurations to support both NetBeans 6.5.1 and 6.7 in the same user home directories. Fortunately, it is not a dramatically heavy storage investment.

And the evaluation will begin for NetBeans 6.7.

Yesterday, the Eclipse Consortium officially released the sixth major release of the IDE, Eclipse “Galileo”.

While Eclipse was originally developed to support Java development, it has experienced phenomenal growth and expansion to encompass a wide variety of programming languages and architectures. Since it has broad industry support from a galaxy of IT companies and groups, it has continued to gather more functionality, to such an extent that it is difficult for it to remain as the all-in-one IDE package. As a result, over the past several years, it has been released as a suite-of-sorts of different combinations of functional components: developers are obligated to pick and choose with configurations best suits their needs.

Unfortunately, the extensive componentization of Eclipse has also increased its apparent complexity (some would even argue that it is overly complicated). This is part of the lively competition between Eclipse and its arch-nemesis, NetBeans, which is also undergoing an upcoming 6.7 release. This also brings into the equation the issue of which company is supporting what… after all, given Oracle’s [ORCL] acquisition of Sun Microsystems [JAVA] and its support of the Eclipse Consortium, what will Oracle’s own tool set evolve into?

Developer’s Perspective

Exploring new dev tools is always a mixture of trepidation (“Oh, is it going to break everything I’ve been working on?”) and fun (“Oh, another new feature I’ve been buggin’ them to include… got it now!”). The new Eclipse release is no exception.

What makes Eclipse unique in considering whether the upgrade is valid is its componentized nature. Some savvy developers have, in the past, merely reached into their current configuration set, inspected the new modules, and fetched just the ones that they needed and/or grabbed the source code for the modules they were interested in, and just hacked it into their current version, disregarding the core platform upgrade altogether. This has become more and more daunting of a task, however, so during the inspection process, I would imagine that a lot of developer-hackers who have done this in the past may reconsider.

As for dev shops that have worked with both Eclipse and NetBeans: long gone are the days when you could build a hybrid Eclipse-NetBeans IDE for your developers. The codebases are too disparate, and unless you’re using one of our Mac Pro monsters, managing the code updates may not be worth it.

If you’re using a combination of Eclipse and NetBeans, or some other 2+ IDEs, the level of integration or coordination frequently converges at the VCS level. On more rare circumstances, it may be abstracted to the build/CI level; and even more rare, it may be at the issue tracking level– which would be quite dire indeed. If this manner of dev coordination is acceptable, you’re not going to want to change it any time soon. But if not, this latest release of Eclipse may be the deciding point to force the issue to a single-IDE methodology.

For the Love o’ the Mac

In case you haven’t noticed yet… The Eclipse 3.5 distributions are now shipping with Cocoa-built binaries now. This has been a long time coming for many developers who’ve used Eclipse on the Mac, and for some developers, has often made them strongly veer toward NetBeans instead.

It remains to be seen, outside of those developers who’ve been playing with the beta versions of this release, whether native Cocoa support is what brings developers back to Eclipse. I’d imagine that iPhone developers who also manage their OS X apps via Xcode will be at least curious about how Eclipse can mesh with their Xcode-provided libs; and it almost goes without saying that GNU C/C++ and Web developers who have been struggling with other tools on the Mac will want to look at Eclipse 3.5-based IDEs (even if not the official Galileo toolset).

Management Perspective

Always a sticky subject for the stricter management teams, unless they are distinctly single-IDE shops.

The reliable way of handling this issue is to assign your most experienced developer-architect to experiment with the new release to see how well it works in your existing dev environments. This becomes more crucial when you have a continuous dev cycle that blends your dev, testing, staging, and deployment targets together.

DevPal’s (and Javamancy’s) Stance

It’s all good ‘n fine to sit around and speculate on how great one dev tool is, blah blah blah. But outside of generating noise, it isn’t otherwise productive.

Since we’re running a mixed-tool studio, it’s clear that we want to put the new release through its paces before we make any significant retooling efforts. But most likely, unless there are glaring problems, we would be using a customized Eclipse 3.5 as our main IDE with several Eclipse Galileo variants for more specialized work and deployments given to clients who require special code considerations during design or coding phases.

In the meantime, good hunting, folks!