Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
Now that we provide a list of alternatives in case a method could not be found, we should maybe also think about diagnose class duplication problems there. A common thing would be that:
class A { static foo(GroovyConfig){} }
Is written in Java and loaded by a different loader than used for the runtime, which tries to execute this
A.foo(new GroovyConfig())
This can fail if the GroovyConfig loaded through class A is a different one than the GroovyConfig loaded in the calling script. This can happen for example if two RootLoader are used or other comparable loaders are involved. So I suggest that in this case we look at all methods of A that fit by name and number of arguments (including vargs) and then make a check to see if the argument class name or one of its parents is equal to the parameter class name. If that is the case, but the loaders are different, then a class duplication error is involved.
This kind of error can give a big headache to newcomers and diagnosing them on the list is usually more guessing than knowing. Additionally it is the kind of error that is not easily reproducible, since a simple script would naturally have a different class loader setup.
So I think this improvement could help in some cases tremendously.