Graalvm native image cause with Groovy 4

[jonaskahn]

Bug Report

Which version of ShardingSphere did you use?

• 5.1.1

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

• ShardingSphere-JDBC

Expected behavior

• Can build native-image with graalvm

Since lib using Groovy 4, some api was remove in version 3. jar file can build to native-image

[linghengqian]

• I'm worried about the fact that even Groovy dropping to 3 won't fix this problem. Since the packaging of GraalVM Native Image is affected by other factors, Groovy is not the most important factor.

• Refer to Support Quarkus extension #12594 and [CALCITE-4882] Introduce new Lambda-based Metadata framework calcite#2603 (comment) .

• Another fact is that Spring brings AOT from Spring Native to Spring Framework 6.0.0, I don't think Groovy 4 will drop support for Native Image after the introduction of SpringBoot 3.0.0 ( refer to spring-boot-dependencies incompatibility with Groovy 4 spring-projects/spring-boot#30278 ), just to see which is faster Calcite or Groovy deal with. The bad truth is that all my previous attempts to package ShardingSphere JDBC into Spring Native have failed.

[linghengqian]

Do you mean IndyInterface. InvalidateSwitchPoints ()? Refer to oracle/graal#4492 .

[jonaskahn]

Oh, that's the point @linghengqian . Should I leave the issue to keep track with oracle

[linghengqian]

Oh, that's the point @linghengqian . Should I leave the issue to keep track with oracle

It looks like Graal's team is tracking this problem. So I'm personally not going to dive into the Groovy problem until the Calcite problem is solved.

[linghengqian]

It seems that compared to 4.0.1, Groovy 4.0.2 introduces additional bugs(maybe？👨‍🔧) that prevent smooth upgrades, see #17785 . I don't see additional information from the changelog, refer to http://groovy-lang.org/changelogs/changelog-4.0.2.html .

[jonaskahn]

@linghengqian Method IndyInterface. InvalidateSwitchPoints () only exist in Groovy 3 and removed in Groovy 4. I think Graalvm need time to adapt new change. But I will try Groovy 4.0.2 in my local to see can it resolved the problem

[linghengqian]

@linghengqian Method IndyInterface. InvalidateSwitchPoints () only exist in Groovy 3 and removed in Groovy 4. I think Graalvm need time to adapt new change. But I will try Groovy 4.0.2 in my local to see can it resolved the problem

IndyInterface.InvalidateSwitchPoints() being removed is expected behavior, I pointed out Classic bytecode generation removal at #15303 .

[linghengqian]

It seems that compared to 4.0.1, Groovy 4.0.2 introduces additional bugs(maybe？👨‍🔧) that prevent smooth upgrades, see #17785 . I don't see additional information from the changelog, refer to http://groovy-lang.org/changelogs/changelog-4.0.2.html .

Fixed by #17796 .

[linghengqian]

• In fact only one class needs to be processed, https://github.com/oracle/graal/blob/vm-ce-22.1.0/substratevm/src/com.oracle.svm.polyglot/src/com/oracle/svm/polyglot/groovy/GroovySubstitutions.java . But submitting a PR against it is a difficult problem for me due to my lack of further knowledge about Groovy Native. I made an additional comment on the GraalVM issue.

• @tuyendev Is it convenient for you to submit a relevant PR to Graal?

[linghengqian]

I've started a discussion on dropping Groovy 3 support on Graalvm's Slack community's Polygolt channel, and I welcome comments.

[jonaskahn]

@linghengqian Sorry for lately reply. I will continue checking on Monday next week. I’m currently in my days off 🌝, I will give you feedback as soon as posbile cause i dont have my PC now

[jonaskahn]

Tested and still failed.
I also don't have expericence with Groovy, so I think we need to waited Graalvm adapt the change .

[linghengqian]

Tested and still failed.
I also don't have expericence with Groovy, so I think we need to waited Graalvm adapt the change .

Perhaps you can do some of this in Groovy's main branch. If you're in Groovy slack group's Groovy channel.

If you are talking about GROOVY-10643, then indeed, it wasn't intended to "fix" the GraalVM issue per se. It was just a point of "arguably unintended" binary breakage on the Groovy side - where unintended means that existing compiled classes, e.g. a Grails plugin compiled with Groovy 3 could have technically extended the v7 IndyInterface overriding the invalidateSwitchPoints method. Mind you, it was deemed an internal class and was deprecated so we didn't keep it in place previously. As to whether that helps or makes no difference to the GraalVM issue, I'd have to dive into it a bit more to say.
I'd be keen to make Groovy 4 more Graal friendly regardless of this particular issue if you have any suggestions.

[linghengqian]

@tuyendev Cheers for the solution of the https://issues.apache.org/jira/projects/GROOVY/issues/GROOVY-10643 ! You can use Groovy's main branch experiment natively!

[linghengqian]

@tuyendev

• I don't think this problem has to wait until 4.0.3 is released, you can add the following fields to your project's conf/reflect-config.json to solve it. Refer to Groovy Slack Channel. Of course you need to install the master branch of ShardingSphere locally.

 {
   "name": "org.codehaus.groovy.runtime.dgm$53",
   "allDeclaredConstructors": true,
   "allPublicConstructors": true,
   "allDeclaredMethods": true,
   "allPublicMethods": true
 }

• I don't feel the need to put an incomplete graal configuration directly into the master branch of the shardingsphere at this stage.

• If the groovy's gral support is ok after configuration, turn off this issue? (Other dependent graal support is not part of this issue discussion)

[linghengqian]

I plan to close this issue in a PR, because my local verification is successful. If you still have problems, please reopen.

[linghengqian]

@tuyendev

• I don't think this problem has to wait until 4.0.3 is released, you can add the following fields to your project's conf/reflect-config.json to solve it. Refer to Groovy Slack Channel. Of course you need to install the master branch of ShardingSphere locally.

 {
   "name": "org.codehaus.groovy.runtime.dgm$53",
   "allDeclaredConstructors": true,
   "allPublicConstructors": true,
   "allDeclaredMethods": true,
   "allPublicMethods": true
 }

• I don't feel the need to put an incomplete graal configuration directly into the master branch of the shardingsphere at this stage.

• If the groovy's gral support is ok after configuration, turn off this issue? (Other dependent graal support is not part of this issue discussion)

For revision, this question must be upgraded to Groovy 4.0.3, cf. oracle/graal#4492 (comment) . The master branch of ShardingSphere has resolved this issue.