[leonardo-pilastri-sonarsource]

---

Summary by Gitar

• Release API resolution:
  • Resolve the JDK API of the target release from the runtime image via SystemReleaseClasspath in JParserConfig
• Dependency bump:
  • Upgrade jdt-package to 1.9.0.12280 in java-frontend/pom.xml
• Test updates:
  • Add unit and parser tests covering release API selection and fallbacks
  • Update RunFinalizersCheckTest expectations for Java 10 API visibility
• Collector mutator coverage:
  • Add CollectorsToListCheckSequencedSample covering SequencedCollection mutators on Java 21
• Ruling expectations:
  • Remove obsolete S5738 and S2387 expectations and add a guava S3551 expectation

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-7279

[github-actions]

⚖️ Ruling update ready for review: #6461

[datadog-sonarsource]

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: ac3fd7c | Docs | Give us feedback!}

[gitar-bot]

Code Review ✅ Approved 2 closed / 2 findings

🟡 Medium risk · Selecting release-specific JDK APIs changes Java symbol resolution; incorrect API selection could produce misleading findings across analyzed projects.

Resolves the JDK API of the target release from the runtime image through the new jdt-package option, upgrading jdt-package to 1.9.0.12280. Resolved the lost coverage of SequencedCollection mutators in CollectorsToListCheck with a new Java 21 sample. No open issues found.

✅ 2 closed

✅ Quality: SequencedCollection mutators of CollectorsToListCheck lose all coverage

📄 java-checks-test-sources/default/src/main/java/checks/CollectorsToListCheckSample.java:126-140
CollectorsToListCheck still lists addFirst, addLast, removeFirst and removeLast (Java 21 SequencedCollection methods) as list mutators (CollectorsToListCheck.java:61-62). Those were the only calls exercising them in the sample. The sample is checked with withJavaVersion(16), and the release-API change means those methods no longer resolve at that version, so the PR swapped them for add(0, ..), add(..), remove(0) and remove("C"). add and remove were already covered, and a grep finds no other CollectorsToList sample that uses the sequenced methods. A regression in how they are matched (for example, dropping them from names(...)) would now go unnoticed. One fix: add a small sample checked with withJavaVersion(21) (or higher) that keeps the addFirst/addLast/removeFirst/removeLast compliant cases.

Closed: Cross-PR: Merging with #6451 silently drops the release-specific JDK API

📄 java-frontend/src/main/java/org/sonar/java/model/JParserConfig.java:136-146 📄 java-frontend/src/main/java/org/sonar/java/model/JParserConfig.java:168-182
Breaks when this PR and #6451 both merge and the conflict in JParserConfig.astParser() is resolved toward #6451's EcjFrontendBackend.newParser(configuration) delegation. A project targeting an older Java release with sonar.java.jdkHome set to a newer JDK then sees that JDK's full API again.

How

1. This PR sets SystemReleaseClasspath.OPTION_RELEASE in astParser() and calls useReleaseApiOfConfiguredJdk(options) (JParserConfig.java:136-137). That call reads the classpath/javaVersion fields and removes lib/jrt-fs.jar (JParserConfig.java:168-189).
2. In SONARJAVA-7284 Introduce frontend sessions and deterministic resource ownership #6451, astParser() only delegates to EcjFrontendBackend.newParser(configuration) (EcjFrontendBackend.java:14). That method rebuilds the options and environment from FrontendConfiguration.
3. EcjFrontendBackend.newParser never sets OPTION_RELEASE or OPTION_JAVA_HOME, and it passes jrt-fs.jar straight to setEnvironment. FrontendSession/FrontendBackend.open is the only parse path and has no hook for these options.
4. This PR's tests (JParserConfigTest calling useReleaseApiOfConfiguredJdk, and JParserTest calling .astParser()) depend on the old JParserConfig shape and stop compiling against SONARJAVA-7284 Introduce frontend sessions and deterministic resource ownership #6451.

Fix

• This PR: If it merges second, port OPTION_RELEASE and the useReleaseApiOfConfiguredJdk environment filtering into EcjFrontendBackend.newParser, driven by FrontendConfiguration, and adapt the new tests.
• SONARJAVA-7284 Introduce frontend sessions and deterministic resource ownership #6451: If it merges second, carry the release option and the jrt-fs.jar replacement into EcjFrontendBackend.newParser so the release behavior survives the refactor.

Compared 7509a6b with #6451 at b07e3d4

Verification Rules 1/1 met PRs 4 inspected

Functional validation No results

Rules 1 passed 2 not applicable

✅ Repository license compliance

Broader impact PRs 4 inspected

Cross-PR 4 PRs inspected 0 open impacts

PR 169: SONARJAVA-7278 Override ASTParser to expose the JDK API of a requested release (JEP 247) Inspected
PR 6449: SONARJAVA-7283 Decouple the frontend from Eclipse JDT core Inspected
PR 6451: SONARJAVA-7284 Introduce frontend sessions and deterministic resource ownership Inspected
PR 6456: SONARJAVA-7288 Replace Eclipse JDT core with PSI in the Java frontend Inspected

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing compact verification results.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
95.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube