[vharseko]

Fixes #340.

Failed construction

The SecureCsvWriter constructor opened the audit file, and with rotation a RotatableWriter with its rotator thread, before it read the keys and verified a file it resumes, and closed neither when that failed. It now closes the writer in its catch block; a RuntimeException from that close is added to the original one as suppressed (TextWriterAdapter.close() logs an IOException of the close instead of throwing it). new HmacCalculator(...) moves into the try block, since it can fail after the file is opened too.

Exception type

An IOException raised during the construction is now thrown as is instead of being wrapped in RuntimeException: Error when initializing a secure CSV writer. A topic whose file cannot be resumed, or whose keystore cannot be loaded, now always fails this way:

• its file fails verification;
• its file cannot be parsed or decoded, as a crash while a row is written leaves it: a row with fewer columns than the header or an unclosed quote (SuperCsvException), a final signature cut short so that it no longer decodes as Base64 (NullPointerException), a header cut short to one column (ArrayIndexOutOfBoundsException). CsvSecureVerifier.verify() lets these through; the constructor turns them into an IOException that keeps the cause, as CsvSecureArchiveVerifier turns any exception of the verification into a failed result;
• its headers do not match;
• its keystore is missing or holds no initial key. JcaKeyStoreHandler reads a missing keystore file as an empty keystore, and CsvSecureVerifier failed on it with an IllegalStateException. The constructor now checks the initial key before it verifies the file, and fails with an IOException that names the keystore;
• its keystore cannot be opened or loaded, whether the file is resumed or not: a directory or a file that cannot be read in its place (FileNotFoundException), an empty keystore, as a crash while it was stored leaves it, or a keystore stored under another password (KeyStoreBuilder throws an IllegalStateException for both), or a corrupted keystore, on which KeyStore.load can throw a RuntimeException, such as a ClassCastException or a NullPointerException, before it checks the digest of the keystore. The constructor turns it into an IOException that names the keystore and keeps the cause. This is not only a file to resume: the keystore is stored when the writer is constructed, the header only with the first event, so a topic that got no event keeps an empty file next to its keystore;
• its keystore holds no current key. The verifier already rejects such a file ("Final HMAC key is null"); the check after it now throws an IOException too, instead of an IllegalStateException.

CsvAuditEventHandler catches only an IOException there:

• startup() logs the failure for the topic and opens the other topics. Before, the exception left the loop over the topics and AuditServiceImpl.startup(), which catches only a ResourceException, and the audit service stayed in the STARTING state.
• A writer reopened at runtime fails with a BadRequestException through resetAndReopenWriter(), and publishEvent() returns it as a failed promise. [#334] CSV audit: the rotate action waits for the events being written #347 turns it into an InternalServerErrorException (CSV audit: a failure to write, open or read the audit file is reported as BadRequestException (400) #364).

Behaviour change: the password of a topic's keystore is derived from the Password key of the handler keystore. After that key changes, every topic that has a keystore, a topic that got no event yet included, now fails on its own with an IOException, which startup() logs, instead of failing the whole startup; a topic without a keystore still starts with a new one.

Behaviour change: a topic whose file fails verification at startup no longer keeps the audit service in the STARTING state, where every request got a 503. Its publishes fail, but a read or a query of the topic returns the rows of the file as they are: getEntries() reads the file through CsvSecureMapReader, which drops the HMAC and signature columns and verifies nothing. Reads have never verified a tamper-evident file; a row changed while the service runs is returned the same way. The file is verified by CsvSecureArchiveVerifier and when a writer resumes it.

Other failures, such as a handler keystore without the Password or Signature key, or a JVM that cannot create a JCEKS keystore (KeyStoreBuilder throws an IllegalStateException whose cause is a KeyStoreException, or a NoSuchAlgorithmException for the digest that checks the keystore), are still wrapped in a RuntimeException, so a misconfiguration still fails the startup.

Tests

• SecureCsvWriterTest.shouldStopRotatorAndFailWithIOExceptionWhenFileCannotBeResumed: a written file is resumed with rotation and a size policy, from a thread of its own ThreadGroup, where the rotator creates its thread. Before, one of the following is done to it: an event row changed after it was signed, its keystore deleted, the current key removed from its keystore, its keystore truncated to 0 bytes, its keystore stored under another password, its keystore replaced by a corrupted one, a row with fewer columns than the header appended, a quoted value cut short appended, its final signature cut short by 3 characters, its header cut short to one column. The construction fails with an IOException that gives the reason, and the rotator thread terminates.
• SecureCsvWriterTest.shouldStopRotatorAndFailWithIOExceptionWhenKeystoreOfEmptyFileCannotBeLoaded: the same for the empty file of a writer that got no event, whose keystore is replaced by a directory, stored under another password, or replaced by a corrupted one.
• The corrupted keystore is a JCEKS keystore whose secret key entry holds a string in place of the sealed key: KeyStore.load throws a ClassCastException on it, checked on JDK 11, 17, 21 and 27.
• Both tests have a 60 s timeOut, so a constructor that deadlocks fails them instead of hanging the fork.
• CsvAuditEventHandlerTest.testStartupOpensOtherTopicsWhenTamperEvidentFileCannotBeResumed: a tamper-evident handler with two topics, whose file of the topic opened first fails verification. The AuditService reaches the running state, the other topic accepts an event, and a publish to the failing topic returns a BadRequestException.
• CsvWriterTest: a header mismatch on resume is now an IOException.

Measured on JDK 27:

• With the SecureCsvWriter of master, every case of both writer tests fails, and so do the handler test and CsvWriterTest.shouldResumeExistingCsvSecureFile.
• Dropping the close fails every case of both writer tests ([pool-N-thread-1 alive]).
• Catching only a SuperCsvException from the verifier fails the signature-cut-short and header-cut-short cases.
• Rethrowing the IllegalStateException of an unloadable keystore when the file is not resumed fails the empty-file case with the keystore stored under another password.
• Catching only the IOException and the IllegalStateException of the keystore fails the corrupted-keystore case of both writer tests.
• audit/handler-csv passes locally; SecureCsvWriterTest also on JDK 11.

Not covered by a test: the open file handle itself, which cannot be observed portably on POSIX; the path without rotation; and a JVM that cannot create a JCEKS keystore.

Not in this PR

• While a topic's file cannot be resumed, every publish to it still constructs a writer under the handler monitor and verifies the whole file again; it no longer leaks.
• The RotatableWriter constructor leaks its file when scheduleRotationAndRetentionChecks() rejects the check interval: [#343] Tamper-evident CSV audit: construct the rotatable writer once the resumed file is verified #355.
• The rotator can rotate a resumed file while the constructor still verifies it: Tamper-evident CSV audit: the rotator can rotate a resumed file while the writer still verifies it #343, in [#343] Tamper-evident CSV audit: construct the rotatable writer once the resumed file is verified #355.
• A resumed header with an empty column name fails with a NullPointerException: [#345] CSV audit: compare the header lengths when resuming a CSV file #353.

[maximthomas]

praise: The close is placed exactly where the leak was, and the tests measure it.

• The SecureCsvWriter constructor's catch now closes csvWriter, which stops the RotatableWriter rotator. Removing that close turns all five rows of shouldStopRotatorAndFailWithIOExceptionWhenFileCannotBeResumed red ([pool-N-thread-1 alive]). Measured on JDK 26.
• Restoring the RuntimeException wrapping turns testStartupOpensOtherTopicsWhenTamperEvidentFileCannotBeResumed red. Measured on JDK 26.
• readInitialKey() == null is checked before verify(), so a missing keystore fails with a message that names the keystore, not with an IllegalStateException from the verifier.

---

issue (blocking): A resumed file with a row cut short, a wrong column count or an unclosed quote still fails the whole startup, not only its topic.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:150, :201-205; commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/CsvSecureVerifier.java:97, :108

CsvSecureVerifier.verify() catches only SecureStorageException. super-csv's SuperCsvException from csvReader.read(header) therefore reaches the constructor's catch, which wraps it in RuntimeException. A probe against super-csv 2.4.0 got "the nameMapping array and the sourceList should be the same size" for a short row and "unexpected end of file while reading quoted column" for an unclosed quote. CsvAuditEventHandler.startup() catches only IOException, so the loop over the topics ends and AuditServiceImpl.startup() leaves the service in STARTING. A crash or a full disk during a write leaves the last row cut short, which is a common way for a file to become unresumable. The description says such a file "now always fails" with an IOException. A header line with one column fails on the same path: header[header.length - 2] throws ArrayIndexOutOfBoundsException.

// SecureCsvWriter.java:149-150 — import org.supercsv.exception.SuperCsvException;
CsvSecureVerifier verifier = new CsvSecureVerifier(csvFile, csvPreference, secureStorage);
final CsvSecureVerifier.VerificationResult verificationResult;
try {
    verificationResult = verifier.verify();
} catch (SuperCsvException e) {
    // A row cut short by a crash while it was written, or a row with a missing or extra column.
    throw new IOException("Resuming an existing CSV file but it cannot be parsed: " + csvFile, e);
}

// CsvSecureVerifier.java:97 — a header with fewer than two columns fails verification
if (header.length < 2 || !(HEADER_HMAC.equals(header[header.length - 2])
        && HEADER_SIGNATURE.equals(header[header.length - 1]))) {

Pin: add an unresumableFiles row that appends a line with fewer columns than the header to a written file. At this head it fails with the RuntimeException. With the fix it fails with the IOException.

---

question (non-blocking): Should an unreadable .keystore next to a new file fail the whole startup, as the description says, or only its topic, as the code now does?

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:118, :201-203

JcaKeyStoreHandler.init() opens an existing keystore path with KeyStoreBuilder.withKeyStoreFile(). For a mode-000 file or a directory, its new FileInputStream throws FileNotFoundException before anything is wrapped in IllegalStateException. The inner catch takes only IllegalStateException, so this IOException now passes through for a new file too, and startup() logs it for the topic. At base it was wrapped, and the startup failed. The description says a new file next to a keystore that cannot be loaded "still fails as before". Either answer is minor. If per-topic is intended, only the sentence changes. If "as before" is intended, the inner catch also takes IOException and wraps it when !fileAlreadyInitialized.

Pin: a 0-byte CSV next to a directory named <csv>.keystore, asserting the outcome you choose.

---

question (non-blocking): Is it intended that a topic that never got an event still fails the whole startup after a Password change?

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:123-125

A topic's keystore is stored when its writer is constructed, but its header is written only with the first event. An idle topic therefore leaves a 0-byte CSV next to a keystore. After the Password key changes, that keystore no longer loads. fileAlreadyInitialized is false, so the IllegalStateException is rethrown and wrapped, and the startup fails, the same as at base. The description says "a topic without a file still starts with a new keystore", which holds only when no keystore is left behind. If this is intended, the sentence needs "and no keystore". If not, dropping the rethrow at :123-125 makes such a topic fail on its own.

---

issue (non-blocking): The rotator can rotate a resumed file while the file is still being verified. This is pre-existing and not changed by this PR.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:104, :239-240, :443-451

constructWriter() builds the RotatableWriter and registers the rotation hooks before the keys are read and verify() runs. The first rotation check runs one check interval later (default 5s). Take a resumed file that is already over maxFileSize or maxFileLifetime and takes longer than that interval to verify. It is renamed while it is being verified, and postRotationAction renames .keystore and swaps in random keys. verify() then reports "Final HMAC key doesn't match" for a valid file that has already been archived. This was traced in the code, not run. Suggested follow-up issue: start the rotation checks only once construction has succeeded.

---

nitpick (non-blocking): The IOException arm of the new close catch can never fire.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:198

TextWriterAdapter.close() calls shutdown(). With rotation, RotatableWriter.shutdown() logs the IOException from its close(). Without rotation, TextWriter.Stream closes a PrintWriter, which swallows the exception. A failed close is therefore logged and not added as suppressed; only a RuntimeException can be. The catch has to stay because the compiler requires it. The description's "a failure of that close is added to the original one as suppressed" could say "a RuntimeException from that close".

[vharseko]

Addressed in 7327f11, on top of a rebase onto master (#330, #332).

1. issue (blocking), a resumed file that cannot be parsed. Fixed, and more widely than the SuperCsvException catch. A probe on the previous head confirmed the short row, the unclosed quote and the one-column header, and found one more case: a final signature cut short, the most likely cut of a crash, since the signature is the last column of the last row. Base64.decode returns null for it, and Signature.verify fails with a NullPointerException ("sigBytes" is null), which a SuperCsvException catch does not take. The constructor now turns any RuntimeException from verify() into an IOException ("Resuming an existing CSV file but it cannot be verified"), as CsvSecureArchiveVerifier.verify() already turns any exception of the verification into a failed result. I did not add the header.length < 2 check: the catch covers that case, and #342 changes CsvSecureVerifier too. Pinned by four new unresumableFiles rows: row cut short, quoted value cut short, signature cut short, header cut short. Catching only SuperCsvException fails the signature and header rows.

2. question, an unreadable .keystore next to a new file. Failing only its topic is intended, and the description now says so. A CSV file that cannot be opened has always failed only its topic, since constructWriter() runs outside the try; its keystore now does the same. The keystore catch also takes the IOException, so the message names the keystore. Pinned by shouldStopRotatorAndFailWithIOExceptionWhenKeystoreOfEmptyFileCannotBeLoaded, with a directory in place of the keystore of an empty file.

3. question, an idle topic after a Password change. Not intended. The rethrow is dropped, so a keystore that cannot be loaded fails only its topic, whether its file is resumed or not. Pinned by the same test, with the empty file of a writer that got no event and its keystore stored under another password. Restoring the rethrow fails that case.

4. issue (non-blocking), the rotator during the verification. Agreed, opened as #343, and listed under "Not in this PR".

5. nitpick, the IOException arm of the close catch. Agreed. The catch stays, and the description now says that a RuntimeException from that close is added as suppressed, while TextWriterAdapter.close() logs an IOException.

[maximthomas]

praise: The constructor now cleans up after itself, and the round 1 gap on unparseable files is closed.

• The catch closes the writer and keeps a close failure as suppressed (SecureCsvWriter.java:202-206), so a failed resume no longer leaves the file open or the non-daemon rotator thread running.
• verify()'s RuntimeExceptions become an IOException that keeps the cause (SecureCsvWriter.java:151-156), as CsvSecureArchiveVerifier does. The rows "row cut short", "quoted value cut short", "signature cut short" and "header cut short" pass on every CI row.
• assertReopeningFailsWithIOException runs each writer in its own ThreadGroup and asserts that the rotator thread terminates, for resumed files and for empty ones.

---

issue (non-blocking): A topic keystore with a corrupted byte still fails the whole audit startup.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:118-126

For a corrupted JCEKS file, KeyStore.load can throw ClassCastException or NullPointerException (JDK 11 to 26), NegativeArraySizeException (11, 17) or InvalidPathException (25, 26). KeyStoreBuilder.build() wraps only CertificateException | NoSuchAlgorithmException | IOException | KeyStoreException. These exceptions get past the catch at :120, the outer catch wraps them in RuntimeException, and the service stays in STARTING. That is the case this PR already fixes for the CSV file around verify(). A probe over 8196 corrupted variants of a two-key JCEKS found 14 to 64 per JDK that escape as unchecked exceptions. Every truncation is an EOFException and is caught. JDK 27 was not probed. The same block also handles the question on :120 below.

            final KeyStoreHandler hmacKeyStoreHandler;
            try {
                hmacKeyStoreHandler = new JcaKeyStoreHandler(CsvSecureConstants.KEYSTORE_TYPE, keyStoreFile.getPath(),
                        keyStorePassword);
            } catch (IllegalStateException e) {
                if (e.getCause() instanceof KeyStoreException || e.getCause() instanceof NoSuchAlgorithmException) {
                    // The JVM cannot create or check a keystore of this type: a configuration error, not the file.
                    throw e;
                }
                // KeyStoreBuilder throws it for a keystore it cannot load: an empty one, left by a crash while it was
                // stored, or one stored under another password, after a change of the Password key.
                throw new IOException("The keystore " + keyStoreFile + " of the CSV file cannot be loaded.", e);
            } catch (IOException | RuntimeException e) {
                // A directory or a file it may not read; KeyStore.load also lets a ClassCastException or a
                // NullPointerException through for a corrupted file.
                throw new IOException("The keystore " + keyStoreFile + " of the CSV file cannot be loaded.", e);
            }

It needs import java.security.KeyStoreException; and import java.security.NoSuchAlgorithmException;. The keystore reopened after a rotation (:456) is not part of this PR and stays as is.

---

issue (non-blocking): A resumed file whose header has an empty column name still fails the whole startup.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:168

super-csv reads an empty header name as null. verify() checks only the last two header names, and the HMAC skips null values. So a header edited to "" over a column that is empty in every row passes verify(). Then actualHeaders[idx].equals(headers[idx]) throws an NPE outside the verify try, and the outer catch wraps it in RuntimeException. The startup fails, and on a runtime reopen the exception leaves publishEvent(). The line predates this PR, but the comment at :152-154 says that an edited file fails the same way as a file that fails verification.

                    for (int idx = 0; idx < actualHeaders.length; idx++) {
                        if (!Objects.equals(actualHeaders[idx], headers[idx])) {
                            throw new IOException("Resuming an existing CSV file but the headers do not match.");
                        }
                    }

It needs import java.util.Objects;.

---

question (non-blocking): Is the IllegalStateException catch meant to cover a JVM that cannot create a JCEKS keystore at all?

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:120

KeyStoreBuilder.build() calls KeyStore.getInstance inside the same try. It turns that call's KeyStoreException into the same IllegalStateException("Unable to load keystore") (KeyStoreBuilder.java:172-188), on the missing-file branch of JcaKeyStoreHandler too. Take a JVM whose providers lack JCEKS (a FIPS provider list without SunJCE) and a handler keystore that is not JCEKS. Before this PR the startup failed. Now every tamper-evident topic logs "cannot be loaded" and the service starts. The description says a misconfiguration still fails the startup. This is minor either way. If the catch was meant for the file only, the block in the first issue rethrows these failures by their cause. I did not check whether a real FIPS configuration has this provider set.

---

question (non-blocking): Should read and query refuse a topic whose file failed verification at startup?

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/CsvAuditEventHandler.java:222-223, :530-554

Before this PR, a file with a row changed after signing kept the service in STARTING, so create, read and query all got 503. Now the service runs. Creates on the topic get 400, or an empty success plus a WARN when CSV is not the query handler (AuditServiceImpl.java:284, :296-298). A query goes through getEntries, which reads the file with a plain CsvMapReader and returns the forged row. The description covers the running service and the per-topic failure, but not the reads. Minor; no change needed in this PR.

---

question (non-blocking): Is 400 intended when a writer reopened at runtime finds that its file cannot be resumed?

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/CsvAuditEventHandler.java:467-468

The IOException now reaches catch (IOException e) { throw new BadRequestException(e); } in resetAndReopenWriter. Before this PR, the RuntimeException went through the catch in AuditServiceImpl and ResourceExceptionsUtil.adapt and came out as a 500. With CSV as the query handler, a client now gets 400 for a tampered or truncated file on the server. A client that retries on 5xx and drops on 4xx drops the event. Mapping these to InternalServerErrorException in resetAndReopenWriter would also change the existing 400 for the IOExceptions of StandardCsvWriter. Minor.

---

suggestion (non-blocking): The two new parameterised tests can hang the fork instead of failing.

commons/audit/handler-csv/src/test/java/org/forgerock/audit/handlers/csv/SecureCsvWriterTest.java:407, :426, :473

callInThreadGroup waits with thread.join() and no timeout, and neither test sets timeOut, unlike shouldForceRotationWhileAnotherThreadWritesAnEvent (:277). If a regression deadlocks the constructor, the surefire fork hangs until the CI job times out.

    @Test(dataProvider = "unresumableFiles", timeOut = 60_000)
    // ...
    @Test(dataProvider = "unloadableKeystoresOfEmptyFiles", timeOut = 60_000)

---

note (non-blocking): The Tests section of the description is out of date.

• PR description: the bullet on withSecureLoggingEnabled() (test keystore, 5-minute signature interval) describes a builder that is already on master. The diff does not change it.

[vharseko]

@maximthomas, round 2 is in 3a4b8b3, on a branch rebased onto the current master (#360, #354, #361 and #366 were merged meanwhile; the rebase had no conflict). The description is updated.

1. issue, a corrupted topic keystore. Fixed with your block: the IllegalStateException of KeyStoreBuilder and any other RuntimeException or IOException of new JcaKeyStoreHandler(...) become the IOException that names the keystore. Pinned by a "corrupted keystore" row in both unresumableFiles and unloadableKeystoresOfEmptyFiles: a JCEKS keystore whose secret key entry holds a string in place of the sealed key, on which KeyStore.load throws a ClassCastException. A probe gave that exception on JDK 11.0.32, 17.0.20, 21.0.12 and 27. With the catch of the previous head, both rows fail with RuntimeException: Error when initializing a secure CSV writer. Once the keystore has loaded, its keyed digest has matched, so reading its keys does not hit a corrupted byte.

2. issue, an empty column name in a resumed header. Fixed in #353 (4ed28b856), for this writer and for StandardCsvWriter, and pinned there by CsvWriterTest.shouldNotResumeCsvSecureFileWithEmptyColumnName. Not repeated here, so that the two PRs do not change that loop twice. The description lists it under "Not in this PR".

3. question, a JVM that cannot create a JCEKS keystore. The catch was meant for the file only. It now rethrows the IllegalStateException whose cause is a KeyStoreException (KeyStore.getInstance) or a NoSuchAlgorithmException (the digest that checks a JCEKS keystore), and the outer catch wraps it in the RuntimeException, so such a JVM fails the startup as on master. A CertificateException stays with the file: for JCEKS, KeyStore.load throws it for a certificate type read from the file. No test covers this case: making KeyStore.getInstance("JCEKS") fail means removing SunJCE for the whole JVM, which also removes the HMAC algorithm the writer creates first. The description says so.

4. question, read and query of a topic whose file failed verification. Left as is, and the description now says so, as a second behaviour change. getEntries() reads the file through CsvSecureMapReader, which drops the HMAC and signature columns and verifies nothing. A row changed while the service runs has always been returned the same way. The 503 before this PR came from the service never reaching RUNNING, not from a check on the reads. The file is verified by CsvSecureArchiveVerifier and when a writer resumes it.

5. question, 400 for a writer reopened at runtime. That is #364, and #347 fixes it: resetAndReopenWriter() answers an InternalServerErrorException for an IOException of the file. As the description of #347 notes, testStartupOpensOtherTopicsWhenTamperEvidentFileCannotBeResumed expects a BadRequestException here, so whichever of the two PRs is merged second updates that assertion. The description of this PR now points to #364.

6. suggestion, timeOut on the two parameterised tests. Done as proposed: timeOut = 60_000 on both.

7. note, the Tests section. The withSecureLoggingEnabled() bullet is gone; the builder is on master and the diff does not touch it. The "Not in this PR" section now points to #355 for the leak of the RotatableWriter constructor and for #343.

audit/handler-csv passes locally on JDK 27 (83 test invocations), and SecureCsvWriterTest on JDK 11.0.32 as well.

[maximthomas]

praise: The split keystore catch separates the environment from the file, and the new fixture pins the arm it adds.

• SecureCsvWriter.java:122-127 rethrows the IllegalStateException whose cause is a KeyStoreException or NoSuchAlgorithmException, so a JVM that cannot create a JCEKS keystore fails the startup again, as on master. The check is sound: KeyStore.load declares no KeyStoreException, and the only NoSuchAlgorithmException in JceKeyStore.engineLoad is the SHA digest. Neither depends on the file (JDK 11-26 sources, jdk-27-ga).
• corruptKeyStore (SecureCsvWriterTest.java:416-425) is deterministic. KeyStore.load throws the ClassCastException that drives the new RuntimeException arm on JDK 11, 17, 21, 24, 25 and 26, run for this review.