groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Bayer <andrew.ba...@gmail.com>
Subject Re: How does Groovy decide to coerce a GString to a String at method dispatch?
Date Tue, 22 Aug 2017 20:44:41 GMT
I'll answer in more detail later, but it's a LinkedHashMap.get that's being
called.

A.

On Tue, Aug 22, 2017 at 4:34 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:

> On 22.08.2017 00:53, Andrew Bayer wrote:
>
>> Hey all -
>>
>> I'm working on an issue in Jenkins' Groovy sandboxing logic -
>> https://issues.jenkins-ci.org/browse/JENKINS-46327. The problem is that
>> 'map."some${variable}"' seems to be acting as if the GStringImpl was the
>> key, rather than the String it should coerce to. I've got a feeling this is
>> due to a flaw in our sandbox's method dispatch code somewhere, so I'm
>> trying to figure out how Groovy is deciding to coerce normally. And I can't
>> tell where that would be. =) Anyone got any pointers?
>>
>
> it is legal to call get(String) with a String, but the transformation
> happens during the method call by the runtime. Method dispatch in the meta
> class is deciding about what method is to be taken. It is different for
> static compilation of course.
>
> Now if you have a list of all the get-methods that are available I can
> easily tell you which method will be called and why. So for example if you
> have get(String), get(Object) and get(CharSequence) a call to that method
> with a GString will call the CharSequence method, because that is an
> interface GString is implementing. If that methods would be not there it
> would have been get(String), because String is seen as more near to GString
> than Object for the runtime. Obviously this is not following strictly the
> class hierarchy
>
> bye Jochen
>
>

Mime
View raw message