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.