groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: How does Groovy decide to coerce a GString to a String at method dispatch?
Date Tue, 22 Aug 2017 20:34:56 GMT
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