Migrate from Jakarta EE 8 to Jakarta EE 9

[linghengqian]

Fixes #26041.

Changes proposed in this pull request:

• Migrate from Java EE 8 to Jakarta EE 9. Refer to https://jakarta.ee/release/9/ .
  • Migrate jakarta.platform:jakarta.jakartaee-bom:8.0.0 to jakarta.platform:jakarta.jakartaee-bom:9.0.0.
  • Migrate org.glassfish.jaxb:jaxb-bom:2.3.9 to org.glassfish.jaxb:jaxb-bom:3.0.2.
  • Since Jakarta EE 9.1, the baseline JDK version was upgraded to JDK 11, and features after that were not available on the ShardingSphere side.
  • javax.transaction.xa.* was retained because javax.transaction.xa.* is now part of Java SE 21. Refer to https://jakarta.ee/specifications/transactions/2.0/jakarta-transactions-spec-2.0.html#java-se .
  • This change means that all Java EE 8-based web frameworks cannot use ShardingSphere's XA distributed transactions. As a reminder, Spring Boot OSS 2.7.x, the last version of Spring Boot OSS to use Java EE 8, will end community support on 2023-11-18. Refer to https://spring.io/projects/spring-boot#support .
• Replace the jakarta variant with Narayana 5.12.7.Final.
  • Since Narayana 5.13.0.Final, the baseline JDK version was upgraded to JDK 11, and features after that were not available on the ShardingSphere side. Refer to https://issues.redhat.com/browse/JBTM-3590 .
  • At the Narayana 5.12.4.Final milestone, the JBoss Team created Jakarta variants for Uber Jars like org.jboss.narayana.jta:narayana-jta, such as org.jboss.narayana.jta:narayana-jta-jakarta, but not for org.jboss.narayana.jta:jta, so the ShardingSphere side needs to use Narayana's Uber Jar. Reference https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12310200&version=12378489 and https://github.com/jbosstm/narayana/blob/5.12.7.Final/ArjunaJTA/narayana-jta-jakarta/pom.xml .
  • More early discussions are in https://issues.redhat.com/browse/JBTM-3544 .
  • Once ShardingSphere upgrades the baseline JDK version to JDK 11 in the future, we can update Narayana to 7.0.0.Final.
    • https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12310200&version=12398668 (6.0.0.CR1)
    • https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12310200&version=12400773 (6.0.0.Final)
    • https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=12310200&version=12406603 (7.0.0.Final)
• Update jboss-logging to 3.4.3.Final. This is just to avoid the CVE passed over by Narayana.
  • Since org.jboss.logging:jboss-logging:3.5.0.Final, the baseline JDK version was upgraded to JDK 11, and features after that were not available on the ShardingSphere side. Refer to https://issues.redhat.com/browse/JBLOGGING-162 .
• Replace the jakarta variant with Atomikos 6.0.0. The jakarta variant of Atomikos does not have a bom, so this PR removes the corresponding bom.

---

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.

[terrymanu]

Thank you, I need more time to check it.

[linghengqian]

• This PR will be converted to a draft. I'm still not sure if this PR should be merged before Spring Boot OSS 2.x reaches end of OSS support, unless the original issue gets broader feedback.

[github-actions]

There hasn't been any activity on this pull request recently, and in order to prioritize active work, it has been marked as stale.

[linghengqian]

• @terrymanu Since web frameworks like Quarkus have started to actively exclude older Java EE 8 dependencies, can we merge this PR at the current milestone? See Transition from Java EE to Jakarta EE #26041 (comment) .
• Spring boot 2.x will stop OSS support on 2023/11/24, and the next release of shardingsphere will be next month.

[totalo]

LGTM

[linghengqian]

So for this current controversial PR, I assume there are two steps that need to be taken care of first - this will align with what Narayana was doing during the transition period.

1. Migrate from Java EE 8 to Jakarta EE 8. This will only change the GAV information of the corresponding dependencies to align the behavior of Spring Boot 2.2-2.7.
2. Create a Jakarta EE 9 variant of ShardingSphere JDBC Core. The series of processing of ShardingSphere at DistSQL is ignored for the time being, because DistSQL only involves ShardingSphere Proxy.

[alan2lin]

JAXB_patch.zip

share a bash script to migrate from java EE 8 to Jakarta ,in springboot 3.1.6 ,jdk 17+

repodir=/data/gitrepo/shardingsphere/

search for all file extensions

find ${repodir} -type f -name "." -exec bash -c 'ext="${1##*.}"; [ ${#ext} -lt 5 ] && echo "$ext "' _ {} ; | sort -u > suffix.txt

find import javax.xml.bind.annotation.*

find ${repodir} -type f ( -name ".java" -o -name ".md" -o -name ".xml" -o -name ".yaml" -o -name ".yml" -o -name ".txt" -o -name "*.toml" ) -exec bash -c 'sed -n "s/import javax(.xml.bind.annotation.[^;]+;)/import jakarta\1/p" "$1" | awk -v file="$1" -v OFS=, "{if ($0 != "") print file, NR, $0}"' _ {} ; > preview.txt

find import javax.xml.bind.JAXB*

find ${repodir} -type f ( -name ".java" -o -name ".md" -o -name ".xml" -o -name ".yaml" -o -name ".yml" -o -name ".txt" -o -name "*.toml" ) -exec bash -c 'sed -n "s/import javax(.xml.bind.JAXB[^;]+;)/import jakarta\1/p" "$1" | awk -v file="$1" -v OFS=, "{if ($0 != "") print file, NR, $0}"' _ {} ; >> preview.txt

replace import javax.xml.bind.annotation.* with import jakarta.xml.bind.annotation.*

find ${repodir} -type f ( -name ".java" -o -name ".md" -o -name ".xml" -o -name ".yaml" -o -name ".yml" -o -name ".txt" -o -name "*.toml" ) -exec bash -c 'sed -i "s/import javax(.xml.bind.annotation.[^;]+;)/import jakarta\1/g" "$1" ' _ {} ;

replace import javax.xml.bind.JAXB* with import jakarta.xml.bind.JAXB*

find ${repodir} -type f ( -name ".java" -o -name ".md" -o -name ".xml" -o -name ".yaml" -o -name ".yml" -o -name ".txt" -o -name "*.toml" ) -exec bash -c 'sed -i "s/import javax(.xml.bind.JAXB[^;]+;)/import jakarta\1/g" "$1" ' _ {} ;

[linghengqian]

• This PR will not actually prevent Spring Boot OSS 3 integration, as usage of the JAXB API has been removed in Removes use of JAXB API via jackson-dataformat-xml #29384.

• Of course, XA distributed transactions are still not ready on Spring Boot OSS 3/Quarkus 3/Micronaut Framework 4/Helidon 3/Helidon 4. Since the SPI and corresponding implementation of XA distributed transactions has always been an optional module, creating a Jakarta EE variant for an optional module seems very strange and far inferior to the current PR solution.

• If When the localName property of @JacksonXmlProperty is not set, the required of @JsonProperty does not detect the property name of POJO FasterXML/jackson-dataformat-xml#628 is resolved, I will try to remove the use of JAXB API in the test suite. This will further reduce the impact of this PR.

[linghengqian]

• This PR will not actually prevent Spring Boot OSS 3 integration, as usage of the JAXB API has been removed in Removes use of JAXB API via jackson-dataformat-xml #29384.

• Of course, XA distributed transactions are still not ready on Spring Boot OSS 3/Quarkus 3/Micronaut Framework 4/Helidon 3/Helidon 4. Since the SPI and corresponding implementation of XA distributed transactions has always been an optional module, creating a Jakarta EE variant for an optional module seems very strange and far inferior to the current PR solution.

• If When the localName property of @JacksonXmlProperty is not set, the required of @JsonProperty does not detect the property name of POJO FasterXML/jackson-dataformat-xml#628 is resolved, I will try to remove the use of JAXB API in the test suite. This will further reduce the impact of this PR.

• Terminate this process until further exploration is conducted in shardingsphere-jdbc-5.5.0 causes spring boot to return JSON data as XML #31203 within the context of Spring Boot's WebMVC component. It appears, based on the issue description, that regardless of the XML parsing library introduced, there always exists a corresponding auto-configuration within Spring Boot's WebMVC component that modifies the format of responses from the controller layer. However, the associated issue still lacks unit tests.