GeezerVison

@fudianchn: I love this very much and I am honestly impressed by it!

But I also wonder:

1. how much improvement does it yield for JSQLParser (e. g. how many LOOKAHEADs did it clean up and what is the JMH impact)
2. should this not better be moved into JavaCC, so any other Grammar can also benefit from it?

@manticore-projects Thanks! On the cleanup and performance question: this narrows 57 single-token lookaheads across 27 productions and removes one redundant lookahead guard.

I reran the parser JMH comparison on the same machine, using the same JDK, JVM settings and 54-statement corpus, with interleaved baseline/candidate runs. Across 12 JVM forks and 120 measurement iterations, the aggregate time for parsing the full corpus went from 17.832 to 17.539 ms/op, a 1.64% reduction.

However, the two paired comparisons were -0.05% and -3.21%, and host load was lower toward the end. The fork-bootstrap 95% interval for the aggregate change was [-2.91%, -0.40%], but that does not account for time-dependent host-load drift. The earlier run was also mixed (-1.04% and +0.49%). I would therefore not present this as a meaningful, reliably demonstrated parser speedup.

The main value is reducing unnecessary lookahead and making the grammar easier to understand and maintain. The tool provides an evidence-based way to review future LOOKAHEAD changes. From a purely performance perspective, these measurements have not established a substantial practical improvement.

@manticore-projects On your second point, I have opened a draft PR for the reusable audit tooling in your JavaCC core fork: manticore-projects/javacc-8-core#1 .

The extraction and JSqlParser integration have been validated locally. The JavaCC PR documents the outstanding parent-build and artifact-publication questions. This JSqlParser PR still contains the original in-repository tooling; it has not yet switched to the extracted implementation or an unpublished JavaCC dependency. I am marking this PR ready for review with that distinction made explicit.

This is fantastic work!

I would like to suggest to move all of this into JavaCC (only) and to only apply the Grammar fixes.
I have see your PR and work on integrating this.

Thank you much for all your work and effort.

Would you like me to narrow this PR down to just the grammar fixes, or are you planning to handle that as part of the JavaCC integration?

Would you like me to narrow this PR down to just the grammar fixes,

Yes, exactly. Thank you much!

Narrowed this PR to the grammar changes and parser regressions, and merged current master to resolve the conflict. The in-repository analyzer, Gradle task, CI integration and audit documentation are removed. JavaCC integration remains separate in manticore-projects/javacc-8-core#1.

Thank you very much!

~~One question for my understanding though: What is the effective difference between LOOKAHEAD(1, <K_DOMAIN>) and LOOKAHEAD(<K_DOMAIN>)?

I would have expected (and hoped for) both results in the same parser code? Although not tested myself.~~

Answered it, LOOKAHEAD(1, <K_DOMAIN>) is indeed "cheaper"! Awesome stuff!

JavaCC integration remains separate in manticore-projects/javacc-8-core#1.

Thank you again, I look into this asap.