JRuby

I've landed, gotten mostly back in the right timezone without too many incidents (except running through SFO to board very badly scheduled connection).After allowing the impressions from the last 6-7 days to sink in a little, it's time to summarize ... [More] RailsConf. I'll go through the sessions I saw and then do some concluding remarks.The first day was tutorials. I had a good time in Neal Fords and Pat Farleys tutorial on Metaprogramming. I can't say I learned much from the sessions, but it was very good content, extremely well presented, and I got the impression that many in the room learned lots of crucial things. The kind of knowledge about internals you get from a talk like this allows you to understand how metaprogramming in Ruby actually works, which makes it easier to achieve the effects you want.After that I sat around hacking in the Community Code Drive for the rest of the day, with lots of other people. I wasn't involved in gitjour (which by the way is incredibly cool), but I did manage to find a memory leak in iTerms Bonjour handling due to gitjour. Neat. Me and David Chelimsky paired on getting support for multiline plain text story arguments into RSpec, and by the end of the afternoon it was in.Finally, we headed out to the JRuby hackfest, which ended up being over full with people. That's a good problem to have. We had a great time, hacking on different things, helping people to get started and debugging various problems. All in all it was a very productive day.I began the Friday with Joel Spolsky's keynote. In contrast to many other people I didn't like it. There wasn't really any content at all, just some humorous content and lots of jokes about naked women. I expect something a bit more profound for the first keynote of the conference, since they have a tendency to actually set the standard for the rest of the days.After the keynote, John Lam showed off IronRuby running a few simple Rails requests. This is a great achievement, and I'm very impressed with their results. I have argued that IronRuby would probably never reach this point, and I'm very happy to admit I was wrong and offer my apologies to John Lam and the IronRuby team. That said, the fact that IronRuby runs a few different Rails requests is not the same thing as saying that IronRuby runs Rails. My personal definition of running Rails is more about having the Rails test suite run at a high percentage of success (something like 96-98% would be good enough for almost all Rails apps to work, provided they are the right 98%). (ED: Evan Phoenix just told me that MRI doesn't run the Rails test suite totally clean either, because of the way the Rails development process works. So a 100% is probably not a good measure of Rails compatibility.) I assume that this is going to be the next goal for the IronRuby team, and I wish them good luck.I saw the Hosting talk after that, but I have to admit I was wrapped up in a seriously annoying JRuby bug at the moment so I didn't really pay attention.The DataMapper talk was very full and gave a good overview of why DataMapper might be a better choice than AR in many cases. The presentation style could possibly have been a bit less dry, but the content was definitely delicious.If the next two days were the JRuby days, the Friday was the day for all other alternative implementations. I sat in on the Rubinius talk by Evan Phoenix and friends, and then the much talked about MagLev presentation.I first want to congratulate Rubinius on running several different Rails requests. It's very cool and a great milestone. The same caveats as for IronRuby applies of course. But wow, the debugging features is awesome. First class meta objects are extremely powerful, and will provide many capabilities to the platform. The presentation was also extremely entertaining. One of the best presentations for the sheer fun everyone seemed to have. Props to Evan, Brian and Wilson for this.So. The MagLev talk. First, there seems to be some misunderstandings about what MagLev actually is. It is not a hosting service. Gemstone might offer a hosting service around MagLev in the future, but that's not what is going on here. MagLev is a new virtual machine for Ruby, based on Gemstone/S. Basing it on a Smalltalk machine makes it very easy for Gemstone to implement a large subset of Ruby and having it running cleanly and with good performance. Exactly how much has been implemented at this point is not really clear, since no major applications run, and the RubySpecs have not been used on it yet. I assume that the implementation doesn't handle enough Ruby features yet to be able to run the mspec runner and other important machinery.Was this presentation important? Yeah, sure. To a degree. It was a cool presentation, whetting peoples appetite by showing something that might some day become a real Ruby platform with built in support for an incredible OODB. But it's still early days.The Saturday began with Jeremy's keynote. He talked about the new things in Rails 2.1 and also showed the same app running in Ruby 1.8, 1.9, Rubinius and JRuby. Very cool.I ended up in Nathaniel Talbotts 23 Hacks session which was fun. Good stuff.After that the JRuby day began in earnest with Nick's talk about deploying JRuby on Rails. This was mostly the same talk as given at JavaOne, but more geared towards Ruby programmers. Useful information.Dan Manges and Zak Tamsen gave an extremely useful talk about how to test Rails applications correctly. Very good material. Exactly the strong kind of deep technical knowledge, gained by experience, that people go to conferences to get.My talk about JRuby on Rails was generally well received. I had a fun time, and of course I managed to run out of time as usual. I wonder why I'm always afraid of running out of material. That has never happened when I'm talking bout JRuby.The final technical session of the day ended up being a walk-around to all the different presentations going on and taking a peek, and then ending up hacking in the speakers room.The evening keynote was by Kent Beck, and as usual he is fantastic to listen to.The Sunday started with the CS nerds anonymous session, held by Evan Phoenix. It ended up being a kind of lightning talk session, and had some nice points.After that Ezra gave his talk - that had nothing to do with the session title. He presented Vertebra, which is a cloud computing control system, based on XMPP, Erlang and the actors model. Very cool stuff, although it might not be that useful for people who aren't in charge of a quite large number of computers. But if you have your own botnet, this might be the best way to control them all. =)The final session of the day was the JRuby Q&A session, which basically flew by. The first ten minutes went in normal time, and then suddenly the session was over. I think we had good attendance, and the right level of questions. You can see all the points covered in Nicks blog, here.And then it was over.So, what was good? The technical level was definitely deeper and more rooted in experience. I have to say that this was probably the best Ruby conference I've been to, based on the depth and level of the presentations. Kudos to the scheduling people.And what was bad? A little bit too much hype about MagLev, and everyone's tendency to use dark colors on black backgrounds in their presentations. Hey, they look good on your computer screen, but it's really not readable! [Less]

RailsConf 2008 is over, and it was by far better than last year. I'm not one for drawn-out conference wrap-up posts so here's a summary of my most inspiring moments and if applicable how they're going to affect JRuby going forward.IronRuby and ... [More] Rubinius both running Rails has inspired me to finally knock out the last Rails bottlenecks in JRuby. Look for a release sometime this summer or later this fall to be accompanied by a whole raft of numbers proving better performance under JRuby than any other options. Oh, and huge congratulations to both teams, and I wish you the best of luck on the road to running larger apps.Phusion's Passenger (formerly mod_rails) has made some excellent incremental improvements to MRI for running Rails. It's nothing revolutionary, but judging by the graphs they've managed 10-20% memory and perf improvements over the next best MRI-based option. We're going to try to match them by more aggressively sharing immutable runtime data across JRuby instances such as parsed Ruby code (which on some measurements accounts for almost 40% of a freshly-started app's memory use). We'd like to be able to say that JRuby is also the most memory-efficient way to run Rails in the near future.The Maglev presentation inspired me to dive back into performance. For the most part, we stopped really working hard on performance once we started to be generally as fast as Ruby 1.9. Now we'll start pulling out all the stops and really kick JRuby into high gear.Wilson Bilkovitch impressed me most when he used the historically-correct "drinking the Flavor-Ade" instead of the incorrect but more popular "drinking the Kool-Aid".Ezra's talk on Vertebra, Engine Yard's upcoming Erlang-based XMPP routing engine, almost inspired me to try out Erlang a bit. Almost. At any rate it sounds awesome...I am all set to write an agent plugin for JRuby when it's released and the protocol is publishedMy keynote was generally pretty well received, but I had several people say I should have smiled more, and that it came off as a bit defensive. I think a lot of that had to do with getting only 10 minutes for the whole thing and trying to jam too much in, but I'll definitely pay attention to that in the future.This was my first US-based Ruby-related conference where I did not play Werewolf. I don't expect to ever play much (or maybe ever) in the future. I've decided I don't really want to play a game where the best players are the ones who can learn to lie most convincingly. It seems like a crucial flaw in the game, and if I ever do play again I will try to make a strong case that to win, kill the most experienced people first. They'll never be a net good, because if they're good villagers with strong deductive skills, they're also likely to be good warewolves, with strong lying skills. Eject them immediately.All told, a great conference. I'm looking forward to RailsConf EU 2008 and RubyConf 2008. [Less]

Of course anyone who reads my blog expected I'd have something to say about Maglev once it was made public. I've previously performed what I thought was a fair analysis of the various Ruby implementations, and Maglev was mostly a sidebar. With their ... [More] coming out at RailsConf, they're now fair game for some level of analysis.Avi Bryant and Bob Walker talked about Maglev, a new Ruby VM based on Gemstone's Smalltalk VM, at RailsConf this weekend. And there's been an explosion of coverage about it.First off, they demonstrated its distributed object database automatically synchronizing globally-reachable state across multiple VMs. It's an amazing new idea that the world has never really seen...except that it isn't. This is based on existing OODB technology that Gemstone and others have been promoting for better than a decade. It's cool stuff, no doubt, but it's been available in Gemstone's Smalltalk product and in their Java product for years, and hasn't seen widespread adoption. Maybe it's on the rise, I really don't know. It's certainly cool, but it's certainly not new.The duo eventually moved on to show off some performance numbers. And please pardon me if I don't have these numbers exactly right. They showed our old friend fib running something like 15x faster. Method dispatch something like 30x faster. While loops 100x faster. Amazing results.Except that these are results reported entirely in a vacuum. Whether this is fib following the "rules" of Ruby is entirely an open question. Whether this is method dispatch adhering to Ruby's call logic is entirely an open question. Whether this is a while loop using all method calls for its condition and increment steps is an open quesetion. Because the Maglev guys haven't started running Ruby tests yet. Is it Ruby?I don't want to come off as too defensive here, and I don't want to appear as though I'm taking shots at another implementation. I've certainly launched my share of controversial commentary at Rubinius and IronRuby over the past few months, and while some of it may perhaps have slipped over the edge of polite commentary, I always thought I was being at least honest.But there's an entirely new situation with Maglev. Maglev has begun to publish glowing performance numbers well in advance of actually running anything at all. They haven't started running the RubySpecs and have no compatibility story today. You can't actually get Maglev yet and run anything on it. It's worse than Vaporware, it's Presentationware. Go to Gemstone's site and download Maglev (you can't). Pull the source (you can't). Build it yourself and investigate what it does (you can't). You start to understand what I mean. And this is what the "Ruby media" is calling the most disruptive new Ruby technology. Dudes, come on. Were you born yesterday?It's time for a confession. I've been too hard on IronRuby and Rubinius. Both teams are working really hard on their respective implementations, and both teams have really tried to stay true to Ruby ideals in everything they do. Guess what...IronRuby runs Rails. Rubinius runs Rails. And if they're not production ready now, they will be soon. And that's a good thing for Ruby. Sure, I still believe both teams may have made unreasonable claims about what they'd be able to accomplish in a given period of time, but we've all made those claims. If they haven't delivered on all milestones, they've delivered on most of the important ones. And it's those milestones I think deserve some credit now.My sin is pride. I'm proud of what we've accomplished with JRuby. And when new implementers come along saying they're going to do it in half the time, I feel like it belittles the effort we've put in. IronRuby has done it. Rubinius has done it. And while I've occasionally lashed out at them as a result, I've always been right there trying to help them...answering questions, contributing specs, suggesting strategies and even committing code. In the end it's the cockiness...the attitude...the belief that "I know better than you do" that irritates me, and I'm too sensitive to it. Color me human. But it's time for me and others to understand another side of IronRuby and Rubinius in light of this new contender.Rubinius and IronRuby teams have always considered compatibility as the primary goal. If you can't run Ruby apps, you're not Ruby, right? And so every step of the way, as they published performance results AND compatibility metrics, they've always been honest about the future.IronRuby has managed to get great performance on several benchmarks by leveraging the DLR and the excellent language implementation folks on the DLR and IronPython teams at Microsoft. So if nothing else, they've proven many of the "fast-bootstrapping" claims they've made about the DLR. And they've always been balanced in reporting results...John Lam has shown a couple slow benchmarks along with fast benchmarks at every talk, not to mention showing spec results with pass/fail rates clearly spelled out. That honesty has not gone unnoticed, and it shows a realism and humility that will ensure IronRuby's future; a realism that will ensure Ruby users who really want or need a .NET implementation will receive an excellent one.Rubinius has taken an entirely new approach to implementing Ruby by attempting to write as much as possible in Ruby itself. Maybe they have a lot of C/C code right now, but it's not that big a deal...and I was perhaps too pedantic to focus on this ratio in previous posts. What's important is that Rubinius has always tried to be an entirely open, community-driven project. Their successes and failures are immediately accessible to anyone who wants to pull the source; and anyone who wants to pull the source can probably become a Rubinius contributor within a short amount of time. They've had performance ups and downs, but again they've been honest about both the good and the bad. And like IronRuby, if they haven't trumpeted the bad side of things, it's because they're already proving that the Ruby-in-Ruby approach absolutely can work. The bad side will lessen over time until it completely disappears.Then there's Maglev. Like the other impls, I'm excited that there's a new possibility for Ruby to succeed. A high performance, "scalable" Ruby implementation is certainly what this community needs. But unlike most of the other implementations, it seems like Maglev is pushing performance numbers without compatibility metrics; marketing before reality. Am I far off here?Let's take a step back. Maglev will probably be amazing. It will probably be fast, maybe on some order approaching the numbers they've reported. Maybe this will happen some day along with support for existing Ruby code. And hell, maybe I'll use it too...I want to be able to write applications in Ruby and have insane performance so I can just write code the way I want to write code. So do you.But we're talking theory here. So let's do an experiment using JRuby briefly.Maglev published fib numbers as being around 15x MRI performance. That's very impressive. So let's check MRI perf on my machine (keeping in mind, as I've stated previously, that fib is far from indicative of any real-world performance):Ruby 1.8.6, fib(34), best of 10: 6.56sNow let's try stock JRuby, with full compatibility:JRuby 1.1.2, fib(34), best of 10: 1.735s (3.8x faster)Not bad, but certainly not up to Maglev speeds, right? Well...perhaps. JRuby, like IronRuby and Rubinius, has always focused first on compatibility. This means we're bending over backwards to make normal Ruby code run. So in many cases, we're doing more work than we need to, because compatibility has always been the primary goal. IronRuby and Rubinius will report the same process. Make it work, then make it fast. And both IronRuby and Rubinius are now starting to run Rails, so I think we've proven at least three times that this is the right approach.But let's say we could tweak JRuby to run with some "future" optimizations, optimizations that might not be quite "Ruby" but which would still successfully run these benchmarks.First, we'll turn off first-class frame object allocation/initialization, since it's not needed here:JRuby 1.1.2, fib(34), no frames: 1.273s (5.15x faster than MRI)Now we'll turn off thread checkpointing needed to implement operations like Thread#kill and Thread#raise, as well as turning off artificial line-position updates:JRuby 1.1.2, fib(34), -frames, -checkpoints, -positions: 1.25s (5.24x faster)Now we'll add in some fast integer operations like Ruby 1.9 includes, where Fixnum# , -, etc are specially-handled by the compiler. And we'll simultaneously omit some last framing overhead that's still around to handle backtrace information:JRuby 1.1.2, fib(34), "fastest" mode: 0.984s (6.67x faster)So just by tweaking a few things we've gained another 3x performance over MRI. Are we having fun yet? Should we extrapolate to optimizations X, Y, Z that bring JRuby performance another half-dozen times faster than MRI? If we can run the benchmarks, it shouldn't matter that we can't run Ruby code, right?The truth is that not all of these optimizations are kosher right now. Removing the ability to override Fixnum# certainly makes it easier to optimize addition, but it's not in the spirit of Ruby. Removing frames may be legal in some cases (like this one) but it's not legal in all cases. And of course I've blogged about how Thread#kill and Thread#raise are broken, but we have to support them anyway. On and on we can go through lots of optimizations you might make in the first 100 days of your implementation, only to back out later when you realize you're actually breaking features people depend on.This all adds up to a very different picture of Ruby implementation. Rather than wishing for a rose-colored world where anyone with a new VM can swoop in and post magic performance numbers, perhaps we as Ruby community members should be focusing on whether this is going to help us actually run today's apps any better; whether these results are repeatable in ways that actually help us get shit done. Perhaps we should be focusing on the compatibility story over bleeding-edge early performance numbers; focusing on tangible steps toward the future rather than the "furs and gold rings" that David warned about in his keynote. Maybe we should think more about the effect that broadcasting vaporware performance numbers will have on the community, rather than rushing to be the first to republish the latest numbers on the latest slides. Maybe it's worth taking all this microbenchmark nonsense with a grain of salt and trying it out ourselves (if, of course, that's even possible) before serving as the mouthpiece for others' commercial ventures.Am I wrong? Am I being unfair? Am I taking an unreasonable shot at Maglev? [Less]

OK. It's time to get rid of this terminology problem. Ruby does NOT have meta classes. You can define them yourself, but it's not the same thing as what is commonly called the meta class. That is more correctly called the eigen class. The singleton ... [More] class is also better than meta class, but eigen class is definitely the most correct term.So what is a meta class then? Well, it's a class that defines the behavior of other classes. You can define meta classes in Ruby if you want too by defining a subclass of Class. Those classes would be metaclasses.Edit: Of course, if you actually try to define a subclass of Class you will find that Ruby doesn't allow you to do that, which means that you don't have any meta classes in Ruby. Period. [Less]

OK. It's time to get rid of this terminology problem. Ruby does NOT have meta classes. You can define them yourself, but it's not the same thing as what is commonly called the meta class. That is more correctly called the eigen class. The singleton ... [More] class is also better than meta class, but eigen class is definitely the most correct term.So what is a meta class then? Well, it's a class that defines the behavior of other classes. You can define meta classes in Ruby if you want too by defining a subclass of Class. Those classes would be metaclasses.Edit: Of course, if you actually try to define a subclass of Class you will find that Ruby doesn't allow you to do that, which means that you don't have any meta classes in Ruby. Period. [Less]

OK. It's time to get rid of this terminology problem. Ruby does NOT have meta classes. You can define them yourself, but it's not the same thing as what is commonly called the meta class. That is more correctly called the eigen class. The singleton ... [More] class is also better than meta class, but eigen class is definitely the most correct term.So what is a meta class then? Well, it's a class that defines the behavior of other classes. You can define meta classes in Ruby if you want too by defining a subclass of Class. Those classes would be metaclasses.Edit: Of course, if you actually try to define a subclass of Class you will find that Ruby doesn't allow you to do that, which means that you don't have any meta classes in Ruby. Period. [Less]

This should probably have been part of one of my posts on closures or defining methods, but I'm just going to write this separately, because it's a very common mistake.So, say that I want to have a class, and I want to send a block when creating the ... [More] instance of this class, and then be able to invoke that block later, by calling a method. The idiomatic way of doing this would be to use the ampersand and save away the block in an instance variable. But maybe you don't want to do this for some reason. An alternative would be to create a new singleton method that yields to the block. A first implementation might look like this:class DoSomethingdef initialize def self.call yield endendendd = DoSomething.new doputs "hello world"endd.calld.callBut this code will not work. Why not? Because as I mentioned in my post about defining methods, "def" will never create a closure. Why is this important? Well, because the current block is actually part of the closure. The yield keyword will use the current frames block, and if the method is not defined as a closure, the block invoked by the yield keyword will actually be the block sent to the "call" method. Since we don't provide a block to "call", things will fail.To fix this is quite simple. Use define_method instead:class DoSomething def initialize (class << self; self; end).send :define_method, :call do yield end endendd = DoSomething.new do puts "hello world"endd.calld.callAs usual with define_method we need to open the singleton class, and use send. This will work, since the block sent to define_method is a real closure, that closes over the block sent to initialize. [Less]

This should probably have been part of one of my posts on closures or defining methods, but I'm just going to write this separately, because it's a very common mistake.So, say that I want to have a class, and I want to send a block when creating the ... [More] instance of this class, and then be able to invoke that block later, by calling a method. The idiomatic way of doing this would be to use the ampersand and save away the block in an instance variable. But maybe you don't want to do this for some reason. An alternative would be to create a new singleton method that yields to the block. A first implementation might look like this:class DoSomethingdef initialize def self.call yield endendendd = DoSomething.new doputs "hello world"endd.calld.callBut this code will not work. Why not? Because as I mentioned in my post about defining methods, "def" will never create a closure. Why is this important? Well, because the current block is actually part of the closure. The yield keyword will use the current frames block, and if the method is not defined as a closure, the block invoked by the yield keyword will actually be the block sent to the "call" method. Since we don't provide a block to "call", things will fail.To fix this is quite simple. Use define_method instead:class DoSomething def initialize (class << self; self; end).send :define_method, :call do yield end endendd = DoSomething.new do puts "hello world"endd.calld.callAs usual with define_method we need to open the singleton class, and use send. This will work, since the block sent to define_method is a real closure, that closes over the block sent to initialize. [Less]

This should probably have been part of one of my posts on closures or defining methods, but I'm just going to write this separately, because it's a very common mistake.So, say that I want to have a class, and I want to send a block when creating the ... [More] instance of this class, and then be able to invoke that block later, by calling a method. The idiomatic way of doing this would be to use the ampersand and save away the block in an instance variable. But maybe you don't want to do this for some reason. An alternative would be to create a new singleton method that yields to the block. A first implementation might look like this:class DoSomethingdef initialize def self.call yield endendendd = DoSomething.new doputs "hello world"endd.calld.callBut this code will not work. Why not? Because as I mentioned in my post about defining methods, "def" will never create a closure. Why is this important? Well, because the current block is actually part of the closure. The yield keyword will use the current frames block, and if the method is not defined as a closure, the block invoked by the yield keyword will actually be the block sent to the "call" method. Since we don't provide a block to "call", things will fail.To fix this is quite simple. Use define_method instead:class DoSomething def initialize (class << self; self; end).send :define_method, :call do yield end endendd = DoSomething.new do puts "hello world"endd.calld.callAs usual with define_method we need to open the singleton class, and use send. This will work, since the block sent to define_method is a real closure, that closes over the block sent to initialize. [Less]

In true boilerplate style:The JRuby community is pleased to announce the release of JRuby 1.1.2!Homepage: http://www.jruby.org/Download: http://dist.codehaus.org/jruby/JRuby 1.1.2 is the second point release of JRuby 1.1.  The fixes in this release ... [More] are primarily obvious compatibility problems and performance enhancements.  Our goal is to put out point releases more frequently forthe next several months (about 3-4 weeks a release).  We want a more rapid release cycle to better address issues brought up by users of JRuby.Highlights:- Startup time drastically reduced- YAML symbol parsing >100x faster- Performance, threading, and stack depth improvements for method calls- Fixed several nested backref problems- Fixed bad data race (JRUBY-2483)- Gazillions of bigdecimal issues fixed (all?)- 95 issues resolved since JRuby 1.1.1JRUBY-672        java.lang.Class representation of Ruby class not retrievableJRUBY-1051     Rubinius bignum_spec failuresJRUBY-1163     Doesn't allow 'included' to be protectedJRUBY-1190     Cannot call protected constructors from an abstract base classJRUBY-1332     It should be possible to add a jar to the load path and have it act like a regular directoryJRUBY-1338     Concurrent file uploads in Rails cause OOM errors with JRuby Goldspike GlassfishJRUBY-1386     instance_eval is a nightmarish can of worms; it needs to be completely refactoredJRUBY-1387     define_method methods are pushing two frames onto the stack, among other inefficienciesJRUBY-1390     Calling super without args does not (always) pass original argsJRUBY-1395     while loops and other protected constructs may require synthetic methods in the compilerJRUBY-1463     Java deserialization through java-integration is broken in JRubyJRUBY-1574     Extract into jruby.home from jar: urlJRUBY-1582     Allow heap and stack to be set via environment variablesJRUBY-1688     Problems with multiple arguments to Kernel#exec/system and Rake's FileUtils#shJRUBY-1725     Gem installs a bad shebang on application scripts (like rails)JRUBY-1749     JRuby fails test/externals/bfts/test_time.rb on Japanese environmentJRUBY-1753     while cases disabled with precompiled tests now runninng; known lackings in the compilerJRUBY-1767     JRuby needs a fast JSON libraryJRUBY-2041     Calling the attached method after 6 times returns nilJRUBY-2086     class cast exception randomly appearsJRUBY-2230     Compiler emits exception-handling sections of code that can be reached through non-exceptional paths.JRUBY-2247     Object#methods is incorrect in some casesJRUBY-2265     BigDecimal outputs to_s("F") differently than MRIJRUBY-2267     in `method_missing': no id given (ArgumentError) (RubyKernel class)JRUBY-2318     $~/Regexp.last_match lost when evaluation is inside a blockJRUBY-2347     Race condition in DRb: Socket not always closed in DRb.stop_serviceJRUBY-2348     FasterCSV's :auto option for row separator doesn't work in JRubyJRUBY-2370     JRuby startup time significantly slower than MRIJRUBY-2378     Hundreds of new rubyspec fiailures with BigDecimalJRUBY-2383     File.stat fails confusingly on large filesJRUBY-2392     Problem marshalling timeJRUBY-2418     protected method bug: plugin will_paginate shows symptomsJRUBY-2423     Avoid double copying data in ChannelDescriptor#read()JRUBY-2431     Rubygems under JRuby doesn't install BAT executable files on WindowsJRUBY-2432     Rubygems under JRuby detects the ruby executable name incorrectly on WindowsJRUBY-2434     Implement BigDecimal#sqrtJRUBY-2438     Support SQLite3 using JRubyJRUBY-2442     Each value of SCRIPT_LINES__ contains two redundant empty linesJRUBY-2444     NPE from o.j.r.scope.ManyVarsDynamicScope#getValueJRUBY-2445     Regression: jirb_swing broken, prints out to the stdin, not to the GUIJRUBY-2450     StringIO#gets should set $_ to nil when it runs out of linesJRUBY-2451     Cannot compile JRuby (regression of rev: 6565)JRUBY-2452     Predefined globals $_ and $~ handled incorrectlyJRUBY-2453     Etc.getpwnam crashes JVM on LinuxJRUBY-2458     Move jruby.properties to a proper packageJRUBY-2459     Upgrade rubygems to version 1.1.1JRUBY-2461     RubyGems are installing with incorrect shebang lineJRUBY-2474     --debug for interpreted mode, --jdb for jdbJRUBY-2476     Rubygems fails with NameError: StringIOJRUBY-2477     ClassCastException org.jruby.RubyString cannot be cast to org.jruby.RubySymbolJRUBY-2478        InlineCachingCallSite perf degradation due to JRUBY-2477 fixJRUBY-2479     YAML Parse Error for Array of Hash of HashJRUBY-2480     Ruby object passed to Java method impl passed back to Ruby method impl loses original ruby instanceJRUBY-2482     ClassCastException in RubyThreadGroup.addJRUBY-2483     PatternCache data race in RubyRegexp#initializeJRUBY-2485     Regression: Most BAT starter scripts are broken on WindowsJRUBY-2486     rails --version command still brokenJRUBY-2487     Bugs in REXML::DocumentJRUBY-2489     Regexp.last_match broken inside Enumerable's grep blockJRUBY-2490     Initializing structs including Java interfaces crashes JRubyJRUBY-2491     File.umask with no argument sets umask to 0JRUBY-2492     Add --debug option explanation in RubyInstanceConfigJRUBY-2493     Classpath changes for workspace in eclipseJRUBY-2494     REXML unusable from multiple threads: java.lang.ClassCastException: org.jruby.RubyStringJRUBY-2499     Parser bug with :doJRUBY-2502     Major regression in Array#packJRUBY-2503     variance from MRI: Module.new expects zero block paramsJRUBY-2509     URI::HTTP.build behave incompatibly with MRIJRUBY-2510     JRuby crashes with -XstartOnFirstThread on carbonJRUBY-2511     Dir.pwd with non-ascii chars does not display correctlyJRUBY-2512     YAML 10x slower loading Graticule dataJRUBY-2514     JIT max and JIT threshold should be adjusted for improvements in JRuby over the past monthsJRUBY-2523     Deprecated StringScanner#getbyte is infinitely recursiveJRUBY-2524     File.exists? "file:/" crashes jruby (I believe the actual cause is the file: prefix)JRUBY-2527     jruby -e chomp throws AbstractMethodErrorJRUBY-2530     Multiply-binding JRubyMethod's with arity (min:0, max:2) can't have block argsJRUBY-2531     IO#seek= with non-fixnum vaule breaks JRuby (and rubyspec run)JRUBY-2533     NPE when using a closed Iconv objectJRUBY-2536     Bignum#div should never return non-integer values, even if arg is FloatJRUBY-2537     Fixnum rubyspec failures for methods with Bignum argumentsJRUBY-2540     Two rubyspec failures for ComplexJRUBY-2547     JRuby 1.1.1 can't install native gems like Mongrel, Hpricot, etcJRUBY-2549     Calling java.lang.Intger#method raises ExceptionJRUBY-2551     JavaProxyClassFactory and JavaClass should use getDeclaredConstructors to get all public/protected constructorsJRUBY-2558     Rational#divmod follows MRI bug behaviorJRUBY-2563     java.lang.NoSuchMethodError: org.jruby.Ruby.newFixnum(I)Lorg/jruby/RubyFixnum; happens when trying to access rails applicationJRUBY-2568     Float divided by BigDecimal incorrectly coerced to FixnumJRUBY-2569     Specs to test method reflection and invocationJRUBY-2570     BigDecimal#to_f incorrectly handles negative zeroJRUBY-2571     some IO constants not definedJRUBY-2572     File::FNM_SYSCASE defined incorrectly on non-Windows systemsJRUBY-2573     Revision 6754 randomly dispatches the wrong method under multithreaded loads.JRUBY-2575     Regression on Windows: Can't execute jruby, with path constructed out of rbconfig's CONFIG entriesJRUBY-2579     Yaml ParserExceptionJRUBY-2580     Regression: yaml tests break JRuby hard [Less]