Headius

Thursday, September 7, 2006

More FAQs about JRuby and Sun

There's been a lot of buzz about Tom and my new jobs at Sun, and understandably so. The response so far has been overwhelmingly positive, and we're grateful for that. It's all very exciting.

There have been a few questions to come up again and again on blog postings and mailing lists, however, that I figured I could answer. Some are fear, some are uncertainty, and some are doubt, but almost all have good answers. I understand some folks have concerns and want to address those as best I can.

Note, my responses may not be Sun policy, but they're my policy. And I don't bend so easily.

1. Does the Sun move mean Groovy, Jython, BeanShell, and friends are being cut out of the picture? Has Sun chosen a winner in the dynamic languages realm?

Absolutely not, on both counts. I got involved in JRuby for one reason: Ruby was underrepresented in the Java world, and happened to be a very attractive language to me. Jython was fairly well-established and performed quite nicely. Groovy was gaining some traction and seeing an upswing in developer interest. JavaScript was scheduled to be included in Java 6. What about Ruby? JRuby didn't run most Ruby apps, had known major incompatibilities with C Ruby, and performance was very poor. Something had to be done.

I like to solve difficult problems, and JRuby certainly has presented some difficult problems. How do you take an existing interpreter that mostly works and--without breaking it--completely refactor and rewrite its internals to maximize performance and compatibility? Answer: very carefully. JRuby has come a long way this past year, and now we have leave to round things out on an accelerated schedule.

So what then? Naturally there's the tools angle (which I'll address in a moment), but will a JRuby 1.0 release mean the end for JRuby and continuing development of dynlangs on the JVM? Of course not! JRuby will continue to be a learning experience for all involved...inside and outside of Sun. Once we've solved JRuby's issues, why not find a way to raise all ships? Support for invokedynamic, open classes, and closures at the VM level? Hooks for code generation, alternative typing systems, and deeper threading, IO, and memory integration? Seamless cross-app connectivity for dynlangs + Java EE with all the tasty agility we've come to love?

This is only the beginning, my friends!

2. Sun has stated that Charles and Thomas have a mandate to think about/work on developer tools; does this mean Eclipse-based solutions are off the support list?

I want to make this perfectly clear...we will not discriminate between any users of JRuby. JRuby is a community project, first and foremost, and part of cultivating and growing that community is a rigid adherence to non-discriminatory support policies. We would be cutting off our right hand (or in my case, left hand) if we started picking and choosing who "deserves" support and help from the JRuby team. Nobody would benefit and everyone would suffer from such a move.

Of course, as Sun employees, we've got a major interest in ensuring NetBeans provides a world-class IDE for Ruby projects on the Java platform. But we were JRuby developers first, and we know that although we want people to migrate to NetBeans, we'll engender no community love by giving existing, mature Ruby IDE solutions the boot. Remember folks, competition is good. It would just be entirely unfair to deny NetBeans users the distinct joy of Ruby and Rails development. We're going to spread the love.

3. Will Charles and Thomas have to move to California?

Not at all. Tom and I will continue working from the Minneapolis area under Sun's remote-employee programs. You'll certainly see me and sometimes Tom at your favorite Ruby or Java conferences, but we'll continue to make home in flyover country. Moo.

4. Was this move in response to the IronPython 1.0 release this week?

Come on folks, you know how fast HR moves. You honestly think they could officially hire us in less than a month? This move has been in the making for several weeks..and man has it been hard to keep secret. I'm glad the truth is finally out and we can take a deep breath...before really getting down to business. (And really, for a move of this magnitude to only take "several weeks" is impressive by any measure...)

I wish the IronPython guys success...and Jim Hugunin is obviously in a similar position, doing what he loves. Hopefully our differing sponsorship won't get in the way of cross-pollenation and idea sharing. It would be a real shame if being hired to innovate by innovative companies actually hurt the innovation that got us here in the first place.

--

I'll plan to keep up with major questions as they come up. I really want this to be full disclosure, folks, as much as humanly possible. JRuby isn't my project or Tom's project--it's yours. You deserve to be in the loop (zero-day media blitz secrets notwithstanding, of course ;)

JRuby Steps Into the Sun

It's going to be a big news day for JRuby :)

The two core JRuby developers, myself and Thomas Enebo, will become employees at Sun Microsystems this month. Our charge? You guessed it...we're being hired to work on JRuby full-time.

Perhaps some of you may have seen this one coming. For others, it may be a pleasant surprise.

The primary goal is to give JRuby the attention it really needs. The potential for Ruby on the JVM has not escaped notice at Sun, and so we'll be focusing on making JRuby as complete, performant, and solid as possible. We'll then proceed on to help build out broader tool support for Ruby, answering calls by many in the industry for a "better" or "smarter" Ruby development experience. I'm also making it a personal priority to continue growing the JRuby community, foster greater cooperation between the Java and Ruby worlds, and work toward a "whole-platform" Ruby-on-JVM strategy for Sun.

And yes, JRuby will remain as open source as it is today. It just might start moving a bit faster (as if it weren't moving fast already!)

You can imagine how excited I am about this opportunity, and how pleased I am to know that Sun takes Ruby so seriously. Not only will I get to work on the project I've poured my heart into this past year, but I'll be able to do it while helping one of my favorite companies turn a technological corner. Naturally I've been talking with a myriad of folks at Sun over the past several weeks, so believe me when I say these guys really get it. The tide has turned and dynamic languages are on everyone's agenda. It's going to be quite a ride.

Thanks very much to Tim Bray, who has proven a fearless advocate for Ruby and dynamic languages at Sun. Thanks also to Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahé, and others fighting to improve Java and make the Java platform a dynlang-friendly place. Thanks also to my Sun interviewers for their excellent, thoughtful questions and ideas about the future of JRuby and dynlangs on the JVM. I'm looking forward to working with you all.

And finally, thanks to all you who use, contribute to, and blog about JRuby. You're a huge part of this, and I want you all to join us on this great Ruby adventure. Community involvement has gotten JRuby where it is today, and community involvement is vital to making Ruby on the JVM a reality.

Updates: I'll list substantive news items and blog postings as they come in (and I'll let your RSS aggregators deliver the one-liner posts ;)

Tim Bray: JRuby Love - Tim lays out some informative FAQs on the Sun move. He was our biggest Sun advocate, so he should know.

InfoQ: Sun Officially Back Ruby, Brings JRuby In-House - Includes a link to the newly-posted presentation we taped for InfoQ this past spring.

Thomas Enebo: JRuby Shines in Sun - My co-conspirator's almost-as-cleverly-named post about the event.

Bloglines Aggregation of JRuby articles - The blogosphere is very busy today!

InternetNews.com: JRuby Developers Join the Sun Fold - Andy Patrizio talks to Tim Bray and I about what this means for JRuby and for Sun.

InfoWorld: Sun picks up a gem in JRuby - Mostly a blog wrap-up, but a few good links and quotes.

Wednesday, September 6, 2006

ActiveRecord-JDBC 0.2.1 Released!

I told you it would only be a couple days!

ActiveRecord 0.2 has been released. (It's actually 0.2.1 because of a minor Gem glitch)

Ola wraps it up in the link above, but for the record it supports normal AR operations and basic migrations for the following databases:

MySQL
PostgreSQL
Oracle
HSQLDB
Microsoft SQL Server (except for change_column_default)
DB2 (except change_column, change_column_default, rename_column, remove_column,
add_index, remove_index and rename_table)
Derby (except change_column, change_column_default, remove_column, rename_column)
FireBird (except change_column_default and rename_column)

Whew! And we really only started getting migrations and additional databases into the mix a week or two ago. Things go very fast when you have JDBC to handle all the heavy lifting!

I'm going to demo the AWDwR2 Depot app running on top of MySQL at Rails, and probably demonstrate one of the other databases Rails doesn't normally support as well (Derby perhaps? or SQL Server if I can get Parallels up before presenting?)

Usage

Ola has a Derby walkthrough with some unusual typos [Update: my mistake, he symlinked stuff like "gem" to "jem" to avoid collisions with MRI], but here's my walkthrough for MySQL in ultra-condensed form:

Install JRuby from trunk or my branch
Build it (not necessary once we get another release out)
```
ant clean jar
```

Set up env vars for JRuby

export JRUBY_HOME=[jruby dir]
export PATH=[jruby dir]/bin:$PATH

Install Rails
```
gem install rails -y --no-rdoc --no-ri
```

Install ActiveRecord-JDBC

gem install activerecord-jdbc --no-rdoc --no-ri

Generate a Rails App
```
rails ~/testapp
```
Go to the app
```
cd ~/testapp
```

Modify database.yml

development:
 adapter: jdbc
 driver: com.mysql.jdbc.Driver
 url: jdbc:mysql://localhost/testapp_development
 username: ...
 password: ...

Modify environment.rb:

require File.join(File.dirname(__FILE__), 'boot')
require 'active_record/connection_adapters/jdbc_adapter'

Add driver to CLASSPATH
```
export CLASSPATH=$CLASSPATH:mysql.jar
```
Create a testapp_development database, grants for testapp user, and widgets table in MySQL (use migrations if you like)
Scaffold Widgets CRUD
```
jruby script/generate scaffold widget
```
Start up the server
```
jruby script/server
```

And that's about it. You've got a scaffolded widget page running in JRuby over JDBC to MySQL.

Pretty neat, eh?

Troubleshooting

ActiveRecord-JDBC does not install: I had some trouble myself; I think something's up with either RubyForge or with our released gem. You can always download ActiveRecord-JDBC and install it locally, of course.
scaffold fails with an error about "nonexistent jdbc adapter": Ensure you've added the require line to environment.rb (hopefully this will be unnecessary in the future)
scaffold and script/server terminate without running: Make sure you've successfully installed the ActiveRecord-JDBC gem. The additional require in environment.rb causes Rails scripts to die silently if there are any errors.
scaffold fails with the error "cannot convert NilClass into String": Make sure you've correctly specified the driver and url lines in database.yml

What's Next

We're going to continue adding database support, especially if you folks can contribute migrations impls for your database of choice. It's fun and easy!

We've also got a patch under discussion to allow adding JDBC database jars to [RAILS_ROOT]/lib and have the driver pick them up automatically. This could obviously be extended to Rails at large for service client jars, persistence framework jars, and so on. No more CLASSPATH manipulation!

We're hoping to get the Rails guys to include "jdbc" in the list of supported adapters out-of-the-box, so that environment.rb require is not necessary.

We're also going to see if there's a way to abstract out all the DDL code in core Rails, so we can all benefit from the same code.

Monday, September 4, 2006

More ActiveRecord Information

Supporting More Databases

A number of folks have asked about support for database X. We want to support all possible databases, of course, and JDBC gives us a huge head start on that. Many databases will only need a bit of tweaking to support all the basic CRUD operations. The additional work...small though it may be...is implementing the schema-manipulating methods of ActiveRecord. Here's a complete list...if you can provide examples for each operation, it would speed our supporting them:

add_column
add_index
change_column
change_column_default
columns
create_table
drop_table
initialize_schema_information
native_database_types
remove_column
remove_index
rename_column
rename_table
structure_dump
table_alias_for
table_alias_length

Check available docs for ActiveRecord or look at the existing adapters in ActiveRecord in SVN for examples on each.

Avoiding Modifying active_record.rb

There's now a thread going on the Rails core mailing list and a bug to address the issue of adding adapters to Rails. Hopefully one of two things will come out of this:

"jdbc" will be added to the list of adapters available in core Rails
a mechanism will be added (or fixed) to allow adding to the list of adapters from outside the core source

The former would be ideal, since no additional, special config changes would be needed for jdbc versus MySQL, for example. The latter would be an "ok" compromise, but would require modifying all apps to add "jdbc" to the adapter list. I'll report back when something comes of it.

Sunday, September 3, 2006

Java Regex Broken for Alternation over Large Strings

This is a serious bummer.

I've been working through some of Rails's test cases this evening. Since I've got Depot running reasonably well now and I know I can easily wire together a simple Rails app that calls Hibernate or EJBs, I figured I'd try to get a better handle on the true state of Rails support.

As I'm running test cases--the majority of which appear to be passing, btw--I came across a couple goofy regex issues. The first is one we'd seen before, where dot refuses to match \r. In this case, adding DOT_ALL to the Pattern's flags seems to resolve it. I think we just hadn't noticed that flag before, so many other similar bugs might be resolved the same way. Not an easy issue to narrow down, but I found it and moved on.

So then I started seeing SystemStackErrors popping up within the CGI library. When I see stack overflows in JRuby, I usually figure it's one of two things:

Something's wrong with JRuby that's breaking a termination condition in Ruby code, so a recursion is never ending
JRuby itself is missing a termination and recursing endlessly

Pretty simple issues to track down...find where the recursion is happening, and figure out why it's not terminating. Except in this case, the recursion wasn't in either Ruby or JRuby code. It was in Java's regex library.

Blowing The Stack

O Java, how I love Thee. Every library I could want, all in one place. You care for me so well. It pains me to find your faults.

So it appears that the Java regex library's compiled patterns execute recursively. This alone wouldn't be particularly unusual, especially if the recursion was limited by the complexity of the regex itself. However in this case it seems the recursion is a factor of the string to match, rather than of the expression complexity. With a large enough input string, I can get Java's regex to blow the stack every time.

regex = /\A((?:.|\n)*?)?([\r\n]{1,2}|--)/n
long_string = ""
76.times { long_string += "xxxxxxxxxxxxxxxxxx" }

long_string.sub(r) {""}

This bit of Ruby code will cause java.util.regex.Pattern to blow the stack during matching. I'm sure this regex could be reduced to a simpler case, but I don't really need to go through the exercise of doing so; others have reported the same issue:

Pattern.matches throws StackOverFlow Error - Closed, will not be fixed (reported in 2004)
java.util.regex routines should use less stack space - In progress, request for enhancement (reported in 2002)

So the issue stands, unfortunately. I'm not sure I'd characterize it as an RFE...I'm no regex expert, but I would hope my regex engine wouldn't overflow based on large input, especially if that input was completely bogus as in my example above. I don't think that's unreasonable, especially considering that Ruby's regex engine appears to handle this case (and considerably larger cases) just fine. Correct me if I'm expecting too much.

So what's the damage? Well, since we currently use java.util.regex exclusively, and since Ruby libraries and apps very frequently use regex to match against very large strings, we'll have to migrate to a different regex library. Until that happens, however, Rails under JRuby will not support large multipart posts, at a minimum. There may be other places this has an effect, but multipart posting was the area I investigated.

So for now...I guess it's just busted. We'll begin evaluating alternative regex libraries posthaste. Any help from you folks would be appreciated...just take that regex or one from the bugs and try to match against extremely large input.

Rewrite the Regex?

Some may say that the regex should be rewritten to avoid the use of alternation. Perhaps so, perhaps there's a better way. However Ruby handles it fine, so requesting that the Rails folks or any other Ruby devs start tailoring their regex so they will work under JRuby is quite out of the question. If we can't run the same regex against the same input, we need a different regex library...that's all there is to it.

Besides, the bugs posted have additional regex that are even simpler. It just seems to be a limitation of the Java regex library that certain regex will blow the stack on large input.

For the record, here's the relevant bit of the stack. I get pages and pages of this, under both Java 5 and Java 6 beta 2...both 64-bit under Linux:

...
at java.util.regex.Pattern$Branch.match(Pattern.java:3998)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4052)
at java.util.regex.Pattern$LazyLoop.match(Pattern.java:4241)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4111)
at java.util.regex.Pattern$BranchConn.match(Pattern.java:3962)
at java.util.regex.Pattern$CharProperty.match(Pattern.java:3314)
at java.util.regex.Pattern$Branch.match(Pattern.java:3998)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4052)
at java.util.regex.Pattern$LazyLoop.match(Pattern.java:4241)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4111)
at java.util.regex.Pattern$BranchConn.match(Pattern.java:3962)
at java.util.regex.Pattern$CharProperty.match(Pattern.java:3314)
at java.util.regex.Pattern$Branch.match(Pattern.java:3998)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4052)
...

What a downer.

Update (2011-3-1): Someone stumbled across this post recently and I realized I'd never updated it with a solution for this problem. I checked out several alternative Java regex engines. Some had the same problem, being implemented the same way, but JRegex both resolved the issue and performed very well. I'd recommend it to anyone that needs to work around the problems in Java's built-in regex library.

Using the ActiveRecord-JDBC Adapter

Ola Bini, Nick Sieger, and others have been making great progress on the ActiveRecord-JDBC adapter lately. I figure it's a good time for a brief update on progress, and a short walkthrough on how to use it.

Where We Are, Where We're Going

There has been one official release of the ActiveRecord-JDBC adapter, a 0.1 that has basic SQL support for MySQL. It's available as a gem called "ActiveRecord-JDBC" (case-insensitive). It provides normal MySQL support for most major ActiveRecord operations today, and it's mostly the same code we used for our JavaOne demo.

Although the JDBC libraries give us plenty of information on database typing and precision, they provide practically nothing for generating DDL. Because of this, a large part of current ActiveRecord capabilities have to be written outside of the JDBC-aware code. DDL differs between databases, so like the core Rails project, we're forced to implement the various schema-related methods of ActiveRecord differently for different database vendors.

Currently, we're just reproducing the same code available in core Rails, with a little manipulation to work with ActiveRecord-JDBC, but we're hoping to work with the Rails team to abstract out the non-driver-specific portions of the core ActiveRecord adapters so the JDBC version can leverage the same code. I'm also hoping we'll be able to get the "jdbc" adapter name added to core Rails in the active_record.rb file where such adapters are listed. This will allow JRuby users to install Rails and the JDBC adapter and immediately start using them, without additional steps.

We are planning a second release of the JDBC adapter very shortly. It should have reasonably solid migrations/DDL support for MySQL, Oracle, and Firebird, as well as some level of support for HSQLDB, Derby, and others. It's moving along quickly now that it's been spun off into its own jruby-extras project. You can go there or to the jruby-extras SVN repository to grab the bleeding-edge source from SVN.

Getting up and running with ActiveRecord-JDBC

Despite the design complexities and our DDL woes, getting an ActiveRecord-based app up and running on JDBC is now very simple. This walkthrough proceeds from a stock JRuby install, and is based on current JRuby trunk (though it may work ok with 0.9.0 as well...we'll have a new release out soon).

Ensure JRuby is set up and working correctly via the normal setup procedures
gem install rails -y --no-rdoc --no-ri (ri and rdoc generation are still too slow under JRuby)
gem install ActiveRecord-JDBC --no-rdoc --no-ri (this is the 0.1 version for now, but hopefully we'll have 0.2 out this week)
Edit lib/ruby/gems/1.8/gems/activerecord.../lib/active_record.rb, adding jdbc to the list of RAILS_CONNECTION_ADAPTERS toward the bottom of the file:
```
RAILS_CONNECTION_ADAPTERS = %w( jdbc mysql postgresql sqlite firebird sqlserver db2 oracle sybase openbase )
```

Modify database.yml for your settings. For example, using MySQL:

development:
  adapter: jdbc
  url: jdbc:mysql://localhost/testapp
  driver: com.mysql.jdbc.Driver
  username: testapp
  password: testapp

As always, ensure the appropriate JDBC jar files are in your CLASSPATH

That's pretty much all there is to it. We'll get that second release out in a day or two so that migrations work and additional databases are supported, but these instructions won't change. I'll post here when that release is out.

How Well Does It Work?

It seems to work very well so far. As part of my JRuby on Rails presentation at RailsConf, I'll be demonstrating the new Depot application from Agile Web Development with Rails 2nd Ed. The entire app seems to work very well under JRuby, and I only had to make one additional manual change in the database because JRuby doesn't yet work well with edge rails (on which the book's examples are currently based). It's quick and responsive, and will only improve as we continue on.

Also keep in mind that the DDL issue only limits the JDBC adapter's usefulness for migrations or schema-manipulation purposes. Without DDL generation, it will still work with many, many databases without major modifications, since JDBC really shines here. Hopefully a future version of JDBC will provide DDL metadata or tools for manipulating database schemas. Until then, we'll continue to work with the Rails folks to find a good solution for DDL under the ActiveRecord-JDBC adapter.

Saturday, September 2, 2006

From Eclipse to NetBeans: Part 3

I got a lot of good tips from NetBeans developers and users about how to resolve some of the issues I ran into. A number of them, as I mostly expected, were related to my running a beta that's still under development. Others are resolved via modules and add-ins (that in many cases should perhaps be included as standard). And still other cases are resolved or scheduled to be resolved in NetBeans 6. So to be fair, I decided to continue my NetBeans adventure by diving to the bleeding edge of NetBeans: building directly from source and running JDK 1.6 Beta 2.

I won't go into the details, but getting NetBeans to build was an extremely simple matter (thanks to Tor Norbye from Sun). Set CVSROOT, checkout -P standard, cd nbbuild, ant. It's really that simple. I did need to up the maximum memory needed for ant, but that was a minor issue. After the build, I found "ant tryme" that starts up NetBeans, and I was off and running.

This article will be a short wrap-up of issues from Part 1, revisited based on tips, tricks, and NetBeans 6 current and planned features. Hopefully it will demonstrate to potential switchers that NetBeans has really turned a corner. I'll revisit Part 2 in the next article.

I used to be among the NetBeans detractors...and for good reason; NetBeans had a rocky start. But I'm rapidly growing fond of it, especially using NetBeans 6.

Salvation

I'll take the items from Part 1 point-by-point. There's some useful links inline as well, so feel free to skim this list for issues of particular interest to you.

Antialiasing - RESOLVED! When running under JDK 1.6, all text elements are immediately antialiased according to the host platform's settings. No additional configuration changes are needed.
SVN by default - RESOLVED, I think. My basic pull of NetBeans 6 from CVS included SVN support immediately. I believe it's intended to be in the full release by default as well.
Workspaces - OPEN. My main use for workspaces is to keep different sets of projects in different places, and to a lesser extent to have different configurations for those sets. No obvious support for this in NetBeans 6 yet.
Separate repository view - OPEN. Eclipse's repository view is a godsend when you're hunting around for projects, tags, and branches, or if you want to do any remote repository management. I still miss it, and there's no out-of-the-box support in NB 6 for a repository view.
Standard SVN layout support - OPEN. I would like NetBeans to understand what "trunk", "tags", and "branches" dirs in SVN are used for.
Delete project not deleting files - OPEN. I tried to delete a working copy locally and the files remained on disk.
Wizarditis - OPEN. The best example of this is perhaps the SCM wizard, where at least seven clicks are required for me to check out my JRuby branch. If I had a repository view, it might take three or four.
Show non-project files in project view - OPEN, but not a big deal. I've gotten accustomed to just using the Files view when I need access to non-Java source. I still think it's necessary to show other files in the project view, but it hasn't gotten in my way as much as I thought it might.
Settings dialog search - OPEN, but improving. I remember once being told that if people need to use a site map or search for your site, you're doing something wrong. NetBeans should actually be applauded for presenting common settings in a novice dialog and a full complement of expert settings a button-press away. In NB6, they appear to be moving some of the important advanced settings to the main dialog as well. It's a balancing act, but I think a lot of people will appreciate the easy dialog.
Browser selection - Doubly RESOLVED. With JDK 1.6, NB6 uses your platform's browser by default, and the setting has been moved to the basic settings dialog.
NetBeans is a goofy name - UNRESOLVABLE. There's too much branding and history behind the NetBeans name to change it, or so I'm told. Oh well, at least it's not limiting in any way, and it does have a nice mouthfeel to it unlike "Visual Studio 2005".
Eclipse keybindings - OPEN, but workable. The default Eclipse keybindings are missing some important ones, but you can go map them yourself easily enough. Unfortunately there's no equivalent to Ctrl-Shift-R, which is like a "super open" for any file in the workspace. I also haven't found an outline view shortcut like Ctrl-O, which hurts a bit.
Sorted members view - OPEN. However I can deal with the default sorting for now.
Show packages as a hierarchy - OPEN, but I've been using the Files view almost exclusively which already uses a hierarchy.
Anti-aliased UI - RESOLVED! Under JDK 1.6, UI elements are also antialiased! It looks great!
Collapsing comments - RESOLVED, but one bug. It turns out that only the large license block at the top of our JRuby source files refuses to collapse. Everything else, including JavaDocs and multi-line comments, collapses ok. Probably a bug in how NB determines what comments to collapse.
Improved coloration - RESOLVED SOON. Better coloration and other editor improvements are planned for NB6.
Memory usage - OPEN, but improved. NetBeans 6 is a little better, but still typically takes over 200MB and sometimes over 300MB of memory. Eclipse usually stays under 200MB for me. However I don't have any modules disabled, and NB6 comes with UI design, Java EE, DB support, XML support, Web design support and a ton of other stuff out-of-the-box. That balances things out a lot.
FIXME support - RESOLVED via external module. The NetBeans Tasklist looks quite a bit more sophisticated than Eclipse's support.
Clear search results - OPEN, but workable. Search for nothing and the results clear. However I conversed with Roman Strobl, NetBeans Evangelist, and he agreed that was a little cumbersome.
Right-click editor menu with SCM operations - RESOLVED. You can't get those options right-clicking in the editor, but you can right-click the editor tab for the same effect. Hooray!
Odd behavior of SVN menus in file view - RESOLVED. This and several other SVN issues I ran into appear to have been fixed in recent 5.5 and 6.0 development builds. Subversion support seems to be tighter in NB6, or so it seems.
Slow start-up - OPEN, but fading fast. It's not a large perceptible difference between Eclipse and NetBeans now, and NetBeans is loading a lot more stuff. It's very nearly RESOLVED.

Hopefully it's apparent that NetBeans is arriving fast. If I were to make predictions, I'd say that NetBeans 5.5 will be a really powerful and useful release, especially considering suport for Java SE 5 and Java EE 5 out-of-the-box. I believe the bugs I've encountered will be wrapped up, and 5.5 will be a compelling alternative to "Eclipse-plus-ten-thousand-plugins", which functionality it easily matches.

I would also predict that NB6 may finally be the big release that surpasses Eclipse for day-one usability and functionality. There's just so much packed into the base product, I don't think Eclipse itself is even a fair comparison. WSAD may be the only real competitor at that point, and I'd prefer not to run that monster (and I also prefer not to use WebSphere.)

One area I think NetBeans needs to improve is in making development releases easily available. I have to dig down through multiple pages, dropdowns and license-acceptance forms to get at the 5.5 and 6.0 dev releases, which have so far been very stable and very nice. To save some time, here's a link to the NetBeans Download form. "Daily" builds are obvious enough, but I believe "Q-Build" builds are probably "QA" builds, perhaps equivalent to Eclipse's "integration builds" or "milestones". Q-Builds might be a good place to get started for you Pro users out there.