From 507ae9917635c098826563793d38b47d1f49a32c Mon Sep 17 00:00:00 2001 From: opendpp-node Date: Sun, 26 Jul 2026 16:25:43 +0300 Subject: [PATCH] fix(java): compile and document as UTF-8, not the platform default MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The generated sources are UTF-8 and carry the contract's own punctuation — em dashes, ellipses, curly quotes — lifted straight from the OpenAPI descriptions. javac and javadoc default to the JVM's PLATFORM encoding, which on a CI runner is US-ASCII. Every such character becomes `?`, javac emits an `unmappable character (0xE2)` line per occurrence, and because those are warnings rather than failures the build stays GREEN while the sources and javadoc jars published to Maven Central ship the corruption. Observed on opendpp-node's SDK regen verification: hundreds of error-looking lines across src/main and src/test, with the echoed source showing the damage directly — "Developers ??? API keys", "Tenant identity is token-bound ??? it is derived from your API key". Bytecode is unaffected (the damage is in comments), so this is cosmetic — but cosmetic on a public artifact carrying the company name, and it worsens with every typographic character added to the contract. `options.encoding` on JavaCompile covers main and test compilation. Javadoc needs all three: `encoding` is how it READS the sources, `charSet` and `docEncoding` are how it WRITES the HTML — set one and the jar is still corrupted at the other end. Fixed here rather than by setting LANG in the consuming workflow: this repo is where the Maven artifact is actually published, and the same corruption hits anyone building locally on an ASCII-defaulted machine. Fixes OpenDPP/opendpp-node#1156 --- java/build.gradle.kts | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/java/build.gradle.kts b/java/build.gradle.kts index d43108d..06d4426 100644 --- a/java/build.gradle.kts +++ b/java/build.gradle.kts @@ -36,10 +36,28 @@ java { toolchain { languageVersion.set(JavaLanguageVersion.of(17)) } } +// The generated sources are UTF-8 and carry the contract's own punctuation — em dashes, ellipses and +// curly quotes lifted straight from the OpenAPI descriptions. javac and javadoc default to the JVM's +// PLATFORM encoding, which on a CI runner is US-ASCII: every such character then becomes `?`, javac +// emits an `unmappable character (0xE2)` line per occurrence, and — because those are warnings, not +// failures — the build stays green while the sources and javadoc jars published to Maven Central ship +// the corruption. Pin UTF-8 explicitly so the toolchain reads what the generator actually wrote. +// (opendpp-node#1156.) +tasks.withType().configureEach { + options.encoding = "UTF-8" +} + // Maven Central requires a javadoc jar. The generated sources carry spec-derived markdown/HTML in // their doc comments, which strict doclint rejects — disable lint (the docs still render). +// `encoding` is how javadoc READS the sources; `charSet`/`docEncoding` are how it WRITES the HTML — +// all three are needed, or the jar is corrupted at one end or the other. tasks.withType().configureEach { - (options as StandardJavadocDocletOptions).addStringOption("Xdoclint:none", "-quiet") + (options as StandardJavadocDocletOptions).apply { + encoding = "UTF-8" + charSet = "UTF-8" + docEncoding = "UTF-8" + addStringOption("Xdoclint:none", "-quiet") + } } // Byte-reproducible archives + JPMS-friendly identity; ship LICENSE/NOTICE inside the jar.