[ 
https://issues.apache.org/jira/browse/GROOVY-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17800920#comment-17800920
 ] 

Eric Milles commented on GROOVY-11258:
--------------------------------------

I believe the rule that covers this is in section 
[15.12.2.5|https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5]:
{quote}A type S is more specific than a type T for any expression if S <: T 
(ยง4.10).
{quote}
That says to me that {{ThrowingExtractor}} is more specific since it extends 
{{{}Function{}}}.

This appears to be checked in the eclipse compiler for java (ecj) by this: 
[https://github.com/eclipse-jdt/eclipse.jdt.core/blob/7d2442b37130c73f1ffe174d2bb1ead95159c69b/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/lookup/InferenceContext18.java#L871]

> AssertJ collection mapping is badly supported
> ---------------------------------------------
>
>                 Key: GROOVY-11258
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11258
>             Project: Groovy
>          Issue Type: Bug
>          Components: Static Type Checker
>    Affects Versions: 4.0.17
>            Reporter: Jan Hackel
>            Assignee: Eric Milles
>            Priority: Major
>
> The following code will fail with the message 
> {noformat}
> [Static type checking] - No such property: x for class: java.lang.Object
>  @ line 8, column 13.
>          .map{ it.x }
>                ^
> {noformat}
> {code:groovy}
> @groovy.transform.CompileStatic
> class AssertJCollectionMappingTest {
>   @org.junit.jupiter.api.Test
>   void mapping() {
>     def texts = somePojos()
>     org.assertj.core.api.Assertions.assertThat(texts)
>       .map{ it.x }
>       .containsExactlyInAnyOrderElementsOf(['a', 'b'])
>   }
>   private static Collection<Pojo> somePojos() {
>     return [new Pojo(x: 'a'), new Pojo(x: 'b')]
>   }
>   static class Pojo {
>     String x
>   }
> }
> {code}
> Changing the line  to  
> {noformat}
> .map({ it.x } as Function<Pojo, String>) 
> {noformat}
> makes it compile but it is clumsy for more complicated types.
> It would be nice if Groovy was able to resolve the types without hints.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to