A year ago, I filed a bug report for JRuby. Unfortunately, the bug is still alive and well today. Its name is JRuby 6763.
I am interested in the idea of Ruby having alternative implementations. Such alternatives have their own advantages, and create their own opportunities, such as bringing Ruby into a Java only shop.
I also like the JRuby team. I’ve met Charles Nutter and Hiro Asari in Australia and Japan, and I like them. Not to mention Yoko Harada, and other people I’ve met who I either forgot their names, or forgot they were JRuby people. JRuby people have also contributed to MRI, which is wonderful news for a world where too many unnecessary divides exist. In addition, the JRuby team fixed a performance issue that I encountered (JRuby 6766).
But my experience with MRI, compared to that of JRuby and other implementations, is that MRI has never produced false information, whereas the alternatives have.
What I mean by this is that I’ve found bugs in MRI that causes it to crash. But I’ve never written a program that successfully executed, but gave me incorrect output. By contrast, both of the major alternatives have done so.
In fairness to the other implementations, some of the Ruby code that I’ve had issues with has been fairly obscure and esoteric. I was the one who complained that Rubinius didn’t implement the flip flop operator. And JRuby 6763 is about trouble when I use a method named … “method”.
I don’t know why MRI has been more reliable for me. It could be a different culture in the MRI team compared to JRuby or Rubinius. It could be that MRI has more staff and volunteers. Or merely that MRI has more users, which mean bugs are detected earlier.
No doubt, some people have code that works fine on alternative implementations, but has trouble on MRI. I can only talk about what I know.
As to why I haven’t fixed 6763 myself? With regards to fixing it in work hours, the problem is that I’m a bioinformatician, not a programmer. I wouldn’t be able to justify learning Java during work hours to be able to fix this problem. And with regards to spare time, I spend too much of my time staring at a computer screen as it is, and becoming a JRuby patch submitter would make it worse.
Do I feel “entitled” to a bug fix? No I don’t. The only thing I’m entitled to do is write a blog post expressing what I think.
Would I use JRuby if this bug were fixed? Not in production. The first thing I’d do if this bug were fixed would be to run the unit tests failing because of 6763, and try to find another bug or three to complain about! I might also use JRuby to profile my application for CPU usage or object creation.
Do I think the JRuby team doesn’t pay enough attention to bugs? I wouldn’t assume that. This is just speculation, but I assume the core team decided their time is best spent on major tasks that improve JRuby, and that bug fixes that don’t affect many people and are trivial to fix are best handled by casual committers.
Unfortunately, I don’t have the answers for what can be done. Is it more users trying out alternative implementations? More paid staff? Or something else? I don’t know.
Running late and out of timetable order 
July 8, 2013 at 6:27 pm |
Your thesis here depends on the idea that MRI is incontrovertibly correct. If that were correct, MRI would never have bugs, would never change its output over time, would never break old code. That’s obviously not the case.
JRuby and Rubinius and other Ruby implementations implement Ruby to the best of our ability by using existing test suites (JRuby uses several), building new test suites (JRuby and Rubinius both write new tests and specs, many of which we share), and by running real applications’ and libraries’ test suites (which depends on users in many cases). It’s a long, hard job to implement a language that has no complete specification, no complete test suite, and no clear agreement across the board on how it should behave.
In this case, we diverged in behavior partially because block argument logic has gone through many changes in Ruby over time. Under some versions of Ruby, a single-element array passed as the sole argument to a block causes that element to be unwrapped and used as the argument. This logic was still in play in JRuby for our proc-wrapping-method logic, which caused the single-element array in your bug report to get unwrapped incorrectly. It may have been correct logic for blocks, and may even have been correct for methods at some time in the past…but it has not been correct for some time.
Fixing the issue was not terribly complex, but did require breaking away from the old block parameter-passing behavior and using a different path, with some additional work to fix issues along that path that were not completely compatible with existing Method logic. It wasn’t that we didn’t want to fix the issue or didn’t consider it a high priority…it was simply that it got left behind. These things happen.
In any case, your bug has now been fixed for JRuby 1.7.5. As they say, the squeaky wheel gets the grease, and I always tell users to make noise about unfixed bugs that affect them. With limited resources, this is the best way to ensure issues move forward…and as in this case, sometimes it elicits a fix the same day.