.groovy files still are corrupted by open rewrite for well over a year now.

[hazendaz]

I had previously opened tickets on this first with Jenkinsfile where its removing spacing by open rewrite. Every single version still continues to remove spaces when writting something like this

int value = something as int

The 'somethingasint' is the result making it useless for working with groovy. What ever came of fixing this as I see tickets claiming groovy was fixed but I've never seen it fixed at all. We alrady had to globally ignore Jenkinsfile. But any vars / groovy classes have the same issue.

[shanman190]

Hi @hazendaz,

Historically speaking, the fix was to fully and completely disabled recipes and the auto format system. A while later a new way to control auto formatting (ie. AutoFormatService) was introduced allowing each language binding to provide their specific implementations for how styling should behave for the specific language. At that time, the Groovy language binding reintroduced auto formatting being very specific about what to actually format and what to avoid as known problematic.

Things have been pretty quiet on the formatting front since the introduction of that new system, but it sounds like the as type cast may be causing you some problems.

As we ask in the bug report issue type, would you mind confirming that the behavior is present in the latest release as well as how you are executing and with what versions you're executing the OpenRewrite recipes using? Including the specific recipe that you're executing as well when you are observing the issue would also be of great help.

[knutwannheden]

I indeed also think this was fixed quite a while ago in release 8.11.1 as part of #3792. If you still see Groovy type casts getting mangled this way, it is possible that you are still using an old release of OpenRewrite.

[mccartney]

FWIW, I've just tried the following test:

    @Test
    void groovyStyleCastForInt() {
        rewriteRun(
          groovy(
            """
               int value = 3 as int
              """
          )
        );
    }

and it passes in the current main (7d7021603e4d451975b0e24ab60c369fa3cd07b7)

[hazendaz]

Still not fixed. Some files seem to work with exact same code but others still get space corrupted. I was unable to confirm until now due to couple of issues with open rewrite. First being each new release comes with other broken items and second being the license change that put us in complete lockout until it could get approved and its still not fully approved for us. So we only have bits and pieces of updates. So could it be entirely fixed now, maybe but more than half the stack now is on builds from last month from open rewrite.

[hazendaz]

I know I mentioned it early here, these are Jenkins groovy files. So lots of 'sh(...)' commands that occur, those typically echo data back and have to cast to Integer or int. So it looks more like this

int something = sh(
    script: 'echo 1',
    returnStatus: true
).trim() as Integer

What I don't get after latest updates, is that we had 4 files doing the same problem but 3 cleared, the code is identical and all cases the file is .groovy.

What it ends up with is this (note the extra space between = and sh).

int something =  sh(
    script: 'echo 1',
    returnStatus: true
).trim()asInteger

Hope that at least helps, I'm perplexed why all the ones before no longer show up but this one does. The only real difference is that its returnStatus instead of standard out but not sure how that would matter.

[greg-at-moderne]

I think we need some more detailed input.

I've just tried the following unit test in GroovyParserTest:

    @Test
    void castInALongerExpression() {
        rewriteRun(
          groovy(
            """
            int something = sh(
                script: 'echo 1',
                returnStatus: true
            ).trim() as Integer
            """
          )
        );
    }

and it worked.

Is it something specific recipe which is involved in these problems?

[hazendaz]

Try real code and not a test.

[hazendaz]

why does open rewrite take groovy casts such as 'as Integer' and strip spaces from it? ChatGPT said:

OpenRewrite strips spaces from Groovy casts like 'as Integer' → 'asInteger' most likely due to how it parses and prints AST nodes, not because Groovy syntax rules require it. 🧪 What’s Happening?

In Groovy:

def x = someValue as Integer

is valid and correct Groovy syntax. The as keyword is used for type coercion.

But OpenRewrite works by:

Parsing source code into an abstract syntax tree (AST)

Applying transformations

Printing back (serializing) the modified AST into source code

During this last step, OpenRewrite may normalize or simplify whitespace—especially if it doesn’t treat as casts as needing strict formatting. 🧱 Why It Matters

someValue as Integer is semantically different from someValueasInteger, but OpenRewrite may serialize it without a space as:

someValue asInteger

This is invalid Groovy and will fail at runtime or during compilation.

So if OpenRewrite is outputting asInteger, that's not valid Groovy, and it's a bug or limitation in its Groovy parser/printer. ✅ What You Can Do

1. Confirm OpenRewrite version

There may be an updated plugin or recipe pack that fixes this. 2. Check Groovy support status

Groovy support in OpenRewrite is less mature than Java or Kotlin. If you’re using it for Groovy scripts, some edge cases (like type coercion or dynamic constructs) may break. 3. File a bug or enhancement

You can open an issue at OpenRewrite GitHub — ideally with:

Original Groovy code

Transformed output

Expected correct output

4. Workaround: use parentheses or comments

Sometimes reformatting like:

def x = (someValue as Integer)

or adding a comment can protect against formatting normalization. 🧭 TL;DR

OpenRewrite likely strips the space in as Integer due to how it parses/prints AST nodes — not because it's valid Groovy.

This is likely a bug or formatting oversight in OpenRewrite's Groovy support.

You should report it and/or avoid such rewrites if the parser doesn't preserve semantics.

[knutwannheden]

If you could share the full script here or on a private channel, that would be extremely helpful.