RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v8]

[Volkan Yazici]

On Thu, 28 Aug 2025 13:02:51 GMT, Alan Bateman <alanb at 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