[
https://issues.apache.org/jira/browse/GROOVY-11105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734303#comment-17734303
]
Eric Milles edited comment on GROOVY-11105 at 6/19/23 4:21 PM:
---------------------------------------------------------------
For the most part, dynamic groovy (default compiler mode) will write
{{invokedynamic}} instructions for method invocations. I updated your script
to use static compilation, which will look up the methods you discuss and write
{{invokevirtual}} instructions.
It is quite a major effort for the compiler to process the target platform
specification (aka {{ct.sym}}). Is there an api for doing this that we
could/should leverage?
was (Author: emilles):
For the most part, dynamic groovy (default compiler mode) will write
{{invokedynamic}} instructions for method invocations. I updated your script
to use static compilation, which will look up the methods you discuss and write
{{invokevirtual}} instructions.
It is quite a major effort for the compiler to process the target platform
specification (aka {{ct.sym}}). Is there an api for doing this that we
could/would leverage?
> Support jdk-release option for configuring the target JDK release when doing
> the compilation
> --------------------------------------------------------------------------------------------
>
> Key: GROOVY-11105
> URL: https://issues.apache.org/jira/browse/GROOVY-11105
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
> Reporter: Vladimir Sitnikov
> Priority: Major
>
> See the motivation and description in Kotlin:
> [https://youtrack.jetbrains.com/issue/KT-29974/Add-a-compiler-option-Xjdk-release-similar-to-javacs-release-to-control-the-target-JDK-version]
>
> Sample code that requires {{jdk-release}} option for a proper compilation,
> and it could not be solved with "target bytecode version" alone.
> {code:java}
> @groovy.transform.CompileStatic test() {
> def bb = java.nio.ByteBuffer.wrap(new byte[8])
> // it should compile to invokevirtual Buffer.flip()Ljava.nio.Buffer;
> // when compiling for Java 1.8 since Java 1.8 does not have ByteBuffer
> flip() override in ByteBuffer
> // However, if the build uses JDK17 for execution, then it contains
> ByteBuffer flip() override,
> // and Groovy would compile it to invokevirtual
> ByteBuffer.flip()Ljava.nio.ByteBuffer
> // which would fail to execute in Java 1.8
> bb.flip()
> }
> test()
> {code}
> See https://www.morling.dev/blog/bytebuffer-and-the-dreaded-nosuchmethoderror/
> See https://stackoverflow.com/a/61267496/1261287
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
