RFR: 8356439: Rename JavaLangAccess::*NoRepl methods

Chen Liang liach at openjdk.org
Mon Jul 28 09:47:04 UTC 2025


On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici 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`.)

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


More information about the core-libs-dev mailing list