Repository navigation
Read Spoon compliance level from the project's pom.xml - #352
Merged
Merged
Conversation
At level 8, Java 9+ syntax (`var`, `try (r)`, switch expressions) fails to compile, so verification runs on a broken model (e.g. `var` becomes a class `testSuite.var`). 17 is the highest level Spoon 10.4.2's JDT accepts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Collaborator
|
Should this be a cli flag? or read from maven? |
Collaborator
Author
|
I can check that but im not sure if all versions are supported by spoon |
Spoon's compliance level is now taken from the nearest pom.xml of the verified paths (compiler plugin release/source, then the maven.compiler.release/source properties, walking up to enclosing poms). It defaults to 19 when no pom declares one and is capped at 19, the highest level Spoon 10.4.2's JDT accepts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CatarinaGamboa
changed the title
CatarinaGamboa
commented
Oct 7, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
rcosta358
approved these changes
Oct 7, 2026
CatarinaGamboa
added this pull request to stack #365
October 7, 2026 11:33
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 7, 2026
Fixes #334. **Stacked on #352** (compliance level 17, needed to parse `try (r)`); retarget to `main` once #352 merges. ## Problem The `close()` Java inserts at the end of a try-with-resources block was never checked, so a double close or a use after the block passed verification. ## Change `RefinementTypeChecker#visitCtTryWithResource` scans resources → body → a synthesized `r.close()` per resource (reverse declaration order, as Java does) → catchers → finally. The close goes through the normal invocation check, so it works for both `@StateRefinement` classes and external refinements. Errors are reported at the resource declaration (`Res r = new Res()`). For a Java 9 resource reference they're reported at the `try (r)` header. **Spoon workaround:** Spoon 10.4.2 models `try (r)` as an *implicit* copy of `r`'s declaration, initializer included. It is also repeated once per earlier local named `r` in the file, so `try (r)` can yield `[r, r, r]`. Scanning those would re-run `new Res()` and reset the state, so implicit resources are not scanned and are closed once per name. ## Tests - `classes/try_with_resources_error`: double close (both reproducers from #334), use after the block, use in `catch`, and `try (r)` on an already-closed `r`. - `classes/try_with_resources_correct`: use inside, multiple resources, `try (r)`, catch + finally. `mvn test`: 369/369 pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 7, 2026
Follow-up to #352 (stacked on it; GitHub will retarget to `main` once #352 merges). ## Problem Spoon 10.4.2 bundles JDT 3.33, which only accepts compliance levels up to 19 (`20` throws `Unrecognized option : -20`), so #352 has to cap the level read from the project's pom at 19. ## Change - `version.spoon`: 10.4.2 → **11.5.0** (JDT 3.46). It needs a Java 17+ runtime (class files are Java 17), which is fine since the verifier already targets 20. - `ComplianceLevel.MAX_SUPPORTED` (and so the default when no pom declares a version): 19 → **26**, the highest level JDT 3.46 accepts (`27` throws). No source changes were needed for the Spoon API. ## Downstream `vscode-liquidjava/server/pom.xml` declares `spoon-core` directly with `version.spoon` = 10.4.2. That direct dependency overrides the verifier's transitive one, so the server should be bumped to 11.5.0 together with the verifier version that includes this change. Otherwise projects declaring Java 20+ would make the model builder throw there. ## Testing `mvn test`: 369/369 pass (same as #352). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 8, 2026
Redoes #363, which was merged into `fix/compliance-level` after that branch had already been merged into `main` (#352), so `main` is 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; `27` throws), and a separate `DEFAULT` of **21** is used when no pom declares a Java version (it used to be the cap). - `RefinementTypeChecker#visitCtTryWithResource` (from #358): in Spoon 11, `CtResource` is no longer a `CtVariable`. A resource is now either a `CtLocalVariable` (`try (R r = ...)`) or a `CtVariableRead` (Java 9 `try (r)`). Spoon 10 modelled `try (r)` as an implicit copy of `r`'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 implicit `close()` is built from the declaration's reference or a clone of the read, positioned at the resource. ## Downstream `vscode-liquidjava/server/pom.xml` declares `spoon-core` 10.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, including `try_with_resources_correct` / `try_with_resources_error` (both resource forms) and `CorrectModernJavaSyntax`. 🤖 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
3 participants
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.
Problem
CommandLineLaunchersets Spoon's compliance level to 8, so any Java 9+ syntax fails to compile and LiquidJava verifies a broken model with only a generic warning ("Java compilation encountered issues"). E.g.var n = 5;is read as a variable of classtestSuite.var(Sorts testSuite.var and Int are incompatible), andtry (r)(Java 9 resource reference) does not parse, which blocks the second reproducer of #334.Change
ComplianceLevelreads the level from themaven.compiler.release(ormaven.compiler.source) property of the nearestpom.xmlof each verified path, walking up to enclosing poms, using the existingmaven-modeldependency.1.8is read as8; with several paths the highest level wins.20throwsUnrecognized option : -20). The cap is silent (the level is printed with--debug), since e.g.liquidjava-exampledeclares 20 and a warning would show up on every run.CorrectModernJavaSyntax(var,try (r), switch expression): fails at level 8, passes now.TestComplianceLevel(reads the pom, caps).Not read (falls back to 19): the compiler plugin's
<release>/<source>config, parents outside the enclosing directories, Gradle builds. Upgrading to Spoon 11.5 (levels up to 26) is in #363.Testing
mvn test: 369/369 pass.🤖 Generated with Claude Code