The same bug still exists in JRuby 9000, and was in fact the first thing I ran into when trying it.

Considering threading is the main selling point, one of the commonest patterns of regexp use being completely and dangerously broken with them would have seemed like something of a showstopper.

"Commonest" is a big claim. I'm not a JRuby user, but I sling a whole bunch of Ruby and I've never, not once, used the global regexp stuff--indeed, I didn't know it existed before just now.

I can see wanting it fixed, but it's a pretty odd hill to die on.

I've been writing Ruby for 7 years now, and I've known about the regex svars for about as long. Never used them once. They're obviously bad style.

> one of the commonest patterns of regexp use

Is it really? Even fairly early in the Ruby 1.8.x era, most recommendations I saw were that the magic regexp globals (and many other magic globals) were a perlism that should generally be avoided.

Huh, I use `$1` all the time, and see it all the time. Probably because the alternative with an explicit match object ends up being relatively a lot more code and a lot harder to read, really.

If avoiding `$1` has been often recommended for a while... I think it's a recommendation more often ignored than followed.

I've never seen $1 used in production code.

Try grepping your lib directory sometime. In fact, let me do it for you, on a relatively clean install:

time, benchmark, irb, pry, rubygems, resolv, erb, rake, open-uri, debug, rack, cgi/util, optparse, getoptlong, bundler, activesupport, actionpack, activemodel, erubis, slim, haml, sass, sequel, roda, nokogiri, rugged, faraday, mime-types, thor, test-unit, tzinfo, mail, ffi

Ouch. That's pretty awful.

I don't think it's that common a pattern. All those perlisms make code unreadable anyway. I much prefer things like match with named captures, which generally make everything more obvious.

Ah, I didn't get that from your original post. So JRuby 9000 shipped with a known concurrency bug that, from the face of it, seems likely to be a problem in actual use. I agree that seems a bit worrying.

You have to ship some time. Noisy bugs get fixed...and patches are always accepted :-)

Of course is can be completely reasonable to ship with a known bug, which is why my initial reaction to the OP was: why are you bringing this up here?

However, not all bugs are made equal and this one seems relatively likely to actually cause problems for users. Wouldn't someone running some service and handling say 10 requests/second, while using the regex global variables, run into this bug on a daily basis?

So I guess I'm just interested in how such a decision is made: what bugs get shipped and which block a release?

If this bug would reasonably cause problems in such a situation and if the policy of JRuby is to ship anyway, that seems to be a relevant piece of information to consider for someone using JRuby in production and considering whether to upgrade.

Perhaps one should always check the list of open bugs for the version of a compiler/interpreter one intends to start using, but I've never done so, haven't been bitten by a bug yet (AFAIK) and yet this one seems one that could be a problem. The main problem is of course that this may just be 'the curse of knowledge' in play.

So I guess I was being a bit dismissive towards OP, then I was sympathetic and now I'm mostly thinking about how I should handle this as someone using JRuby in production. Perhaps I should just ignore it. Perhaps I should investigate the set of concurrency tests and contribute a few. Perhaps I should be conservative and only use 'proven' JRuby versions. Perhaps I should learn to stop worrying and love the bomb :)

Of perhaps you should simply shy away from global perlisms in a Ruby app, which are really bad practice anyway.

What VM doesn't ship with bugs likely to be a problem in actual use, though?