Slashdot Mirror
Tim Boudreau On The Future of NetBeans
maffstephens writes "With the release of NetBeans 4.0 set to reignite the open-source Java IDE war and all sorts of cool developments on the horizon, it seemed like a very good time to talk to one of the key senior NetBeans developers. In this interview, Tim Boudreau (co-author of NetBeans: The Definitive Guide) speaks candidly about his views on rival IDE Eclipse, the future of NetBeans, and the thinking behind its new Ant-based projects system."
I'm a dyed-in-the-wool Emacs and shell guy, but the feature that has me salivating over NetBeans 4.0 is the upcoming code profiler previously known as "JFluid". Have a look at http://profiler.netbeans.org/index.html.
That, and the potential for using refactoring tools has me seriously considering an IDE for the first time in my life. The question is: can I make all of this work with Emacs?
Only newbie wannabe programmers use Java.
NetBeans is NOT Open Source software. While parts of it may qualify as such, the IDE as distributed by http://www.netbeans.org/ is not.
Below I cite sample parts of NetBeans license. There is "Binary Code License Agreement" which gives us no rights to redistribute and "Supplemental License Terms" for each part, which, basically, allows us to redistribute it in binary form only, unchanged. And such terms are repeated in almost exact same way for all other parts.
As far as I can tell it's not even close to open source. However, if someone knows better I'd like to be proven wrong, but facts, please, not opinions.
Here is first paragraph of NetBeans license:
Here are two first paragraphs of Sun Microsystems, Inc. Binary Code License Agreement:
Of course there are supplemental license terms for each part mentioned above, let's see what rights they give us for "JAVA(TM) DEVELOPMENT TOOLS JAXP.JAR AND PARSER.JAR ARCHIVE FILES FROM JAVA API FOR XML PARSING, VERSION 1.0":
I have test driven just about every Java IDE out ther, and so far, hands down, Intellij Idea is the way to go. It isn't free, but it's quite cheap. It's had Java 5.0 support since Java 5.0 was java 1.5 beta and generic support even before that. It's got refactoring capabilities out the whoozow and integrated amazingly well with cvs. It can even do codeanalysis and find duplicated code across your entire project (and of course help you refactor it out). Except for JBuilder's GUI building, I can't think of another IDE that can do anything that it does better.
Before eclipse, netbeans was the only free IDE that could compete with its commercial counterparts. The 1.x and 2.x versions were pretty OK compared to other free IDEs. The 1.x generation was the first time I preferred an IDE over an editor/compiler combination. Especially the GUI editor was one of my favorites (and having done swing programming manually, I am very critical of such tools).
Then eclipse came and especially in its 2.x version and 3.x version showed the weaknesses in netbeans (usability & GUI performance). Fast forward to 2004. I'm using eclipse 3.0.1 on a daily basis with some plugins and I'm reasonably happy with it. Performance is a bit sluggish on my (soon to be replaced) 1Ghz pIII but acceptable on smaller projects.
I disliked all of the netbeans 3.x stuff, including 3.6 which I only gave a brief glance. But I tried netbeans 4.0 beta the other day and I liked what I saw. Out of the box it supports a lot of stuff that eclipse simply does not support (basically all the j2ee stuff, ant integration, xml, html). You can get most of these things in eclipse by installing commercial plugins but if you want everything for free it's pretty hard to find e.g. jsp support, good servlet container integration (more than the pathetic tomcat start/stop support in some eclipse plugins), etc. The netbeans people already had most of this in the 2.x and 3.x generations and the functionality has been much improved since then. Also the features are well integrated: you can create a jsp file from a template, use autocompletion to hook it up to your java stuff and deploy it to tomcat with the debugger attached. Doing the same in eclipse requires a lot of manual intervention since eclipse 3.0.1 doesn't understand tomcat, jsp, deployment descriptors and debugging a running tomcat server. It resorts to plaintext editors for most of these things.
Also, to my surprise, netbeans was very fast on my old pc at work. It effortlessly handled large projects which eclipse is having problems with on the same machine. This is definately progress from 3.x. Browsing in 3000+ loc java files in eclipse is a pain but netbeans seems to handle this much better. IMHO the whole swing vs swt performance debate is over, neither party won. Eclipse is not faster for the same tasks in netbeans and both are resource hogs.
Not all is well though. Eclipse has much better refactoring support and seems to have the better java editor. In the end, a java programmer spends lots of time editing java code and that is what eclipse is very good at. All the other stuff is nice to have but not essential for powerusers like me.
In addition, some interesting tools are under development at eclipse which will again level the playing field for eclipse. The webtools project for instance intends to bring lots of j2ee goodies to eclipse.
Jilles
That's just the plugin model, mind you, which is not specific to Eclipse; it just specifies the way plugins are packaged, declare their metadata, are loaded, accessed etc.
Eclipse's object model, which rests on top of this framework, is something else, and that's Eclipse-specific. Eclipse's object model is much more generic and vast in scope than NetBean's OpenIDE API.
In case you don't know the Eclipse plugin system well, it's a modular design based on loose coupling of components all extending each other.
There's no central plugin point to speak of; Eclipse is essentially a collection of loosely-coupled components, with some glue at the bottom to bootstrap the core plugins.
Every extension can potentially extend another. For example, if I provide a view, then I can let anyone extend that view by, say, providing context menu items, toolbar buttons, visual overlays and the like.
These extensions would all communicate using publicly declared APIs; hidden inter-component communication is discouraged.
For example, if I were building a stock trading app, I might write a bunch of different views -- graph view, a table view, a ticker view, etc.; the table view would expose a mechanism to detect when the user has clicked on a specific stock symbol.
The graph view would plug into this mechanism and change its view to show the currently selected stock. However, the graph view would not know anything about the view into which it was plugging into; it would only know about the interface contract of the extension point, which could be anything.
You could potentially bundle each of these views separately and mix and match with other, third-party views: as long as they know the public interfaces, they can talk to each other. I could write a better graph view and plug it in without having to change any code in any other view.
The reason Eclipse is so flexible, and is popularly touted as an "integrated anything environment", is precisely because it is so loosely defined.
Eclipse would not be able to use the NetBeans APIs directly because they are, well, NetBeans. Eclipse could not do everything it does today if it adhered to the NetBeans API.
Also, NetBeans/OpenIDE is tightly coupled to Swing, and while SWT can embed Swing, consistently and seamlessly adapting Swing-using components into the SWT environment would be a lost cause.