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

Eric Milles commented on GROOVY-11746:
--------------------------------------

[~paulk]  Can you give your thoughts on this?

Given a type like this that implements List or Collection:
{code:groovy}
class Thing extends Tuple {
  def getAt(String name) {
    //...
  }
  @CompileStatic test() {
    getAt('foo')
  }
}
{code}

The old {{removeCovariantsAndInterfaceEquivalents}} would remove these three:
{code}
 
org.codehaus.groovy.transform.stc.ExtensionMethodNode@4bcc81a6[java.lang.Object 
getAt(java.lang.String) from java.lang.Object],
 org.codehaus.groovy.transform.stc.ExtensionMethodNode@3f9ed1f2[java.util.List 
getAt(java.lang.String) from java.util.Collection],
 org.codehaus.groovy.transform.stc.ExtensionMethodNode@78e4c3b1[T getAt(int) 
from java.lang.Iterable]
{code}

The return value:
{code}
 org.codehaus.groovy.ast.MethodNode@1486b7bc[java.lang.Object 
getAt(java.lang.String) from Thing],
 org.codehaus.groovy.transform.stc.ExtensionMethodNode@75759650[T 
getAt(java.lang.Number) from java.util.List],
 org.codehaus.groovy.transform.stc.ExtensionMethodNode@4bb5d877[T getAt(int) 
from java.util.List],
 org.codehaus.groovy.transform.stc.ExtensionMethodNode@2cfd6818[java.util.List 
getAt(java.util.Collection) from java.util.List],
 org.codehaus.groovy.transform.stc.ExtensionMethodNode@3931d90[java.util.List 
getAt(groovy.lang.Range) from java.util.List],
 org.codehaus.groovy.transform.stc.ExtensionMethodNode@5a0ddca4[java.util.List 
getAt(groovy.lang.EmptyRange) from java.util.List]
{code}

The new {{removeCovariantsAndInterfaceEquivalents}} for GROOVY-11341 and 
GROOVY-11746 drops "getAt(java.lang.String) from Thing" and keeps 
"getAt(java.lang.String) from java.util.Collection" because the List return 
type is covariant with Object.

I'm not sure if the DGM Collection#getAt(String) should be kept or if the 
declared method Thing#getAt(String) should be kept or both.

> Specific method call failing static compile in Groovy5 but not Groovy4
> ----------------------------------------------------------------------
>
>                 Key: GROOVY-11746
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11746
>             Project: Groovy
>          Issue Type: Bug
>          Components: Static compilation
>    Affects Versions: 5.0.0
>            Reporter: Aleks Tamarkin
>            Assignee: Eric Milles
>            Priority: Major
>             Fix For: 5.0.1
>
>
> The following code works on Groovy4 but not Groovy5
> {code:java}
> @Grab('org.apache.pdfbox:pdfbox:3.0.5') 
> import org.apache.pdfbox.pdmodel.PDPageContentStream 
> import org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject 
> import groovy.transform.CompileStatic 
> @CompileStatic 
> def doesNotCompile(PDPageContentStream stream, PDImageXObject pdImage, float 
> x, float y, float width, float height) { 
>   stream.drawImage(pdImage, x, y, width, height) 
> }{code}
> It fails with the errorĀ 
> {code:java}
> [Static type checking] - Cannot find matching method 
> org.apache.pdfbox.pdmodel.PDPageContentStream#drawImage(org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject,
>  float, float, float, float). Please check if the declared type is correct 
> and if the method exists.
>   at line: 9, column: 5 {code}
> I cannot reproduce this specific issue outside Apache PdfBox



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

Reply via email to