Building with Java 21 fails due to ancient Antlr plugin

[cmahnke]

I know, that support for Java 17 is planned for version 7.0, see the blog post "January 2023 Releases" from 2023/01/15 - over a year ago.
Since Java 8 is EOL for non paying customers for about two years now and the current LTS is already Java 21, the following should be fixed in the development branch ASAP:

[ERROR] Failed to execute goal org.codehaus.mojo:antlr-maven-plugin:2.2:generate (default) on project exist-core: Execution default of goal org.codehaus.mojo:antlr-maven-plugin:2.2:generate failed: The Security Manager is deprecated and will be removed in a future release -> [Help 1]

Enviroment:

mvn --version
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec
Java version: 21.0.1, vendor: Oracle Corporation, runtime: /Users/cmahnke/.sdkman/candidates/java/21.0.1-graal
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.2.1", arch: "aarch64", family: "mac"

The problem is introduced by the Maven plugin org.codehaus.mojo:antlr-maven-plugin:2.2 (which was released 2010) in the exist-core module. Even though there seems to be a fix. A clean solution would get rid of this unmaintained dependency of the build system and maybe switch to AntLR 4 in the process.

[adamretter]

• eXist-db 4.x.x, 5.x.x, and 6.x.x require JDK 8.
• eXist-db 7.0.0-SNAPSHOT requires JDK 17.

There is no plan to support JDK 21 in eXist-db version 4, 5, 6, or 7.

Even though there seems to be a fix. A clean solution would get rid of this unmaintained dependency of the build system and maybe switch to AntLR 4 in the process.

That is not a simple thing to achieve:

• eXist-db's XQuery Parser is written in Antlr 2.
• Antlr 2 and Antlr 4 syntax are very different.
• Antlr 4 has an issue which likely won't be resolved (as it is there by design), which makes it suitable for one-time-use but unsuitable for repeated use in a database query engine.

[cmahnke]

@parrt: Do you agree with this assessment regarding Antlr 4?

[parrt]

hm... I'm not sure what issue it is that's causing this but java has definitely moved on into some weird territory that I've not kept up with over the last five to ten years I'm afraid.

[cmahnke]

Thanks, I was just wondering whether Antlr 4 is still considered costly or even unusable in terms of reusing parsers / lexers...

@adamretter Can you please elaborate the issue at hand a bit to get an assessment by @parrt ? Thanks!

[adamretter]

@cmahnke @parrt It's been a while since I looked into it, but if I recall correctly, the way that Antlr4 is designed is that it caches decisions it makes on which path to take whilst parsing. I understood that that is fine for parsing a few things, but for a long-running database server which has to parse an unlimited number of queries on demand it effectively results in a memory leak. Perhaps this may have been addressed in a newer Antlr 4 since I last looked (a year or so ago), I haven't checked...

[parrt]

You have to hit the cache clear function if your parser is going to run in a long running server. (at some interval or when et gets a certain size)