JRuby - any reasons why we should use JRuby?

8 views
Skip to first unread message

S. M. Sohan

unread,
Dec 28, 2008, 5:12:31 AM12/28/08
to rubyonrails...@googlegroups.com
Hello folks,
I was looking into JRuby last night and found it to be interesting. It is good in the sense that one can use the Java library and other third party java programs from within the Ruby language. This is surely good for developing Desktop applications. Also, I found that you can use JRuby with Rails. So, basically getting rid of all the configurations that you had to write for Java web apps. But I am personally a little bit skeptical about scripting/dynamic languages. May be because of my background on typed and compiled languages is the reason. But, can anybody provide me a list of compelling reasons for which I should sacrifice the advantages of typed/compiled languages?

For some reason, I have the feeling that the typed/compiled languages are 'safer' than the dynamic ones.

Another issue, not related to the initial intention of this email. We are experiencing long delays (close to 20 mins) as we run our unit tests for ScrumPad. This is mainly because of the data centric AR models. So, cleaning up the part of the db each time before running the tests is causing this long time delay. Any idea on reducing this database dependency in AR models' unit testing?

Best Wishes,
Sohan
http://www.smsohan.com
http://smsohan.blogspot.com
http://www.code71.com

nhm tanveer hossain khan

unread,
Jan 3, 2009, 5:26:36 AM1/3/09
to rubyonrails...@googlegroups.com
hi sohan bhai, thanks for nice topic. sorry for being late,
last year on railsconf europe, i was in one presentation on jruby that was presented by ola bini.
you can find his presentation here.

so far i can remind (around 2004 or 2005) (probably this link) james golsing mentioned about dynamic language on top of JVM.

sun evident their trust on dynamic language by investing a lot with JRuby and netbeans. so far i heard most of the jruby core developers were hired by sun. eventual they came up with a full jruby on rails based application stack. (on top of glassfish)

i tried jruby for experimenting, matter of fact jruby is interpreted language on top of jvm, so jvm has to interpret two level of instructions, one for understanding what ruby script is talking about and java byte code which is used to understand what to do by the JVM.  (though recently i heard in a podcast from (rails envy) clamming jruby new fixs are uplifting jruby performance over ruby c version)

i think, jruby on rails and java ee both are not compliant with each other standards, therefore there is no chance to mix up with java ee and rails. so the configuration you have been talking about are not relevant, since you are not actually developing java ee application anymore (java ee = servlet + ejb + jndi), so actually you are running other server instead of known ruby based implementations (mongrel, thin, passenger and so on..)

though java ee compliant servers were more standard than rails based server until Rack takeover.
i will obviously look towards more feature like JMX which enables us to investigate through the running java vm (using jconsole we could view and investigate through the jvm object space which was cool to see what killing your server/service).

one advantage i can see over jruby on rails is you can use java based proven library with your ruby code which you already mentioned.

personally i use jirb (irb running on jruby)  for experimenting with java libraries rather not trying not trying with my java code. (it saves a lot of time, because you can try out java library without even writing any java source or not event compiling it.)

anyway, i haven't found any good reason yet to move few of my application on jruby. if i had to use java based application i rather prefer to expose java based web service and let other use them through.

one more think,
the way we code in java (following or not following AOP) we feel much confident because of strongly typed language, i think when it comes over ruby you can't expect the same mentality. (dont freeze your ruby class :))
so java is better in its own way rather being adoptive for other way.

the last issue you have pointed,
rails team is actually thinking about this problem thats why they are now more emphasizing on mock object rather fixture based approach. use mocha or other ruby based mocking tool instead of fixture.

anyway thanks once again.
best wishes,
--
----------------------------------------------------
nhm tanveer hossain khan (hasan)
http://hasan.we4tech.com
----------------------------------------------------
mobile: +880 1713 090 511
aawaj: hasan15422
----------------------------------------------------
"work for fun"
"you think you are silly because you are not in right circle"
"all human beings are entrepreneurs" - m. yunus



--
----------------------------------------------------
nhm tanveer hossain khan (hasan)
http://hasan.we4tech.com
----------------------------------------------------
mobile: +880 1713 090 511
aawaj: hasan15422
----------------------------------------------------
"work for fun"
"you think you are silly because you are not in right circle"
"all human beings are entrepreneurs" - m. yunus
Reply all
Reply to author
Forward
0 new messages