On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyaz...@openjdk.org> wrote:
> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid > characters, but throw `CharacterCodingException` on encounter. This behavior > cannot easily be derived from the method footprints, has been a source of > confusion for maintainers, and is not uniformly adopted, e.g., > `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. > This PR removes `NoRepl` suffix from method names and consistently uses > `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.) I strongly suggest against using CCE as the standard exception. The only place that relies on CCE is `Files`; IAE is more suitable for everywhere else. I recommend adding the special CCE handling in `Files` alone so we can remove the redundant try-catch everywhere else. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328: > 326: * @throws CharacterCodingException for malformed or unmappable bytes > 327: */ > 328: String uncheckedNewString(byte[] bytes, Charset cs) throws > CharacterCodingException; The docs should mention these two details: 1. This method does not replace upon malformed data but fails 2. This method does not copy the byte array for validation (can add to the warning) ------------- Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3038008799 PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2219148757
