Repository navigation
Upgrade Spoon from 10.4.2 to 11.5.0 - #363
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), so raise ComplianceLevel.MAX_SUPPORTED accordingly. No API changes were needed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CatarinaGamboa
force-pushed
the
chore/spoon-11
branch
from
October 7, 2026 10:53
ad6f12c to
c9991c3
Compare
rcosta358
approved these changes
Oct 7, 2026
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 7, 2026
## Problem
`CommandLineLauncher` sets 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 class `testSuite.var` (`Sorts testSuite.var
and Int are incompatible`), and `try (r)` (Java 9 resource reference)
does not parse, which blocks the second reproducer of #334.
## Change
- New `ComplianceLevel` reads the level from the
`maven.compiler.release` (or `maven.compiler.source`) property of the
nearest `pom.xml` of each verified path, walking up to enclosing poms,
using the existing `maven-model` dependency. `1.8` is read as `8`; with
several paths the highest level wins.
- Defaults to **19** when no pom declares it, and caps at **19**: the
highest level Spoon 10.4.2's JDT (3.33) accepts (`20` throws
`Unrecognized option : -20`). The cap is silent (the level is printed
with `--debug`), since e.g. `liquidjava-example` declares 20 and a
warning would show up on every run.
- New test `CorrectModernJavaSyntax` (`var`, `try (r)`, switch
expression): fails at level 8, passes now.
- Unit tests `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](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 8, 2026
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>
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 8, 2026
Fixes #369. ## Problem Since #363 (Spoon 11), any `record` crashed verification with an NPE in `TypeChecker.scan`. Spoon 11 dispatches records to `visitCtRecord`; `ExternalRefinementTypeChecker` overrides only `visitCtClass` (to skip user classes), so it walked the record's methods with `prefix == null` and `createReference(null)` threw. Building the error message then failed on the record's implicit members, which have no source file. ## Change - `ExternalRefinementTypeChecker.visitCtRecord`: skip, as for classes. - `TypeChecker.scan`: when the failing element has no source file, the message says so instead of throwing an NPE. With this, record methods are verified: a refinement violation inside a record method is reported (related to #342). ## Tests - `CorrectRecord`: a record with a method calling a refined method correctly; crashed on main, now passes. - `ErrorRecordMethod`: a violation in a record method is reported. - `mvn test` passes. 🤖 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
2 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.
Follow-up to #352 (stacked on it; GitHub will retarget to
mainonce #352 merges).Problem
Spoon 10.4.2 bundles JDT 3.33, which only accepts compliance levels up to 19 (
20throwsUnrecognized 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 (27throws).No source changes were needed for the Spoon API.
Downstream
vscode-liquidjava/server/pom.xmldeclaresspoon-coredirectly withversion.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