Directly use Java 17 and below Javac APIs.#7582
Conversation
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
javacutil/src/main/java/org/checkerframework/javacutil/TreeUtilsAfterJava11.java (1)
327-335:⚠️ Potential issue | 🟡 MinorRemove the outdated lower-JDK fallback wording.
These docs still describe behavior on pre-Java-17 runtimes, but the wrappers now call
JCVariableDecl#declaredUsingVar()andInstanceOfTree#getPattern()directly. Please describe only the AST semantics here, not runtime compatibility that this shim no longer emulates.✏️ Suggested doc cleanup
- * For Java 17+, returns true if {`@code` variableTree} was declared using {`@code` var}. Otherwise, - * returns false. + * Returns true if {`@code` variableTree} was declared using {`@code` var}. ... - * Returns the pattern of {`@code` instanceOfTree} tree. Returns null if the instanceof does not - * have a pattern, including if the JDK version does not support instance-of patterns. + * Returns the pattern of {`@code` instanceOfTree} tree, or null if the instanceof does not have + * a pattern.Also applies to: 353-359
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@javacutil/src/main/java/org/checkerframework/javacutil/TreeUtilsAfterJava11.java` around lines 327 - 335, Update the Javadoc to remove references to runtime/JDK compatibility and lower-JDK fallbacks and instead document only the AST semantics: state that isVariableTreeDeclaredUsingVar(VariableTree) (and the analogous method around lines 353-359) check whether the VariableTree is syntactically declared using the "var" type in the AST, and note that the implementation delegates to JCVariableDecl.declaredUsingVar() (and InstanceOfTree.getPattern() where relevant); remove any "Java 17+" or fallback wording and focus solely on the AST-level meaning.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/CHANGELOG.md`:
- Around line 10-17: Update the CHANGELOG paragraph to remove the contradiction
by explicitly stating the runtime vs compile-time requirements: clarify that JDK
17+ is required to run javac for Checker Framework type-checking, that
checker-qual.jar and checker-util.jar are built with Java 11 bytecode and thus
require Java 11+ at runtime, and note that Java 8 runtime compatibility only
applies when those JARs are not present on the runtime classpath (or provide
instructions how to obtain Java‑8‑targeted builds if available). Mention the
specific artifacts checker-qual.jar and checker-util.jar and add a short
sentence describing the compile-time‑only vs runtime dependency distinction so
readers know when JRE 8 is acceptable.
---
Outside diff comments:
In
`@javacutil/src/main/java/org/checkerframework/javacutil/TreeUtilsAfterJava11.java`:
- Around line 327-335: Update the Javadoc to remove references to runtime/JDK
compatibility and lower-JDK fallbacks and instead document only the AST
semantics: state that isVariableTreeDeclaredUsingVar(VariableTree) (and the
analogous method around lines 353-359) check whether the VariableTree is
syntactically declared using the "var" type in the AST, and note that the
implementation delegates to JCVariableDecl.declaredUsingVar() (and
InstanceOfTree.getPattern() where relevant); remove any "Java 17+" or fallback
wording and focus solely on the AST-level meaning.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: eabaea82-917e-4b91-bc63-b744ab013bf5
📒 Files selected for processing (2)
docs/CHANGELOG.mdjavacutil/src/main/java/org/checkerframework/javacutil/TreeUtilsAfterJava11.java
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (4)
docs/CHANGELOG.md (1)
6-6:⚠️ Potential issue | 🟡 MinorReplace the placeholder release date before merge.
Line 6 still uses
2026-??; changelog entries should use a concrete date or explicitTBD.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/CHANGELOG.md` at line 6, Change the placeholder date in the changelog header "## Version 4.0.0 (2026-??)" to a concrete release date (YYYY-MM-DD) or the explicit string "TBD" before merging; update the line exactly matching that header in docs/CHANGELOG.md so the changelog entry no longer contains "2026-??".docs/manual/external-tools.tex (1)
826-828:⚠️ Potential issue | 🟡 MinorThis Maven-profile paragraph is still outdated and grammatically incorrect.
Line 826 says “creating a new profiles”, and Lines 827-828 still reference Java 8/two profiles though the section now uses a single Java 17+ profile.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/manual/external-tools.tex` around lines 826 - 828, The paragraph contains a grammatical error ("creating a new profiles") and outdated references to Java 8/two profiles; update the sentence to singular ("creating a new profile") and remove or replace the Java 8/two-profiles wording so it correctly states that the example uses a single Java 17+ profile (mentioning the "Nullness Checker" example as appropriate), and rephrase the surrounding sentences for correct grammar and clarity to reflect a single Java 17+ profile rather than multiple profiles.build.gradle (2)
252-254:⚠️ Potential issue | 🟡 MinorRegister the Javadoc exclusion during configuration, not in
doFirst.
exclude(...)changes theJavadocsource input, and Gradle explicitly warns that mutating task inputs indoFirstis not seen by up-to-date/build-cache logic. SinceJavadocapplies excludes to itssource, move this call into the surroundingconfigureEachblock. (docs.gradle.org)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@build.gradle` around lines 252 - 254, The Javadoc task is mutating its inputs inside doFirst by calling exclude("**/module-info.java"), which prevents proper up-to-date/cache behavior; move the exclude("**/module-info.java") call into the surrounding Javadoc configureEach block (i.e., apply it to the Javadoc task's source/excludes during configuration rather than inside the doFirst action) so the exclusion is registered as a task input (update the Javadoc task configuration where configureEach is used and remove the exclude call from any doFirst body).
295-298:⚠️ Potential issue | 🟠 Major
sourceCompatibility/targetCompatibilitystill do not enforce the Java 17 API floor.Gradle documents that these are legacy
-source/-targetsettings and do not block newer JDK APIs; onlyoptions.releaseor compiling with a Java 17 toolchain gives that guarantee. Because this branch can still compile withcompilerJdkVersionvalues above 17, it can link against 21+/24 APIs and only fail later on a Java 17 runtime. A safe alternative here is to pin this branch’sjavaCompilerto 17, or add a dedicated Java 17 verification compile if--releasecannot be combined with these exports. (docs.gradle.org)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@build.gradle` around lines 295 - 298, The build currently only sets legacy sourceCompatibility/targetCompatibility and can still compile against newer JDK APIs; update the Gradle build to pin the Java compiler toolchain to Java 17 instead of relying on sourceCompatibility/targetCompatibility (or add a separate verification compile with Java 17) — specifically, replace or augment the existing sourceCompatibility/targetCompatibility settings by configuring the Java toolchain (java { toolchain { languageVersion.set(JavaLanguageVersion.of(17)) } }) and ensure tasks of type JavaCompile (compileJava/compileTestJava) use that toolchain so the branch cannot accidentally compile against >17 APIs.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@build.gradle`:
- Around line 290-293: The three-project predicate for Java 11 is duplicated;
extract a shared set (e.g., java11Projects) and reuse it where you currently
check project.name (the blocks that set options.release = 11 and that add the
-AstubNoWarnIfNotFound compiler arg). Replace the repeated
project.name.equals(...) checks with a single membership test against that
helper, update references in the tasks/configurations that set options.release
and the compiler arg, and ensure the helper is visible to both places (define it
at the top of the script or in the same scope as the Gradle configuration
blocks).
In `@docs/CHANGELOG.md`:
- Around line 14-16: The CHANGELOG statement claiming that checker-qual.jar and
checker-util.jar use Java 11 bytecode is incorrect; update docs/CHANGELOG.md to
state they are compiled to Java 17 bytecode (or remove the bytecode-version
claim) because the root build.gradle sets sourceCompatibility and
targetCompatibility to 17 and no subproject overrides those settings—ensure the
entry references checker-qual.jar and checker-util.jar and the Java 17 bytecode
version consistently.
In `@docs/manual/external-tools.tex`:
- Line 850: The JDK requirement is inconsistent: the manual uses
<jdk>[17,)</jdk> but the Maven example uses <jdk>[1.8,)</jdk>; update the Maven
example's <jdk> element (the value in docs/examples/MavenExample/pom.xml) to
match the manual by changing <jdk>[1.8,)</jdk> to <jdk>[17,)</jdk> so both
documents declare the same minimum JDK version.
---
Duplicate comments:
In `@build.gradle`:
- Around line 252-254: The Javadoc task is mutating its inputs inside doFirst by
calling exclude("**/module-info.java"), which prevents proper up-to-date/cache
behavior; move the exclude("**/module-info.java") call into the surrounding
Javadoc configureEach block (i.e., apply it to the Javadoc task's
source/excludes during configuration rather than inside the doFirst action) so
the exclusion is registered as a task input (update the Javadoc task
configuration where configureEach is used and remove the exclude call from any
doFirst body).
- Around line 295-298: The build currently only sets legacy
sourceCompatibility/targetCompatibility and can still compile against newer JDK
APIs; update the Gradle build to pin the Java compiler toolchain to Java 17
instead of relying on sourceCompatibility/targetCompatibility (or add a separate
verification compile with Java 17) — specifically, replace or augment the
existing sourceCompatibility/targetCompatibility settings by configuring the
Java toolchain (java { toolchain {
languageVersion.set(JavaLanguageVersion.of(17)) } }) and ensure tasks of type
JavaCompile (compileJava/compileTestJava) use that toolchain so the branch
cannot accidentally compile against >17 APIs.
In `@docs/CHANGELOG.md`:
- Line 6: Change the placeholder date in the changelog header "## Version 4.0.0
(2026-??)" to a concrete release date (YYYY-MM-DD) or the explicit string "TBD"
before merging; update the line exactly matching that header in
docs/CHANGELOG.md so the changelog entry no longer contains "2026-??".
In `@docs/manual/external-tools.tex`:
- Around line 826-828: The paragraph contains a grammatical error ("creating a
new profiles") and outdated references to Java 8/two profiles; update the
sentence to singular ("creating a new profile") and remove or replace the Java
8/two-profiles wording so it correctly states that the example uses a single
Java 17+ profile (mentioning the "Nullness Checker" example as appropriate), and
rephrase the surrounding sentences for correct grammar and clarity to reflect a
single Java 17+ profile rather than multiple profiles.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 212f85c7-9f04-4721-9e6d-c8f26f4a5e2a
📒 Files selected for processing (5)
build.gradledocs/CHANGELOG.mddocs/examples/MavenExample/pom.xmldocs/manual/external-tools.texdocs/manual/introduction.tex
💤 Files with no reviewable changes (1)
- docs/examples/MavenExample/pom.xml
| if ((project.name.equals("checker-qual") | ||
| || project.name.equals("checker-util") | ||
| || project.name.equals("checker-qual-android"))) { | ||
| options.release = 11 |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Extract the Java 11 project set.
The same three-project predicate now drives both options.release = 11 and -AstubNoWarnIfNotFound. Keeping those lists separate makes the compatibility policy easy to drift; define one shared set/helper and reuse it in both places.
Also applies to: 848-850
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@build.gradle` around lines 290 - 293, The three-project predicate for Java 11
is duplicated; extract a shared set (e.g., java11Projects) and reuse it where
you currently check project.name (the blocks that set options.release = 11 and
that add the -AstubNoWarnIfNotFound compiler arg). Replace the repeated
project.name.equals(...) checks with a single membership test against that
helper, update references in the tasks/configurations that set options.release
and the compiler arg, and ensure the helper is visible to both places (define it
at the top of the script or in the same scope as the Gradle configuration
blocks).
| The type qualifiers and utility libraries in `checker-qual.jar` and | ||
| `checker-util.jar` still use Java 11 bytecode. Thus, they may be used in | ||
| projects that run under Java 11 or later. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify effective bytecode target declarations in Gradle files.
set -euo pipefail
echo "== Root compatibility settings =="
rg -n "sourceCompatibility|targetCompatibility" build.gradle -C 2
echo
echo "== checker-qual overrides (if any) =="
rg -n "sourceCompatibility|targetCompatibility|options\\.release" checker-qual/build.gradle -C 2 || true
echo
echo "== checker-util overrides (if any) =="
rg -n "sourceCompatibility|targetCompatibility|options\\.release" checker-util/build.gradle -C 2 || trueRepository: typetools/checker-framework
Length of output: 518
🏁 Script executed:
head -20 docs/CHANGELOG.md | cat -nRepository: typetools/checker-framework
Length of output: 869
CHANGELOG claim about bytecode version contradicts build configuration.
Lines 14-16 claim checker-qual.jar and checker-util.jar use Java 11 bytecode, but root build.gradle sets sourceCompatibility and targetCompatibility to 17 (line 297-298). Since neither subproject overrides these settings, both libraries will be compiled to Java 17 bytecode, not Java 11. Update the CHANGELOG to reflect the actual bytecode version.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/CHANGELOG.md` around lines 14 - 16, The CHANGELOG statement claiming
that checker-qual.jar and checker-util.jar use Java 11 bytecode is incorrect;
update docs/CHANGELOG.md to state they are compiled to Java 17 bytecode (or
remove the bytecode-version claim) because the root build.gradle sets
sourceCompatibility and targetCompatibility to 17 and no subproject overrides
those settings—ensure the entry references checker-qual.jar and checker-util.jar
and the Java 17 bytecode version consistently.
| <!-- If you omit the activation block, run mvn with "-P checkerframework" to run checkers. --> | ||
| <activation> | ||
| <jdk>[1.8,)</jdk> | ||
| <jdk>[17,)</jdk> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Compare JDK activation range in manual vs Maven example.
set -euo pipefail
echo "== Manual snippet =="
rg -n "<jdk>\\[" docs/manual/external-tools.tex -C 1
echo
echo "== Maven example =="
rg -n "<jdk>\\[" docs/examples/MavenExample/pom.xml -C 1Repository: typetools/checker-framework
Length of output: 262
Align JDK version requirements between manual and Maven example.
The manual documents <jdk>[17,)</jdk> but the Maven example in docs/examples/MavenExample/pom.xml specifies <jdk>[1.8,)</jdk>. Reconcile these conflicting requirements.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/manual/external-tools.tex` at line 850, The JDK requirement is
inconsistent: the manual uses <jdk>[17,)</jdk> but the Maven example uses
<jdk>[1.8,)</jdk>; update the Maven example's <jdk> element (the value in
docs/examples/MavenExample/pom.xml) to match the manual by changing
<jdk>[1.8,)</jdk> to <jdk>[17,)</jdk> so both documents declare the same minimum
JDK version.
…o java17-buildsystem
…o java17-treeutils
…o java17-treeutils
framework/src/main/java/org/checkerframework/framework/ajava/ExpectedTreesVisitor.java
Show resolved
Hide resolved
| List<Expression> labels = node.getLabels(); | ||
| List<? extends ExpressionTree> treeExpressions = CaseUtils.getExpressions(javacTree); | ||
| List<? extends ExpressionTree> treeExpressions = javacTree.getExpressions(); | ||
| assert node.getLabels().size() == treeExpressions.size() |
There was a problem hiding this comment.
I am concerned about this assertion.
Aren't there more labels than expressions? There are pattern labels and default labels, for example.
There was a problem hiding this comment.
I agree that this code is wrong. I'll open a separate PR to address it.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
javacutil/src/main/java/org/checkerframework/javacutil/ElementUtils.java (1)
1006-1018:⚠️ Potential issue | 🟡 MinorRefresh deprecated helper Javadoc to match current behavior.
getKindRecordAsClassJavadoc still explains pre-RECORD JDK switch limitations, which no longer matches this code path.✏️ Suggested doc update
- /** - * Calls getKind() on the given Element, but returns CLASS if the ElementKind is RECORD. This is - * needed because the Checker Framework runs on JDKs before the RECORD item was added, so RECORD - * can't be used in case statements, and usually we want to treat them the same as classes. - * - * `@param` elt the element to get the kind for - * `@return` the kind of the element, but CLASS if the kind was RECORD - * `@deprecated` Use {`@link` ElementKind#RECORD} - */ + /** + * Returns {`@code` elt.getKind()}, but maps {`@link` ElementKind#RECORD} to + * {`@link` ElementKind#CLASS}. + * + * <p>Deprecated compatibility helper; callers should handle + * {`@link` ElementKind#RECORD} directly. + * + * `@param` elt the element to get the kind for + * `@return` the kind of the element, but CLASS if the kind was RECORD + * `@deprecated` Use {`@link` ElementKind#RECORD}. + */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@javacutil/src/main/java/org/checkerframework/javacutil/ElementUtils.java` around lines 1006 - 1018, The Javadoc for getKindRecordAsClass is outdated—remove the historical pre-RECORD JDK explanation and instead clearly state the current behavior (this method returns ElementKind.CLASS when elt.getKind() is ElementKind.RECORD to preserve legacy behavior), and update the `@deprecated` text to recommend calling elt.getKind() and handling ElementKind.RECORD directly (or using ElementKind#RECORD) as the replacement; keep the `@Deprecated` annotation as-is and ensure the summary, `@param` and `@return` descriptions reflect the current behavior and the suggested alternative.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@javacutil/src/main/java/org/checkerframework/javacutil/TreeUtils.java`:
- Around line 2368-2371: The fallback branch currently unsafely casts switchTree
to SwitchTree and can throw a raw ClassCastException; update the logic in
hasNullCaseLabel to explicitly check for SwitchTree (e.g., use else if
(switchTree instanceof SwitchTree) and call getCases on that instance) and
otherwise throw a diagnosable error (e.g., throw new BugInCF(...) with
contextual info about the unexpected tree/kind) so failures are clear and not
raw ClassCastExceptions.
- Around line 2578-2580: Update the deprecation javadoc for isRecordTree and
getKindRecordAsClass to give correct replacement guidance: for isRecordTree
replace "@deprecated Use {`@link` Tree.Kind#RECORD}" with a predicate example such
as "@deprecated Use {`@code` tree.getKind() == Tree.Kind.RECORD}" (referencing
isRecordTree and Tree.Kind.RECORD), and for getKindRecordAsClass replace its
deprecation text with an explanation that callers should check {`@code`
tree.getKind()} and explicitly handle {`@code` Tree.Kind.RECORD} when records must
be normalized to classes (mentioning getKindRecordAsClass and the RECORD→CLASS
normalization behavior) so the guidance matches the actual behavior.
---
Outside diff comments:
In `@javacutil/src/main/java/org/checkerframework/javacutil/ElementUtils.java`:
- Around line 1006-1018: The Javadoc for getKindRecordAsClass is outdated—remove
the historical pre-RECORD JDK explanation and instead clearly state the current
behavior (this method returns ElementKind.CLASS when elt.getKind() is
ElementKind.RECORD to preserve legacy behavior), and update the `@deprecated` text
to recommend calling elt.getKind() and handling ElementKind.RECORD directly (or
using ElementKind#RECORD) as the replacement; keep the `@Deprecated` annotation
as-is and ensure the summary, `@param` and `@return` descriptions reflect the
current behavior and the suggested alternative.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1adc6d41-cc03-46e8-8eb1-b5e00c6b7496
📒 Files selected for processing (5)
framework/src/main/java/org/checkerframework/framework/ajava/ExpectedTreesVisitor.javaframework/src/main/java/org/checkerframework/framework/stub/AnnotationFileUtil.javajavacutil/src/main/java/org/checkerframework/javacutil/ElementUtils.javajavacutil/src/main/java/org/checkerframework/javacutil/Resolver.javajavacutil/src/main/java/org/checkerframework/javacutil/TreeUtils.java
| if (switchTree instanceof SwitchExpressionTree switchExpressionTree) { | ||
| cases = switchExpressionTree.getCases(); | ||
| } else { | ||
| cases = SwitchExpressionUtils.getCases(switchTree); | ||
| cases = ((SwitchTree) switchTree).getCases(); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Guard the fallback branch with an explicit SwitchTree check.
hasNullCaseLabel accepts any Tree, but the current else turns a bad caller into a raw ClassCastException. An else if/BugInCF keeps failures diagnosable.
♻️ Suggested change
- if (switchTree instanceof SwitchExpressionTree switchExpressionTree) {
- cases = switchExpressionTree.getCases();
- } else {
- cases = ((SwitchTree) switchTree).getCases();
+ if (switchTree instanceof SwitchExpressionTree switchExpressionTree) {
+ cases = switchExpressionTree.getCases();
+ } else if (switchTree instanceof SwitchTree switchStatementTree) {
+ cases = switchStatementTree.getCases();
+ } else {
+ throw new BugInCF(
+ "TreeUtils.hasNullCaseLabel: expected SwitchTree or SwitchExpressionTree, found %s [%s]",
+ switchTree, switchTree.getClass());
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@javacutil/src/main/java/org/checkerframework/javacutil/TreeUtils.java` around
lines 2368 - 2371, The fallback branch currently unsafely casts switchTree to
SwitchTree and can throw a raw ClassCastException; update the logic in
hasNullCaseLabel to explicitly check for SwitchTree (e.g., use else if
(switchTree instanceof SwitchTree) and call getCases on that instance) and
otherwise throw a diagnosable error (e.g., throw new BugInCF(...) with
contextual info about the unexpected tree/kind) so failures are clear and not
raw ClassCastExceptions.
| * @deprecated Use {@link Tree.Kind#RECORD} | ||
| */ | ||
| @Deprecated(forRemoval = true, since = "2026-03-25") |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Record helper implementations ==="
sed -n '2573,2600p' javacutil/src/main/java/org/checkerframework/javacutil/TreeUtils.java
echo
echo "=== Call sites of getKindRecordAsClass ==="
rg -n -C2 '\bgetKindRecordAsClass\s*\('
echo
echo "=== Call sites of isRecordTree ==="
rg -n -C2 '\bisRecordTree\s*\('Repository: typetools/checker-framework
Length of output: 3523
The record-helper deprecation messages point callers to incorrect replacements.
getKindRecordAsClass intentionally normalizes RECORD to CLASS, so Tree.Kind.RECORD is not a behaviorally equivalent replacement. isRecordTree requires a full predicate expression, not just the enum constant. Both methods currently carry incomplete or misleading deprecation guidance.
For isRecordTree (line 2578):
Change @deprecated Use {@link Tree.Kind#RECORD} to something like @deprecated Use {@code tree.getKind() == Tree.Kind.RECORD} to show the required predicate expression.
For getKindRecordAsClass (line 2592):
Change @deprecated Use {@link Tree.Kind#RECORD} to clarify the RECORD→CLASS normalization behavior, such as @deprecated Use {@code tree.getKind()} and handle {@code Tree.Kind.RECORD} explicitly when records should still be treated like classes.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@javacutil/src/main/java/org/checkerframework/javacutil/TreeUtils.java` around
lines 2578 - 2580, Update the deprecation javadoc for isRecordTree and
getKindRecordAsClass to give correct replacement guidance: for isRecordTree
replace "@deprecated Use {`@link` Tree.Kind#RECORD}" with a predicate example such
as "@deprecated Use {`@code` tree.getKind() == Tree.Kind.RECORD}" (referencing
isRecordTree and Tree.Kind.RECORD), and for getKindRecordAsClass replace its
deprecation text with an explanation that callers should check {`@code`
tree.getKind()} and explicitly handle {`@code` Tree.Kind.RECORD} when records must
be normalized to classes (mentioning getKindRecordAsClass and the RECORD→CLASS
normalization behavior) so the guidance matches the actual behavior.
2 participants
Merge #7575 first.If this is merged first, then #7429 needs to change. If it is merged first, this PR needs to change.