Fix Java parser for annotated varargs by adding marker on `J.ArrayType`, as opposed to field on `J.VariableDeclarations` by knutwannheden · Pull Request #6098 · openrewrite/rewrite

knutwannheden · 2025-10-01T18:37:45Z

Using a new Varargs marker.

TODO:

Fix all parsers
Phase out varargs field

Using a new `Varargs` marker.

timtebeek · 2025-12-22T17:06:45Z

Let me know if you'd like help replicating this pattern to the Java 8, 11, 17 and 25 parsers. Would be good to see this resolved.

timtebeek

Approved from my side; anything that had made you held off on merging?

I'd seen this fail in a number of projects, including when serializing the LST, so figured good to clear out.

timtebeek · 2025-12-31T10:16:18Z

            """
            class Test {
-                void method(String first, int... values) {}
+                void method(String first, int ... values) {}


Above we had two spaces; after normalization we are now left with one instead of zero. I think that's fine?

Yep, intentional — SpacesVisitor doesn't have a rule that strips the space, just normalizes it. Going from two spaces to one is the expected behavior.

timtebeek · 2025-12-31T20:20:46Z

+        @Deprecated
+        @ToBeRemoved(after = "2026-04-01")
        Space varargs;


It's still used once with a non-null value in the Groovy parser, but figured we can revise that if/when we decide to drop the field. Most other cases it's null already, and then there will be the long tail of deserialization support.

Updated based on the cross-language audit (see main thread comment): keeping @Deprecated (right signal for Java recipe authors — use the marker), but removed @ToBeRemoved since JS/TS, Python, and Go are all actively using the field for their own native varargs syntax. Removal needs the cross-language migration tracked above.

timtebeek · 2026-01-05T11:50:42Z

Tagging Jonathan for review since we're adding a marker to the LST model, and deprecating a field (not yet removed).

timtebeek · 2026-03-13T18:11:31Z

+ * Indicates that a {@link org.openrewrite.java.tree.J.ArrayType} represents a varargs parameter type.
+ * When present, the array type should be printed using {@code ...} syntax instead of {@code []}.
+ * <p>
+ * For example, {@code String...} instead of {@code String[]}.
+ */
+@Value
+@With
+public class Varargs implements Marker {
+    UUID id;


This marker could use a review before we merge, since we're adding a marker for what used to be a field.

Sam reviewed on Apr 1 — marking resolved.

sambsnyd

Basically all languages have some concept of varargs. Can we standardize this across all of them? Assuming it's agreed this is the way to go.

greg-at-moderne · 2026-04-08T12:26:31Z

all languages have some concept of varargs. Can we standardize this across all of them?

Just to help with the discussion, I think below is a fair description of current state of affairs. TLDR: it's fairly consistent.

Java: varargs field of type Space on J.VariableDeclarations, this PR aims to change it to a marker
JS/TS: same varargs field of type Space on J.VariableDeclarations, plus custom JS.Spread for ... call-site syntax
Python: same varargs field of type Space on J.VariableDeclarations (*args, **kwargs), plus custom Py.Star for call-sites
C#: the language has different syntax: params, stored as a J.Modifier
Go: same varargs field of type Space on J.VariableDeclarations
Scala: not implemented yet (?)
Kotlin: the language has different syntax: vararg, stored as a J.Modifier
Groovy: varargs field of type Space on J.VariableDeclarations

Comment:

I think it's fair to call it fairly consistent, even if not ideal
I understand Sam's comment as a call for changing other parsers to be in line with Java, if we decide to make the change for Java

JS/TS, Python, and Go all use this field for their own native varargs/star-args syntax (rest parameters, `*args`/`**kwargs`, variadic types). Removing the field requires coordinated migration across all five frontends, so a fixed removal date isn't realistic. The `@Deprecated` annotation remains.

knutwannheden · 2026-04-23T20:51:49Z

Thanks @greg-at-moderne for the survey — couple of corrections after digging into each.

Scala is implemented, but not using the varargs field for varargs. It repurposes the Space slot to store whitespace before the colon in field type ascription (ScalaTreeVisitor.scala:2772, e.g. given IntSchema : SchemaFor[Int]). Cleaning that up is independent of varargs and can be its own small PR (probably an S.SpaceBeforeColon marker on J.VariableDeclarations).

The other languages share a more interesting pattern: JS/TS, Python, and Go all actively read/write this same field for their own native varargs syntax, not just relay it over RPC:

JS/TS prints ...args rest parameters (print.ts:497-499)
Python prints *args/**kwargs (printer.py:1852-1854 — the Space is the whitespace before *)
Go prints variadic ...T (go_printer.go:332-334)

So this isn't a Java field that other languages happen to relay — it's a shared whitespace bucket every variable-declaration-having frontend is squatting on. Only C# is pure relay (it uses a params modifier natively).

That reshapes the plan. I think the right path is: land this PR as Java-only now, then track the cross-language work separately:

Java (this PR) — Varargs marker on J.ArrayType
Groovy — same pattern (also String... syntax)
JS/TS — marker on the rest-parameter representation
Python — dedicated field/marker for * / **
Go — marker on variadic-param representation
Scala — orthogonal: stop misusing the field for : whitespace

Once 1–5 land we can drop the field; until then it stays. I've also dropped the @ToBeRemoved(after = "2026-04-01") annotation in the latest push — no realistic removal date until the cross-language migration completes, and a stale date is worse than none. I'll open a tracking issue for 2–6.

Parse Java varargs annotations

8583bb4

Using a new `Varargs` marker.

github-project-automation Bot added this to OpenRewrite Oct 1, 2025

github-project-automation Bot moved this to In Progress in OpenRewrite Oct 1, 2025

knutwannheden added 3 commits October 1, 2025 20:41

Remove old code path

9d9cd5b

Simplify

a2583c6

Polish

04fcda6

timtebeek added java parser labels Dec 22, 2025

Merge branch 'main' into java-varargs-annotations

a2e7cdd

timtebeek added the bug Something isn't working label Dec 24, 2025

timtebeek assigned knutwannheden Dec 24, 2025

timtebeek added 5 commits December 24, 2025 22:33

Merge branch 'main' into java-varargs-annotations

31d7953

Replicate fix to the Java 25 parser

259d250

Replicate fix to the Java 17 parser

1705fef

Replicate fix to the Java 11 parser

d84967a

Replicate fix to the Java 8 parser

096f798

timtebeek approved these changes Dec 24, 2025

View reviewed changes

github-project-automation Bot moved this from In Progress to Ready to Review in OpenRewrite Dec 24, 2025

timtebeek added 2 commits December 31, 2025 11:07

Merge branch 'main' into java-varargs-annotations

3472475

Expect to go from two to one space before normalized ...

c09692b

timtebeek marked this pull request as ready for review December 31, 2025 10:14

timtebeek reviewed Dec 31, 2025

View reviewed changes

Mark the J.VariableDeclarations.varargs field as deprecated

ea5059e

timtebeek reviewed Dec 31, 2025

View reviewed changes

timtebeek changed the title ~~Parse Java varargs annotations~~ Fix Java parser for annotated varargs by adding marker on J.ArrayType, as opposed to field on J.VariableDeclarations Jan 5, 2026

timtebeek requested a review from jkschneider January 5, 2026 11:49

timtebeek and others added 2 commits January 15, 2026 12:21

Merge branch 'main' into java-varargs-annotations

749f0c9

Merge branch 'main' into java-varargs-annotations

1342772

timtebeek reviewed Mar 13, 2026

View reviewed changes

sambsnyd reviewed Apr 1, 2026

View reviewed changes

knutwannheden added 2 commits April 23, 2026 22:51

Merge branch 'main' into java-varargs-annotations

8022740

This was referenced May 3, 2026

"There were problems parsing" should show line number and/or excerpt of source code #7554

Open

Java 25 parser: don't merge /// blocks across blank lines #7556

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix Java parser for annotated varargs by adding marker on `J.ArrayType`, as opposed to field on `J.VariableDeclarations`#6098

Fix Java parser for annotated varargs by adding marker on `J.ArrayType`, as opposed to field on `J.VariableDeclarations`#6098
knutwannheden wants to merge 17 commits intomainfrom
java-varargs-annotations

knutwannheden commented Oct 1, 2025 •

edited by timtebeek

Loading

Uh oh!

timtebeek commented Dec 22, 2025

Uh oh!

timtebeek left a comment

Uh oh!

timtebeek Dec 31, 2025

Uh oh!

knutwannheden Apr 23, 2026

Uh oh!

timtebeek Dec 31, 2025

Uh oh!

knutwannheden Apr 23, 2026

Uh oh!

timtebeek commented Jan 5, 2026

Uh oh!

timtebeek Mar 13, 2026 •

edited

Loading

Uh oh!

knutwannheden Apr 23, 2026

Uh oh!

sambsnyd left a comment

Uh oh!

greg-at-moderne commented Apr 8, 2026 •

edited

Loading

Uh oh!

knutwannheden commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

knutwannheden commented Oct 1, 2025 • edited by timtebeek Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

timtebeek commented Dec 22, 2025

Uh oh!

timtebeek left a comment

Choose a reason for hiding this comment

Uh oh!

timtebeek Dec 31, 2025

Choose a reason for hiding this comment

Uh oh!

knutwannheden Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

timtebeek Dec 31, 2025

Choose a reason for hiding this comment

Uh oh!

knutwannheden Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

timtebeek commented Jan 5, 2026

Uh oh!

timtebeek Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

knutwannheden Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

sambsnyd left a comment

Choose a reason for hiding this comment

Uh oh!

greg-at-moderne commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

knutwannheden commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

knutwannheden commented Oct 1, 2025 •

edited by timtebeek

Loading

timtebeek Mar 13, 2026 •

edited

Loading

greg-at-moderne commented Apr 8, 2026 •

edited

Loading