[
https://issues.apache.org/jira/browse/GROOVY-10544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-10544.
------------------------------
> Static compiler chooses superinterface return type
> --------------------------------------------------
>
> Key: GROOVY-10544
> URL: https://issues.apache.org/jira/browse/GROOVY-10544
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
> Affects Versions: 4.0.1
> Reporter: Christopher Smith
> Assignee: Eric Milles
> Priority: Major
> Fix For: 4.0.2
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> I am using Vavr 0.10, which has the following type relationship:
> {{Try<T> extends Value<T>}}
> {{Value}} defines the method {{<U> Value<U> map(Function<? super T, ? extends
> U> mapper)}}, which is narrowed in the interface definition for {{Try}} to
> return a {{Try<U>}}. When used in a functional pipeline, however, the STC
> infers {{Value<U>}} as the return type even when it knows that the previous
> value is a {{Try<T>}}, causing downstream type failures. Instead, it should
> infer that the return type is the more specific {{Try<U>}}.
> I am inspecting this intermediate inference in Groovy-Eclipse, but the CLI
> errors I'm getting are exactly consistent with the erroneous inference. I
> will try to create a minimal replication after getting the ticket ID.
> ---
> This feels like the same problem:
> {code}
> List<DeleteItemRequest> batch = createBatch() // from Amazon DynamoDB SDK 2
> Map<String, List<DeleteItemRequest>> requestsByTable =
> batch.stream().collect(toMap(DeleteItemRequest::tableName, List::of))
> {code}
> This results in the error
> {code}
> Groovy:Failed to find the expected method[tableName(java.lang.Object)] in the
> type[software.amazon.awssdk.services.dynamodb.model.DeleteItemRequest]
> {code}
> even though from the context it's clear that the type being submitted is
> {{DeleteItemRequest}}, and Groovy-Eclipse correctly identifies
> {{Stream<DeleteItemRequest>}}. Somehow the "inner generics context" of
> {{toMap}} isn't getting the information, which also accounts for the
> functional-pipeline glitch.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
