I'm interested in promoting JRuby in our office as the platform hosting Rails applications.
But how reliable is it?
Is its performance better than MRI 1.8.7?
JRuby 1.5 states that it is 100% compatible with Ruby 1.8.7, does this mean that JRuby can run any Ruby/Rails code?
Yes, JRuby is reliable! Oracle uses JRuby for Oracle mix (http://mix.oracle.com/), Sun had used it for Kenai (http://kenai.com), and it's gonna be the next base for java.net (from kenai site: "Work is on-going for migrating the Java.net domain over to the Kenai infrastructure")!!
You can run almost every code, some gems uses native C extension and in JRuby there's a primitive support to it, but yes...rails just works.
You can deploy Rails apps in Application Servers like Tomcat or JBoss with Warbler that wraps Rails apps inside a .war file, it's pretty awesome!
update: you can see a lot of benchmarks here: http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/
I am doing a lot of jruby work right now and can tell you that rails is certainly a viable option under the jruby interpreter. I've been pretty pleased and in my case have to use many native Java libraries, so jRuby is just such an awesome wrapper around that java code. I will say that I have had some technical challenges some that are worked out, some that are not yet.
unit testing: spooling up the jvm and then spooling up rails takes much longer, so your tests take longer to run - solution, potentially something like nailgun that keeps the jvm running
deployment: i have not gotten warbler to work for me, with my flavor of tomcat. this is a major issue for us.
pick your libraries, while some c extensions work, they are not all equally compatible.
if you are interested I would highly reccomend the jruby book, in beta, from Pragmantic Programmers at http://pragprog.com
JRuby rocks!! The simple reason being its portability features and integration with Java libraries. I personally use it with Netbeans and the fast debugger that comes with that seems very handly. Plus you do not want to see that native build errors and handling them. All these gems that you download for JRuby work 100% across any platform. With JRuby, you are simply bringing in the advantages of the Java's Platform independence.
Moreover, JRuby uses native threading which uses OS threads instead of Green threads as in CRuby (i think its not the case with the latest versions though)
In Gist, go JRuby!!
for windows I have found it to be much more stable than MRI when working with larger amounts of data. There are some bugs on windows still but they are actually work-around-able. Recommend.
Disclaimer: I don't use jruby in my day job - I merely experimented with running existing code using jruby.
It doesn't mean that it'll run all code successfully. For example, bioruby currently calls fork on jruby even though jruby doesn't really support it. (That's more of a bug in bioruby than a bug in jruby though)
I wouldn't call such behaviour "unreliable" though. It's fail-safe, like a plane that would not get off the ground, much less crash.
Related
Current status of truffleruby says:
TruffleRuby is progressing fast but is currently probably not ready for you to try running your full Ruby application on. Support for critical C extensions such as OpenSSL and Nokogiri is missing.
Why does truffleruby need C extensions? It's built on GraalVM which is built on top of the JVM, it is in fact a fork of JRuby:
TruffleRuby is a fork of JRuby, combining it with code from the Rubinius project, and also containing code from the standard implementation of Ruby, MRI.
Can't they use JRuby world gems instead of depending on their C variants?
EDIT link to the issue on github
Running C extensions is hard because the C extension API is just the entire internals of MRI exposed as a header file. You aren't programming against a clean API - you're programming against all the implementation details and internal design decisions of MRI.
JRuby's Java extensions have exactly the same problem! The JRuby Java extension API is just the entire internals of JRuby, and you aren't programming against an API, instead you're programming against all the implementations details and design decisions of JRuby.
We plan to eventually tackle both problems in the same way - which is to add another level of abstraction over the C or Java code using an interpreter which we can intercept and redirect when required, so that it believes it is running against MRI or JRuby internals, but really we redirect these to our internals.
We think C extensions are more important, so we're tackling those first. We haven't really started on Java extensions yet, but we have started the underlying interpreter for Java that we'll use.
This video explains all
https://youtu.be/YLtjkP9bD_U?t=1562
You have already gotten a good answer by the project lead himself, but I want to offer a different point of view:
Why does truffleruby need C extensions?
It doesn't need them. But they do exist and there is code out there which uses them, and it would sure be nice to be able to run that code.
What I mean by this is if I install jRuby on Rails, can I use only the ruby language to build my application? I wanted to install my rails application with jRuby in case I wanted to use Java in the future, though I don't need it now. Or do I not understand? Is jRuby ruby that has access to java libraries?
yes, jruby is ruby (your ruby scripts need no modification to run under jruby). in addition, it has full access to java libraries - check out the wiki for how easy it is to integrate a java class or library into your ruby code.
The others have answered your direct question. I just want to say that I've been using jruby full time at work for the past 6 months and it's great. Deploying a rails app with the glassfish gem is very easy and jruby performs better than MRI ruby 1.8.x.
I've seen no real downside after 6 months other than the fact that we can't use gems that have pieces written in C. However, we've taken a C library and created a gem using FFI and it wasn't too much trouble.
It's also really easy to speed up your app by writing a few key pieces in java (which is easier t work with than C).
Background: I'm writing a 'standard' (nothing special) web application in Ruby (not Rails) and I need to start thinking about deployment.
So I've been hearing a lot of recommendations to use JRuby to deploy Ruby web applications, regardless of whether you actually need Java libraries or not. How true is this? Is it worth using the Java implementation just for speed? Would I gain anything else by doing so? Would I run into any issues?
PS: I don't know Java that well, so "you can write parts of it in Java" isn't very helpful.
JRuby is one of the most complete ruby implementations (there are a lot other ones out there such as IronRuby, Maglev, Rubinius, XRuby, YARV, MacRuby). It is very comprehensive, therefore, unless you use gems that use native C code, you will very very likely be just fine compatibility-wise.
JRuby is a bit faster than the actual C implementation, but it supports actual threads, whereas the official implementation is struggling a bit into getting it (it still uses Green Threads). Using Java threads from JRuby is quite trivial, even though it will require you to couple your code with Java (with a little DI, this coupling will only happen once, though).
Another benefit: runtime tools. Java, as a platform, instead of a language, has a lot of runtime tools to help you diagnose problems and check the state of the application (profilers, JConsole, and so on).
Twitter engineers also mentioned that the Ruby VM kinda has trouble being an environment for long lived processes, while the JVM is very good at that, because it’s been optimized for that over the last ten years.
Ruby also had a little security issue recently, which did not affect JRuby's implementation.
On the other hand, your project requires more artifacts (JVM, JRuby jars, etc). If you are using an application that will stay alive for long, and you want better runtime support, JRuby can be a great way to go. Otherwise, you can safely wait until you need these things to actually make the move (it is likely to go smoothly).
I use and love JRuby on daily basis, but I suggest you use MRI (a.k.a. C-Ruby) unless you have a actual need for JRuby.
Reasons for using JRuby:
Java integration
Restricted environment (your machine has Java installed by not ruby and you don't have root)
Restricted environment (you have ruby installed but don't have root so can't install gems you need)
You reached the limits of Ruby 1.8 performance and cannot use 1.9
From what you've described, you don't have any of the above reasons.
C-Ruby 1.9 has significant performance improvements over C-Ruby 1.8. I've yet to read (or find out for myself) how C-Ruby 1.9 compares with JRuby 1.8 or JRuby 1.9. In anycase, you don't have a performance problem (yet) so don't worry about it.
The good news is, you can start with either and convert later if needs be. It's all Ruby, and the Webrick and Mongrel gems work with both.
As mentioned above, ruby gems that have C extensions cannot be installed under JRuby. Hopefully this will change in the future if ruby C extensions utilize FFI.
http://kenai.com/projects/ruby-ffi/pages/Home
http://isitjruby.com/
What are the advantages/disadvantages of the major Ruby VMs (things like features, compatibility, performance, and quirks?) I know there are also some bonus features like being able to use Java interfaces through JRuby, too. Those would also be helpful to note. Does any VM have a clear advantage at this point, and in what contexts?
I've used both Matz's Ruby and JRuby, and they solve different tasks. If you are developing a straight Ruby or Rails app, then that will probably suffice, but if there are some powerful Java libraries that would help a lot, then JRuby might be worthwhile.
I haven't done anything overly complicated, but JRuby seemed to match up pretty well, at least as far as implementing the core language features (I haven't run into any differences yet, but they may exist).
One little anecdote I wish to share... I was writing a script to interact with a DB2 database. The DB2 support in Ruby is abysmal... you have to install the whole DB2 express version just to be able to compile the Ruby drivers, which didn't even work for me. I got fed up and switched to JRuby, using JDBC and a few small DB2 JDBC jars. It resolved my problem perfectly. The point? Well, if gaining access to some Java libraries will simplify the problem at hand, by all means go for it!
I hope this was helpful! Sorry I don't have any experience with other VMs....
One more caveat I have read about, but I don't know the details too well... JRuby I think supports threading via Java threads, instead of the "green" threads supported in Matz's implementation... so if you want multithreading on multicore systems, JRuby will probably serve you better... unless you want to do the threading in C.
Here's a bit of info I scrounged up on the main VMs: Ruby MRI, Ruby 1.9 (YARV), JRuby, XRuby, Rubinius, and IronRuby
There was a performance benchmark last year that compared the major VMs, but with how quickly VM development has been it probably is not as relevant today. Ruby 1.9 was generally the fastest, and still has the edge over JRuby for now, I believe.
Four VMs are currently capable of running Ruby on Rails: Ruby MRI, Ruby 1.9, JRuby, and Rubinius.
XRuby runs on the JVM, as does JRuby, and compiles the Ruby source files to a Java .class.
IronRuby runs on .NET, making use of their DLR, and allows you to integrate Ruby with the .NET libraries and infrastructure. It cannot yet run Ruby on Rails.
There is also a VM called HotRuby that lets you run Ruby source code in the browser or in Flash.
There are multiple Ruby implementations in the works right now. Which are you looking forward to and why? Do you actively use a non-MRI implementation in production?
Some of the options include:
Ruby MRI (original 1.8 branch)
YARV (official 1.9)
JRuby
Rubinius
IronRuby - Ironruby.net
MagLev (Thanks Julian) Github link
MacRuby (Thanks Damien Pollet)
Maglev. It will have the speed benefit of all the optimization that has gone into a major Smalltalk VM over many, many year. Plus it will automatically persist all your data pretty much automatically so there is no more need to monkey around with Object-Relational mapping layers and so on.
Ruby 1.9 (YARV) gives us a good idea as to where ruby is headed, but I wouldn't recommend using it for production use. While it's certainly much faster than 1.8, even some parts of the syntax keep changing, so I don't think you could call it stable. It does have some interesting new features and syntax which will surely find their way into all the other implementations over time.
JRuby and IronRuby are useful in that they give ruby access to a whole range of new libraries and environments where ruby couldn't be used otherwise. I've not found much use for them myself yet, but think it's great that they exist. They may allow ruby to infiltrate corporate environments where it wouldn't otherwise be permitted. That can only be a good thing.
Rubinius and Maglev are probably the most interesting projects, but also those where their benefit to the community is likely to be furthest into the future. Rubinius may well develop into a cutting edge 'pure' VM for the ruby language, allowing ruby code to run much faster than it can now. Maglev too seems extremely promising, backed as it is by 20+ years of VM experience. It will also provide features over and beyond a standard VM, but of course these will come at the cost of code portability.
Overall though, what I'm most excited about is the competition between these implementations. Having competing projects all working to make ruby better can only make the ruby ecosystem stronger. From what I've seen too, while the competition exists it is friendly; each project giving and taking ideas from each other. The work done by the JRuby and Rubinius teams in creating a ruby spec is probably the most important outcome so far, as it will help ensure that all implementations remain compatible.
jRuby is stable and reliable today. Maglev is very promising.
No one mentioned MacRuby yet? I guess it's a bit Mac-specific now, but it could probably be made to compile to the GNU or Étoilé objective-c runtimes too.
Also, I'm waiting for Maglev :)
What about Enterprise Ruby? This has been out there for a while.
https://www.phusionpassenger.com/enterprise