Provide built-in GraalVM Reachability Metadata and introduce a separate nativeTest in CI

[linghengqian]

Feature Request

For English only, other languages will not accept.

Please pay attention on issues you submitted, because we maybe need more details.
If no response anymore and we cannot make decision by current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Is your feature request related to a problem?

• Linked to Add support for org.apache.shardingsphere.elasticjob:elasticjob-lite-core:3.0.2 oracle/graalvm-reachability-metadata#206 and Make ShardingSphere Proxy in GraalVM Native Image form available shardingsphere#21347 .

Describe the feature you would like.

• For the GraalVM Reachability Metadata required by ElasticJob Lite Core, multiple PRs have been completed at https://github.com/oracle/graalvm-reachability-metadata .

  • Add support for org.apache.commons:commons-dbcp2:2.9.0 oracle/graalvm-reachability-metadata#380
  • Add support for org.apache.curator:curator-client:5.5.0 oracle/graalvm-reachability-metadata#381
  • Add support for org.apache.curator:curator-framework:5.5.0 oracle/graalvm-reachability-metadata#383
  • Add support for org.apache.shardingsphere.elasticjob:elasticjob-lite-core:3.0.3 oracle/graalvm-reachability-metadata#390

• But the RSS of https://github.com/oracle/graalvm-reachability-metadata is really too high. I have been waiting on the front PR for nearly a year to seek reviews from the GraalVM Team, and after one year Completed reconstruction again and again in time. I think we should solve this problem inside ElasticJob now.

• In addition, the investigation results at Complete nativeTest of SCRIPT Job and TracingConfiguration in ElatsicJob linghengqian/graalvm-trace-metadata-smoketest#4 also show that SCRIPT Job and TracingConfiguration cannot be used under Native Image. Considering the extremely high RSS of https://github.com/oracle/graalvm-reachability-metadata , I don't think a similar issue would get much help on the central repository side of graalvm-reachability-metadata.

• The target of this issue is

  • Migrate from Junit 4 to Junit Platform to introduce GraalVM Native Build Tools into the project.
  • Updated most dependencies to versions matching https://github.com/oracle/graalvm-reachability-metadata.
  • Introducing a new submodule that provides some JSON file containing the GraalVM Reachability Metadata of ElasticJob itself and third-party dependencies that have not yet been merged, and writes some core unit tests. This is to avoid a series of limitations of Mockito when used under Native Image.
  • Fixes the issue where SCRIPT Job and TracingConfiguration cannot be used under GraalVM Native Image. Refer to java.nio.file.Files#setPosixFilePermissions cannot be used under Native Image oracle/graal#7390 .
  • Fixes the issue where the Spring Bean injected by ElasticJob Lite's Spring Boot Starter under GraalVM Native Image is null. See Fixes the issue that OneOffJobBootstrap cannot be used under ElasticJob Spring Boot Starter #2422 .

[linghengqian]

• I'm working on this issue.

[zjx990]

我们在做这种自动化测试的时候，可以引入一个场景么，就是一个客户端或者准确的说一个真正执行作业的server，它的极限。
例如: 这台实例是900个作业的执行节点也就是真正的server。这900个作业都是一秒调度一次，这台server什么时候会到它的承受极限。
我的想法: 我的想法是关注它的cpu信息，因为作业的调度是有周期的，它的cpu波动也会周期，作业占用的内存我先忽略不计，如果它的cpu峰值达到70%，那么我就认为这台实例的极限就是900.

[linghengqian]

• @zjx990 This is a bit hard for me to understand how to handle. After all, the Github Actions device only has 8GB of memory, and Github Actions only has AMD64 devices. On ARM64 we will need to perform instruction set simulation, which may lead to inconsistent test results between AMD64 and ARM64.

• If necessary, you can open another issue and submit some PR.

• I do not expect that the current issue will be open for a long time. This issue partly involves factors outside the project, such as the review efficiency of the GraalVM Team.

[linghengqian]

• Usage of SCRIPT Job and TracingConfiguration with GraalVM Native Image has been fixed by Provides built-in GraalVM Reachability Metadata and nativeTest on Elasticjob Bootstrap #2268.

[linghengqian]

我们在做这种自动化测试的时候，可以引入一个场景么，就是一个客户端或者准确的说一个真正执行作业的server，它的极限。 例如: 这台实例是900个作业的执行节点也就是真正的server。这900个作业都是一秒调度一次，这台server什么时候会到它的承受极限。 我的想法: 我的想法是关注它的cpu信息，因为作业的调度是有周期的，它的cpu波动也会周期，作业占用的内存我先忽略不计，如果它的cpu峰值达到70%，那么我就认为这台实例的极限就是900.

• @zjx990 As https://ge.apache.org/ has started to be used by ASF projects on a large scale this year, I've opened Integrate ge.apache.org in the project to prepare for possible performance testing #2413 to discuss the way forward.