[groovy-user] Ambiguous method overloading for method org.codehaus.groovy.runtime.MethodClosure#call.

18 views
Skip to first unread message

mcgarvey

unread,
Nov 14, 2013, 6:05:10 PM11/14/13
to us...@groovy.codehaus.org
We have a process that works fine for a time (months) and then seems to get
in a state where MethodClosure#call fails in strange ways, repeatedly, for
various invocations of groovy methods. The stack is below. Note that the
failing method is an internal one, not something we call directly. BTW, we
are running Groovy 1.7.4, which is certainly quite old.

Does anybody have a hunch what might cause this condition? Is there
anything we might do to trigger it? Is it fixed in a more current Groovy
version?
---------------------
Ambiguous method overloading for method
org.codehaus.groovy.runtime.MethodClosure#call.
Cannot resolve which method to invoke for [class java.lang.Integer] due to
overlapping prototypes between:
[class [Ljava.lang.Object;]
[class java.lang.Object]
groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method
org.codehaus.groovy.runtime.MethodClosure#call.
Cannot resolve which method to invoke for [class java.lang.Integer] due to
overlapping prototypes between:
[class [Ljava.lang.Object;]
[class java.lang.Object]
at
groovy.lang.MetaClassImpl.chooseMostSpecificParams(MetaClassImpl.java:2900)
at groovy.lang.MetaClassImpl.chooseMethodInternal(MetaClassImpl.java:2853)
at groovy.lang.MetaClassImpl.chooseMethod(MetaClassImpl.java:2794)
at
groovy.lang.MetaClassImpl.getNormalMethodWithCaching(MetaClassImpl.java:1229)
at groovy.lang.MetaClassImpl.getMethodWithCaching(MetaClassImpl.java:1135)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:904)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
at
groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1104)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1060)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
at
org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151)




--
View this message in context: http://groovy.329449.n5.nabble.com/Ambiguous-method-overloading-for-method-org-codehaus-groovy-runtime-MethodClosure-call-tp5717472.html
Sent from the groovy - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


Jochen Theodorou

unread,
Nov 15, 2013, 7:45:39 AM11/15/13
to us...@groovy.codehaus.org
Am 15.11.2013 00:05, schrieb mcgarvey:
> We have a process that works fine for a time (months) and then seems to get
> in a state where MethodClosure#call fails in strange ways, repeatedly, for
> various invocations of groovy methods. The stack is below. Note that the
> failing method is an internal one, not something we call directly. BTW, we
> are running Groovy 1.7.4, which is certainly quite old.
>
> Does anybody have a hunch what might cause this condition? Is there
> anything we might do to trigger it? Is it fixed in a more current Groovy
> version?
> ---------------------
> Ambiguous method overloading for method
> org.codehaus.groovy.runtime.MethodClosure#call.
> Cannot resolve which method to invoke for [class java.lang.Integer] due to
> overlapping prototypes between:
> [class [Ljava.lang.Object;]
> [class java.lang.Object]

those two are no overlapping prototypes at all. There have been changes
to method selection in the past... but if it fixes this issue here I
don't know - and they are not visible before Groovy 2.0...

I strongly suspect that in those months calls like that have been made
already - and successful too. Just tested... yes, normally it selects
the right method.

This is an extremely strange error you are observing here...actually
there was a very small fix in that area for 1.7.11... I doubt it has
really any impact though.

All in all I must confess I have not the slightest clue what is going on
in that case.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
Reply all
Reply to author
Forward
0 new messages