11 ms·
JRuby 9000 released
- Scarbutt 11y agoJRuby 9000 now uses native operations for much of IO and almost all of Process. This makes us the first POSIX-friendly JVM language. Did they achieved this via JNI?
- chrisseaton 11y agoThe system is called JNR - Java Native Runtime - http://www.oracle.com/technetwork/java/jvmls2013nutter-2013526.pdf http://www.oracle.com/technetwork/java/jvmls2013nutter-20135.... It uses libffi, which I guess the final call is made to via JNI.
- divideby0 11y agoCharlie Nutter gave a great talk covering this and a lot of additional new JVM features here: https://vimeo.com/114187541 https://vimeo.com/114187541 Edit: The JNR stuff is covered around 42 minutes in.
- mdavidn 11y agoThis will prevent running JRuby 9000 in (today's) Google App Engine. The project has been drifting away from App Engine support for some time now. See #2304. https://github.com/jruby/jruby/issues/2304 https://github.com/jruby/jruby/issues/2304
- dragonwriter 11y ago> This will prevent running JRuby 9000 in (today's) Google App Engine. 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.
- mdavidn 11y agoTrue, but many teams running Ruby in Managed VM will use opt to run YARV directly.
- chrisseaton 11y agoThere'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.
- jshen 11y agoHave you tried the pure-Java fallback on App Engine? I tried it for JRuby 1.7 and it didn't work. I haven't tried yet with 9000, have you?
- headius 11y agoWe 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.
- jshen 11y agoJruby 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 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.
- fokinsean 11y agoIt's at 9000!
- gary4gar 11y agois it faster than MRI?
- pesnk 11y agoCourse it is. JRuby has been faster then MRI for a long time. That does not mean I use it for production.
- rurounijones 11y agoTrue in the 1.8 1.9 era. Against 2.2 it is not an automatic "Is faster"
- headius 11y agoRuby performance has not improved substantially since 2.0, and we should almost always be faster for straight-line workloads. If we're not...tell me.
- Twirrim 11y ago> That does not mean I use it for production. Any particular reason why? (I'm just curious, I do absolutely nothing with ruby)
- aurochs 11y agoIt should be faster. 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=peak&test=query https://www.techempower.com/benchmarks/#section=data-r10&hw=... .
- headius 11y agoThey'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.
- joegyoung 11y agoIf 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.
- mrkrwtsn 11y agoHow 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.
- rugmug5 11y agoYou're using the standard jvm, why would they care?
- headius 11y agoWe 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.
- aurochs 11y agoJRuby is a great idea. 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.
- astrodust 11y agoDefine "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.
- amalag 11y agoI don't want to complain because it is a free product. But there is no doubt a big lag with activerecord. Rails 4.2 is still not supported: https://github.com/jruby/activerecord-jdbc-adapter/issues/599 https://github.com/jruby/activerecord-jdbc-adapter/issues/59...
- juliangregorian 11y agoCurrently, there's $1700 in store for whoever does support it: https://www.bountysource.com/issues/5831191-tasks-to-finish-4-2-support https://www.bountysource.com/issues/5831191-tasks-to-finish-...
- mataug 11y agoDamm, I so wish Jython improved like this too. I've been thinking of helping out.
- brightball 11y agojRuby 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.
- WaxProlix 11y agoLike what? They both benefit from the lack of GIL (Jython maybe moreso) as well as the portability and other benefits of JVM as a platform.
- chrisseaton 11y agoJython doesn't use advanced functionality like invokedynamic.
- jrochkind1 11y agoIt'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.
- headius 11y agoInvokedynamic'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.
- Freaky 11y agoConcurrent threads using magic regexp vars like $1 stomp all over each other, quite nasty: https://github.com/jruby/jruby/issues/3031 https://github.com/jruby/jruby/issues/3031 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 :/
- cheald 11y agoOne 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.
- Confusion 11y agoYour 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.
- Freaky 11y agoThe 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.
- eropple 11y ago"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.
- rf3000 11y agoFantastic news! Very excited about seeing the Ruby ecosystem advance.
- lgleason 11y agoBig thanks to the Jruby team!
- flowerpot 11y agoI'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.
- kul_ 11y agoSo 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!
- VeejayRampay 11y agoFor 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).
- pjcabrera 11y agoNothing to do with Java? Really? How did you come to that conclusion?
- vorg 11y agoClojure 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.
- magicdream 11y agoWe'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.