[jira] [Resolved] (GROOVY-10047) STC infers Closure instead of SAM for method references

["Eric Milles (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Milles resolved GROOVY-10047.
----------------------------------
    Fix Version/s: 4.0.0-beta-1
       Resolution: Fixed

> STC infers Closure instead of SAM for method references
> -------------------------------------------------------
>
>                 Key: GROOVY-10047
>                 URL: https://issues.apache.org/jira/browse/GROOVY-10047
>             Project: Groovy
>          Issue Type: Bug
>          Components: Static Type Checker
>    Affects Versions: 3.0.8
>            Reporter: Christopher Smith
>            Assignee: Eric Milles
>            Priority: Major
>             Fix For: 4.0.0-beta-1
>
>
> I thought I had reported this earlier, but I couldn't find the duplicate.
> When using a very basic method reference, the STC is inferring {{Closure}} as the type instead of the proper functional interface. Explicitly specify {{as}} works, which I think might not have with the {{::}} syntax previously.
> In my particular case, I'm wrapping a {{List<DeleteItemRequest>}} (from the Amazon SDK 2 DynamoDB client) into a {{Map<String, List<DeleteItemRequest>>}} to feed to its batch API. The line is:
> {code:groovy}
> def requestItems = batch.stream().collect(toMap(DeleteItemRequest::tableName, List::of))
> {code}
> In contrast to GROOVY-9881, it seems the STC is correctly identifying the signature, at least, but it's inferring {{Closure}} where {{Function}} is expected:
> {code}
> /home/christopher/path/CleanupHandler.groovy: 50: [Static type checking] - Cannot call <T,K,U> java.util.stream.Collectors#toMap(java.util.function.Function <? super T, ? extends K>, java.util.function.Function <? super T, ? extends U>) with arguments [groovy.lang.Closure <java.lang.String>, groovy.lang.Closure <java.util.List>]
> {code}
> Adding an explicit {{as Function}} to each reference fixes the problem (though it is still using {{getMethodPointer}} instead of real method references).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)