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.
This is really an unfortunte side effect of every Rails AR adapter being a one-off piece of code. In JRuby, there's not much code different between the databases, but in Rails they're all completely different. That means we basically have to emulate N different codebases just to be compatible. If they settled on a common database layer, our job would be done. Write your congressman.
If you're open to alternatives, I highly recommend using Sequel. It integrates fairly well with Rails, optimizes extremely well on JRuby, has a consistent update schedule, and has a real API for developing plugins against. I realize it's not part of the standard Rails stack, but it actually makes upgrading Rails easier because you're not constantly chasing a non-standard API that changes release to release (even on MRI, ActiveRecord "plugins" break with almost every release).
Disclaimer: I now work on JRuby full time. But prior to this I ran Mogotest and switched to Sequel successfully on that project.
In general everything ActiveRecord does should be supported by JDBC. The pg port is for cases where you need features the JDBC driver does not support but the C driver does, like geocoding etc.
Define "newer" and define "poor"? The JRuby team has done a fantastic job of keeping things working. Do you have any specific problems other than vague grumblings?
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.
Yeah; but at the same time when you're building and scaling an app you run into all sorts of issues like this. JRuby is almost a platform of its own: you get the scalability and benefits of the JVM with the flexibility of Ruby. IMO it's a decision you make pretty early in the product lifecycle. If you're already on Rails, there are other solutions that give you many of the same benefits with an easier migration path (i.e. app containers like Docker).
Yep, I've put up money for it myself, and regularly be on twitter for other folks to do the same. I wish a big company that uses jRuby would step up and support the tools they use :/
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 :/
One of the things I've most appreciated about the JRuby community is that bugs get fixed in a hurry. My first experience with JRuby was trying it, something not working, jumping into IRC to ask about it, and headius had it diagnosed and patched 10 minutes later. From then on I was hooked.
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.
This is not a hard one to fix but it didn't make the final release and had never been reported before, despite being largely the same for 9 years. It will be fixed as soon as we can get to it.
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.
> had never been reported before, despite being largely the same for 9 years
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 :)
It would be worth proposing to ruby-core that captured closures are thread-local, but that would break a lot of code that actually depends on the sharing. Programming is hard :-(
Huh, if the local various was only scoped to the closure block, and not above it, I would never expect it to be shared. I would think "avoid using closure state" means exactly that, use only local variables scoped no higher than the closure block itself. (It's true this can sometimes be difficult to ensure in ruby; block local variables can help).
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.
You're largely right. The problem is that $~ (and related vars) and $_ are scoped to the nearest method body. If they were scoped to the closure itself, there'd be no problem.
You really shouldn't be relying on globals anyway. Using $1 etc. is a serious code smell. It shouldn't by definition be threadsafe in any event. The only way that would work would be if you rely on the threads not actually running at the same time as an implementation detail of the MRI.
def f
p $~ # => nil
"123" =~ /\w+/
p $~ # => #<MatchData "123">
end
p $~ # => nil
"abc" =~ /\w+/
p $~ # => #<MatchData "abc">
f
p $~ # => #<MatchData "abc">
Matz himself has said he regrets putting these variables in the language, and some day they may disappear. We'll match behavior as much as possible, but they're a relic no matter how you slice it.
Well, it's fair to say "it works in MRI"; $1 being frame-local and thread-local is an exception to the rule, but it is How It Works. JRuby should behave similarly, full stop.
They're what MRI calls "svars", or special variables. They're thread and scope-local, and regardless of your feelings towards them, they're still used all over the place, in old and new code alike.
Your comment has little to do with JRuby 9000, as the bug reported there was observed in JRuby 1.7.20. Yes, JRuby has bugs, like MRI, like any interpreter or compiler.
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.
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 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.
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 :)
There's a pure-Java fallback that has most of the same functionality. But if you wanted precise POSIX function calls you probably weren't running on App Engine anyway.
We welcome GAE users of JRuby but they never seemed to be a big segment of the community. And we continue to maintain non-native IO and process logic for limited environments. If that is not sufficient for GAE, we'll work with you to make it so.
Jruby 1.7 simply doesn't work in GAE, and maybe it's not worth making it work there, which I would understand. I opened an issue a while ago (https://github.com/jruby/jruby/issues/2304) and I spent about a week trying to fix it. Each time I fixed one issue another one popped up and I gave up after hacking up JRuby beyond my comfort level.
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.
We're using JRuby in some core projects and it's great.
From my experience (moved 2 high load projects to Jruby) transition to JRuby from Ruby is not just changing Ruby version. But often you spend around 1-2 weeks to move medium size project on it, change some gems and configure Java options to not have out of memory errors.
So it works fine, I'd not say that it works much faster than latest Ruby. But I think that main reasons why you should switch are multithreading and Java libs. We switched because of we was need to use latest Java libs for Kafka.
But the main disadvantage is that sometimes when you need to deal with Java objects you need to think about object data type casting (from Ruby object to Java and vice versa). And this is
extra actions, extra memory usage.
I'm very happy to see JRuby 9000 and hope we'll upgrade soon.
I've actually found JRuby to be very handy when it comes to packaging. Using warbler I can generate a jar file and then using the javapackager I can create self contained packages for all the major platforms/package managers: windows (.exe/.msi), linux (.rpm, .deb), osx (.dmg). Way more painless than packaging a ruby runtime. I've tried traveling ruby, but have not had the same seamless experience. Especially when it comes to multiple platforms. However, packaging with java, jruby and my application usually turn out to be quite large. Around 80Mb for a CLI and the startup time for short running programs like CLIs using JRuby can be quite long.
jRuby is one of the biggest reasons I lean to Ruby over Python. Ruby gains a lot more from the JVM than Python (at least that's my understanding) does and that leads to much more momentum behind jRuby.
It's unclear how much benefit invokedynamic actually provides at present, I recall seeing benchmarks not showing much.
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.
Invokedynamic's benefits have been a bit of a mixed bag, but id does make the JVM see through dynamic call sites and optimize them like it does statically-typed call sites. That generally improves performance for JRuby, but there are cases where simply inlining the code together doesn't lead to a measurable increase.
Given that both you and Chris are posting to this thread, I was kind of surprised to learn that you're planning to focus on a non-Truffle compiler/optimisation engine in future. Isn't Truffle meant to give huge speedups? It sounds like you might eventually get JRuby 9000 to be faster than MRI but that a rewrite of the current code didn't do it yet.
Is there some kind of vision or plan for how Graal/Truffle fits into the JRuby roadmap?
Truffle is a research project. It is not a short-term goal to replace the current IR-based runtime in JRuby, and Truffle isn't really part of the 9k release (it's there but I wouldn't recommend trying to use it).
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.
So why does JRuby never got as much traction as other jvm langs like clojure, scala, groovy? I have heard good things about the ruby syntax, top that you get unparalleled powers of jvm like gc, cross platform, libs and much more!
For the same reason that alternative implementations of Python never got the kind of traction they deserve, because 90% of the gems, libraries and everything are specifically tailored to MRI and it's always harder to play catch up.
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).
Clojure and Scala are pretty good ideas, being modified versions of two leading programming paradigms, i.e. Lisp and Haskell respectively. Groovy is the most JRuby-like of those choices, and probably has far more traction than JRuby because it uses Java syntax and is more heavily promoted.
That depends on what you mean by faster. For CPU-bound work, JRuby is almost always faster. The JVM is very good at optimizing. However, the best performance doesn't kick in until the JVM is sufficiently warmed up, which means JRuby shines mostly for long-running tasks. Warming up can take a few minutes, although some people tell me that I should warm up for half an hour (!).
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.
We've added a --dev flag to JRuby that attempts to turn on fast-starting flags in JRuby and the JVM to reduce startup time. It can be as much as twice as fast.
We continue to try to improve startup performance, and hopefully over the next year we can close the gap a bit more.
In practice I've found the start-up times aren't all that different. The drag is more pronounced on older hardware, though. A current i5 or i7 system with an SSD is usually roughly the same.
That is very contrary to my experience. A Rake task in a Rails project almost always takes somewhere like 15-20 seconds just to start up (on MRI it's around 2-5). Just today, I tried to run the Middleman static site generator. Where on MRI, Middleman starts building after around 3 seconds, on JRuby it starts building after around 10 seconds. And I'm on a 2012 Macbook Air.
The real advantage comes from the fact that JRuby isn't enslaved to a GIL like MRI, so you get JVM threads out of the box. Even with the JIT, JRuby (at least 1.7) isn't appreciably faster than MRI when running a single-threaded app: http://www.isrubyfastyet.com/
JRuby used to be much faster than MRI (definitely so when MRI 1.8 was current), but MRI has gotten better faster than JRuby, and IIRC, its now mostly a mixed bag based on workload, particular application design choices, etc.
That's generally not true. MRI's straight-line performance has not improved as fast as JRuby's, and if we're ever slower than MRI it's generally something we're doing wrong. When we're doing things right, performance can be anywhere from two to ten times faster than MRI.
It is a stated goal of the JRuby project to meet or exceed MRI performance. The team will actually accept issues/bugs if you can provide a (well structured and isolated) benchmark illustrating a performance deficiency relative to MRI.
What I read is that it's faster for long running applications (example: web apps) because the JIT can optimize the code. It should be slower for anything else, example: tests (very unfortunately).
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.
I've been doing some progresses but there are a few (almost) show stoppers.
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.
It sounds like most of your issues are with JDBC/AR-JDBC rather than JRuby itself though, no?
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.
JRUBY_OPTS="--dev" lowered the startup time to 12 second, basically on par with MRI. Thanks! I googled you suggestion and I found https://github.com/jruby/jruby/wiki/Improving-startup-time I'll try a few suggestions that look like doing with spring does (Theine and Drip).
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.
FWIW, I've never had any luck with Theine or Drip. But --dev is good stuff - it basically turns off the JIT and invokedynamic, which are great for long-running processes but not that useful for shorter script runs or consoles. JRuby defaults to "good for long-running processes" mode, which is great for production but less useful when running short-lived tasks.
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 realized that PostgreSQL can listen to both the Unix domain socket and a TCP address so I've been able to run the tests. I'm stuck now with the integration tests failing because they can't run the Selenium Chrome webdriver. I opened an issue. I also have some failed tests on a model, still didn't looked at them.
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.
At least with the previous JRuby, for us the answer is "usually no." If you do any large string ops (hello JSON), or parsing, or use any ruby gems which use exception handling for flow control (which is cheap in MRI, but like 9ms per exception in JRuby) in a loop then you will be slower. Also, SSL connection negotiation is exceedingly slow in JRuby 1.7x (like 100ms) and this made our microservices tough. Using HTTP Client with keepalives helped with this.
In a hello world, you might come out ahead in 1.7.x. Maybe 9000 is better?
I wrote Manticore (https://github.com/cheald/manticore) because of my dissatisfaction with Ruby HTTP clients under JRuby; it uses the Apache HTTPComponents (completely sidestepping Ruby's stdlib http/networking stuff) and is extremely fast. It might be worth looking into for you.
Do you have anything you can point at regarding String performance? Everything I've seen shows JRuby being faster than MRI. But I'm looking to see if we can make it even faster than it currently is. Any pathological cases would be incredibly helpful.
I can send you an example. Can I drop you an email? I think also that we are friends on linkedin, coincidentally. I can message you there (if that is a useful way to get in touch?).
They're a mixed bag because they're benchmarking libraries more than they're benchmarking runtimes. Often the JRuby-specific versions of libraries (e.g. activerecord-jdbc) do not get the same performance attention as the ones for MRI, and as a result they perform worse.
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.
You don't have to spawn a separate instance for each CPU core. Granted there are web servers that take care of some of that by having multiple workers.
What do you mean? JRuby can make system calls as fast as MRI, generally. We don't support their C extension API, but we support and maintain an FFI library to programmatically call C from Ruby.
Because the C extension API isn't supported. Or to put it another way, you can call C libraries from JRuby, but you can't write C that calls JRuby. If you want to do that, you would replace it with a Java extension, instead. It's possible to offer "native extensions" for both MRI and JRuby from a gem by providing both via C and Java extensions, though.
If I committed to using jRuby instead of regular ruby, I would have that nagging fear that Oracle would go after all the other companies that build their product using Java APIs.
We work closely with engineers at Oracle and JRuby is one of the premier projects on the JVM. There's also no legal way they could come after us; their suit against Google is about copying Java APIs, a very narrow domain.
How would that help them? It doesn't seem like they have any incentive to prevent more people from using the JVM. In fact, I would imagine they want more people to use it, and multiple languages compiling to it makes it more popular.
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.