Rich Unger >> There's really two camps in the J2EE world these days. If you're the type of developer who uses EJB's, and must use JSR-blessed libraries (JSF over Tapestry, for example), then you'll be a lot happier with NetBeans. Also, their web services support is second to none. They've got a built-in Tomcat and Derby DB that let you get up and running extremely quickly. The HTTP Monitor window helps you figure out exactly what's going on in your app.

"If you must use JSR blessed libraries, you'll be a lot happier with NetBeans..."

NetBeans is less strong when it comes to supporting some of the more popular OSS libraries out there. It's got nothing like Spindle (an Eclipse plugin) for Tapestry. I think the Hibernate support is currently a bit better with the appropriate Eclipse plugins. Spring is so simple that I think it doesn't matter which IDE you use. Just having decent XML syntax completion should be adequate.

"NetBeans is less strong when it comes to supporting some of the more popular OSS libraries..."

Rich moonlights as a dancer in a swing dance performance troupe

This is certainly something they're addressing in NetBeans, though. They've finally added nice Struts support. Also, the module-writing support includes some fantastic wizards that make writing something like a Hibernate plugin pretty simple, so I think we'll be seeing those kinds of modules in the near future.

IndicThreads >> NetBeans Profiler is a recent development that NetBeans seems to be pushing in a big way. In what state is the Profiler today and will the Profiler stay an independent product or will it become a part of NetBeans at a later state?

Rich Unger >> I think the main reason it's a separate product right now is that it requires JDK 5.0, and the core NetBeans project must remain 1.4-compliant. I've asked on the mailing list why the profiler isn't just a module on the Update Center, and the answer was something like, I don't know. Probably it will be soon.

"NetBeans Profiler is fantastic technology..."

 The profiler is fantastic technology. You can profile pieces of your application, thereby reducing the performance impact. For example, if you're working on a J2EE app, you don't have to profile the whole app server, just your own code. They're finally hitting the point where it's no longer a question of “should I profile my app?” It's just too easy not to.

"It's no longer a question of should I profile my app? It's just too easy not to..."

The one downside is that it required changes to the JRE. Most of those changes made it into JDK 5.0 update 4. However, we have to wait for Mustang before we can attach to a running application (the way we already can with the debugger).