On Mon, 26 Jun 2023 15:25:08 GMT, Glavo <d...@openjdk.org> wrote:

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, 
> creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, 
> `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so 
> users can make the compiler happy without using useless try-catch statements.

Since it appears you missed my edit to my comment, this part can be replaced by 
the newStringLatin1NoRepl as well:
https://github.com/openjdk/jdk/blob/5ff42d14294199eb3bf10b66530f9249fb68810d/src/java.base/share/classes/java/lang/String.java#L812-L814

after this block:

        if (cd instanceof ArrayDecoder ad &&
                ad.isASCIICompatible() &&
                !StringCoding.hasNegatives(src, 0, src.length)) {

I've created a JBS ticket for this patch: 
https://bugs.openjdk.org/browse/JDK-8310901

In the ticket, I included a more comprehensive description about the whole 
situation (which is also why I strongly support this patch)

src/java.base/share/classes/java/lang/String.java line 803:

> 801:         }
> 802:         if (cs == US_ASCII.INSTANCE) {
> 803:             if (!StringCoding.hasNegatives(src, 0, src.length)) {

The duplicated compact_string logic below this line and that one for 
arraydecoder can be replaced by a simple newStringLatin1NoRepl as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1607741464
PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1607760378
PR Review Comment: https://git.openjdk.org/jdk/pull/14655#discussion_r1242379842

Reply via email to