On Thu, 28 Aug 2025 10:46:01 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 replaces the `NoRepl` suffix with `NoReplacement` in method names >> and consistently uses `throws CCE` in method footprints. > > Volkan Yazici has updated the pull request incrementally with one additional > commit since the last revision: > > Improve docs src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 392: > 390: * @throws CharacterCodingException For malformed input or > unmappable characters > 391: */ > 392: byte[] getBytesUTF8NoReplacement(String s) throws > CharacterCodingException; Happy to see this throwing CharacterCodingException as it was very confusing and fragile for the use sites to have to deal with IAE. It would be nice if these methods didn't have to have to "NoReplacement" suffix but you are bridging APIs that deal with coding errors so the verbose name help with that. Note that CodingErrorAction defines this as "REPORT" rather than no-REPLACE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2307333723
