build: declare UTF-8 source encoding, so Windows reads the sources correctly - #2047
Merged
Merged
Conversation
…rrectly Closes #2046. Without this the compiler uses the PLATFORM default charset: UTF-8 on Linux and macOS, windows-1252 on Windows. The same sources become different text depending on who builds them. It surfaced when the client E2E workflow compiled this repo on a windows-latest runner - the first time it had been built on Windows in CI. Five files fail outright ("unmappable character (0x9D) for encoding windows-1252"), and 109 more compile CLEANLY as windows-1252 and yield the wrong characters. That second group is the dangerous one, because it reaches user-visible strings with a green build: new JButton("▶") -> a button labelled "â–¶" Verified by forcing the charset javac would default to on Windows (MAVEN_OPTS=-Dfile.encoding=windows-1252) and reading the COMPILED class, not the log: unmappable errors compiled play-button constant without the fix 1 mojibake "â–¶" with the fix 0 correct U+25B6 This declares what is already true rather than converting anything - all 114 of those files decode cleanly as UTF-8 today - and it changes nothing on Linux or macOS, where UTF-8 was already the default. Released artifacts were never affected, since release builds run on Linux; this is for anyone building on Windows. project.reporting.outputEncoding is set alongside it for the same reason, and because Maven warns about it being unset once the source encoding is declared. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx
jcschaff
added a commit
that referenced
this pull request
Sep 1, 2026
#2047 set project.build.sourceEncoding=UTF-8 in the root pom, so passing it on the command line here is redundant. Removing it as promised in that PR. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx
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
1 participant
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.
Closes #2046.
One property. The root
pom.xmlset no source encoding, somaven-compiler-pluginused the platform default charset — UTF-8 on Linux and macOS,windows-1252on Windows. The same sources became different text depending on who built them.Surfaced when the client E2E workflow (#2045) compiled this repo on a
windows-latestrunner — the first time it has been built on Windows in CI.Two failure modes, and the quiet one matters more
Five files fail outright:
109 more compile cleanly and produce the wrong characters. Their bytes all happen to be defined in
windows-1252, so javac never complains — it just decodes them as something else, and it reaches user-visible strings:Fixing only the five loud ones would leave a developer with a corrupted client and no signal that anything was wrong.
Verified, not assumed
I can't run Windows here, so I forced the charset javac would default to there (
MAVEN_OPTS=-Dfile.encoding=windows-1252) and read the compiled class, not the build log:PathwayModel.java:237, the exact CI errorâ–¶U+25B6Both categories, both directions.
Risk
Low, and asymmetric. This declares what is already true rather than converting anything — all 114 affected files decode cleanly as UTF-8 today. On Linux and macOS nothing changes, because UTF-8 was already the default there; the normal build passes unchanged.
Released artifacts were never affected, since release builds run on Linux. This is for anyone building on Windows, and for the Windows lane of the client E2E.
project.reporting.outputEncodingis set alongside it for the same reason, and because Maven warns about it once the source encoding is declared.Follow-up
.github/workflows/client-e2e.yml(in #2045) passes-Dproject.build.sourceEncoding=UTF-8on the command line as a local workaround. That line becomes redundant once this lands and should be deleted — whichever of the two merges second.🤖 Generated with Claude Code
https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx