Bump the Antlr4 Maven Plugin version and bump the minimum JDK compilation level to JDK11

[linghengqian]

Why you need it?

Is your feature request related to a problem? Please describe in details

• I personally noticed that Seata is still using org.antlr:antlr4:4.8 when writing downstream documents like https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-jdbc/special-api/transaction/seata/ and https://www.yuque.com/linghengqian/meve2v/es8d3a8a18odao7x .
• The use of old versions of Antlr4 causes downstream projects to always manually exclude the Antlr4 dependency in Seata Client.

      <dependency>
         <groupId>org.apache.seata</groupId>
         <artifactId>seata-all</artifactId>
         <version>2.2.0</version>
         <exclusions>
            <exclusion>
               <groupId>org.antlr</groupId>
               <artifactId>antlr4-runtime</artifactId>
            </exclusion>
         </exclusions>
      </dependency>

• At the source, ShardingSphere uses Maven Plugin of org.antlr:antlr4-maven-plugin:4.10.1 to compile *.g4 files, while org.antlr:antlr4-runtime:4.8 used by org.apache.seata:seata-all:2.2.0 obviously cannot read the binary of org.antlr:antlr4-maven-plugin:4.10.1.
• This affects the integration of projects including Hibernate, ShardingSphere, and Spark. Because the core reason why ShardingSphere updated the Antlr4 version is 6.0 - Antlr 4.10? hibernate/hibernate-orm#4975 on the Hibernate side. See Force to build on JDK 11+ shardingsphere#23550 .
• Although Spark 4.0.0 with Antlr4 4.10+ has not been officially released, Spark 4.0.0-preview2 with [SPARK-44366][BUILD] Upgrade antlr4 to 4.13.1 spark#43075 has been released. See https://spark.apache.org/news/spark-4.0.0-preview2.html . This will definitely cause some problems in Seata integration testing.

How it could be?

A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.

• Long story short, I expect Seata Client to update the version of org.antlr:antlr4 from 4.8 to 4.10.1. This necessarily means raising the minimum JDK compilation level for compiling Seata to JDK11.
• org.antlr:antlr4-maven-plugin:4.10.1 requires JDK 11, but org.antlr:antlr4-runtime:4.10.1 still works on JDK 8. So I don't think this is likely to affect downstream users using JDK8, only developers need to use JDK11+ to compile Seata. See https://lists.apache.org/thread/kgtfx5vnw73o61lkvdshyfvjfvvzk3js .
• Or another possibility is to remove the use of Antlr4. I noticed that Seata actually uses Alibaba Druid parsing dialect and does not use Antlr4 at all.

Other related information

Add any other context or screenshots about the feature request here.

• See Improve GraalVM Reachability Metadata and corresponding nativeTest related unit tests shardingsphere#29052 , https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-jdbc/special-api/transaction/seata/ and 跨越 MySQL 边界 -- GraalVM Native Image 下 ShardingSphere JDBC 的 Seata AT 集成 https://www.yuque.com/linghengqian/meve2v/es8d3a8a18odao7x .
• This did affect some of the tests in Does Shardingsphere-proxy currently support integration with Seata? shardingsphere#33791 . When writing the Dockerfile for the integration test, I also had to consider whether to temporarily create an Uber JAR for the Seata Client.

[funky-eyes]

Actually, as you mentioned, ANTLR is currently just a supplementary solution and not the default SQL parsing method. Therefore, theoretically, on the ShardingSphere side, we can directly exclude this dependency to resolve the issue.

[linghengqian]

No problem. Should I just close the issue?

[funky-eyes]

I think this issue can be closed