Groovy & Scala: a tale of two JVM languages

Compile the Scala source with the following command:

$ scalac -cp $GROOVY_HOME/embeddable/groovy-all-1.6.4.jar:. Test.scala

Finally run it by typing the following on your command prompt

$ scala -cp $GROOVY_HOME/embeddable/groovy-all-1.6.4.jar:. Test
Hello Scala from Groovy!

Granted, this example is quite simple, some would even say that by virtue of Scala's type inference we wouldn't need to define the type for the greeter variable. For example, just imagine that the value comes from a factory or an IoC/DI container, then it makes perfect sense to leave the type. This is how things would look like if the roles were reversed. First a Scala based implementation of the Greeter interface, as demonstrated by Listing 4.

Next the “business” end in Groovy shown in Listing 5.

Compile and run the additional sources with the following commands:

$ scalac -cp $GROOVY_HOME/embeddable/groovy-all-1.6.4.jar:. ScalaGreeter.scala
$ groovy -cp $SCALA_HOME/lib/scala-library.jar:. GTest.groovy
Hello Groovy from Scala!

That wasn't so bad, was it? The added benefit is that you can send either implementation of Greeter to any method that accepts a Greeter and it will work, no matter in which language that method was written.

But we can do better than this, let's cut the middle man out and have both languages talk to each other directly.

Groovy calling Scala

Groovy is quite happy handling Scala code, it will do it in the same way as it handles Java code. But if your intention is to harness the power of a particular Scala library then you might be in for a surprise. Let's say for the sake of argument that you need to deal with Scala's collection library. As mentioned before, these collections come in two flavors: mutable and immutable, with the latter being the preferred ones. Scala collections have plenty of useful methods that simplify your code, however those collections cannot be interchanged with Java/Groovy collections, they have their own independent hierarchy (by design). This can be troublesome as pretty much all Groovy additions to JDK Collections are not visible in Scala collections. Furthermore those handy collection methods that rely on Scala's functional style require you to send them a Function object, not a Groovy closure.

If only there was a way to enhance a class with new behavior... oh wait, but there is! The Groovy MOP (Meta Object Protocol) can take care of this issue in an elegant manner.

We will start by defining the domain. Listing 6 shows a Scala class that defines 4 methods (though for Groovy eyes they look more like properties don't they?)

The first 2 methods return an instance of scala.List, the last 2 methods return an instance of scala.Function1. It is worth noting that if you ever try to apply sfun to ilist from Scala the compiler will not let you proceed, because the types don't match.

Alright, here comes the first trick, a target class requires a single method in order to take advantage of the so-called iterator methods that Groovy adds to the JDK, That method must comply with the following signature:

java.util.Iterator iterator()

Yes, it is that simple. Now it is a simple matter of finding a java.util.Iterator friendly method on a Scala List. Sadly there is no such method but there is one that returns a scala.Iterator, maybe we can wrap that with our own implementation of java.util.Iterator. We also need a way to attach the new method to a scala.List, this task can be easily achieved via its MetaClass. Listing 7 demonstrates how it might be implemented.

Sweet! With this setup we're now able to make the following calls from a Groovy script as shown in Listing 8.

Once the new iterator() method has been added all other iterator based methods will work as expected. You can certainly use find(), grep(), findAll(), any(), each() and every other iterator based method with confidence now.

Let's turn our attention to Functions & Closures. Functions in Scala are defined by interfaces. Each interface defines 3 methods: curry(), toString() and apply(). Each Function interface has a different signature for apply(), related to the number of arguments it can process. For example, scala.Function0 defines apply() but scala.Function1 defines apply(Object). We must be careful with the number of arguments accepted by each function when transforming a closure into a Function, the same rules apply in reverse. Luckily for us Groovy knows how to handle variable arguments, as shown by the helper class in Listing 9.

We leave the implementation of curry() empty for now, after all this is a first approach to language interoperability, it is definitely far from finished. Transforming a closure into a function will work provided you do not define more than 22 arguments (there is a Function22 class but there isn't a Function23) and that function is not curried afterwards. The reverse operation, function to closure, is achieved by wrapping the function with a closure that takes variable number of arguments (varargs for short). Notice there is no particular type defined for the function variable. The spread operator will take care of expanding the argument list, thus the correct apply() method should be called. With this helper class we're now able to make the calls from a Groovy script as seen in Listing 10.

The map() function is a method defined in scala.List. It takes a function as parameter and applies it to each element on the list, returning a new list with each transformed element, in other words, it’s pretty much collect()'s twin. First we check that map() works as expected when passed a function as an argument, then we convert a closure (named mapper) into a function, map it again and check results. Because Groovy is happy with duck typing only one mapper closure was required. Lastly we use Groovy's collect() method with the mapper variable and transformed function.

Naturally this is just the tip of the iceberg. Similar steps can be replicated to enhance other Scala collections, like Maps, Sets and Sequences. That however, is left as an exercise to the reader. Who knows, maybe somebody will come up with a library that eases up interoperability from Scala to Groovy.

Let's take a look at the other side of the coin, shall we?

Scala calling Groovy

It turns out Scala is also quite happy calling your Groovy code as if it were Scala code. The problem comes when you want said Groovy code to be used with idiomatic Scala, it simply won't work all the time. Just like Groovy, Scala supports properties out of the box, but with a different set of conventions. Listing 11 shows a simple class with a single property.

When compiled, the Bean class will look like the snippet shown below

javap Bean
Compiled from "Bean.scala"
public class Bean extends java.lang.Object implements scala.ScalaObject{
    public Bean(java.lang.String);
    public void name_$eq(java.lang.String);
    public java.lang.String name();
    public int $tag() throws java.rmi.RemoteException;
}

It's true, in Scala the Bean class fits in a single line. Notice the naming convention for its name property. You can be sure that every property on every Scala bean follows the same convention. Imagine writing those property accessors by hand, surely there is a better way: the AST Transformations framework.

Introduced in Groovy 1.6, the AST Transformations framework includes compile time metaprogramming capabilities to the Groovy language. With it you'll be able to tweak a class at compile time by doing things such as adding new methods, removing unwanted code and so forth. Writing an AST Transformation is a hard task, frankly a bit daunting too, but the rewards are worth it. But let's not get into the gory details this time, for now you only need to know that an AST Transformation requires a marker interface. This interface can be used to inject metadata that the AST processor requires to do its work. There a few standard AST Transformations which come bundled with Groovy, like @Delegate, @Bindable and @Lazy. [See Guillaume Laforge's “What's new in Groovy 1.6” in GroovyMag April 2009 for more information]. However there is an additional module that serves as an incubator for non-standard AST transformations called Groovy Transforms, it so happens to provide @Scalify, just what we need

Any Groovy class annotated with @Scalify will generate the required boiler plate code to make it friendlier to Scala when compiled. In its current release @Scalify will generate property accessors that follow the Scala conventions. It will also generate operator overloading methods that follow the Scala conventions too. Listing 12 shows an example of Groovy bean which is annotated with @Scalify.

import groovyx.transform.Scalify @Scalify class GBean { String name GBean plus(GBean other) { new GBean(name: name+other.name) } } Listing 12: GBean.groovy

Once compiled it will generate the following bytecode:

$ groovyc -cp $SCALA_HOME/lib/scala-library.jar GBean.groovy
$ javap GBean
Compiled from "GBean.groovy"
public class GBean extends java.lang.Object implements scala.ScalaObject,groovy.lang.GroovyObject{
    // ... snip
    public GBean();
    public GBean plus(GBean);
    public GBean $plus(GBean);
    public void name_$eq(java.lang.String);
    public java.lang.String name();
    public int $tag();
    public java.lang.String getName();
    public void setName(java.lang.String);
    // ... snip
}

The previous command assumes you placed the groovy-transforms-0.1.jar into $GROOVY_HOME/lib. As you can see, the GBean class contains both valid Groovy byte code and valid Scala byte code. There is a catch however, and it has to do with how Scala manages signatures. Even though the byte code appears to be correct, if you attempt to call the Scala friendly setter from Scala using it's short notation, i.e, by calling gbean.name = “Foo” instead of gbean.name_$eq(“Foo”), the Scala compiler will complain about a missing method! This happens because the Scala compiler performs an additional step while working, it creates a class attribute named Pickle and attaches it to the generated byte code. This attribute contains the signature for each method, and it is used by the compiler to verify the code while compiling (among other things). The @Scalify AST transformations doesn’t generate a pickle (update 2) attribute at the moment. Hopefully this missing feature will be provided in a future release.

Can Scala quack?

There is one last option left to explore. Scala can let your dogs, cats and ducks quack even though Scala is statically typed. What you will see next is Scala's last resort to duck typing: structural types.

Essentially, if you cannot know in advance what type of object you will be receiving, at least constrain its behavior to a predefined set of methods. Be warned that this feature relies heavily on reflection, many Scala developers shun it away for performance reasons.

First, let's define two Groovy classes that share a method signature, say Human (Listing 13) and Robot (Listing 14), both should be able to get some work done, right?

We will continue with the example despite our Human class not being very helpful. We need a place for both humans and robots to do some work, a factory would be perfect. However the people in charge of the factory don't care who performs the job as long as the work gets done, so the Factory (Listing 15) simply hands a task to the next worker.

Below is some sample output of running the code once:

$ scalac -cp $GROOVY_HOME/embeddable/groovy-all-1.6.4.jar Factory.scala
$ scala -cp $GROOVY_HOME/embeddable/groovy-all-1.6.4.jar:. Factory
Robot@11e0c13 bzzzt * click ... wheee .. bzzzt
Human@1d2b01b *need coffee break*

There you have it. A word of caution, not only are structural types a sure hit on your application's performance (when compared to regular Scala code) but they can get in the way once additional signatures are required, the usage of Traits or plain Java interfaces is recommended instead.

Conclusion

Using more than one language to develop an application is a growing trend, the main reason being that there is no silver bullet; there is no single language that can solve all problems. Mixing Groovy and Scala makes perfect sense if what you need is better performance, a functional style for developing algorithms and very flexible DSLs. Hopefully this article tickled your curiosity to learn more about each language and test them out together.

Update #1: Groovy 1.7 (recently released) supports anonymous inner class definitions. The usage of a runtime proxy may not be needed anymore.

Update #2: I've been told that the upcoming Scala 2.8 release does not require a Pickle.