[
https://issues.apache.org/jira/browse/GROOVY-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18045060#comment-18045060
]
Eric Milles commented on GROOVY-11817:
--------------------------------------
{code:groovy}
@CompileStatic(extensions='com.example.DynamicFinderTypeCheckingExtension')
void test() {
def books = Book.findByName("Joe")
def firstBook = book[0]
}
{code}
This fails because the makeDynamic call within the type checking extension
affects the entire method. The normal path to book[0] is to fall through to
BinaryExpressionHelper#evaluateBinaryExpression then into
StaticTypesCallSiteWriter#makeSingleArgumentCall. The dynamic resolution
causes it to go to IndyCallSiteWriter#makeSingleArgumentCall instead which just
throws.
If you isolate the dynamic stuff to its own method, the impacy of dynamic
resolution is minimized.
> Various CompileStatic issues when switching to invokedynamic
> ------------------------------------------------------------
>
> Key: GROOVY-11817
> URL: https://issues.apache.org/jira/browse/GROOVY-11817
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.29
> Environment: mac os
> jdk 17
> Reporter: James Daugherty
> Priority: Major
>
> I'm trying to switch a rather large Grails 7 project to invoke dynamic, and
> when enabling indy options, I'm seeing compile issues when CompileStatic &
> invokedynamic are used. Some of these issues are seen when a compile static
> extension is used, but they do work when indy is disabled.
>
> I generated a basic Grails application & created reproducers at this GitHub
> repo: [https://github.com/jdaugherty/groovy-grails-compile-static-issues]
> Each reproducer has it's own branch, so please ignore the code at the root of
> main other than the README.md file.
>
> At a high level, here are the issues:
> # Where books is a list of domain objects, calling books[0] errors
> # A second example is provided similar to #1, but after calling the sort()
> call and using `[0]` to get the result
> # a long multiplication issue exists where you can't do `holder.created *
> 1000L`, where created is a property that returns a Long
> # this may be related, but a similar long addition issue exists
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
