Today at JavaOne, Engine Yard is announcing support for JRuby. This means that people will soon be able to select JRuby as a runtime option for Engine Yard Cloud, and subsequently on the Engine Yard private cloud for cluster and slice customers. We’re excited to partner with Charlie Nutter and Tom Enebo and the broader JRuby team to make this happen. JRuby support will be in beta for Engine Yard Cloud in early July.
Since we’re announcing this at JavaOne, it might be good to reiterate the main reasons why Java developers have migrated and are continuing to migrate to Ruby and Rails:
- Rails: easier to learn, and faster to code than Java frameworks, and with Rails 3 coming—even simpler to extend.
- Ruby: easier to write with lots of means of abstraction (blocks, modules and metaprogramming.)
- Ruby: faster for iterative and agile methods with dynamic typing and no compile cycles
- An active community with excellent tools, training and lots of innovation: Agile Development With Rails, TextMate, Peepcode, RubyForge, RSpec, DataMapper, Rack etc.
Not to mention excellent REST support, a very fast regex engine, great collections handling, and all the other hundred reasons why people simply ENJOY developing in Ruby.
Very practically, we’re also adding JRuby support in response to demand from both companies and from professional web developers, who want to use Ruby and Rails, but have existing libraries written in Java. For various reasons, they sometimes prefer Java native integration over the more ideal method of exposing old code via web-services. These folks like JRuby because it gives them an easy way to transition from Java to Ruby without having to re-write all their existing libraries on day one with Ruby (or completely swap out their platform and tools). In our mind, when you’re getting people to adopt a language and framework like Ruby and Rails—the more you can do to keep backward compatibility with existing stuff (code, tools, platforms) the better.
With JRuby support, our ongoing maintenance of the 1.8.6 branch of MRI and our continued sponsorship of Rubinius, we hope that Engine Yard is continuing to help Ruby and Rails be the first choices of web developers everywhere.
Loading ...
Watch a Live Demo of Engine Yard AppCloud
The Engine Yard Newsletter
Take THAT Googler$!!!
Maintance of 1.8.6, developing Rubinius and support for JRuby – this is massive !
Keep to good work, guys :)
What will this look like, technically? Which application server will be used and what will administration look like?
We haven't commited to any specific application server yet, I am researching all the options right now and working on what our running jruby stack looks like. None of it is set in stone.
I will blog about my journey through all the different deployment options for Jruby apps as the investigation continues.
At this point I'm convinced that jruby is a better platform than mri. It's awesome to see commercial options available for jruby!!!
Taking a swipe at Java people while announcing something at Java one is pretty poor form.
"Rails: easier to learn, and faster to code than Java frameworks, and with Rails 3 coming—even simpler to extend."
In some cases you're right, but you won't win over any Java people by telling them that, categorically, their platform blows.
"For various reasons, they sometimes prefer Java native integration over the more ideal method of exposing old code via web-services."
This is a simple one. If you already have a re-usable library, why on earth would you want to bolt on a service architecture to it?
"These folks like JRuby because it gives them an easy way to transition from Java to Ruby without having to re-write all their existing libraries on day one with Ruby (or completely swap out their platform and tools)."
Ruby isn't nirvana, and perhaps you consider that Java developers appreciate that the JVM can now host:
– Java
– PHP
– Ruby
– JavaScript
– Scala
– Clojure
… just to name a few. Some of us might be interested in this offering because we see the value in being able to use the best libraries and frameworks for a job, regardless of the language, not because we think Ruby is the Future of Programming embodied.
I'm a pretty polite guy, I find it difficult to understand why you would consider this post to be "taking a swipe at Java people", that "their platform blows" or how this could conceivably be characterized as "Ruby is the Future of Programming embodied". None of which was either intended or I believe expressed.
This is good news for Ruby community in general. Kudos Engine Yard
The entire post is phrased in terms of Java's (perceived) lackings. The web frameworks are all worse than Rails, Ruby is so much better than Java, and why wouldn't you want to move all your libraries to Ruby?
If you're advertising to the Ruby Faithful, it makes sense, but it sure seems like the idea is to target Java (or JVM-based-language) developers who may want to leverage Ruby for the front-end.
Do you have a timeframe for the JRuby support?
Hi Roderick – we're aiming for early July for beta support of JRuby on Engine Yard Cloud.
Pretty much awesome!