Support compiling and using ShardingSphere under OpenJDK 23

[linghengqian]

For #32927.

Changes proposed in this pull request:

• Support compiling and using ShardingSphere under OpenJDK 23.
• According to https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#proc , switch the value of maven.compiler.proc.
• Update Maven Wrapper version. Multi-threaded deadlock problems in the Maven lifecycle often plague CI.

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally : ./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.

[linghengqian]

• More errors surfaced.

Caused by: java.lang.ClassNotFoundException: javax.management.loading.PrivateMLet
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)
        ... 44 more

[linghengqian]

• @kanha-gupta I observed Add test case for PluginLifecycleServiceManager #24007. Why does the relevant unit test have to use the deprecated javax.management.loading.PrivateMLet starting from JDK20? This class was removed in JDK23.

package javax.management.loading;

/**
 * An MLet that is not added to the {@link ClassLoaderRepository}.
 * This class acts exactly like its parent class, {@link MLet}, with
 * one exception.  When a PrivateMLet is registered in an MBean
 * server, it is not added to that MBean server's {@link
 * ClassLoaderRepository}.  This is true because this class implements
 * the interface {@link PrivateClassLoader}.
 *
 * @deprecated This API is part of Management Applets (m-lets), which is a legacy feature that allows loading
 * of remote MBeans. This feature is not usable without a Security Manager, which is deprecated and subject to
 * removal in a future release. Consequently, this API is also deprecated and subject to removal. There is no replacement.
 *
 * @since 1.5
 */
@Deprecated(since="20", forRemoval=true)
@SuppressWarnings({"serial", "removal"}) // Externalizable class w/o no-arg c'tor
public class PrivateMLet extends MLet implements PrivateClassLoader {

• Also see https://bugs.openjdk.org/browse/JDK-8297794 .

[RaigorJiang]

Hi @linghengqian

When I use JDK 17 (Zulu) to compile the master branch, this error occurs:

---

If I switch to JDK 21, the compilation is successful. Since the -proc option is specified, does it mean that JDK 21 or above must be used to compile ShardingSphere?

[linghengqian]

If I switch to JDK 21, the compilation is successful. Since the -proc option is specified, does it mean that JDK 21 or above must be used to compile ShardingSphere?

• I rechecked the OpenJDK Committer's blog https://inside.java/2024/06/18/quality-heads-up/ , and -proc:full has been backported to jdk 17.0.11, 11.0.23, 8u411. Can you print the output of java -version?

[RaigorJiang]

@linghengqian I used the following command to compile and compare the result of different JDKs

./mvnw clean install -B -DskipTests

1. Oracle JDK 17

• Compile failed

2. Zulu JDK 17

• Compile failed

3. Oracle JDK 21 (In Zulu JDK 21 is also successful, omitted here)

• Compile successful

[RaigorJiang]

• I rechecked the OpenJDK Committer's blog https://inside.java/2024/06/18/quality-heads-up/ , and -proc:full has been backported to jdk 17.0.11, 11.0.23, 8u411. Can you print the output of java -version?

After upgrading JDK from 17.0.9 to 17.0.11, there is indeed no problem anymore, thank you @linghengqian

[linghengqian]

• I rechecked the OpenJDK Committer's blog https://inside.java/2024/06/18/quality-heads-up/ , and -proc:full has been backported to jdk 17.0.11, 11.0.23, 8u411. Can you print the output of java -version?

After upgrading JDK from 17.0.9 to 17.0.11, there is indeed no problem anymore, thank you @linghengqian

• Maybe some contributors are using non-LTS versions lower than JDK21. Currently, the master branch can only be built with jdk8, jdk11, jdk17, and jdk21-23. I set this JVM parameter in Support building Example module with OpenJDK 23 #33224 to take effect only on JDK23. This will allow contributors to build shardingsphere with jdk15, jdk20, etc.

[RaigorJiang]

After upgrading JDK from 17.0.9 to 17.0.11, there is indeed no problem anymore, thank you @linghengqian

• Maybe some contributors are using non-LTS versions lower than JDK21. Currently, the master branch can only be built with jdk8, jdk11, jdk17, and jdk21-23. I set this JVM parameter in Support building Example module with OpenJDK 23 #33224 to take effect only on JDK23. This will allow contributors to build shardingsphere with jdk15, jdk20, etc.

Great, thanks! 👍