Raphaël Valyi wrote:
- Could you design a Swing application in, say, Matisse, and then
use JRuby for implementing the business logic that drives that
application? i.e. instead of using something like Cheri to write a
Swing app entirely in Ruby...we would seek a hybrid approach (some
Java, some Ruby).
No problem. Get some JRuby Runtime from java and launch it on some ruby
script with some bound content
More details here:
http://www.headius.com/jrubywiki/index.php/Java_Integration
<http://www.headius.com/jrubywiki/index.php/Java_Integration>
That said, we'd like to make it easier. In Groovy, integrating with a
piece of Groovy code is largely "new MyGroovyThing()" and scripting APIs
don't enter into it. We don't have that...but we want it. It's just a
matter of figuring out how to make it more natural.
- Will 1.1, which appears to be the targeted release for the
compiler to be finished, allow us to compile our entire application
to bytecode? I'm coming at this this morning from an intellectual
property perspective. If we can go all the way to bytecode and not
distribute any *.rb files in our app, then we should be able to
obfuscate that bytecode or use something like Excelsior Jet to
compile to native. We have a few applications that we may distribute
outside of our company, and IP protection will be important. I took
a look at what ThoughtWorks did with Mingle...it appears they've
encrypted the *.rb files and modified JRuby to decrypt them.
However, seems like it would be relatively easy to get access to the
point where the code is decrypted and then stream it off, so I'm not
overly confident in this approach.
After the core team, JRuby classes would be VERY VERY tricky to
un-obfuscate so JRuby could be a very good way to achieve Ruby
obfuscation even if nobody should do closed source anymore (well at
least that would be cool).
I'd say impossible. It can't be decompiled into Java code, because it
does a lot of VM-level things that don't have equivalents in Java. You
could dump the bytecode, but then you'd just have a bunch of bytecode
doing all the tricks necessary to make Ruby work. Algorithms would be
really possible to pull out of that mess. Plus most people can't read
bytecode.
- What can't you do with Java integration and JRuby today?
No big limit as far as I know. I think if you extend a Java class in
Ruby, then that class won't look extended from Java. Only Ruby will see
those extensions. Of course changing an object from JRuby also changes
it in Java, I was really talking about the classes here.
I'm not really sure this limit remain true with the new compiler advances.
Core team devs will reply you better here.
If you extend a Java class from Ruby and override methods with new
versions, it works just like Groovy. Java-land will end up calling the
Ruby methods. Here's the limitations I see currently:
- calling into Ruby requires you to implement a Java interface, extend a
Java class, and/or use a scripting API. That's not as nice as just
constructing an object and running with it.
- You can't extend a Ruby class with a Java class. I have my doubts
whether this will ever be supported for normal Ruby classes, since
there's some really nasty complexity involved.
- You can't tell Ruby code which method you want called by specifying
types. JRuby runs heuristics on the target class to find the narrowest
method that's applicable for the Ruby types of arguments you're passing.
Sometimes it's wrong. But it's really rare.
- JRuby has its own type system, so many core types entering and leaving
Ruby must be coerced to be useful. Basically, Strings, primitives, and a
few additional classes like BigInteger end up getting coerced into their
Ruby equivalents on the way in and then back to their Java equivalents
on the way out. This is a performance issue for Java integration, but we
know it's an issue and it's improving every day. Eventually, we hope the
two type systems will mostly be the same, as they are in Groovy, with
JRuby just adding Rubyisms on top of normal Java types.
- Why would you use Groovy over JRuby?
Charity action. Well, no seriously, if your devs really fear new
language constructs (but IMHO Ruby basics are easy to pick up) or if you
really want to use mainly J2EE frameworks and you aren't really
interested in Rails nor in other ruby frameworks.
I'm not sure what I'd use Groovy for. I'd considered it in the past for
implementing pieces of JRuby, since it would basically be like Java with
closures. Have a look at NodeCompilerFactory to see the hell that arises
when a closure-addicted developer has to use anonymous inner classes for
everything. But Groovy's so much slower than Java and drags along so
many dependencies it would never be feasible. If those two details were
fixed, and Groovy was a 200k JAR file and ran really fast, there'd be
few reasons not to use it as a better Java. But it wouldn't be Ruby.
I suppose you should think about it this way:
- if your primary goal is to add dynamic features to Java, Groovy is the
language you want.
- if your primary goal is to use a dynamic language that has access to
Java libraries and the Java platform, Ruby's probably a better choice.
- Why would you use JRuby over Groovy?
If you need to do efficient web dev and think Rails is great for that,
if you like Ruby as a language to use, if you don't want to take too
much risk with a language who has a very small community (Groovy vs Ruby
communities). If you want to get rich and save the world from the
bloatware attacks :)
The community thing is a big one. There's thousands of Ruby developers
out there, and many of them are starting to use JRuby for more and more
of their work. Former Java haters are actually returning to the platform
because of JRuby, since they can use the language they've come to love
with all the libraries they miss. Add to that the dozens of conferences,
books, user groups, web sites, and so on, and the Ruby community is a
force to be reckoned with.
But my primary reason for using Ruby for many things is simple: Ruby's
more fun. I never feel like I'm limited by Ruby; I never have to know
about Ruby or JRuby internals to accomplish what I want (i.e. I never
have to implement my own MetaClass or Closure to get the additional
dynamic features I need...the language already supports all such
constructs). Ruby's not completely consistent across all methods and all
classes...but it seems to do a lot better job than Groovy.
Of course a lot of my comments about Groovy are probably due to my
unfamiliarity with the language and implementation. The Groovy guys have
done fantastic work stitching together the feature-set they have today.
If they can resolve the performance issue and make some of the dynamic
features a bit more consistent, Groovy will be a great choice. But it
will never feel like Ruby to me, so I'll probably never use it.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
