Engine Yard scripts JRuby brain trust support plan Rudderless on JRuby? The experts will come to your assistance - for a price. Engine Yard, the company that became a magnet for JRuby brains as Sun Microsystems expired, claims it has become the first company to provide JRuby developers with support. The company is offering technical advice on building with JRuby and how to " …
Surely most Java shops will look at Groovy/Grails or Scala if they want the benefits of Rails but in a Java environment? As for Ruby/Rails users who migrate to JRuby for scalability, performance or security.. well I don't know of any case studies - anyone got any pointers?
So this is a Ruby interpreter written in Java?
So its an interpreted/compiled/emulated language.
For *enterprise* size applications
I'll admit I've heard of *something* like this in mainframe land but there it was *definitely* the exception (very old, very complex, very stable programs no one had the source for anymore)
I can sort of understand doing it this way but I thought JVM's were *fairly* tightly specified and it would be possible to target a standard subset of their instructions.
Very clever, but does doing it in Ruby make a big enough difference in the development process to justify what looks like a *substantial* performance hit?
The official Ruby interpreter is no speed demon either. Depending on how cleverly they do it, JRuby could theoretically be quite competitive. Eg. it could generate Java bytecodes on the fly that directly implement frequently used methods, which the JIT in the JVM could then turn into machine code. Result : Native speed execution for some stretches of Ruby code. I have no idea if it really does this, but it could...
"Eg. it could generate Java bytecodes on the fly that directly implement frequently used methods, which the JIT in the JVM could then turn into machine code."
The JIT compiler (is one built in all modern JVM's?) could make all the difference in this. Presumably in a production environment you could go the whole hog, freeze the development and compile *all* critical code to the platforms native code.
"It is nowadays standard issue, at least in all JVMs anyone wants to use in a production environment. "
Now *that* might change things quite a lot. Presumably this is early days for the Ruby interpreter and they will fine tune it as they gather more experience. It still sounds like a bold move to deliver core apps through this model.
I am one of the core folks at Engine Yard working on JRuby, so I thought I'd answer a few questions:
* JRuby makes sense for a lot of folks that depend on or like the JVM but that want to use Ruby or Rails. No other web framework has had as much work done on supporting modern web development, and having it for the JVM makes a lot of sense.
* JRuby is at least as fast and often much faster than the standard C implementations of Ruby. We do compile Ruby to JVM bytecode as needed, and have done a lot of work to make sure things perform well.
Don't think about JRuby or Java as being "interpreted/compiled/emulated". The JVM is fast for running JVM bytecode, which Java and Ruby (in JRuby) both compile to. No modern JVM only interprets anymore; they all JIT that bytecode into native code, and in many cases produce code that's as fast as writing in C or C++. JRuby gains the benefit of that, performing at least as well as a Ruby implemented in C and often better because we can leverage the JVM's best features like garbage collection.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
