JRuby 9000 released
blog.jruby.org
blog.jruby.org
It has one pitfall which consistently stops me from using it though : poor support with newer releases of Rails, usually due to the Active Record stack not working well with the AR JDBC adapter.
I know some work was being done on a JRuby version of the standard pg gem (without the need for JDBC) which would be fantastic if it was completed and working.
Anyone married to the MRI ecosystem because of dependencies on modules with no JVM equivalent may have problems, but new projects usually have no such issues.
When I last experimented with creating a standard Rails 4.2 app with the AR JDBC adapter and a database model a few weeks ago, it still didn't work. I haven't looked at things since then.
The workaround some people will suggest is "replace ActiveRecord with Sequel" but for existing projects a migration to a less standard Rails stack may not be viable.
I agree the JRuby team is doing a great job - however Rails is a big use case for any Ruby implementation, so my comment was not intended as a criticism, more in the line of a bug report and something it would be nice to have working now the new JRuby release is out the door.
Disclaimer: I now work on JRuby full time. But prior to this I ran Mogotest and switched to Sequel successfully on that project.
Stumbling over a serious race condition in the first 5 minutes of trying it with real code makes me a bit wary. All the performance in the world isn't much good if it's randomly wrong :/
The other major thing I like about JRuby is that it's much easier to hack on than MRI - the Java code is extremely clean and easy to understand, and it's easy to use tools like IntelliJ's debugger to diagnose issues quickly and easily. I've contributed dozens of commits to JRuby specifically because the barrier to entry is just a lot lower than it is in MRI.
The community is really, really good, and the project is extremely hackable - it's an embodiment of the best in open source, IMO, and I'm really excited for this release in the hopes that it gets more people using 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.
I can see wanting it fixed, but it's a pretty odd hill to die on.
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 :)
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.
If avoiding `$1` has been often recommended for a while... I think it's a recommendation more often ignored than followed.
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
def f
p $~ # => nil
"123" =~ /\w+/
p $~ # => #<MatchData "123">
end
p $~ # => nil
"abc" =~ /\w+/
p $~ # => #<MatchData "abc">
f
p $~ # => #<MatchData "abc">I will echo what others have said, though...closures capture and share a lot of other state. $~ and the related vars like $1 are supposed to be "special" but there's other state you're going to stomp on all Ruby impls. It's better to avoid using closure state if you know it's going to be called across threads, because most of that state will be shared on all Rubies.
I'll admit to encountering weird "er, why is that randomly nil" errors quite regularly with JRuby when load testing webservers, which, er, I've never reported. It's never been obvious where the fault was, really. And it always seemed unlikely to be your fault, tsk ;)
> It's better to avoid using closure state if you know it's going to be called across threads
Yeah. In this case it was a hash of name -> lambda pairs which boiled down to variations on:
->(obj) do
case obj.bla
when /foo(.*)/ then "FOO_#{$1.upcase}"
when /bla(.*)/ then $1
end
end
Called in lots of tight loops from a pool of worker threads. I refactored it into something neater, but it still should have worked fine :)Do I understand things right, or am I wrong here?
I guess the question is where the regexp special vars are scoped to though, I see how that's not entirely clear.
Did they achieved this via JNI?
Edit: The JNR stuff is covered around 42 minutes in.
The project has been drifting away from App Engine support for some time now. See #2304.
It'll prevent running it on the current Google App Engine Java Runtime.
It won't, AFAICT, prevent running it in a Google App Engine Managed VM, which is an option on today's Google App Engine.
Edit: I just want to stress, the JRuby team is amazing, and I've always been impressed with the responsiveness and openness of the team. This comment isn't meant as a critique in anyway, just a statement of fact with my experience trying to run JRuby on app engine.
I'm very happy to see JRuby 9000 and hope we'll upgrade soon.
I think the big JRuby advantage is actually that by and large code written for MRI Just Works on JRuby. The exceptions are relatively few, and usually easily worked around, or if not quickly bug fixed. Despite this thread, I haven't had significant troubles with ActiveRecord-ODBC, although in Rails 4.2 have occasionally run into relatively minor worked-around-able issues.
My impression is that code written for standard Python tends to have a lot more trouble running on Jython -- not from any fault of Jython, but because 'standard' Python code tends to be more likely to use native C than typical ruby.
Is there some kind of vision or plan for how Graal/Truffle fits into the JRuby roadmap?
We are working towards being fully compliant and we're getting there fast - I think with four full-time people and more in support we are now the largest employer of Ruby implementors anywhere. But since we aren't ready yet, stopping work on IR isn't an option even if we wanted to do so and we all need Charlie and Tom to continue their excellent work on the IR.
In my personal view, Truffle will be good enough to replace JRuby runtime at some point in the next couple of years, but we aren't advocating for this now and if it did happen it would be because the JRuby community and leadership make that decision for themselves.
I think we might come up with some kind of roadmap, or at least stated plan, at JRubyConf next week.
Also, the strong anti-Java culture in the Ruby community probably didn't help (even though JRuby has nothing to do with Java, or very little).
Any particular reason why? (I'm just curious, I do absolutely nothing with ruby)
I haven't seen any newish real world benchmarks to that effect though.
These web benchmarks give some conflicting results between MRI and JRuby : https://www.techempower.com/benchmarks/#section=data-r10&hw=... .
I know this is small consolation, but everything in the JRuby ecosystem is continuing to improve every day. When there's specific reproducible cases where we're slower, we take them very seriously.
On the flip side, JRuby starts much more slowly than MRI. This is a general Java problem: startup times are problematic. Also, code reloading performance may be worse than MRI, so things may be slow in development. JRuby is optimized for production-level long-running workloads. So something like 'rake' will likely take longer with JRuby.
Maybe not for everyone but as long as you know what you are doing it is viable I think.
We continue to try to improve startup performance, and hopefully over the next year we can close the gap a bit more.
I don't know what the edit-reload-check workflow could be with JRuby and how well it can integrate with editors (few Rubyist use IDEs, http://www.sitepoint.com/ides-rubyists-use/).
Anyway, I'm doing a bundle install with jruby on a Rails project right now. Let's see if it completes and passes the tests.
One is that startup is really slow.
rails c takes 25 second to give a prompt vs 10 on with Ruby 2.2.2 and almost 0 after spring has started. It's not something that a developer likes to work with.
Second one: still immature. The PostgreSQL adapter warns
NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us finish 4.2 support - check http://bit.ly/jruby-42 for starters
Not something I want in production.
Third one, now I'm stuck with the JDBC adapter not connecting to my developement PostgreSQL over a unix domain socket. Maybe it can't (perhaps JDBC does only TCP/IP) and I have to reconfigure PostgreSQL to accept connection to 127.0.0.1:5432. That means any other application I'm working with won't work anymore and I should reconfigure them.
Summing up all together I'm not particularly eager to keep testing JRuby. Maybe somebody will solve those problems. I'll give another try to it next July.
The startup time is annoying, though, especially in the context of TDD. I do know it's an area of active research, though. You should try launching with JRUBY_OPTS="--dev" and see if that helps, though.
My other problems are with JDBC but if database drivers don't support Ruby's largest use case (Rails with ActiveRecord) probably JRuby will be negatively impacted. This is about the "ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC". The other one (unix domain socket) is a minor issue but any small nuisance loses developers along the way.
Yeah, certainly understood WRT JDBC. But, as nirvdrum pointed out elsewhere in the thread, you might look at Sequel rather than AR if you do want to do JRuby stuff and AR-JDBC is holding you back - it's well-supported and I know lots of folks use it well.
The domain sockets thing is unfortunate, but AFAIK, they just aren't supported by JDBC.
I won't convert this app to Sequel only to check that it works with JRuby. Neither I'll write the next one with Sequel. If JRuby doesn't handle AR it's over for me. It's JRuby that must be compatible with MRI (the reference implementation of the language), not the other way around. That until the majority of rubyists use JRuby as default. It's too risky.
In a hello world, you might come out ahead in 1.7.x. Maybe 9000 is better?