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