Preserve casts when converting lombok.val to final var - #1233
Merged
Conversation
Contributor
Author
|
greg-at-moderne
self-requested a review
September 2, 2026 21:02
sullis
force-pushed
the
lombok-val-preserve-cast
branch
from
September 2, 2026 21:21
4968a3b to
dae3453
Compare
sullis
force-pushed
the
lombok-val-preserve-cast
branch
from
September 2, 2026 21:40
dae3453 to
3b96790
Compare
Contributor
Author
|
greg-at-moderne
approved these changes
Sep 3, 2026
Contributor
|
Thanks for the PR. Looks well designed and I appreciate the tests. |
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
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.
What's changed?
LombokValToFinalVarbuilt thefinal vardeclaration with aJavaTemplate, which re-prints the initializer expression. Re-printing can lose type information: a cast to a type variable such as(T) ocame out mangled, because the template parse has no knowledge of the enclosing class's type parameters.This replaces the template with a direct LST transformation:
varJ.Identifier(as the existing no-initializer branch already did) and swap it in for thevaltype expression, so both code paths now share that construction.finalmodifier only when one isn't already present, moving the original type expression's prefix onto the modifier so formatting is preserved.The initializer is carried over untouched, so casts — including generic ones — survive the conversion. Behavior for declarations without an initializer is unchanged (still a plain
var, per openrewrite/rewrite#5637).Also included is a small unrelated test fix:
UpgradeToJava25Test.upgradeToJava25pinnedmaven-compiler-pluginto3.15.xin an assertion pattern, which breaks as soon as a newer minor is released. The pattern now accepts any3.15+version.Anything in particular you'd like reviewers to focus on?
The prefix/modifier juggling is the part worth a close look — the existing tests cover annotated, already-
final, multi-variable, and comment-carrying declarations, and two new tests cover the casts:preserveCast((String) "foo") andpreserveGenericCast((T) o).I can't run the build locally — dependency resolution needs credentials for
artifacts.codegenomeproject.org— so I'm relying on CI for verification.Have you considered any alternatives or workarounds?
Keeping
JavaTemplateand making it type-aware. Sidestepping the re-print entirely is simpler, and it also removes the divergence between the initializer and no-initializer code paths.