On Thu, 28 Aug 2025 13:02:51 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/java/lang/String.java line 884: > >> 882: } >> 883: >> 884: private static byte[] encodeWithEncoderNoReplacement(Charset cs, >> byte coder, byte[] val) > > I wonder if we should rename this to encodeNoReplacement while we are here > because "WithEncoder" suggests it takes an encoder, which isn't the case. In 978d981039a, I did something else, which I believe also addresses your concern: removed the two `encodeWithEncoder()` and `encodeWithEncoderNoReplacement()` methods. Each were called from only one place, hence, simply inlined these calls. > 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. Agreed with your remark on naming. I find the negation in the `NoReplacement` very confusing – consider places doubling this negation. :melting_face: Renamed `NoReplacement` suffix to `OrThrow` in 14c0391a3aa. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2308338856 PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2308342544
