Repository navigation
Upgrade Spoon to 11.5.0 and default the compliance level to 21 - #368
Merged
Merged
Conversation
Spoon 11.5.0 bundles JDT 3.46, which accepts compliance levels up to 26 (10.4.2's JDT 3.33 stopped at 19). Projects whose pom declares no Java version are now parsed at 21. Spoon 11 models a try-with-resources resource as either a local variable declaration or a read of an existing variable (Java 9 `try (r)`), instead of an implicit copy of the variable's declaration, so the implicit close() is built from that node directly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 13, 2026
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 14, 2026
Fixes #342 (regression tests only; no verifier change). At the commit in the issue, `CommandLineLauncher` hard-coded compliance level 8. Java 8 has no records, so JDT parsed the record header as a method and its members as locals and a block; the real method was never in the model. Spoon reports this as a warning in noclasspath mode, so the run printed "Java compilation encountered issues" and then "Correct! Passed Verification." It is already fixed on main by #352 (compliance from the pom), #368 (default level 21, Spoon 11.5.0) and #370 (records in the external-spec pass). Forcing level 11 or 15 still reproduces it; 16 and above report the error. Fixtures, with the spec in its own file as in real projects: - `classes/record_external_spec_error/`: State Refinement Errors in a record's instance and static methods. - `classes/record_external_spec_correct/`: the passing counterpart. Related gaps found while investigating, not fixed here: 1. **A parse problem still ends in "Correct!" with only a warning.** If Spoon's level is lower than the code needs, declarations can disappear silently. `ComplianceLevel` reads only `maven.compiler.release`/`source` properties of the nearest pom that has one, and ignores `<release>`/`<source>` in the maven-compiler-plugin configuration, so a parent property of 1.8 overridden in plugin config makes records vanish again. Options: let that warning block the "Correct!" verdict, and read the compiler-plugin config. 2. **One error hides later ones.** An error in a field initializer or initializer block stops checking of the rest of the class (catch in `visitCtClass`). `visitCtRecord` and `visitCtEnum` have no catch, so an error in a record or enum static initializer reaches `RefinementProcessor.processPackage` and later types in the package go unchecked. Per-member catches like those in `visitCtMethod`/`visitCtConstructor` would fix it. 3. **Test harness:** `TestExamples.matches` throws a NullPointerException on a warning with no position (such as the compilation warning). Validation: `mvn test` passes all 412 tests (251 TestExamples cases). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Redoes #363, which was merged into
fix/compliance-levelafter that branch had already been merged intomain(#352), somainis still on Spoon 10.4.2.Change
version.spoon: 10.4.2 → 11.5.0 (JDT 3.46). Its class files target Java 17, so it runs on our Java 20 build.ComplianceLevel: the cap goes from 19 to 26 (highest level JDT 3.46 accepts;27throws), and a separateDEFAULTof 21 is used when no pom declares a Java version (it used to be the cap).RefinementTypeChecker#visitCtTryWithResource(from Model the implicit close() of try-with-resources #358): in Spoon 11,CtResourceis no longer aCtVariable. A resource is now either aCtLocalVariable(try (R r = ...)) or aCtVariableRead(Java 9try (r)). Spoon 10 modelledtry (r)as an implicit copy ofr's declaration, repeated per earlier same-named local. That workaround (skip implicit copies, dedupe by name, header position) is gone: every resource is scanned and closed once, and the implicitclose()is built from the declaration's reference or a clone of the read, positioned at the resource.Downstream
vscode-liquidjava/server/pom.xmldeclaresspoon-core10.4.2 directly, which overrides the verifier's version. Bump it to 11.5.0 together with the verifier release that includes this.Testing
mvn test: 379/379 pass, includingtry_with_resources_correct/try_with_resources_error(both resource forms) andCorrectModernJavaSyntax.🤖 Generated with Claude Code