GeezerVison

Converting this to a draft while I extend it to the other expressions that still come out of the parser without an AST node. Going through the test corpus turned up nested AND/OR, IS NULL, BETWEEN, CASE's WHEN clauses and a few more. I'll update the description once they're in.

Please fix Codacy issues.
Also, please I want to see the Performance/Benchmarks before: ./gradlew jmh. Thank you already.

Thanks! The Codacy findings are fixed in e8de6e9. All four were in the new ASTNodeCoverageTest: visit and checkRange are split to get under the NPath limit, and the == in isHeld is a deliberate identity check, now suppressed the same way as elsewhere in the code base.

I ran ./gradlew jmh with the project's settings, alternating master (c84ad0e) and this branch twice on the same machine. Every run also measures the released 5.4 jar, which serves as a control:

This branch parses performance.sql about 2% slower. That is within the error bars, but consistent across both pairs while the 5.4 control holds steady, so I take it to be real. The branch records a range node for every object the grammar opens no tree node for. I'm looking into deriving the range of objects like binary expressions from their operands on first access instead, which should recover most of it.

Good Job, give me a few minutes for proof reading everything.

Most of that came from my own change: a deque Condition() created on every call for the tokens of a leading NOT, though few conditions have one, and an empty ArrayDeque allocates its 16-slot array up front. 0c8073f creates it only at the first NOT. Bytes allocated per parse of performance.sql (median of 20 parses):

What remains is the range nodes themselves. ./gradlew jmh again, alternating as before:

The branch now averages 0.7% slower, less than master moved between its own two runs (2.3%). Deriving ranges from operands would remove only a small part of what is left, so I'd leave that for a follow-up. The same profile shows a few allocations on master worth trimming, such as the exclamationMarks deque next to the one I fixed, which I'll send as a separate PR.

Looking past this PR: for the next major release, I think it would be cleaner to stop exposing the parser's internals through the AST.

• getASTNode() hands out JJTree's Node and JavaCC's Token, generated classes with mutable public fields.
• Their tree follows the grammar's # nodes, not the model. That is why this PR needs RangeNode: an object the grammar opens no node for has to be given one to report its range.
• Any reachable node keeps the rest of the token stream alive through Token.next.

What callers need is the source range. ASTNodeAccess could offer begin and end offsets in place of getASTNode(), stored as two ints the parser sets, and RangeNode would go with it. Deprecating getASTNode() ahead of that would give callers time to move.

Sorry for asking a stupid question: why not implement for Statement interface (only) and provide DEFAULT methods?

Nevermind, it is clear.

I tried to resolve the merge conflicts, but probably made it worse.
Please resolve the Test failures and I would merge it promptly. I am sorry for the inconvenience.

Thank you much!

JMH before/after for this PR as merged: dd03d6f against its parent df97e40. Three interleaved rounds of ./gradlew jmh -PjmhProfiler=gc on one machine, with the build's 3 forks × 5 iterations. 5.4 is the released jar, the same code in both arms, so it shows the run-to-run noise.

Parse time stays within that noise, while allocation goes up by about 4%:

version  round  df97e40e ms/op  dd03d6ff ms/op     Δ   df97e40e B/op  dd03d6ff B/op     Δ
latest       1          28.755          29.212  +1.6%      6,083,620      6,338,071  +4.2%
latest       2          28.485          28.964  +1.7%      6,083,620      6,354,749  +4.5%
latest       3          29.091          28.989  -0.4%      6,100,302      6,354,750  +4.2%
5.4          1          47.643          47.743  +0.2%      7,788,360      7,755,224  -0.4%
5.4          2          46.829          46.242  -1.3%      7,734,710      7,768,065  +0.4%
5.4          3          48.157          47.676  -1.0%      7,751,284      7,767,851  +0.2%

Parse time is +1.0% on average across the rounds. The control moves between -1.3% and +0.2% across the same runs, so any slowdown is within what this setup can resolve.

Allocation rises a steady 4.2–4.5%, about 260 KB per parse of performance.sql, while the control stays within ±0.4%. This PR creates a node for every parsed object, so some extra allocation is expected. Absolute times come from a different machine than the README's, so only the ratios compare.

Yes, I had confirmed that before. Awesome work and much appreciated!