Skip to content

Preserve escaped backslash-newline text in UsePortableNewlines - #1006

Draft
martinfrancois wants to merge 3 commits into
openrewrite:mainfrom
martinfrancois:agent/repro-use-portable-newlines-escaped-backslash
Draft

Preserve escaped backslash-newline text in UsePortableNewlines#1006
martinfrancois wants to merge 3 commits into
openrewrite:mainfrom
martinfrancois:agent/repro-use-portable-newlines-escaped-backslash

Conversation

@martinfrancois

@martinfrancois martinfrancois commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

Suggested review order: 9 of 52 (Score: 8)
Review first: #988

What's changed?

Updates UsePortableNewlines to distinguish a Java newline escape from an escaped backslash followed by n. The recipe keeps J.Literal.value and J.Literal.valueSource aligned for ordinary strings and text blocks, including Unicode escapes, octal line feeds, CRLF input, and text-block continuations.

What's your motivation?

Recipe: org.openrewrite.staticanalysis.UsePortableNewlines.

I found this by running org.openrewrite.staticanalysis.UsePortableNewlines from org.openrewrite.recipe:rewrite-static-analysis:2.39.0 on CodexModelDefaultsResolverTest.java in Symphony-Trello at a8013f27. I reproduced the same result with the latest released recipe artifact, org.openrewrite.recipe:rewrite-static-analysis:2.41.0. ./mvnw -DskipTests test-compile then fails with illegal escape character in this file and three other affected test files.

Before

printf '%%s\\n' '{"jsonrpc":"2.0","id":1,"result":{}}'

Actual after the recipe

printf '%%s\%n' '{"jsonrpc":"2.0","id":1,"result":{}}'

Expected after the recipe

(unchanged)

The source contains data for a generated shell script: two Java backslashes encode one runtime backslash. Replacing the n creates the invalid Java escape \%, so the transformed checkout no longer compiles.

Confirmed real-world execution

Anything in particular you'd like reviewers to focus on?

Please review the source-to-runtime newline mapping. A formatter newline such as "line=%s\\n" remains eligible, while escaped backslash-newline data remains unchanged.

Have you considered any alternatives or workarounds?

Counting only consecutive raw backslashes does not account for Unicode escapes or text-block continuations and leaves the literal's semantic value inconsistent with its printed source in those cases.

Any additional context

Pre-existing tests changed: None.

This change was prepared with AI assistance. I reviewed the target execution evidence, implementation, tests, and contribution text.

Checklist

@martinfrancois
martinfrancois force-pushed the agent/repro-use-portable-newlines-escaped-backslash branch from 22f04ed to 7279347 Compare August 16, 2026 02:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

1 participant