On Wed, 14 Oct 2026 11:45:35 GMT, Maurizio Cimadamore <[email protected]> wrote:
>> Liam Miller-Cushon 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 13 >> additional commits since the last revision: >> >> - Clean up unused import >> - Merge remote-tracking branch 'origin/master' into short-vector >> - Move asReadOnlyMemorySegment to String >> - Add a benchmark >> >> Also adjust javadoc, convert test to JUnit 5, other small adjustments >> - javadoc >> - Move access to jdk.internal.foreign.StringSupport >> - Make test inputs longer >> - Test coverage >> - Move to X-Vector.java.template, update javadoc, add masked overloads >> - ShortVector.compatibleWith >> - ... and 3 more: https://git.openjdk.org/jdk/compare/af59493b...1c6ff6ab > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java > line 3812: > >> 3810: * {@link ByteVector#fromString(VectorSpecies, String, Charset, >> int)}. >> 3811: * >> 3812: * @param string the string > > In some FFM methods we used these descriptions: > > > * @param str the Java string to be converted into a C string > * @param charset the charset used to {@linkplain Charset#newEncoder() > encode} the > * string bytes > > > They can use some tweaks of course (esp. first), like: > > > * the Java string to be encoded and loaded into a `ByteVector` > * the charset used to {@linkplain Charset#newEncoder() encode} the string > bytes Thanks, that's a helpful reference, and it would be good to document the string and charset better here. I think we want to be careful about 'encoded', though, since no encoding is performed. The result is a code unit sequence in the given charset, but we're not guaranteeing it's a valid encoding (there may be unpaired surrogates). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32373#discussion_r4270432299
