You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Eric Milles (Jira)" <ji...@apache.org> on 2021/10/11 17:18:00 UTC
[jira] [Resolved] (GROOVY-7468) type checker should use superclass
bound when expected by generics
[ https://issues.apache.org/jira/browse/GROOVY-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Milles resolved GROOVY-7468.
---------------------------------
Fix Version/s: 4.0.0-alpha-3
Resolution: Fixed
https://github.com/apache/groovy/commit/c5fd01adbfe3f97c1defd12a18bf2096f970ecff
See GROOVY-7106, GROOVY-7274, GROOVY-8909, GROOVY-9844
> type checker should use superclass bound when expected by generics
> ------------------------------------------------------------------
>
> Key: GROOVY-7468
> URL: https://issues.apache.org/jira/browse/GROOVY-7468
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
> Affects Versions: 2.4.3
> Reporter: Christopher Smith
> Assignee: Eric Milles
> Priority: Major
> Fix For: 4.0.0-alpha-3
>
>
> I believe this is a special case of a general problem with generics and the type checker.
> When I attempt to call a method {{doSomething(Map<String,Object> params)}} with a Groovy inline map, the type checker constructs the map's types as the immediate greatest-common-superclass of the values provided. For example, this map:
> {code}
> [ val1: 3, val2: 5 ]
> {code}
> is always considered to be a {{LinkedHashMap<String,Integer>}}, which can't be passed to the above method. In *some*, but not all, cases using an explicit {{as Map<String,Object>}} will work.
> In the circumstance where an inline map or other generic collection is assigned to a variable or used as a method parameter, the type checker should be able to relax the inferred generic type bound to match the expected bound.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)