From Eclipse to NetBeans: Part 2

I had planned to post a "Part 1.5" that summarized all the emailed and commented help I got for my first post, but I've been too busy working on JRuby on Rails to try most of those suggestions out. Several folks offered a whole bundle of useful tips that will address many of the "bad" points in Part 1. I will revisit those as I have time, and hopefully use them to compile a "NetBeans for Eclipse Users Walkthrough. For now, however, I continue to muddle through with NetBeans as-is.

NetBeans continues to surprise me in both good and bad ways. Some features seem to be very nice and very well thought out, while others...well I wonder if anyone's actually using them, because they're very cumbersome. Most of the UI seems to be solid and clean under Java 6, but there are some occasional jarring glitches and (in my opinion) poorly-designed interfaces. Sometimes NetBeans seems to know exactly what I want to do...sometimes it seems to make what I want to do as hard as possible. It's still been worlds better than earlier versions, but I'd have expected a level of polish I'm just not seeing yet. Is it because I'm running a beta IDE on a beta JVM? Perhaps. Perhaps not.

However I'm going to be a trooper about this and do what I can to fight through issues. I think NetBeans really has a lot of promise if these things can be ironed out, and truth be told, most stuff works fine. However the stuff that doesn't work...REALLY doesn't work.

And again, please don't consider this an attack on the NetBeans product or team. NetBeans is very impressive...but there's room for a lot of good improvement. I hope this hard look at NetBeans vs Eclipse will help make progress to that end.

The Bad:

1. "Extract Method" should have an option to replace all instances of identical code with calls to the new method. I use that feature in Eclipse *very* frequently.
2. No "Inline Method" refactoring? I really need that one. Here's a typical use case for me:
   • N methods all have the same code, for whatever reason..perhaps I've refactored and simplified them each down to the same chunk of code.
   • Extract Method to create a new method that does that duplicate block, and replace all instances of duplicate code so all the old methods call the new one.
   • Inline all the old methods so all callers now call the single new method. The old methods are eliminated.
   In this way, I manage to make all callers calling duplicative methods call a single new method without ever manually modifying a single line of code. I have many such refactoring tricks I have learned over the years, many of which depend on being able to inline methods and extract methods globally. JRuby would not be where it is today without those refactorings.
   
3. The "Find Usages" dialog has a grand total of two or three checkboxes (depending on visibility), one of which I will probably rarely use (find in comments) and the other which should probably just be on by default (find overrides). I would much prefer to just go straight to the search results, rather than always have to hit "Next" on this dialog.
4. There's no way to look at the project view and know whether I have errors in my project or not, even after running a build. In Eclipse, if I save a class with errors, the entire project and all directories leading to that class get marked with a big red X. In NetBeans I can see if the current file has errors, which is good...but being able to see errors anywhere in the project is a must when I'm making refactoring changes that can affect more than one file. I need to know at a glance if I've broken something else. For larger projects, re-running the build can be prohibitively slow.
5. My Projects and Files views only show the little "versioning cylinder" icon next to SOME of the items in my project. Even more confounding, in the Projects view, only SOME packages show up as versioned. I haven't figured out a pattern to it.
6. I should be able to change the delay between typing code and having NetBeans re-parse it and display error squiggles. By my estimate, it takes about three seconds for it to realize I've typed bad code, by which time I've almost certainly moved on to the next line or a different file completely. Yes, it checks when I save, but checking as I type *very slowly* is not really useful. EDIT: I did find this setting...it's at 2000ms by default. I've set it to 1000ms, so we'll see if it's disruptive. Is it set so long because it causes a lot of overhead?
7. There are surprisingly few "non-advanced" settings and a baffling array of "advanced" settings. Almost everything I need to do is in the "advanced" section. Perhaps I could just turn on an "always advanced" view and save myself that button-press?
8. Why can I right-click items in the Advanced Settings tree, to bring up the exact same properties listing I see on the right-hand pane? Prefer one way to do things...the right-click properties dialog should go.
   
9. I can't find how to change the default L&F. Maybe it's in the Advanced Settings somewhere, but I couldn't locate it. Metal is an OK L&F, but it's jarring when the rest of my system looks completely different. It also seems too "bright" to me, for some reason...I prefer softer earth tones.
10. Code completion brings up two popups: one for the list of methods, and one for documentation on the selected method. One displays itself above the line I'm typing and one displays below the line. This effectively hides all contextual code around the line I'm typing, which is frustrating. The documentation window is also enormous, and usually mostly empty.
    
11. There doesn't appear to be a way to revert changes when the changes are new files. Modified files get reverted, but not files or directories that are new. Oddly enough, they DO show up as changes when choosing "Show Changes".
12. I selected all new items in the "Show Changes" pane and hit the delete key...BEEP, nothing happens. I right clicked and selected Delete...and it appeared to proceed with the delete operation. The Delete key should map to a logical Delete operation whenever possible.
13. After deleting, the view continued to show new files that were no longer visible in the Files view, and refreshing did not help.
14. After manually cleaning out the new files, my NetBeans project appeared to be totally hosed, returning a goofy error about a parameter field not being normalized (filed as bug 83665). I had to completely wipe out my working copy and re-get it...
15. ...only to find that once I had deleted my project, NetBeans totally forgot my SVN URL and I had to retype it. Thankfully it remembered my credentials, but why didn't my old URL show up in the list of possible URLs anymore?
16. Then it again asked me where I wanted to check things out, defaulting to my home dir. Can't I just set a single work location and be done with it?

At this point I figured I should call it a night.

The Good:

1. NetBeans shuts down WAY faster than Eclipse. That's a huge benefit. I don't know what the hell Eclipse is doing that takes as much as 15 seconds to shut down, even if it was sitting idle.
   
2. NetBeans ships with way more capabilities than stock Eclipse. I found the Module Manager today to turn some stuff off and was absolutely stunned to see how much stuff comes in the base install. However there's a bad side to this too: NetBeans could be perceived as having a slower startup time because of all these modules, even though most folks will never use most of them. Maybe have a few coarse-grained use cases people can choose to enable AFTER installing and starting up the first time. At any rate, I'm impressed with what ships out-of-the-box.
3. I can confirm that antialiasing appears to work for the whole IDE under Java 6, as reported by one commenter. Very nice!
4. I like being able to turn on line numbers for all editors in one place. However, others may want to be more picky.
5. NetBeans seems to be much more deterministic than Eclipse. For example, when Eclipse is under heavy load, occasionally mouse clicks and keypresses will disappear into the ether. When Eclipse gets laggy I frequently have to double-check that the code or shortcut I just typed was actually received. This sometimes leads to me typing only half of a line of text or typing a search query into my editor. NetBeans so far does not seem to "lose" UI events like Eclipse does.
6. I see that right-clicking editor tabs DOES allow me access to Subversion. I just don't have it in the main pane's context menu. That's totally acceptable, so mark another item off the bad list from Part 1.

Subversion...Wherefore Art Thou

The subversion issues have been severe enough I figured I should rant a bit before closing this article out. As far as I can tell, SVN support is simply broken in 5.5b2, to the point that I'm now afraid to perform many operations out of fear that they'll nuke my working copy in some heinous way. In this case, I had no local changes to lose (or to struggle to save), but I could picture some painful corruption like the "parameter field" error coming right in the middle of some multi-file refactoring. I pray that doesn't happen.

Painful to live in fear, isn't it?

Jack-of-all-Trades...but...

NetBeans seems to have a vast range of capabilities, rivaling multiple major Eclipse-related projects all rolled into one. However there's a lot to be said for polishing the core pieces to death before launching into a new set of features. Subversion should just work. The UI should just work, without glitches. Professional-grade refactorings should work like you expect them to (and Eclipse's complement of refactorings is actually overshadowed by some other IDEs, so NB is well behind the curve here). Under no circumstances should a working copy be so badly damaged by an operation that it must be flushed out and re-gotten. And so on...

These key features need to work perfectly, all the time, before anyone will consider launching into more advanced features like Java EE support or Database Browsing. If I can't even do basic SCM operations on my project, why would I ever invest time in anything more than simple Java code editing?

That said, I think NetBeans could really shine like a star with some polishing...polishing that may be coming in NB6, I really don't know. Most of these issues are obvious or minor, and many of them are in newer features that have perhaps not been tested as well as one would like. Hopefully the excellent improvements in NetBeans over the past year will draw more users...and more testers...to the project.