RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
Roger Riggs
rriggs at openjdk.org
Tue Jul 29 14:26:58 UTC 2025
On Mon, 21 Jul 2025 12:19:11 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`.)
>
> src/java.base/share/classes/java/lang/String.java line 1262:
>
>> 1260: MalformedInputException mie = new MalformedInputException(nb);
>> 1261: String msg = "malformed input off : " + off + ", length : " + nb;
>> 1262: mie.initCause(new IllegalArgumentException(msg));
>
> Earlier `throw(Malformed|Unmappable)` methods were throwing `IAE` containing _extra diagnostics information_ and wrapping a `CCE` as a cause. After switching methods to throw `CCE`, which doesn't have a ctor accepting a `String` message, to retain this extra diagnostics information, I've added swapped their causal chain placement, and wrapped `IAE` with a `CCE` this time.
>
> This played well with `CCE`-throwing methods, yet there are other `public` methods which did not have `throws CCE` in their footprint. For backward compatibility, in those spots, I've used `cce2iae` to obtain, again, a `IAE` wrapping the `CCE`, which matched the old behavior.
Introducing CCE (an IOException) into more places in string handling is going in the wrong direction.
As declared exceptions, they have to be caught and handled or re-thrown. That makes the source more complex and harder to maintain, as seen in the cce2iae mechanism.
The prior use of IAE encapsulating a CCE as needed is simpler and more consistent with other Runtime exception handling in most of the String class.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2240031460
More information about the core-libs-dev
mailing list