RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v13]

[Volkan Yazici]

On Wed, 6 Aug 2025 05:24:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Replace `requireNonNull` with implicit null checks to reduce bytecode size
>>  - Add `@bug` tags
>>  - Improve wording of `@param len`
>>  - Make source array bound checks lenient too
>>  - Cap destination array bounds
>>  - Fix bit shifting
>>  - Remove superseded `@throws` Javadoc
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Make `StringCoding` encoding intrinsics lenient
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/565028e3...c322f0e0
>
> src/java.base/share/classes/java/lang/StringCoding.java line 99:
> 
>> 97:      *         {@linkplain Preconditions#checkFromIndexSize(int, int, int, BiFunction) out of bounds}
>> 98:      */
>> 99:     static int countPositives(byte[] ba, int off, int len) {
> 
> If we name countPositives with parameter checking as countPositivesSB, this PR will have fewer changes.

I presume you mean we would not need to touch `vmIntrinsics.hpp` and such. I discussed this with @cl4es, and we decided to keep the _"`foo` for method, and `foo0` for intrinsic candidate"_ convention, since this matches the existing one. Unless more experienced maintainers tell do to otherwise, I will stick to the current style.

@wenshao, nevertheless, thanks so much for your kind review(s). Please keep them coming. 🙇

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2266851757