elharo opened a new issue, #206: URL: https://github.com/apache/maven-script-interpreter/issues/206
**Describe the bug** Script file reading falls back to the platform default charset when no script encoding is configured, which makes build results dependent on the host encoding. `ScriptRunner.executeRun` decodes the script with `new String(bytes)` when `encoding` is `null` (ScriptRunner.java:202-206), i.e. the platform default charset. The `ScriptRunner` javadoc for `setScriptEncoding` (ScriptRunner.java:119-127) documents this default, but on JDK versions before 18 the platform default is locale/OS-dependent, so: - the same project can build successfully on one machine and fail (or behave differently) on another when the script contains non-ASCII characters; and - on JDK 18+ the default silently changes to UTF-8, so behavior differs across JDK versions. Additionally, `MirrorStreamWrapper.write(byte[], int, int)` decodes mirrored output with `new String(b, off, len)` (FileLogger.java:155), always the platform default charset, which can disagree with the charset used to read the script. **To Reproduce** Run a hook script containing a non-ASCII literal (e.g. `println "café"`) with `setScriptEncoding` never called, on two machines with different default charsets (or on JDK 11 vs JDK 17+). **Expected behavior** A stable, predictable default (e.g. UTF-8) regardless of platform, with an option to override. **Actual behavior** The decoded script content (and mirrored output) depends on the host's platform default charset. **Suggested fix** - Default `encoding` to `StandardCharsets.UTF_8` when not explicitly set instead of using the platform default. - Decode mirrored bytes in `MirrorStreamWrapper` with the same explicit charset. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
