It is a pretty good book. It was released in September and is already a bit out of date. JRuby & the Ruby world in general seem to move pretty fast.
The topics I liked the best were:
- Nuts & bolts of Java & JRuby integration
- Talk of REXML limitations and the (nice) option to just bang out to the multitude of Java XML APIs should you need extra features
- JRuby & JMX
- JRuby & MOM (Message Oriented Middleware) - ActiveMessaging
After reading it and messing with JRuby a bit, I'm more certain of what I thought in May (ok I didn't say that exactly & I've lost track of Scala - focus on the JVM :) ).
There clearly is a very bright future for Ruby in general & in particular Ruby on the JVM.
What (obviously) makes JRuby + Java so compelling is:
- There is a Java API for *everything*. I hope to stay in Ruby code as much as possible, but it sure is nice knowing that the APIs I have been using for the past 10 years are easily available
- The majority of companies run Java in their data center & are very comfortable deploying to it. Many are also not comfortable adding platforms (e.g., C Ruby)
- The JVM has had a tremendous amount of engineering put into it
- Ruby is a fantastic language that truly is a joy to work with
- Ruby has heaps of momentum & enthusiasm behind it
5 comments:
I still entertain thoughts that I'll be able to do some new development again and lean towards Ruby. But links and interfaces tend to be the first stumbling block for me so seeing improved Java integration and API access keeps my hopes alive. Maybe 2008 will be the year...
Hum, at this point I'd be very careful of JRuby. Looks pretty on paper, but the speed of the impl is all over the map. That is something you can work around, but more importantly, in talking with some guys I work with who in turn worked directly with some contributors, it's years off. Until Matz gives them a language spec, it's nearly impossible to map Ruby to the JVM in a deterministic way. In other words, you will spend a lot of time wondering, "will this block actually run and honor the closure without a JVM long jump". If that makes no sense, be rul, rul careful :)
For all but the most demanding, it's generally possible to scale ruby out anyway (mongrel). Unless you are really bound to the JVM, JRuby this is not where you want to be.
erik: That's not really true. JRuby's compatibility is extremely high now, and for examples like you state there are no known incompatibilities. Rails runs excellent in JRuby--faster than in native Ruby--and that wouldn't be possible without JRuby having solid compatibility. And even without a spec, we have been able to map Ruby to the JVM with a very high confidence level; confidence enough for companies like Oracle and Sun to build large public-facing sites entirely on JRuby on Rails.
If you want the best performance from Rails and the best selection of libraries, JRuby is where you want to be.
Thanks for clarifying Charles. I know that performance wasn't always on par, good to know.
I still have my concerns for Mike though around JRuby not really being Ruby. As someone who has done a good bit of Ruby development, when I sit down at jirb and have to wonder "was that a C-based module or do I need to be importing something from Java?", the context switch is an impediment to my productivity.
If I need a quick, productive Java scripting environment, JRuby is my first choice (especially now with readline support, prior to that Jython would have won out). But if I'm building a web application from scratch, I'm working on Rails 2.0 and I don't want to worry about bridging in Java. POR (Plain Old Ruby) is good enough for most cases and you can just reference the standard Ruby docs, libs, etc.
Viking:
"POR (Plain Old Ruby) is good enough for most cases."
I've determined that the system I'm building may not be the "most" case based on integration, BI, etc.
I'm not sure yet though. It may just be that Java is a safety net for me in that if I get into a bind where I need a library that Ruby doesn't have or if there is a better option in Java, it is nice to know that it is easily available.
For instance if I want to integrate with some Pentaho API I can. If I don't want to use ActiveRecord and instead want to use iBatis or Hibernate I can. If I need to do something that REXML can't do I can use any Java XML library. I think there are lots of examples like this.
Time will tell of course. Lots to learn. But nothing that a little set-based dev can't sort out ;)
Post a Comment