Static imports and local method resolution fails when using implied property setter

What does Java here?

Java does what you might expect, outputting:
Harness.method1
Utility.method2

Just to clarify, this works if instead of:
method2(method1()).var1 = 8
one writes:
method2(method1()).setVar1(8)

I get the same error when I split Utility into Utility.java with method1(int) and UtilityG.groovy with method2(One). The error suggests that when trying the:
method2(method1()).var1 = 8
setter access, Groovy finds the local method1(), executes it, then looks for a method with the signature of method1(One) locally, and not finding it, looks for it in Utility.java. The One in the signature of the unfound method is what the local method1() returns. I.e., if the local method1() returns Two, Groovy looks for method1(Two), first locally then in Utility.java (and fails).

The output is:

Harness.method1
Exception in thread "main" groovy.lang.MissingMethodException: No signature of method: static Utility.method1() is applicable for argument types: (One) values: [One@f5db314]

due to the dynamic nature of Groovy we had to make some adjustments to how static imports work. In Java normally a method of Utility may be shadowed by the method declared in the current class. In Groovy we decided to not explicitly support what happens if a method is overloaded or exists in the imported class as well as the current.

So any behaviour you get there is undefined. The current implementation will use the method from Utility because we cannot tell at compile time what method will be called. In your special case we could tell, but once objects are involved the ability to tell will go to zero. So we could "fix" this here, but it will still break in more complex situations.

Interesting. So is the reason that the local method1 is executed AND THEN a method with the same name but with that derived signature is called due to the undefined nature of the call or due to something else?

I probably didn't explain well... We have to decide at compile time what the receiver for the method call will be. Here we have to decide for either the static method call on Utility or the virtual method call on Harness. For Java this is no problem, since Java is static typed and will use those types for method selection anyway. So for Java it is easy to pick a method here. For Groovy it is quite difficult. You can start with the fact that Harness may define such a method at runtime. That is almost impossible to completely implement. Also we do not use the static types, we normally use the runtime types to decide on the method. But the method selection does not take multiple receiver into account. So here the compiler decides, which leads to false results like here. If you have no method shadowing or overloading, there is no issue with the current implementation, which will simply take the Utility methods if the compiler thinks those methods are of use.

So what Groovy does is setting Utility as receiver, since you statically import a method from there, totally ignoring that there is another one in Harness. Now method1() is indeed no allowed method call for method1(int), but if it were method(Integer) then Groovy would have used null for the Integer and the call would have been valid.

The only "solution" I can offer is, that we let the compiler not compile this at all. Would you be satisfied with that?

Thanks for the explanation. What I'm confused about is that the Harness class's method1() does seem to get called first. And then method1(One) is looked for in Utility, since the error states "No signature of method: static Utility.method1() is applicable for argument types: (One) values: [One@f5db314]". I just thought that it was odd that method1(One) is being looked for when the XXXXX.var1 = 8 version of the setter is used and not when XXXXX.setVar1(8) is used. Does that make sense?

add code tags