3

I am in the research phase of a project that needs to make use of 3rd party libraries that are in Java so I am stuck using Java to at least a small degree.

I am considering implementing Ruby as the front-end layer. That would leave me with the option of calling the Java classes as a web service by hitting a certain URL, is that correct?

Is that generally a solid approach to things?

Also, how would it affect my build environment when I create the .war file using Ant? should I have src/java and src/ruby code, or do the ruby files go somewhere else?

Any tips and pitfalls on this? I am a little bit new to Ruby so advice would be appreciated.

Also, I considered JRuby, but it seemed like a less mature tool that just has a JVM for a smoother calling of Java classes, correct? I am concerned with the maturity of that tool and its bein neither Java nor Ruby.

Genadinik
  • 509
  • 1
  • 3
  • 11
  • "its bein neither Java nor Ruby"? JRuby *is* Ruby. – Rein Henrichs Apr 20 '11 at 16:29
  • @Rein but then why is it JRuby and not Ruby? lol ...from reading about it I got the sense that it is a separate thing from Ruby. – Genadinik Apr 20 '11 at 16:32
  • it's a different implementation of Ruby. – Rein Henrichs Apr 20 '11 at 16:43
  • 4
    JRuby is a compatible implementation of the Ruby language that runs on the Java Virtual Machine--which means it is subject to all the optimizations that the Hot Spot VM does for you. It's been shown to run faster than Ruby 1.8 (interpreted C based runtime). – Berin Loritsch Apr 20 '11 at 16:44
  • So if it is a different implementation, should I expect random quirks with it? My concern is that it is a fragmented subset of a tool which will be a pain when it comes to random errors and configuration differences, with smaller community to rely on for help. – Genadinik Apr 20 '11 at 16:48
  • A word of caution: Native gems (those that require C extensions) cannot be used with JRuby. Gems written in Ruby only will work with JRuby. – Srisa May 30 '11 at 07:13

3 Answers3

3

JRuby is quite mature now, has a hell of a better performance than the official Ruby runtime (if you target Ruby 1.8.x; the 1.9.x branch impoved a lot, and makes performance differences between the 2 less relevant), and gives you very easy access to Java libraries.

Plus, if you way that you want to package WAR files then I guess it wouldn't be an issue for you to use a Java-enabled container/server.

So, I would definitely recommend that you get a closer look at JRuby.

And no, JRuby doesn't "have a JVM". It runs on top of a JVM. So you can develop your whole project in JRuby if you want (or even code it with Ruby and then call your code using JRuby, though you might encounter a few surprises so I'd recommend to use JRuby from the beginning) and just use the Java classes whenever you need to.

It's fairly well integrated, it has a lively and friendly community, and they produce regular updates to the implementation.

Regarding you build environment, if you use JRuby you will be able to call the compiler from Ant easily (like anything else, really), so that wouldn't be an issue. There might even be some custom tasks already implemented, I don't really know the state of things in this area.

Personal experience anecdotes and stuff: I used JRuby a lot for implementing automated test harness a few years back (mostly around 2007) and it wasn't even that mature at the time, and yet it was already in my opinion a much better alternative over the official Ruby implementation. Plus it was great in my case that it run on the JVM as I could also use it to unit test Java classes. And it's been improving steadily over time.

Its only disadvantage is that, if you use it to develop small programs or standalone tools, that you need to package your solution with a JVM or have the user install one, and that for short-lived programs the cost of firing up a JVM (especially older versions, it's quite fine now) might be a drag.

Apart from that, that was a very good solution and I still write scripts on it occasionally.

haylem
  • 28,856
  • 10
  • 103
  • 119
2

I worked on a system that had a large Java application side, and a large Ruby side (both a Rails web site and JSON API). Beware the compatibility issues that can crop up when you keep two copies of domain models written in two different languages. You have to carefully plan your production releases so one application doesn't introduce data in the database that the other application finds problematic. What you are proposing is Distributing your Objects. More and more I like to heed Martin Fowler's advice here:

The first rule of distributing your objects is don't distribute your objects!

Source: Microservices and the First Law of Distributed Objects

If you need a set of web services, you need to ask yourself "Why?"

If you need to support both web and native mobile platforms, then you may have a use case for doing what you are proposing. If you want to create web services because you have to use Java, but you really want to use Ruby then you are adding layers of complexity and maintenance for the convenience of Ruby. From personal experience, this is not worth it.

More on Fowler's distaste for "distributed objects":

My objection to the notion of distributed objects was although you can encapsulate many things behind object boundaries, you can't encapsulate the remote/in-process distinction. An in-process function call is fast and always succeeds (in that any exceptions are due to the application, not due to the mere fact of making the call). Remote calls, however, are orders of magnitude slower, and there's always a chance that the call will fail due to a failure in the remote process or the connection.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
0

From an architecture point of view, I like to separate entirely the two layers, through a communication layer (web services, rest services...), like a standard SOA architecture.

From my understanding, you have:

  • Frontend (Presentation Tier) which you plan to realize in Ruby
  • Backend (Business Tier) which you have to implement in Java

You may want to realize separate artifacts, so you may reach larger scale (e.g.: different servers for Presentation and Business Tier), and you may separate the business logic implementation to the rendering.

logc
  • 2,190
  • 15
  • 19
Dan M
  • 151
  • 4