How does Groovy decide to coerce a GString to a String at method dispatch?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How does Groovy decide to coerce a GString to a String at method dispatch?

Andrew Bayer
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?

A.
Reply | Threaded
Open this post in threaded view
|

Re: How does Groovy decide to coerce a GString to a String at method dispatch?

Jochen Theodorou
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

Reply | Threaded
Open this post in threaded view
|

Re: How does Groovy decide to coerce a GString to a String at method dispatch?

Andrew Bayer
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 <[hidden email]> wrote:
On <a href="tel:22.08.2017%2000" value="+12208201700" target="_blank">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