Method Caching within MethodMissiing is not working

My understanding is that the behavior you are seeing is correct. First time you invoke playTennis(), it adds playTennis() on the metaClass of PersonAgain class, but this change won't be visible on the instance that you have already created. Any more instances that you create after this point will see the playTennis() on the PersonAgain's metaClass.

If you want even instance "jack" to see the metaClass change that you have made, then you will have to set its metaClass to null

So, if you do:

class PersonAgain
{
    def work() { "working..." }
    def plays = ['Tennis', 'VolleyBall', 'BasketBall']
    def methodMissing(String name, args)
    {
        System.out.println "methodMissing called for $name"
        def methodInList = plays.find {it == name.split('play')[1] }
        if(methodInList)
        {
            def impl = { Object[] vargs ->
                return "playing ${name.split('play')[1]}..."
            }
            
            PersonAgain.metaClass."$name" = impl
            return impl(args)
        }
        else
        {
            throw new MissingMethodException(name, PersonAgain.class, args)
        }
    }
    static { PersonAgain.metaClass }
}

jack = new PersonAgain()
println jack.playTennis() // call goes to methodMissing 
anotherJack = new PersonAgain()
println anotherJack.playTennis() // call does not go to methodMissing, but to the closure that got mapped to method name playTennis
jack.metaClass = null // refresh "jack"'s metaClass too. 
println jack.playTennis() // now it also does not go to methodMissing, but to the closure mapped

Roshan, I don't agree. IF the code works without call site caching, then it must work with call site caching too, or it is a bug. The call site should have recognized the change. Obviously call sites don't recognize changes in EMC

I first doubted the call-site caching too but then I changed my mind thinking that it might be related to per-instance metaClass and it not picking up the changes made to the class level metaClass.

So, just for me to understand it better - the call site caching comes into picture when you have the same call (at the same place) being executed multiple times, right? For example, if a loop executes a statement like "println jack.playTennis()" multiple times in its iterations, we will have call-site being created in the first call and next time onwards the cached one will be used, right?

I mean in the original example shared in the JIRA, where do you see the use of call-site caching? The below two calls will have their different call sites created.
println jack.playTennis()
println jack.playTennis()

Is my understanding of call site caching wrong? Or, can you please tell me why you are doubting call-site caching as the culprit in this example?

Thanks.

Note: For the example given, call site array looks like

- meaning that both "println jack.playTennis()" are getting their own call-sites and hence no caching is supposed to happen between them.

sorry Roshan, seems like I looked at the wrong program. Of course yours does behave as it should and without error. I should have looked at the one James gave. And here we have a difference between 1.5.7 and 1.6.0. In 1.6.0 methodMissing is called twice, in 1.5.7 not. IMHO the reason for that is, that static

ensures in 1.5.7 that any new instance that is created will have a EMC as default MetaClass You can easily confirm that by adding a "println metaClass" in methodMissing first thing. That means all PersonAgain instances will by default share one EMC. Now it seems that in 1.6 this was changed. In fact the PersonAgain.metaClass."$name"=impl will have no affect as long as no other instance is created or the current metaClass is resetted.

I see that as an regression bug. But yes, it might not have anything to do with call site caching... sorry for the false trace.

it is not a problem, Jochen. We all misread at times.

Thanks for explaining the purpose of "static

" in the JIRA example. I couldn't understand the purpose of it on my own.