RFR: 8356439: Rename JavaLangAccess::*NoRepl methods

[Volkan Yazici]

On Tue, 29 Jul 2025 13:25:14 GMT, Roger Riggs <rriggs at 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`.)
>
> If CCE should have a constructor with a message, it can be added if you have a clear idea how it would be used.

Motivated by @RogerRiggs inquiries, and @AlanBateman's below remark,

> Another high level comment from a first read is that it feels like there are two forms needed. One form is REPLACE action and doesn't throw. The other is REPORT action and throws CharacterCodingException.

grouped `String` methods by `doReplace` argument in 1fb8582e3f9. There are several `String` methods of the following form:

    private static byte[] encode8859_1(..., boolean doReplace) {
        // ...
        if (!doReplace) {
            throwUnmappable(sp);
        }
        // ...
     }

We want to make `doReplace = false` case visible in the function footprint, and this resulted in:

    private static byte[] encode8859_1(..., boolean doReplace) throws CCE { ... }

Though this propagates the checked `CCE` even for `doReplace = true`. To avoid this, I've grouped methods by `doReplace` argument into two:

    private static byte[] encode8859_1(...) { ... }
    private static byte[] encode8859_1NoReplacement(...) throws CCE { ... }

As a result,

1. `doReplace = true` call-sites invoke `encode8859_1()`, replacement *will* occur, and there is no checked `CCE` thrown
2. `doReplace = false` call-sites invoke `encode8859_1NoReplacement()`, replacement will *not* occur, and `CCE` needs to be handled

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3167985180