On Feb 15, 9:04 pm, Michael Neale <michael.ne...@gmail.com> wrote:
> In posse podcasts, the dearth of 3rd party libs written in non java
> JVM languages is often brought up (ie jars that you use as
> dependencies of your project, or that are transitive dependencies of
> something you use).
>
> I could be wrong, but I don't know of any libraries at all myself in
> common use.
>
> So is this a case of time and maturity?
Not for me. For me, it's the hassle of dragging along a big fat
language runtime if I want to use a library written in Groovy or Scala
(or even Clojure). I already have too many dependencies in my
projects, and most of my projects are written in Ruby so I've got
JRuby and its dependencies. Even if I was just writing a Java app, I
would cringe at the thought of having to depend on Scala or Groovy
libs just to use a library. If I'm using Java in the first place, I'm
doing it so things are small and tight...limiting dependencies,
limiting language cross-over, and limiting what I have to know to
effectively debug, profile, and understand my complete application.
With this in mind...I'm pretty adamant that Duby not introduce any
runtime library (at best) or a set of interfaces (at worst). Write
your code, compile it, and *that* is your dependency. You're in
control :)
> Speaking for myself, I have written utilities in scala for my own
> usage, potentially will find other usages (always tends to, over
> time). The issue myself, and others face, is how to expose/export an
> appropriate interface. Each JVM language has its own way of defining a
> "java interface" - in scala it is as simple as using traits and not
> using crazy names, and using the standard types.
>
> However, this still isn't quite right, scala doc is not the same as
> javadoc, and can't be mixed directly with it (that I know). This was a
> showstopped for a colleague who wanted a nice first class java
> interfaces for people to use. My solution is to create a set of java
> interfaces, in its own module, document it - and have that as the
> public face (with implementations in appropriate languages). I guess
> that is making java interfaces as the "IDL" of the JVM (which is not
> such a bad thing - Interfaces in java are one of the nicer things that
> I think they got right).
Interfaces definitely are the primary lingua franca between languages,
but I feel your pain in trying to expose libraries written in a non-
Java language without sacrificing the reasons you're using that
language in the first place. This is a primary challenge for "me" (as
in the JRuby team) this year as we try to add in the missing Java
integration features like "real" Java classes.
Here's an example. Say you want to start swapping parts of your system
(written in Java) for new bits written in another language. If you're
using Groovy or Scala, it's possible...provided you accept the
limitations of exposing a "normal" Java class. Groovy classes look
like normal Java classes, but metaprogramming you do after the fact is
not reflected in the outward API. Scala can make classes and
interfaces that look "normal" (using traits, generally, like you
describe), but you have to be sure you don't cross over into Scala
weirdness and produce things that can't be called nicely from Java (or
that you don't expose classes that have Scala weirdness to them. So
you can do it, but you have to speak Esperanto rather than the Queen's
English.
JRuby needs to support the same sort of "limited" exposure of "normal"
Java classes, with similar limitations. So if you want to write a Java
class in Ruby, you have a few options:
1. Implement an existing interface at runtime
Good, but you can't compile against the class itself
(like...instantiating it with a normal constructor), use the resulting
class in configuration files, and often can't really reflect or
introspect it because it may be a java.lang.reflect.Proxy thingy.
2. Write a Java class that just calls down into Ruby
Like the Ruby code classes...good for extending JRuby, but very
cumbersome when you just want something to compile against that looks
"normal".
3. Use JRuby 1.5 to produce "normal" Java classes
This is where things start, sadly, to impose Java's limitations on
Ruby, in order to interoperate with Java.
class Foo
def my_algorithm(str, int)
# do something awesome and return String
end
end
You'd like to be able to use this from Java. How? By adding type
signature. But since Ruby doesn't really have a syntax for type
signatures, you would do it in a Ruby way...by putting method calls in
the class body
class Foo
java_signature [String, int] => String
def my_algorithm(str, int)
...
This is where it gets a little bit cute. You run jrubyc --java against
this file, and it produces two .class files. The first is what jrubyc
normally does, just a "bag of methods" of precompiled Ruby code. But
the second is a normal Java class, that looks roughly like this:
public class Foo {
public String my_algorithm(String a, int b) {
...
But this class file is not bytecode generated. jrubyc --java actually
just generates a .java file and calls javac against it. Ideally, you
could generate all these .java files and do a "joint compilation" with
whatever tool can compile .java source, and then just throw all your
classes plus the jruby jar into classpath and you're ready to go.
So then, what are the limitations? Well, that "java_signature"
call...isn't. The jrubyc --java logic statically inspects the file and
sees java_signature as basically a method declaration keyword. It
never executes any of the code, never calls a java_signature method to
do the compilation. In fact, at runtime, when java_signature would
*actually* run...it's just a no-op. So this means that although you
*can* metaprogram changes to method after the fact (unlike Groovy),
and you *can* produce "normal" Java classes...you do have to accept
some static structure to the files that expose a Java API. Ultimately
it's very similar to the trade-off you make when writing code in Scala
and force things into traits and more Java-friendly names and
features. I suppose these are the sorces of trade-offs we have to make
if we want the least-common denominator--Java--to see libraries
written in our languages no differently from its own.
- Charlie
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
