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! 
{ 1 trackback }