InfoQ

News

Springy Brings JRuby Power to Spring Configuration

Posted by Pat Eyler on Dec 07, 2006 11:55 AM

Community
Java,
Ruby
Topics
JRuby
Tags
JRuby,
Spring

Last week's coverage of RSpec on Ruby (more coverage is available here) included the thought that JRuby was poised to start making waves by providing new, Ruby influenced tools to Java developers.  Springy looks like just the kind of tool Michael Studman was thinking of when he wrote:

I hope that ... more Java developers to sit up and notice Ruby as a language with incredible potential for all manner of problems.

 Springy is a simple DSL, written in JRuby, that lets Java developers wire up their Spring contexts without having to do "XML sit-ups".  For example:

<bean id="bean3" class="springy.beans.Bean3">
<constructor-arg value="${vic}"/>
<constructor-arg ref="bean2"/>
<property name="aProperty">
<list>
<ref bean="bean1"/>
<value>A String</value>
</list>
</property>
</bean>
becomes:
bean :bean3, "springy.beans.Bean3" do |b|  
  b.new(vic, :bean2).aProperty = [ :bean1, "A String" ]
end
(Contrived example taken from Jan Berkel's blog post about Springy.)

 


When asked about his use of JRuby, Jan said:
 We [Trampoline Systems] use a hybrid development strategy, using (C)Ruby on Rails for the frontend and Java for all backend related things (actually with bits of Lisp in it as well). It's really a "best-tool-for-the-job" approach.   Ruby/Rails is agile and productive whereas Java is the big guy in the background who does the heavy lifting.
And Springy's not the only way they're using JRuby:
Our build system is based on Rake with some Java-related extensions (which we've opensourced recently — Jerbil). It reduced the complexity of our build system from ca. 1500 lines of XML to 180 lines of Ruby, largely thanks to Ruby's metaprogramming capabilities.

 

While Springy isn't in wide use yet (it's only been publicly available for about 2 weeks), it certainly shows promise.  It also shows how well JRuby can leverage rubyisms for Java developers.  Jan talked about this too:
JRuby makes it very easy to extend existing Java code: it is getting to a point now where the boundaries between languages almost completely disappear, at least from a Ruby perspective. You can use and extend Java classes in a very natural way whilst retaining Ruby's power and flexibility.

 

The question doesn't seem to be "Will JRuby have an impact on Java developers?", it's "Where in Java world will JRuby's impact be felt most strongly?".  The first several 'cross-overs' have already occured.  Where will JRuby show up next.

12 comments

Reply

Not easy to read by Yagiz Erkan Posted Dec 7, 2006 1:19 PM
Re: Not easy to read by James Tikalsky Posted Dec 8, 2006 11:41 AM
Re: Not easy to read by Yagiz Erkan Posted Dec 9, 2006 7:10 PM
Re: Not easy to read by Alex Popescu Posted Dec 12, 2006 6:22 PM
Re: Not easy to read by Jan Berkel Posted Dec 18, 2006 3:17 PM
Re: Not easy to read by Jan Berkel Posted Dec 8, 2006 12:03 PM
Same in Groovy by Tom Nichols Posted Dec 7, 2006 2:19 PM
Re: Same in Groovy by Yagiz Erkan Posted Dec 7, 2006 4:43 PM
Agreed by David Skelly Posted Dec 8, 2006 2:54 AM
Re: Agreed by James Tikalsky Posted Dec 8, 2006 11:46 AM
thanks by ugr ony Posted Jun 30, 2008 8:50 AM
welcome by boran Boran Posted Jun 30, 2008 9:21 AM
  1. Back to top

    Not easy to read

    Dec 7, 2006 1:19 PM by Yagiz Erkan

    bean :bean3, "springy.beans.Bean3" do |b| b.new(vic, :bean2).aProperty = [ :bean1, "A String" ] end
    This isn't easy to read at all!!! Give me back my XML!

  2. Back to top

    Same in Groovy

    Dec 7, 2006 2:19 PM by Tom Nichols

    Here's how to do the same in Groovy using Grails: http://grails.org/Spring+Bean+Builder Easier to read than XML _and_ Springy, IMO.

  3. Back to top

    Re: Same in Groovy

    Dec 7, 2006 4:43 PM by Yagiz Erkan

    Yeap! That looks much more elegant.

  4. Back to top

    Agreed

    Dec 8, 2006 2:54 AM by David Skelly

    I have to agree with the others here. I'm not a Spring expert or a Ruby expert. Looking at the XML, I can pretty much figure out what it means without knowing all that much about Spring. But looking at the JRuby equivalent, my eyes glaze over and I find myself thinking, "WTF?"

    It also shows how well JRuby can leverage rubyisms for Java developers.
    Well, being a Java developer myself, I'd rather see something that can leverage Java-isms for Java developers.

  5. Back to top

    Re: Not easy to read

    Dec 8, 2006 11:41 AM by James Tikalsky

    This isn't easy to read at all!!! Give me back my XML!
    Who said anything about taking away XML? If you don't like it, don't use it.

  6. Back to top

    Re: Agreed

    Dec 8, 2006 11:46 AM by James Tikalsky

    Well, being a Java developer myself, I'd rather see something that can leverage Java-isms for Java developers.
    Mabye you should take a look at JACN.

  7. Back to top

    Re: Not easy to read

    Dec 8, 2006 12:03 PM by Jan Berkel

    This isn't easy to read at all!!! Give me back my XML!
    well, ruby allows you to specify blocks without do/end (and omit the block argument, as i've just found out), so you could write it as follows:
    bean(:bean3, "springy.beans.Bean3") {
      new vic, :bean2
      aProperty [ :bean1, "A String" ]
    }
    
    with some tricks you could even get rid of the double quotes in the classname. the example from the blog post was just to show how concise bean declarations can be, you don't have to put everything in one line.

  8. Back to top

    Re: Not easy to read

    Dec 9, 2006 7:10 PM by Yagiz Erkan

    I meant "XML reads much better" so the approach presented in this article doesn't look nice/read nicely. And of course, if I don't like it then I won't use it. Thanks for stating the obvious. ;)

  9. Back to top

    Re: Not easy to read

    Dec 12, 2006 6:22 PM by Alex Popescu

    I think Yagiz point is quite correct: people with Java knowledge are not reading this ruby-ish format code, and so I would say that Springy is losing one important side: writting fewer configuration lines that are still readable. ./alex -- :Architect of InfoQ.com: .w( the_mindstorm )p. Co-founder of InfoQ.com

  10. Back to top

    Re: Not easy to read

    Dec 18, 2006 3:17 PM by Jan Berkel

    ok, agreed, i should have written the blog post for an audience unfamiliar with ruby. while the syntax could definitely be improved on, the main goal of springy was not to make it more readable (to everyone) but more powerful. i guess it's a simple trade-off and a lot more interesting to developers already familiar with ruby.

  11. Back to top

    thanks

    Jun 30, 2008 8:50 AM by ugr ony

  12. Back to top

    welcome

    Jun 30, 2008 9:21 AM by boran Boran

Exclusive Content

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.

Security (CAS and OpenID) with Ruby

In this talk from QCon SF 2007, Justin Gehtland explains two open solutions to distributed identity and their Rails integration components: OpenID (using ruby-openid) and CAS (using rubycas-client).