Migrate to Groovy 1.6

[GoogleCodeExporter]

For migrating to Groovy 1.6, we have to:

1. rewrite all metaclasses in Java to bypass a bug in Groovy 1.6
2. use the default implements of Groovy 1.6 for POJO per-instance meta class
3. jarjar does not work on the codes compiled by Groovy 1.6, so our codes
should depend on the jarjarified jar files with the new package names,
instead of the original jar files
4. fix any bugs which make the tests failed

Original issue reported on code.google.com by JohnnyJianHY on 19 Mar 2009 at 10:19

[GoogleCodeExporter]

Issue 66 has been merged into this issue.

Original comment by JohnnyJianHY on 19 Mar 2009 at 10:19

[GoogleCodeExporter]

Original comment by julien.g...@gmail.com on 20 Mar 2009 at 6:49

• Changed state: Accepted

[GoogleCodeExporter]

Oh, it is unbelievable that jarjar works on Groovy 1.6! It can even change

    private static Class $get$$class$net$sf$cglib$proxy$MethodInterceptor()
    {
        return $class$net$sf$cglib$proxy$MethodInterceptor == null &&
($class$net$sf$cglib$proxy$MethodInterceptor =
_mthclass$("net.sf.cglib.proxy.MethodInterceptor")) == null ?
$class$net$sf$cglib$proxy$MethodInterceptor :
$class$net$sf$cglib$proxy$MethodInterceptor;
    }

into

    private static Class $get$$class$net$sf$cglib$proxy$MethodInterceptor()
    {
        return $class$net$sf$cglib$proxy$MethodInterceptor == null &&
($class$net$sf$cglib$proxy$MethodInterceptor =
_mthclass$("org.gmock.internal.cglib.proxy.MethodInterceptor")) == null ?
$class$net$sf$cglib$proxy$MethodInterceptor :
$class$net$sf$cglib$proxy$MethodInterceptor;
    }

and the _mthclass$() method looks like:

    static Class _mthclass$(String s)
    {
        try
        {
            return Class.forName(s);
        }
        catch(ClassNotFoundException classnotfoundexception)
        {
            throw new NoClassDefFoundError(classnotfoundexception.getMessage());
        }
    }

It is amazing. I am curious about how jarjar can do that, and I think I will 
have a
look at its source code to figure it out.

Original comment by JohnnyJianHY on 22 Mar 2009 at 5:14

[GoogleCodeExporter]

That's ggod for us.

Original comment by julien.g...@gmail.com on 22 Mar 2009 at 8:37

[GoogleCodeExporter]

The following test is failed:

    void testMockConstructorAndCallInAnExternalClass() {
        mock(GroovyLoader, constructor()).load('a').returns('b')
        assertEquals 'a', GroovyClass.createGroovyLoader().load('a')
        play {
            assertEquals 'b', GroovyClass.createGroovyLoader().load('a')
        }
    }

And GroovyClass is:

package org.gmock.utils

class GroovyClass {

    static createGroovyLoader() {
        new GroovyLoader()
    }

}

This may be due to a bug of Groovy 1.6.0. I am still looking for a way to 
bypass it.

Original comment by JohnnyJianHY on 23 Mar 2009 at 6:43

[GoogleCodeExporter]

I have added some tests to test call sites, and there turns out to be 7 failed 
tests.
I have successfully bypassed one of the bugs of call sites and reduced the 
number of
failed tests to 5 (all the failed tests are commented in the trunk, you can 
check out
the groovy 1.6 branch to try these tests). However, I have to say that we 
cannot get
the remaining 5 tests passed, unless to change the code of groovy. That means 
we HAVE
to wait for groovy 1.6.1 :(

Original comment by JohnnyJianHY on 24 Mar 2009 at 2:09

[GoogleCodeExporter]

I had a look at those tests and appreciate your effort to bypass them. I've 
also noticed your conversation on the 
groovy user list.

We could still consider releasing gmock 0.8.0 and mark it as experimental... I 
wonder if MockFor is suffering 
from similar issue.

Original comment by julien.g...@gmail.com on 25 Mar 2009 at 7:25

[GoogleCodeExporter]

I am creating patches for all those bugs of call sites for groovy, and I think 
our
tests will pass with these patches.

There are some special code for MockFor in call sites, for example:

MetaClass metaClassToInvoke = metaClass;
// if it is MockProxyMetaClass, use the one from the registry and not the 
cached one
// as the mock/stub infrastructure replaces metaClass at runtime in the context 
of
use {..}
if(metaClass instanceof MockProxyMetaClass) {
    metaClassToInvoke =
GroovySystem.getMetaClassRegistry().getMetaClass(receiver.getClass());
}
return metaClassToInvoke.invokeMethod(receiver, name, args);

And of course this is not a good approach.

Original comment by JohnnyJianHY on 25 Mar 2009 at 7:44

[GoogleCodeExporter]

You are right that's it's not the right approach and sound more like a hack to 
me.

I was thinking that we might actually benefit from this hack in with the 
MockProxyMetaClass. I thinking that our 
ClassProxyMetaClass could inherit from this MPMC directly. 

I've just give it a try without much luck though. For some reason the 
invokeConstructor is call directly on the 
MPMC and not our CPMC.

Original comment by julien.g...@gmail.com on 25 Mar 2009 at 8:04

[GoogleCodeExporter]

Because there is no such hack in the call site of constructor :)

Original comment by JohnnyJianHY on 25 Mar 2009 at 8:10

[GoogleCodeExporter]

All tests are passed with my patches :)

Original comment by JohnnyJianHY on 25 Mar 2009 at 8:51

[GoogleCodeExporter]

Congratulation! You rock ;). 

Now we need to push for Groovy 1.6.1.

Original comment by julien.g...@gmail.com on 25 Mar 2009 at 9:21

[GoogleCodeExporter]

Original comment by JohnnyJianHY on 9 Apr 2009 at 12:58

• Changed state: Fixed