Some plan to write additional unit tests for the class library need GraalVM Reachability Metadata

[linghengqian]

• This warehouse is my personal temporary warehouse so that I can record the dynamics of a series of issues in time. All unit test designs should be submitted to https://github.com/oracle/graalvm-reachability-metadata as much as possible.

• [ ] org.apache.shardingsphere:shardingsphere-proxy-bootstrap:5.2.1, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] org.apache.shardingsphere:shardingsphere-jdbc-core:5.2.1, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] com.github.luben:zstd-jni:1.5.2, at https://github.com/luben/zstd-jni/issues/115 .

• [x] io.jsonwebtoken:jjwt-jackson:0.11.5, at https://github.com/jwtk/jjwt/issues/637 .

• [x] io.jsonwebtoken:jjwt-gson:0.11.5, at https://github.com/jwtk/jjwt/issues/637 .

• [x] io.jsonwebtoken:jjwt-orgjson:0.11.5, at https://github.com/jwtk/jjwt/issues/637 .

• [ ] org.apache.skywalking:java-agent:8.13.0, at https://github.com/apache/skywalking/discussions/7640 .

• [x] org.ehcache:ehcache:3.10.8, at https://github.com/ehcache/ehcache3/issues/2992 .

• [x] io.vertx:vertx-core:4.3.5 ,at https://github.com/netty/netty/issues/11369 .

• [x] org.apache.groovy:groovy:4.0.6, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] com.hazelcast:hazelcast:5.2.1, at https://github.com/oracle/graalvm-reachability-metadata/issues/117 .

• [ ] org.openjdk.nashorn:nashorn-core:15.4, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] org.graalvm.js:js:22.3.0, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] com.baomidou:dynamic-datasource-spring-boot-starter:3.6.0, at https://github.com/baomidou/dynamic-datasource-spring-boot-starter/issues/465 .

• [x] org.apache.curator:curator-framework:5.4.0, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] org.apache.curator:curator-client:5.4.0, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] org.apache.curator:curator-recipes:5.4.0, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] io.etcd:jetcd-core:0.7.5, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] com.google.protobuf:protobuf-java-util:3.21.12, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] org.opengauss:opengauss-jdbc:3.1.0, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] javax.cache:cache-api, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] org.apache.shardingsphere.elasticjob:elasticjob-lite-core:3.0.2, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] com.github.ben-manes.caffeine:caffeine:3.1.2, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] com.alibaba:transmittable-thread-local:2.14.2, at https://github.com/apache/shardingsphere/issues/21347 .

• [x] org.apache.commons:commons-dbcp2:2.9.0, at https://github.com/apache/shardingsphere/issues/21347 .

• [ ] org.apache.shardingsphere:shardingsphere-db-protocol-core:5.3.1, at https://github.com/apache/shardingsphere/issues/21347 .

• [ ] org.apache.shardingsphere:shardingsphere-mysql-protocol:5.3.1, at https://github.com/apache/shardingsphere/issues/21347 .

• [ ] org.apache.shardingsphere:shardingsphere-postgresql-protocol:5.3.1, at https://github.com/apache/shardingsphere/issues/21347 .

• [ ] org.apache.shardingsphere:shardingsphere-opengauss-protocol:5.3.1, at https://github.com/apache/shardingsphere/issues/21347 .

[linghengqian]

• Waiting for me to confirm the viability of the groovy shell.
• https://blogs.apache.org/groovy/entry/working-with-sql-databases-with
• https://blogs.apache.org/groovy/entry/classifying-iris-flowers-with-deep
• https://blogs.apache.org/groovy/entry/parsing-json-with-groovy
• https://melix.github.io/blog/2019/03/simple-http-server-graal.html
• update: refer to

  <buildArgs>
  <arg>--initialize-at-run-time=groovy.grape.GrapeIvy</arg>
  <arg>--initialize-at-build-time</arg>
  </buildArgs>

• https://github.com/linghengqian/graalvm-trace-metadata-smoketest/commit/5baf4282fbcb2503792ed4768082e81257b3fe45 It shows that it is a stupid thing to try to directly generate GraalVM accessibility metadata for Groovy

[linghengqian]

• The sample submission process is as follows

  ./gradlew scaffold --coordinates io.jsonwebtoken:jjwt-jackson:0.11.5
  ./gradlew :spotlessApply
  ./gradlew clean test -Pcoordinates=io.jsonwebtoken:jjwt-jackson:0.11.5

[linghengqian]

• Considering that libraries like vertx-core need more unit tests, I have to go to the main branch of vertx-core for testing. Modify pom.xml, native/access-filter.json, native/caller-filter.json and native/user-code-filter.json, there are the following steps.

  mkdir -p src/main/resources/META-INF/native-image/io.vertx/vertx-core
  mvn clean test -Pnative -Dagent=true -Dmaven.test.failure.ignore=true -Djacoco.skip=true
  native-image-configure generate-conditional --user-code-filter=native/user-code-filter.json --input-dir=target/native/agent-output/test/session-1372021-20221119T230740Z --output-dir=src/main/resources/META-INF/native-image/io.vertx/vertx-core

• Retrieved from https://github.com/brettwooldridge/HikariCP/pull/1959.
• After the merge https://github.com/graalvm/native-build-tools/pull/343 , the process should not be so cumbersome.
• 
• update: All the generated GRMs are test-like, which disappoints me so much. I still have to write the test code myself.

[linghengqian]

• I plan to additionally handle https://github.com/oracle/graalvm-reachability-metadata/issues/32 .

[linghengqian]

• With truffle, I was able to single test nativeTest under my single test in a heterogeneous language such as javascript. I can even imagine adding spi to a ShardingSphere's actualdatanode to execute a js segment on an implementation so that it runs nativeTest. This is hard coupled to the graalvm sdk's maven dependency. 🌝 But I couldn't get through GroovyShell-related unit tests using truffle's espresso run, which picocli nearly did with its pr a few years ago. The result is a straightforward disregard of groovyshell's operations under graalvm native images 🤔. Refer to https://github.com/oracle/graal/issues/5522 .

• With truffle, other than jvm languages (obviously I'm talking about both java and groovy🌿), graalvm native image behaves just fine... Whether it's javascript, python, or ruby. So abstract.

• No one in groovy seems to have touched truffle, @virtualdogbert discusses some very old stuff (like micronant playing in espresso before 100% jdk tck pass phase). @Alfonso Peterssen successfully tested on internal systems last year host java interworks with guest groovy in the espresso api, but context#eval cannot be used in current espresso at all. graalvm native image also doesn't seem to have the unknown option of --language:groovy. Refer to https://groovy-community.slack.com/archives/C2NEFCM55/p1670101822262799?thread_ts=1670101822.262799&cid=C2NEFCM55 and https://graalvm.slack.com/archives/CPSD12R71/p1627671413006000?thread_ts=1627671413.006000&cid=CPSD12R71 .

• Every time I saw the key point of the issue, an oracle internal tracking number (GR-xxxxx👉🌿) popped up. I wasn't sure how I could change the single test in shardingsphere to look like nativeTest pass. espresso's roadmap on groovy was a bit of a collaboration with the groovy community, but the biggest intersection I saw over the next year was a new project under graalvm moving from maven to gradle. 🙊

• When I played with org.graalvm.truffle:truffle-api:22.3.0, I thought that ASF did not limit the use of UPL LICENSE components in binary at https://www.apache.org/legal/resolved.html, but I seem to be from Haven't seen a project that actually has this type of component...? 👀

[linghengqian]

• Tagging https://twitter.com/debugagent/status/1580914150234271744?s=20&t=C6eUj1p9QVVY89dWa-VdJw . I may in the future create a lite version for Apache ShardingSphere Agent or Apache Skywalking Java Agent to be able to use when building GraalVM Native Image.
• On a more extended social platform, two GraalVM Committers clarified this.

Yes, we're also looking into agent support. Agents that manipulate bytecode should be easy to support as NI operates on bytecode. Other agents may be harder, but not impossible to support. vojjovmay have more details.

And don't worry, I know you're supportive! I'd just like to make sure the community isn't misinformed: just because NI doesn't support something today doesn't mean it can't in the future.

There's still plenty of work ahead of us. I would say that JVMTI agents are unlikely in the near future. Also, it is questionable how much of the JVMTI would make sense in the case of Native Image as there are significant differences in behavior (e.g., class loading).

For Java agents, they should work now as long as you don't modify the code executed at build time (e.g., JDK and the Native Image itself) in ways that would not work on the machine that does the image build.

If we guard generated code that is executed at build time with ImageInfo.inImageRuntimeCode() all should work. Happy to help with concrete cases over our slack channel.

[linghengqian]

• Most work continues at https://github.com/apache/shardingsphere/issues/29052 .