Groovy dynamic stateless mixins

June 7, 2008

Last week I wrote about per-instance meta-classes and ExpandoMetaClass DSL. At that point it was just prototyped code in my working copy and I was not even sure if it will come to Groovy 1.6 trunk. Now it is there. If you didn’t read this previous post I recommend to have quick look on it as it might help to understand current one.

Today I want to talk about another part of the same commit, which is kind of side-effect of ability to have per-instance meta classes. Now we able to have per instance dynamic stateless mixins.

But let me start we explanation of what is mixin for me.

Mixin is either static or dynamic way to extend class or instance behavior by adding methods and/or state defined in another class.

Static here means defined at compile time and dynamic means defined on runtime. This two types of mixins are totally different.

  • Static mixins applied to class but dynamic one to meta class (either class one or instance one)
  • Static mixins always effect hierarchy, dynamic ones may or may not effect it depending on nature of meta class under effect (if meta class is the one associated with the class it does, if not it does not
  • Static mixins always effect type information, dynamic ones never does that.

Stateless or stateless mixins means ability of mixins to extend object behavior not only with methods but with state as well. Stateful compile time mixins can be understand as kind of multiple inheritance.

Groovy has no compile time mixins yet. I think Groovy has to have something similar to Scala traits but it is subject to different discussion.

Groovy has no stateful mixins yet as well and below I will talk a bit about my idea how they should look like. So main subject for today is dynamic stateless mixins

Let me show simple example. First of all we define usual category class, which will be used to mix in.

class DeepFlattenToCategory {
    static Set flattenTo(element) {
        LinkedHashSet set = new LinkedHashSet()
        return set
    // Object - put to result set
    static void flattenTo(element, Set addTo) {
        addTo <
    // Map - flatten each value
    static void flattenTo(Map elements, Set addTo) {
    // Array - flatten each element
    static void flattenTo(Object [] elements, Set addTo) {
        elements.each { element ->

This category does pretty obvious thing – deep flattening of complex data structure as demonstrated by following code snippet.

        // mixin Category to meta class
        Object.metaClass.mixin DeepFlattenToCategory
        // and here we are
        assertEquals ([8,9,3,2,1,4], [[8,9] as Object [], [3,2,[2:1,3:4]],[2,3]].flattenTo () as List)

Careful reader may notice probably that we modify only meta class for Object but methods for Collection, Object [] and Map becomes available as well. Such behavior is usual for categories but a bit uncommon for ExpandMetaClass – in the past he had to call ExpandoMetaClass.enableGlobally () to ask meta classes to look for missed methods. Such approach had several downsides – to name a few: unnecessary memory footprint for creation ExpandoMetaClass for each class (both modified and non-modified) and lack of “good place” where to call ExpandoMetaClass.enableGlobally (). It means that if you developed library, which requires it – you should call it somewhere, because nobody can guarantee that user application will do that. Fortunately, now ExpandoMetaClass can define methods for sub classes and if sub class missed some method he will try to find it in hierarchy. Obviously such behavior is must for mixins – otherwise our sample will look much less nicer(which is still to be valid code but creating four ExpandoMetaClasses instead of one)

        // mixin Category to meta classes
        Object.metaClass.mixin DeepFlattenToCategory
        Collection.metaClass.mixin DeepFlattenToCategory
        Object[].metaClass.mixin DeepFlattenToCategory
        Map.metaClass.mixin DeepFlattenToCategory
        // and here we are
        assertEquals ([8,9,3,2,1,4], [[8,9] as Object [], [3,2,[2:1,3:4]],[2,3]].flattenTo () as List)
{ -> .... }

BTW, ExpandoMetaClass has new syntax to define methods for subclasses
{ -> .... }


        Object.metaClass {
           foo(ArrayList){ -> .... {


        Object.metaClass {
              foo{ -> .... }

OK, back to mixins. So far, it seems very similar to normal categories, so let us make our sample more interesting

        class NoFlattenArrayListCategory {
           // ArrayList - put to result set
           static void flattenTo(ArrayList element, Set addTo) {
              addTo << element;

        def x = [2,3]
        x.metaClass.mixin NoFlattenArrayListCategory
        assertEquals ([x, 8,9,3,2,1,4], [x, [8,9] as Object [], [3,2,[2:1,3:4]],[2,3]].flattenTo () as List)

What we do here is create category, which does not flatten array lists and mix it in instance meta class. Voila!
Of course the same can be achieved with ExpandoMetaClass without mixing in category

        def x = [2,3]
        x.metaClass.flattenTo = { Set addTo -> addTo << delegate }
        assertEquals ([x, 8,9,3,2,1,4], [x, [8,9] as Object [], [3,2,[2:1,3:4]],[2,3]].flattenTo () as List)

but please remember that category can be easily implemented in Java and provide much better performance compare to closure-based meta methods. And now we can use it as mixins.

The last thing I want to talk about is some features, which is missing and which I would love to see in Groovy. All below is just imagination and I don’t know exact implementation details and underwater stones but here are problems to be addressed.

  • Stateful mixins
  • Mixing in objects
  • Better syntax to define categories in Groovy
  • Compile time mixins

Stateful mixins

Imagine that category class defines not only static methods but also some fields and these fields magically becomes available as properties when we mix these category in. Probably if object already has such properties the one defined by category should be ignored, but if not… we have extremely powerful tool.

The main technical problem here is that we don’t want to define these new properties via ExpandoMetaClass, which will be very slow, but if we created instance of category class to associated it with original object… well, we have no good place to store this association. For Groovy compiled objects we of course can store refernence(s) directly in the object and for Java one in WeakHashMap. But what will happen if this mixed in instance keeps strong reference for original Java object… It will never be collected. Believe me, it will happen very often. So far I don’t know any good solution for that.

Mixing in objects

If we had solution for stateful mixin most probably it will lead us to ability to mix in not only category class but any object. I can imagine fantastic possibilities for that.

Better syntax to define categories in Groovy

Well static methods with additional parameter ‘self’ are so ugly. We definitely need something better. So far we have @Category annotation, which solves only part of the problem.

Compile time mixin

Having stateful mixins with good syntax to define category methods will lead us to ability mixin category classes on runtime. As result we will have probably the strongest mixin story between all dynamic languages and as powerful as Scala traits in the world of staticly compiled ones.

So it goes.


Groovy per instance meta classes and ExpandoMetaClass DSL

June 2, 2008

So far Groovy allow per instance meta classes only for objects, which implements GroovyObject interface (like any class defined in Groovy). It can be illustrated by following simple test case:

   // for java.lang.String
   "test string".metaClass.toString = { "modified string" }
   assertEquals( "modified string", "test string".toString() )
   // but any other string will have the same behavior
   assertEquals( "modified string", "any other string".toString() )

At the same time

   // for GroovyObject
   class MyBean {
      String toString () { "bean" }

   def bean = new MyBean ()
   def emc = new ExpandoMetaClass(MyBean,false,true)
   emc.toString = { -> "modified bean" }
   bean.metaClass = emc
   assertEquals("modified bean", bean.toString())
   // but any other bean will keep default behavior
   assertEquals("bean", new MyBean().toString())
   // if we want to modify behavior of all MyBean objects
   MyBean.metaClass = emc
   assertEquals("modified bean", new MyBean().toString())

Notice that we use different technique to add methods to Java and Groovy objects. As getMetaClass () for Java object always returns the same meta class we can use .metaClass notation, each GroovyObject has it is own meta class (of course, it is the same object by default) so we act differently depending on what we want to modify (whole class or just one Object)

Now I have patch which solves all these problems.

First of all we can assigned per instance meta class for any object. Of course, for Java objects it kept in WeakHashMap which involves some performance penalties. But now our first sample looks much more natural

   // for java.lang.String
   "test string".metaClass.toString = { "modified string" }
   assertEquals( "modified string", "test string".toString() )
   // but any other string will have natural behavior
   assertEquals( "any other string", "any other string".toString() )

Groovy objects also has benefits – we don’t need to create ExpandoMetaClass manually.

   def bean = new MyBean ()
   bean.metaClass.toString = { -> "modified bean" }
   assertEquals("modified bean", bean.toString())
   // but any other bean will keep default behavior
   assertEquals("bean", new MyBean().toString())
   // if we want to modify behavior of all MyBean objects
   MyBean.metaClass = bean.metaClass
   assertEquals("modified bean", new MyBean().toString())

But now, when we have unified behavior for Java and Groovy objects we can use simply and powerful ExpandoMetaClass DSL. Here is example

        // add behavior to meta class for Integer
        Integer.metaClass {
           // block of static methods
           'static' {
                fib { Number n ->
                    n.fib ()
                // we can use both = or << if needed
                unusedStatic << { -> }

            // one more syntax for static methods
            static.unusedStatic2 = { -> }

            // property definition
            ZERO = 0

            // method definition
            fib { ->
                def n = delegate
                if (n == ZERO)
                  return 1;
                if (n == 1)
                  return 1
                  return fib(n-1) + fib(n-2)

            // of course we can use both = or << if needed as well
            unusedMethod << { -> }
        // and now we have it
        assertEquals( 3, 3.fib())

        // but we can also modify meta class for particular number
        4.metaClass {
            fib { ->

        // and it works!
        assertEquals( 13, Integer.fib(5))

You know what… I like it. And thanks a lot for Graeme for inspirations and advices while I worked on that. Hope it will be accepted well and commited to the trunk.

invokedynamic: Is It What We Really Need?

May 9, 2008

John Rose wrote interesting post regarding dynamic invocation in the VM. Here are my thoughts as implementor of Groovy language.

DECLAIMER: It is not official opinion of Groovy Development Team or G2One Inc. but only my personal opinion.

First of all I think John and JSR 292 team finally start to do very good job. After long period of uncertainty we have a lot of communication last months about what’s going on and ideas under discussion. It is really helpful.

Finally we have very clear explanation of method handles idea, which sounds very promising. To make long story short it is about avoiding expensive calls to Reflection API, which is one of the biggest problems each dynamic runtime meet. And now we have more or less clear picture (or suggestion) for invokedynamic.

Recent significant progress in JRuby and Groovy runtime performance proved clearly that dynamic languages has a lot of space for improvements in terms of performance. It is also more clear now what kind of support is required from JVM for dynamic language runtime.

In fact, the main challenge for implementor of dynamic language sounds pretty trivial: you have call to the method and in general can assume nothing about type of receiver and types of arguments. So execution of a call consist <i>logically</i> of two important steps:

  • method selection
  • method invocation

IMPORTANT NOTE: Current Groovy MOP doesn’t separate these steps, which also leads to some difficulties. Of course, implicitly (logically) both steps are presented. For Groovy MOP 2.0 we consider possibility to separate them explicitly.

Method invocation in Groovy is expensive. We have to use Reflection API, which does a lot of checks, requires allocating of array for result, boxing/unboxing of arguments and return value and several nested calls before we come to execution of real method. As I said before there is some hope that methods handle will help here. What is especially beautiful in method handles is the fact that they don’t require new bytecode but can be handled directly by JVM.

Method selection in Groovy is even more expensive. Following diagram gives very simplified overview of what’s going on. Let me repeat this: it is simplified overview and real process even more complicated (categories, ExpandoMetaClass etc.)

Fortunately there is solution for the method selection problem: if we store result of previous method selection there is very good chance that next time our choice will be the same and check of this fact is much cheaper compare to real selection process. This technique is implemented in Groovy 1.6 and proved to be very efficient (of course some memory overhead is involved)

Here is pseudo-code of API used by Groovy 1.6

public abstract class CallSite {
    // index of call site
    protected final int index;
    // name of method
    public final String name;
    // array of all call sites in compiled class
    protected final CallSiteArray array;
   // calls to this methods appear in bytecode
   public Object call (Object receiver, Object [] args) {
      retutn acceptCall(receiver,args).invoke(receiver,args);
   // check if receiver, arguments, categories in use, etc. fits to memorized choice
   // if so, we can continue to use same call site
   // if not, new call site created to replace current one
   protected CallSite acceptCall (Object receiver, Object [] args) {
      if (checkCall(receiver,args))
         return this;
         return createCallSite(this,receiver,args);

   // check if receiver, arguments, categories in use, etc. fits to memorized choice
   // depends on type of call site
   protected abstract boolean checkCall (Object receiver, Object [] args);

   // real invocation
   // depends on type of call site
   protected abstract Object invoke (Object receiver, Object [] args);

   // creates new call site, which will replace existing one
   protected final CallSite createCallSite(CallSite base, Object receiver, Object [] args) {

In bytecode receiver.method (arg1, arg2) becomes

callSiteArray[callSiteIndex].call (receiver, new Object[] {arg1, arg2} );

callSiteArray is synthetic local variable filled in the beginning of each method from static soft referenced field. Initially array is filled by dummy call sites, which needed to keep name of target method and index of call site, because we don’t want to send two additional parameters each time and we also don’t want to do null check for call site on each invocation.

So what happen when we visit call site first time is creation of real call site and invocation. On second visit we check if it still to be valid and either recreate or use it.

Truely speaking, API above is not real API. There are special paths reflecting the fact that in Groovy there is several different types of method call but it is out of scope of this note and I hope the idea is clear. Another thing, which makes API much more complex is special paths for binary operations and in the future for calls with small number of parameters, which allow to avoid creating of argument arrays.

So how all that is related to invokedynamic? Very simply. Bootstrap method will call our createCallSite. Target handle will be doing check and either invoking another method handle (really selected method) or setting new target. And voila!

The only thing, which really worries me is do we need special bytecode or Java API (of course specially recognized and optimized by JVM) is enough.

The real beauty of API is that you can use it (backported versions) for old JVMs. Even now a lot of people stay with 1.4 and I am not sure how many already switched to 1.6. For us, as language developers, very important to support old platforms. For sure, to support 1.5. And I would prefer not to have two versions of compiler for platform supporting invokedynamic and for one, which doesn’t.

The only really good side of invokedynamic compare to fixed API is ability to make calls with absolutely any signature. I don’t know how important is that for other languages, for Groovy I think it will be enough to have rich enough fixed API for small number of arguments and Reflection-like general API.

So if I was member of EG, which I am not, I would prefer not to introduce new bytecode.

Dixi šŸ™‚

Joint compilation of Groovy and Java – III

July 4, 2007

Believe you or not but it happened. Now you can compile Groovy and Java together.

Read Jochen Theodorou article on implementation details. And hey… it is based on my patch šŸ™‚

This is the house what Jack built

June 8, 2007

Today I realized what we (or may be just I) live in very strange world. Let me describe why.

I work now on problem of making GORM domain classes accessible in GWT client-side code. It is an interesting task by itself and I planĀ  to dedicateĀ  several separated posts to it but in general it is very simple. I want to define my server data objects in Groovy and be able to request them in from client-side code without coding too much.

TheĀ  solution is almost trivial. GWT provides great idea of generators which can create Java code to be integrated in to compilation of client-side JavaScript, so all what I need is to implement generator, which read groovy classes and generate all additional Java code I need. It is not too compilcated especially with Groovy in your hands.

What I realized debugging my code is how many different compilers, generators and even instrumenters involved in run of my one single test.

  1. Javac. I use it to compile Java part of my generator and the test to be run by JUnit.
  2. Groovyc. Most interesting part of my generator is written on Groovy
  3. GWT compiler from Java to JavaScript. It calls my generator and compile my test and generated Java code. If you curious, it contains built-in parser from Eclipse compiler
  4. BTW, compilation of unit tests in GWT involves generation of client-side part of the test. It’s a long story, which I will probably need to blog separately later. For now we just notice one more generation step.
  5. My generator use Groovy compiler to parse Groovy sources of domain classes. Main task for the generator isĀ  to create client-side twins for domain classes and make them serializable.
  6. Of course, serialization may not happen for free. Fortunately GWT provide default generator, which takes care for generation such code for java source, generated by me.
  7. Again, just for record we should notice that my generator not only written on Groovy but also depends on Groovy runtime, which does some code instrumentation in magical GroovyClassLoader.
  8. There is one more thing, which I am afraid to speak about. GORM uses Hibernate and Spring. How many code generation and instrumentation used inside? God knows.
  9. I know only that even GORM iteself uses some to access Hibernate and Spring.

That’t it. But something is wrong in this world, isn’t it?

Joint compilation of Groovy and Java – I

June 5, 2007

The first thing I’ve learned about Groovy was that you have to compile it separately from Java. OK, it is understandable because the languages are different.

But the next news was even worse. There is no way to compile it correctly if there are dependencies between Groovy and Java code. Again, of course we are software engineers, everything is possible(c) and there is a such possibility but…

Let me give you a sample. Imagine we have

  • Java interface JInterface
  • Groovy class GClass implementing JInterface
  • Java class JClass, which has to create instance of GClass (probably not thinking too much is it Groovy or Java class) and use it as instance of JInterface

I believeĀ  everybody will agree that such design may be very logical in some situations. But how can we compile this code? Well, we do it in three steps of ant script

  • javac for JInterface
  • groovyc for GClass
  • javac for JClass

And here we are. Our problem resolved. May be the solution is not so elegant (carefully written ant script instead of IDE compilation) but it works. And it is what Groovy coders do every day.

But does the solution above really work? No, unfortunately it doesn’t!

Imagine that by some reasons JInterface has to know about GClass. We can argue long hours is it good design or bad one, so let just think it has to. Now we have circular dependencies between Groovy and Java code. To compile Java we need to compile Groovy first but to compile Groovy we need to compile Groovy. Ooops! We have dead lock.

Obviously, it is not new problem. Have a look on issue The problem is nobody knows how to solve it.

Again, we can refactor our design. Probably introduce some additional class. May be add additional step to our carefully written ant script and finally being able to compile our simple code. But does it make us more productive? I am not sure.

Fortunately I have some good news. There is a solution for joint compilation of Groovy and Java. Some nice trick was invented by guys from JetBrains And I can say even more – the’ve submitted patch, which probably will be accepted before Groovy 1.1 Beta 2 is out.

But I will describe this story tomorrow. Stay tuned šŸ™‚

A groovy use case

June 5, 2007

Luc Dewavrin recently discovered Springā€™s ability to declare beans that are script-based. He describes why this is great and helpful to to speed-up development. Sample declarations and scripts are also provided.

The article ends with interesting opinion “…, I like both Groovy and JRuby but now tend to prefer Groovy because it leverages my knowledge of Java API. With Ruby i spend too much time finding the reference web site how to achieve things that i do almost naturally in Java. OTH, Ruby has its core API use closures. Closures are tightly integrated and tend to favor loose coupling.”

Read full story…