From lancea at openjdk.org  Sat Oct  1 10:52:28 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 1 Oct 2022 10:52:28 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v4]
In-Reply-To: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
Message-ID: <OzS-leEMgHAR7JSa4RyIp4K5XrJZ38ZIdvfGiIfRqqg=.4409020a-7d1a-4f19-89d5-dbfe6f0f1302@github.com>

On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment typo
>  - Remove test wrapper

Looks good Justin, thank you for removing the wrapper.

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10475

From itakiguchi at openjdk.org  Mon Oct  3 07:16:29 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 3 Oct 2022 07:16:29 GMT
Subject: <i18n dev> RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <LGD-fiueNpTP8_1CwFf54JPt1o44S1lM0iMGbB4LiK8=.896fea2f-158e-4c9a-83f4-4394e2ff1789@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <LGD-fiueNpTP8_1CwFf54JPt1o44S1lM0iMGbB4LiK8=.896fea2f-158e-4c9a-83f4-4394e2ff1789@github.com>
Message-ID: <iVATVZV3X2vYq-kic_T0AWP48-tn-2TaTC3X9b8okuk=.20eb250d-ff9b-4922-a3e5-8b1303e9a53e@github.com>

On Fri, 26 Aug 2022 09:25:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets.
>> |Charset|Mix|SBCS|DBCS|
>> | -- | -- | -- | -- |
>> | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 |
>> | Korean | Cp933 | Cp833 | Cp834 |
>> 
>> But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets.
>> 
>> I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency
>> |Charset|Mix|SBCS|DBCS|
>> | ------------- | ------------- | ------------- | ------------- |
>> | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 |
>> | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** |
>> | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | 
>> 
>> *1: Cp037 compatible
>
>> Use following options, like OpenJDK: `java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047 20000 1 1` ICU4J `java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047_P100-1995 20000 1 1`
>> 
>> Actually, I'm confused by this result. Previously, I was just comparing A/A with B/B on OpenJDK's charset. I didn't think ICU4J's result would make a difference.
> 
> My initial reaction is one of relief that the icu4j provider can be used with current JDK builds. This means there is an option should we decide to stop adding more EBCDIC charsets to the JDK.
> 
> The test uses IBM-1047 and I can't tell if the icu4j provider is used or not. Charset doesn't define a provider method but I think would be useful to print cs.getClass() or cs.getClass().getModule() so we know which Charset implementation is used. Also I think any discussion on performance would be better served with a JMH benchmark rather than a standalone test.

Hello @AlanBateman .
Sorry I'm late.

I created Charset SPI JAR `x-IBM1047_SPI` (`custom-charsets.jar`) which was ported from `sun.nio.cs.SingleByte.java` and `IBM1047.java` (generated one).

Test code:

package com.example;

import java.nio.charset.Charset;
import org.openjdk.jmh.annotations.Benchmark;

public class MyBenchmark {

    final static String s;

    static {
        char[] ca = new char[0x2000];
        for (int i = 0; i < ca.length; i++) {
            ca[i] = (char) (i & 0xFF);
        }
        s = new String(ca);
    }

    @Benchmark
    public void testIBM1047() throws Exception {
        byte[] ba = s.getBytes("IBM1047");
    }

    @Benchmark
    public void testIBM1047_SPI() throws Exception {
        byte[] ba = s.getBytes("x-IBM1047_SPI");
    }

}

All test related files are in [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834).

Test results are as follows on RHEL8.6 x86_64 (Intel Core i7 3520M) :

1.8.0_345-b01
Benchmark                     Mode  Cnt      Score     Error  Units
MyBenchmark.testIBM1047      thrpt   25  53213.092 ? 126.962  ops/s
MyBenchmark.testIBM1047_SPI  thrpt   25  47442.669 ? 349.003  ops/s


20-ea+17-1181
Benchmark                     Mode  Cnt       Score      Error  Units
MyBenchmark.testIBM1047      thrpt   25  136331.141 ? 1078.481  ops/s
MyBenchmark.testIBM1047_SPI  thrpt   25   51563.213 ?  843.238  ops/s

IBM1047 is 2.6 times faster than the SPI version on JDK20.
I think this results are related to **JEP 254: Compact Strings** .
As I requested before, we'd like to use `sun.nio.cs.SingleByte*` and `sun.nio.cs.DoubleByte*` class as public API.

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

PR: https://git.openjdk.org/jdk/pull/9399

From alanb at openjdk.org  Mon Oct  3 08:53:35 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Oct 2022 08:53:35 GMT
Subject: <i18n dev> RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <iVATVZV3X2vYq-kic_T0AWP48-tn-2TaTC3X9b8okuk=.20eb250d-ff9b-4922-a3e5-8b1303e9a53e@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <LGD-fiueNpTP8_1CwFf54JPt1o44S1lM0iMGbB4LiK8=.896fea2f-158e-4c9a-83f4-4394e2ff1789@github.com>
 <iVATVZV3X2vYq-kic_T0AWP48-tn-2TaTC3X9b8okuk=.20eb250d-ff9b-4922-a3e5-8b1303e9a53e@github.com>
Message-ID: <m93ke-sbqGrG2rTVctm_idprBv-FqNs8eNRVf_9A3ic=.ee6bfb5f-78a3-4fd4-8bbc-7d19ea28766d@github.com>

On Mon, 3 Oct 2022 07:14:09 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> Test results are as follows on RHEL8.6 x86_64 (Intel Core i7 3520M) :
> 
> ```
> 1.8.0_345-b01
> Benchmark                     Mode  Cnt      Score     Error  Units
> MyBenchmark.testIBM1047      thrpt   25  53213.092 ? 126.962  ops/s
> MyBenchmark.testIBM1047_SPI  thrpt   25  47442.669 ? 349.003  ops/s
> ```
> 
>  ```
> 20-ea+17-1181
> Benchmark                     Mode  Cnt       Score      Error  Units
> MyBenchmark.testIBM1047      thrpt   25  136331.141 ? 1078.481  ops/s
> MyBenchmark.testIBM1047_SPI  thrpt   25   51563.213 ?  843.238  ops/s
> ```
> 
> IBM1047 is 2.6 times faster than the SPI version on JDK20. I think this results are related to **JEP 254: Compact Strings** . As I requested before, we'd like to use `sun.nio.cs.SingleByte*` and `sun.nio.cs.DoubleByte*` class as public API.

I don't think that is a workable option. Maybe you could do more performance analysis on the providers that are using the SPI to see if there are any secure primitives that would make sense to expose in java.nio.charset.spi?  I'm hesitate to suggest adding base classes to java.nio.charset.spi but that may be something that could be exposed too.

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

PR: https://git.openjdk.org/jdk/pull/9399

From bchristi at openjdk.org  Mon Oct  3 20:38:34 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 3 Oct 2022 20:38:34 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v4]
In-Reply-To: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
Message-ID: <c0yL64t_RWZ7ujH3QlOgoH-s2IqtiDHOy3v_DPxQTuc=.53dc7c6e-01f9-40c7-b9c8-7812fba79640@github.com>

On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment typo
>  - Remove test wrapper

Looks good.

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

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10475

From jjg at openjdk.org  Mon Oct  3 20:46:17 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 3 Oct 2022 20:46:17 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v4]
In-Reply-To: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
Message-ID: <M9tTeYjizIr5wugG1Pe3S6lbkQ3YNkYDLU5rrQd_J5w=.87ef3853-3cfd-493a-bec9-2f9abd75ae4d@github.com>

On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment typo
>  - Remove test wrapper

src/java.base/share/classes/java/text/DigitList.java line 796:

> 794:         temp.append("x10^");
> 795:         temp.append(decimalAt);
> 796:         return temp.toString();

This could use chained method calls and avoid the local variable completely.

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

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Mon Oct  3 21:22:03 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 3 Oct 2022 21:22:03 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v5]
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove temp var
  
  Remove temp variables and replace with method chaining when possible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10475/files
  - new: https://git.openjdk.org/jdk/pull/10475/files/442c2a4e..cf564a8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=03-04

  Stats: 13 lines in 1 file changed: 1 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Mon Oct  3 21:37:08 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 3 Oct 2022 21:37:08 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v4]
In-Reply-To: <M9tTeYjizIr5wugG1Pe3S6lbkQ3YNkYDLU5rrQd_J5w=.87ef3853-3cfd-493a-bec9-2f9abd75ae4d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
 <M9tTeYjizIr5wugG1Pe3S6lbkQ3YNkYDLU5rrQd_J5w=.87ef3853-3cfd-493a-bec9-2f9abd75ae4d@github.com>
Message-ID: <vLxHg_gfX5k05jakI8asWsOWefvgBSFB322-G7XuUh0=.390df7e4-ac0e-42aa-99ba-b2d29a8ef216@github.com>

On Mon, 3 Oct 2022 20:42:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove comment typo
>>  - Remove test wrapper
>
> src/java.base/share/classes/java/text/DigitList.java line 796:
> 
>> 794:         temp.append("x10^");
>> 795:         temp.append(decimalAt);
>> 796:         return temp.toString();
> 
> This could use chained method calls and avoid the local variable completely.

Thanks for pointing that out, made the switch there and in the getDouble() method as well.

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

PR: https://git.openjdk.org/jdk/pull/10475

From cjplummer at openjdk.org  Tue Oct  4 18:23:32 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 4 Oct 2022 18:23:32 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
 <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
Message-ID: <CR61AGqmsFAARRtaenUEX9DJvp3BC5TknkAuUGNXr8w=.ba3ebdbf-056c-46b7-8762-3e6aff4f1edd@github.com>

On Wed, 28 Sep 2022 15:32:11 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> The title was edited by someone other than me, as you can see from the PR history.

The PR title needs to match the CR synopsis, so update the CR first, and then update the PR.

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

PR: https://git.openjdk.org/jdk/pull/10029

From bchristi at openjdk.org  Tue Oct  4 18:24:34 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Oct 2022 18:24:34 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v5]
In-Reply-To: <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
Message-ID: <Js1_DOMQhbgKxw4sht8sWxdKxSBVNBnQIIPwBFNFEqk=.8a5b4c79-b64c-4944-9490-6709be0e2c00@github.com>

On Mon, 3 Oct 2022 21:22:03 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove temp var
>   
>   Remove temp variables and replace with method chaining when possible

Changes requested by bchristi (Reviewer).

src/java.base/share/classes/java/text/DigitList.java line 161:

> 159:     public final double getDouble() {
> 160:         if (count == 0) {
> 161:             return 0.0;

The doc for this method is incorrect:

* If (count == 0) this throws a NumberFormatException, which
* mimics Long.parseLong().

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

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Tue Oct  4 18:46:14 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 4 Oct 2022 18:46:14 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v5]
In-Reply-To: <Js1_DOMQhbgKxw4sht8sWxdKxSBVNBnQIIPwBFNFEqk=.8a5b4c79-b64c-4944-9490-6709be0e2c00@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
 <Js1_DOMQhbgKxw4sht8sWxdKxSBVNBnQIIPwBFNFEqk=.8a5b4c79-b64c-4944-9490-6709be0e2c00@github.com>
Message-ID: <08qgcEKEf6WzestzSY9xiXCA1tLbdb4zEfCtAh1UF90=.bc631d76-0c99-4967-9108-87f277aaeddd@github.com>

On Tue, 4 Oct 2022 18:20:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove temp var
>>   
>>   Remove temp variables and replace with method chaining when possible
>
> src/java.base/share/classes/java/text/DigitList.java line 161:
> 
>> 159:     public final double getDouble() {
>> 160:         if (count == 0) {
>> 161:             return 0.0;
> 
> The doc for this method is incorrect:
> 
> * If (count == 0) this throws a NumberFormatException, which
> * mimics Long.parseLong().

I believe that relates to https://bugs.openjdk.org/browse/JDK-8170389

Which I can address in a separate PR

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

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Tue Oct  4 18:46:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Oct 2022 18:46:14 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v5]
In-Reply-To: <08qgcEKEf6WzestzSY9xiXCA1tLbdb4zEfCtAh1UF90=.bc631d76-0c99-4967-9108-87f277aaeddd@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
 <Js1_DOMQhbgKxw4sht8sWxdKxSBVNBnQIIPwBFNFEqk=.8a5b4c79-b64c-4944-9490-6709be0e2c00@github.com>
 <08qgcEKEf6WzestzSY9xiXCA1tLbdb4zEfCtAh1UF90=.bc631d76-0c99-4967-9108-87f277aaeddd@github.com>
Message-ID: <Gav1KJeEKgHMIxaiL51B4DisgS3IYmCw8MqVtwTxz9Q=.d934cb9c-7c9a-4d69-a492-f412deff59a6@github.com>

On Tue, 4 Oct 2022 18:42:52 GMT, Justin Lu <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DigitList.java line 161:
>> 
>>> 159:     public final double getDouble() {
>>> 160:         if (count == 0) {
>>> 161:             return 0.0;
>> 
>> The doc for this method is incorrect:
>> 
>> * If (count == 0) this throws a NumberFormatException, which
>> * mimics Long.parseLong().
>
> I believe that relates to https://bugs.openjdk.org/browse/JDK-8170389
> 
> Which I can address in a separate PR

Good catch! Also, I think the comment should compare it with `Double.parseDouble()`

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

PR: https://git.openjdk.org/jdk/pull/10475

From bchristi at openjdk.org  Tue Oct  4 20:21:23 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Oct 2022 20:21:23 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v5]
In-Reply-To: <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
Message-ID: <8eLvxvzT0L8G4yyg42K3xOsiTf5IAe3DYmqwHCzogo4=.4c20bf2f-991f-42e9-b7da-21db4d5fde21@github.com>

On Mon, 3 Oct 2022 21:22:03 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove temp var
>   
>   Remove temp variables and replace with method chaining when possible

Marked as reviewed by bchristi (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10475

From aivanov at openjdk.org  Wed Oct  5 13:27:29 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 13:27:29 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Changes requested by aivanov (Reviewer).

src/hotspot/share/opto/memnode.cpp line 2365:

> 2363:   if (x != this)  return x;
> 2364: 
> 2365:   // Take apart the address into an oop and offset.

?and _an_ offset??

src/java.xml/share/classes/org/w3c/dom/Document.java line 293:

> 291:      * <code>systemId</code>, and <code>notationName</code> attributes are
> 292:      * copied. If a <code>deep</code> import is requested, the descendants
> 293:      * of the source <code>Entity</code> are recursively imported and

This class may come from a 3rd party library. Anyone from `java.xml` can confirm it?

test/hotspot/jtreg/vmTestbase/nsk/share/locks/DeadlockMaker.java line 31:

> 29: /*
> 30:  * Class used to create deadlocked threads. It is possible create 2 or more deadlocked thread, also
> 31:  * is possible to specify resource of which type should lock each deadlocked thread

Suggestion:

 * it is possible to specify resource of which type should lock each deadlocked thread

It doesn't sound right without _?it?_.

test/jdk/com/sun/jdi/connect/spi/GeneratedConnectors.java line 28:

> 26:  * @summary Unit test for "Pluggable Connectors and Transports" feature.
> 27:  *
> 28:  * When a transport service is deployed the virtual machine

Suggestion:

 * When a transport service is deployed, the virtual machine

Let's add a comma for clarity.

test/jdk/java/security/testlibrary/SimpleOCSPServer.java line 445:

> 443: 
> 444:     /**
> 445:      * Check the status database for revocation information on one or more

Suggestion:

     * Check the status database for revocation information of one or more

test/jdk/sun/jvmstat/testlibrary/utils.sh line 181:

> 179:         if [ $? -eq 0 ]
> 180:         then
> 181:             # it's still lingering, now it is hard

Suggestion:

            # it's still lingering, now hit it hard

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

PR: https://git.openjdk.org/jdk/pull/10029

From aivanov at openjdk.org  Wed Oct  5 14:17:13 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 14:17:13 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <VFoXow0glQ610il1bDU1a3KC6dP3S7cxr63T2tRJRZE=.46f798ba-af7c-4aea-9ca8-ce706658b5cc@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

I agree with everyone who said the PR should be broken to smaller pieces so that it touches code / tests in one or two packages, modules. It would be easier to review, you would need to get an approval from reviewers in a one or two specific areas. At this time, this PR touches files in 11 areas according the number of labels which correspond to a specific mailing list where discussions for the area are held.

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

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Wed Oct  5 18:47:30 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 5 Oct 2022 18:47:30 GMT
Subject: <i18n dev> Integrated: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <JCvnP2YV6bKf4sudLPtCtdpUEV67d93eDfHxvI-xGEY=.eebff242-4353-4617-bc40-b2b7c8dee4cc@github.com>

On Wed, 28 Sep 2022 22:54:33 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

This pull request has now been integrated.

Changeset: 87acfee3
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87acfee3c3e8dbc36b87e449f69fda6fca0088f6
Stats:     90 lines in 7 files changed: 10 ins; 35 del; 45 mod

8294397: Replace StringBuffer with StringBuilder within java.text

Reviewed-by: lancea, naoto, bchristi

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

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Thu Oct  6 21:38:48 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 6 Oct 2022 21:38:48 GMT
Subject: <i18n dev> RFR: 6560981: (cal) unused local variables in
 GregorianCalendar, etc.
Message-ID: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>

Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.

Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.

Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

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

Commit messages:
 - Update copyright
 - Remove unusued/redundant code

Changes: https://git.openjdk.org/jdk/pull/10585/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6560981
  Stats: 9 lines in 3 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10585/head:pull/10585

PR: https://git.openjdk.org/jdk/pull/10585

From naoto at openjdk.org  Thu Oct  6 21:53:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Oct 2022 21:53:14 GMT
Subject: <i18n dev> RFR: 6560981: (cal) unused local variables in
 GregorianCalendar, etc.
In-Reply-To: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
References: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
Message-ID: <bv7n4TnMxBkpD7yllMvHzBDi0UjqXzuI_i8IuOqhWgk=.86101fe9-8394-4047-86d5-e79c306ea534@github.com>

On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.
> 
> Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.
> 
> Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10585

From bchristi at openjdk.org  Thu Oct  6 22:15:26 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 6 Oct 2022 22:15:26 GMT
Subject: <i18n dev> RFR: 6560981: (cal) unused local variables in
 GregorianCalendar, etc.
In-Reply-To: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
References: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
Message-ID: <ZCsVYRYfabwYNqbJHSLyoiJgv_AF7JegAPwCUeN_nDQ=.958f0381-5b90-48ee-a3de-bdafbfc8c80e@github.com>

On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.
> 
> Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.
> 
> Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

Looks fine

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

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10585

From iris at openjdk.org  Thu Oct  6 22:15:28 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 6 Oct 2022 22:15:28 GMT
Subject: <i18n dev> RFR: 6560981: (cal) unused local variables in
 GregorianCalendar, etc.
In-Reply-To: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
References: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
Message-ID: <E7fQn2cZOuw7fxyMZUQWzo9tKvq17rdGN-trvldQ7Zo=.dc0d895c-6e7c-471f-8dcc-0c512a77275a@github.com>

On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.
> 
> Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.
> 
> Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10585

From duke at openjdk.org  Thu Oct  6 23:20:31 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 6 Oct 2022 23:20:31 GMT
Subject: <i18n dev> Integrated: 6560981: (cal) unused local variables in
 GregorianCalendar, etc.
In-Reply-To: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
References: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
Message-ID: <WcBGom90hV2XFskBrWdeOsTjSst_qYdodqvIbTp38b8=.f9bc82fb-3654-4695-82f8-6e2a578c7001@github.com>

On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.
> 
> Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.
> 
> Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

This pull request has now been integrated.

Changeset: d4c9a880
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4c9a88073479ff05e6c07ed599c546826d6f6ba
Stats:     9 lines in 3 files changed: 0 ins; 6 del; 3 mod

6560981: (cal) unused local variables in GregorianCalendar, etc.

Reviewed-by: naoto, bchristi, iris

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

PR: https://git.openjdk.org/jdk/pull/10585

From alanb at openjdk.org  Fri Oct  7 12:53:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Oct 2022 12:53:30 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

src/java.se/share/data/jdwp/jdwp.spec line 101:

> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
> 100:         "in the target VM. This includes platform threads created with the Thread "
> 101:         "API and all native threads attached to the target VM with JNI code."

The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

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

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Wed Oct 12 00:10:03 2022
From: duke at openjdk.org (David Alvarez)
Date: Wed, 12 Oct 2022 00:10:03 GMT
Subject: <i18n dev> RFR: 8295173: (tz) Update Timezone Data to 2022e
Message-ID: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>

Please, review this PR for an update of timezone data. No changes besides the import were needed.

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

Commit messages:
 - (tz) Update Timezone Data to 2022e

Changes: https://git.openjdk.org/jdk/pull/10666/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10666&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295173
  Stats: 80 lines in 5 files changed: 22 ins; 12 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/10666.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10666/head:pull/10666

PR: https://git.openjdk.org/jdk/pull/10666

From ysatowse at openjdk.org  Wed Oct 12 02:05:05 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Wed, 12 Oct 2022 02:05:05 GMT
Subject: <i18n dev> RFR: 8295173: (tz) Update Timezone Data to 2022e
In-Reply-To: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
Message-ID: <etwG9IEB7pT5bjK6_ptbrZSV-u7ZX9KsT6SYhtnbXEI=.1d0bee35-0fa3-4338-95fb-b8a233f8e1fc@github.com>

On Wed, 12 Oct 2022 00:01:50 GMT, David Alvarez <duke at openjdk.org> wrote:

> Please, review this PR for an update of timezone data. No changes besides the import were needed.

We normally run test/jdk/java/util/TimeZone/tools/share/Makefile with the JDK integrating new timezone data in order to generate test/jdk/java/util/TimeZone/TimeZoneData/{VERSION, aliases.txt, displaynamex.txt), which are used by some tests.  With tz2022e integrated JDK, the displaynames.txt seems to be updated along with the changes in tzdata2022e.  Since the changes are just removing the entries for Asia/Amman and Asia/Damascus from displaynamex.txt, the will be no impact for the test runs.  But I would suggest these may want to be included for consistency.

diff --git a/test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt b/test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt
index b3823958ae4..2f2786f1c69 100644
--- a/test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt
+++ b/test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt
@@ -97,9 +97,7 @@ America/Winnipeg CST CDT
 America/Yakutat AKST AKDT
 America/Yellowknife MST MDT
 Antarctica/Macquarie AEST AEDT
-Asia/Amman EET EEST
 Asia/Beirut EET EEST
-Asia/Damascus EET EEST
 Asia/Famagusta EET EEST
 Asia/Gaza EET EEST
 Asia/Hebron EET EEST

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

PR: https://git.openjdk.org/jdk/pull/10666

From duke at openjdk.org  Wed Oct 12 04:35:08 2022
From: duke at openjdk.org (David Alvarez)
Date: Wed, 12 Oct 2022 04:35:08 GMT
Subject: <i18n dev> RFR: 8295173: (tz) Update Timezone Data to 2022e [v2]
In-Reply-To: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
Message-ID: <7ttKgbE_WY33wQTCW3VvbGui3XVnpks9CynFzx0eNgA=.83c050d8-b63b-4644-a002-3d57c909a24a@github.com>

> Please, review this PR for an update of timezone data. No changes besides the import were needed.

David Alvarez has updated the pull request incrementally with one additional commit since the last revision:

  Update displaynames.txt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10666/files
  - new: https://git.openjdk.org/jdk/pull/10666/files/ffbbfa84..869d7b3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10666&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10666&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10666.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10666/head:pull/10666

PR: https://git.openjdk.org/jdk/pull/10666

From duke at openjdk.org  Wed Oct 12 04:35:09 2022
From: duke at openjdk.org (David Alvarez)
Date: Wed, 12 Oct 2022 04:35:09 GMT
Subject: <i18n dev> RFR: 8295173: (tz) Update Timezone Data to 2022e
In-Reply-To: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
Message-ID: <D8Clt_iQ_BvbOT-DynkauyAx5KmnVkR8whQ1d6TK4uM=.9ecf7d43-87a1-454a-aaf1-e03e26706932@github.com>

On Wed, 12 Oct 2022 00:01:50 GMT, David Alvarez <duke at openjdk.org> wrote:

> Please, review this PR for an update of timezone data. No changes besides the import were needed.

Thanks for the explanation!. I've run that Makefile and i can see the new files, including a displaynames.txt that matches what you're sending. I will update this PR with the proper change

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

PR: https://git.openjdk.org/jdk/pull/10666

From ihse at openjdk.org  Wed Oct 12 11:03:13 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:03:13 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <alS4RnqiswWATvVIotbyYFGhRJDyO5_JCAU24l30HBs=.2fa01b63-f674-4c78-b7bc-798120cf9694@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>
 <alS4RnqiswWATvVIotbyYFGhRJDyO5_JCAU24l30HBs=.2fa01b63-f674-4c78-b7bc-798120cf9694@github.com>
Message-ID: <-2yChViV1cpNVUS3HMzM3d9I7J3ReBWr9G2w3skxF9M=.034c3f7f-d7fd-4961-a468-e250ac876062@github.com>

On Tue, 13 Sep 2022 22:03:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> I see now that Phil cryptically said:
>> 
>>> Regarding changes in gif + freetype
>> diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c \
>> \
>> diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c \
>> \
>> Please exclude ALL 3rd party libraries from this PR.
>> 
>> That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.
>
>> I see now that Phil cryptically said:
>> 
>> > Regarding changes in gif + freetype
>> > diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c 
>> > 
>> > diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c 
>> > 
>> > Please exclude ALL 3rd party libraries from this PR.
>> 
>> That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.
> 
> I don't know why I mentioned those two files like that but those particular two are JDK code so are fair game.
> 
> I did write 
> "Please exclude ALL 3rd party libraries from this PR."
> and later :
> "We need to revert the native code changes to "libfreetype".
> and those points are correct.
> 
> You did fix the latter, but there are still some 3rd party files in there that are edited : glext.h, wsutils.h, multiVis.c

@prrace Do you think you can approve this now, so we can finally close it? (I promise I won't open huge PRs like this in the future; lesson well learnt.)

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

PR: https://git.openjdk.org/jdk/pull/8328

From ihse at openjdk.org  Wed Oct 12 11:24:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:24:17 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v11]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <qBSXGkjfwNWatB2ur-Lr_FcPctqCFo0XlyjJfcM6hfo=.df53e761-0ba4-47f7-917e-61ec70ffc721@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Merge branch 'master' into typos-in-java.desktop
 - Merge branch 'master' into typos-in-java.desktop
 - Revert changes to glext.h
 - Revert changes to multiVis.c and wsutils.h
 - Merge branch 'master' into typos-in-java.desktop
 - Revert changes in libjpeg
 - Revert changes in libfreetype
 - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - ... and 40 more: https://git.openjdk.org/jdk/compare/bdb4ed0f...e2d0979f

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

Changes: https://git.openjdk.org/jdk/pull/8328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=10
  Stats: 1017 lines in 483 files changed: 0 ins; 0 del; 1017 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328

From naoto at openjdk.org  Wed Oct 12 20:11:13 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Oct 2022 20:11:13 GMT
Subject: <i18n dev> RFR: 8295232: "java.locale.useOldISOCodes" property is
 read lazily
Message-ID: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>

Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

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

Commit messages:
 - 8295232: "java.locale.useOldISOCodes" property is read lazily

Changes: https://git.openjdk.org/jdk/pull/10683/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10683&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295232
  Stats: 71 lines in 3 files changed: 69 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10683.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10683/head:pull/10683

PR: https://git.openjdk.org/jdk/pull/10683

From lancea at openjdk.org  Wed Oct 12 20:22:02 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 12 Oct 2022 20:22:02 GMT
Subject: <i18n dev> RFR: 8295232: "java.locale.useOldISOCodes" property
 is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <gbN1qPx3mY59A7B2ctZfFMdbxZjo3uUIyJW_fVbSScg=.882835b0-dd15-42a7-b029-84c0b7f8a600@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10683

From bpb at openjdk.org  Wed Oct 12 20:35:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Oct 2022 20:35:01 GMT
Subject: <i18n dev> RFR: 8295232: "java.locale.useOldISOCodes" property
 is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <QAmXl-Uvs-hFz5PDlpaqPKk8beY0F6Amu6JQdww0dSM=.547b1100-a038-4861-8c98-c163b6faacec@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10683

From iris at openjdk.org  Wed Oct 12 21:22:05 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 12 Oct 2022 21:22:05 GMT
Subject: <i18n dev> RFR: 8295232: "java.locale.useOldISOCodes" property
 is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <41HXWAXtYCL2DQ4hp6yrDLZkOmcOpGDP6_6eILYBeDo=.85b426ab-9cc7-403e-ba73-768cffb8fd40@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10683

From rriggs at openjdk.org  Wed Oct 12 21:25:30 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Oct 2022 21:25:30 GMT
Subject: <i18n dev> RFR: 8295232: "java.locale.useOldISOCodes" property
 is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <aQoUKIMHYzBATE31nPyc2OFrIJJYkw0vm4ylgV7PjxQ=.bd10b320-f228-4448-a05e-860c4e797e43@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10683

From coffeys at openjdk.org  Thu Oct 13 10:36:27 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 10:36:27 GMT
Subject: <i18n dev> RFR: 8295232: "java.locale.useOldISOCodes" property
 is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <pEvO6BeoHA_sbDL7bhubQFZotGm9XmAMY2ep8nKVvNo=.98e1a149-a23a-4458-ae80-dfec3402e8b9@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by coffeys (Reviewer).

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 38:

> 36: import jdk.internal.util.StaticProperty;
> 37: import jdk.internal.vm.annotation.Stable;
> 38: import sun.security.action.GetPropertyAction;

unused import can be removed "sun.security.action.GetPropertyAction"

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

PR: https://git.openjdk.org/jdk/pull/10683

From naoto at openjdk.org  Thu Oct 13 16:00:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Oct 2022 16:00:56 GMT
Subject: <i18n dev> RFR: 8295232: "java.locale.useOldISOCodes" property
 is read lazily
In-Reply-To: <pEvO6BeoHA_sbDL7bhubQFZotGm9XmAMY2ep8nKVvNo=.98e1a149-a23a-4458-ae80-dfec3402e8b9@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
 <pEvO6BeoHA_sbDL7bhubQFZotGm9XmAMY2ep8nKVvNo=.98e1a149-a23a-4458-ae80-dfec3402e8b9@github.com>
Message-ID: <F9qIEaHSKaSsFed0PxMx7GrZRAmrsfKa-8VWQMHkJxg=.d04f9932-acb0-472c-9c7a-0285b382760c@github.com>

On Thu, 13 Oct 2022 10:33:32 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 38:
> 
>> 36: import jdk.internal.util.StaticProperty;
>> 37: import jdk.internal.vm.annotation.Stable;
>> 38: import sun.security.action.GetPropertyAction;
> 
> unused import can be removed "sun.security.action.GetPropertyAction"

Thanks, Sean. Will remove this unnecessary import before the integration.

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

PR: https://git.openjdk.org/jdk/pull/10683

From naoto at openjdk.org  Thu Oct 13 16:10:04 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Oct 2022 16:10:04 GMT
Subject: <i18n dev> RFR: 8295232: "java.locale.useOldISOCodes" property
 is read lazily [v2]
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <GgAAVn3QxlrQFJuUroZa6oM71CgGhQoaHFdSOjsY12g=.c94954e6-ee7f-4b4e-86a8-91a0d463eca2@github.com>

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10683/files
  - new: https://git.openjdk.org/jdk/pull/10683/files/20bc893d..c920070b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10683&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10683&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10683.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10683/head:pull/10683

PR: https://git.openjdk.org/jdk/pull/10683

From naoto at openjdk.org  Thu Oct 13 16:24:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Oct 2022 16:24:17 GMT
Subject: <i18n dev> Integrated: 8295232: "java.locale.useOldISOCodes"
 property is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <9N0y7WJW_hvIYy3547YRh5z6uZRNzuLwFOxmPHwFKfg=.b1af8721-86be-465b-9ca0-00973b8ed606@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

This pull request has now been integrated.

Changeset: 4224d451
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4224d45132b98e4f7bb7a96b696692d2f0bf645e
Stats:     72 lines in 3 files changed: 69 ins; 2 del; 1 mod

8295232: "java.locale.useOldISOCodes" property is read lazily

Reviewed-by: lancea, bpb, iris, rriggs, coffeys

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

PR: https://git.openjdk.org/jdk/pull/10683

From naoto at openjdk.org  Thu Oct 13 18:58:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Oct 2022 18:58:56 GMT
Subject: <i18n dev> RFR: 8295173: (tz) Update Timezone Data to 2022e [v2]
In-Reply-To: <7ttKgbE_WY33wQTCW3VvbGui3XVnpks9CynFzx0eNgA=.83c050d8-b63b-4644-a002-3d57c909a24a@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
 <7ttKgbE_WY33wQTCW3VvbGui3XVnpks9CynFzx0eNgA=.83c050d8-b63b-4644-a002-3d57c909a24a@github.com>
Message-ID: <aXyNegN4lK5fulhitXeLfG4sgh90xJlvpVdFvbnQ9vo=.ee1a1b6f-8f64-4686-b203-4ed5c90b58c0@github.com>

On Wed, 12 Oct 2022 04:35:08 GMT, David Alvarez <duke at openjdk.org> wrote:

>> Please, review this PR for an update of timezone data. No changes besides the import were needed.
>
> David Alvarez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update displaynames.txt

Looks good. Thanks for the fix.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10666

From duke at openjdk.org  Thu Oct 13 20:53:57 2022
From: duke at openjdk.org (David Alvarez)
Date: Thu, 13 Oct 2022 20:53:57 GMT
Subject: <i18n dev> Integrated: 8295173: (tz) Update Timezone Data to 2022e
In-Reply-To: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
Message-ID: <fmECM7ctYtz-IY0gWfswOYrecKAzXbROGRYiaiML4-E=.e9e13778-f774-47a4-b68e-16e55aba47f9@github.com>

On Wed, 12 Oct 2022 00:01:50 GMT, David Alvarez <duke at openjdk.org> wrote:

> Please, review this PR for an update of timezone data. No changes besides the import were needed.

This pull request has now been integrated.

Changeset: 21407dec
Author:    David Alvarez <alvdavi at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21407dec0156301871a83328615e4d975c4287c4
Stats:     82 lines in 6 files changed: 22 ins; 14 del; 46 mod

8295173: (tz) Update Timezone Data to 2022e

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/10666

From duke at openjdk.org  Thu Oct 13 22:01:58 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 13 Oct 2022 22:01:58 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
Message-ID: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>

Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 

Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 

Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

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

Commit messages:
 - Adjust template to reduce whitespace
 - Re-add modified BasicDateTime test contents removed by generated template
 - Adjust template to cleanup errors

Changes: https://git.openjdk.org/jdk/pull/10684/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10684&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295000
  Stats: 312 lines in 20 files changed: 205 ins; 6 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/10684.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10684/head:pull/10684

PR: https://git.openjdk.org/jdk/pull/10684

From bchristi at openjdk.org  Fri Oct 14 00:42:05 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 14 Oct 2022 00:42:05 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
Message-ID: <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>

On Thu, 13 Oct 2022 01:02:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
> 
> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
> 
> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

Changes requested by bchristi (Reviewer).

test/jdk/java/util/Formatter/BasicByteObject.java line 232:

> 230: 
> 231:     private static Byte negate(Byte v) {
> 232:         return (byte) -v.byteValue();

We want to be returning a `Byte`, so casting to `(byte)` doesn't seem right to me.

`Byte.valueOf()` takes a `byte` and returns a `Byte`, so using that as the replacement for `new Byte`, we get:
`return Byte.valueOf(-v.byteValue());`
Is there a way to get the template to do that?

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

PR: https://git.openjdk.org/jdk/pull/10684

From duke at openjdk.org  Mon Oct 17 22:09:42 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 17 Oct 2022 22:09:42 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic script
 into a Java native test launcher
Message-ID: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>

Issue: Formatter unit tests are launched via basic.sh

Fix: Replace basic.sh with a Java test launcher

Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 


Original output on success
<img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">


New output on success
<img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

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

Commit messages:
 - Address PR comments (Junit, exceptions)
 - Remove basic.sh, replace with java test launcher

Changes: https://git.openjdk.org/jdk/pull/10715/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295239
  Stats: 165 lines in 3 files changed: 102 ins; 61 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Mon Oct 17 22:09:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Oct 2022 22:09:45 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <C2M8mobydziM2sFOUlh8S5vOR8QZTDA_J3hZeUKHXx4=.e765c9c1-6120-4504-bba3-fc2157e3500a@github.com>

On Fri, 14 Oct 2022 20:38:32 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

test/jdk/java/util/Formatter/Basic.java line 24:

> 22:  */
> 23: 
> 24: import static java.lang.System.out;

It's not your change, but probably this does not seem necessary, as `out` appears only once.

test/jdk/java/util/Formatter/BasicTestLauncher.java line 36:

> 34:  *      8059175 8204229
> 35:  *
> 36:  * @run main/othervm BasicTestLauncher

It does not seem to require `othervm` mode.

test/jdk/java/util/Formatter/BasicTestLauncher.java line 48:

> 46:         runFormatterTests(TZ_UP);
> 47:         runFormatterTests(TZ_AN);
> 48:     }

Could use testng/junit, instead of normal main. This way both timezones are guaranteed to be tested. Currently, if an error occurs with `US/Pacific`, `Asia/Novosibirsk` will not run.

test/jdk/java/util/Formatter/BasicTestLauncher.java line 74:

> 72:             throw new RuntimeException(String.format("$$$ Error(s) found within %s subprocess: " +
> 73:                     "%s%n", timeZone, err.getMessage()));
> 74:         }

I'd prefer not to catch an exception (and turn it into `RuntimeException`) here, as the exception type will be lost.

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Mon Oct 17 22:09:45 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 17 Oct 2022 22:09:45 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher
In-Reply-To: <C2M8mobydziM2sFOUlh8S5vOR8QZTDA_J3hZeUKHXx4=.e765c9c1-6120-4504-bba3-fc2157e3500a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <C2M8mobydziM2sFOUlh8S5vOR8QZTDA_J3hZeUKHXx4=.e765c9c1-6120-4504-bba3-fc2157e3500a@github.com>
Message-ID: <56-sprlAOMO7jocaocsNMDpHP64K4XVJ34Bj_O1MGpc=.e4616ffd-7b1f-485d-83e5-62e6cc371a88@github.com>

On Fri, 14 Oct 2022 21:48:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> test/jdk/java/util/Formatter/Basic.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: import static java.lang.System.out;
> 
> It's not your change, but probably this does not seem necessary, as `out` appears only once.

Got rid of it!

> test/jdk/java/util/Formatter/BasicTestLauncher.java line 48:
> 
>> 46:         runFormatterTests(TZ_UP);
>> 47:         runFormatterTests(TZ_AN);
>> 48:     }
> 
> Could use testng/junit, instead of normal main. This way both timezones are guaranteed to be tested. Currently, if an error occurs with `US/Pacific`, `Asia/Novosibirsk` will not run.

Thank you for the catch, replaced with JUnit

> test/jdk/java/util/Formatter/BasicTestLauncher.java line 74:
> 
>> 72:             throw new RuntimeException(String.format("$$$ Error(s) found within %s subprocess: " +
>> 73:                     "%s%n", timeZone, err.getMessage()));
>> 74:         }
> 
> I'd prefer not to catch an exception (and turn it into `RuntimeException`) here, as the exception type will be lost.

Thank you, separated to distinguish the IO and runtime exceptions

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

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Mon Oct 17 22:28:22 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 17 Oct 2022 22:28:22 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>

On Fri, 14 Oct 2022 20:38:32 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Hi Justin,

A few comments on a quick pass through your changes

test/jdk/java/util/Formatter/Basic.java line 93:

> 91:                                        + fail + " failure(s), first", first);
> 92:         else
> 93:             System.out.println("all " + (fail + pass) + " tests passed");

Perhaps use System.out.printf vs println and "fail" should not be needed as all tests passed

test/jdk/java/util/Formatter/BasicTestLauncher.java line 52:

> 50: 
> 51:     @Test
> 52:     public void testUsPac() throws IOException{

You could use a DataProvider

test/jdk/java/util/Formatter/BasicTestLauncher.java line 99:

> 97:         }catch(RuntimeException err){
> 98:             throw new RuntimeException(String.format("$$$ %s: Test(s) failed or TestJVM did not build correctly." +
> 99:                     " Check stderr output from diagnostics summary above%n",  err.getMessage()));

Do you need to catch the RuntimeException and then throw a new RuntimeException?  I think you might want to consider reworking this

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

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Mon Oct 17 22:43:03 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 17 Oct 2022 22:43:03 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher
In-Reply-To: <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
Message-ID: <EHnJYJ7PlmwIN4QzgGCeLbJC9izbrabKqvFUi6EF0A0=.08e0a8e6-1b9e-4cbc-8487-4dd77ce3c63d@github.com>

On Mon, 17 Oct 2022 22:20:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 52:
> 
>> 50: 
>> 51:     @Test
>> 52:     public void testUsPac() throws IOException{
> 
> You could use a DataProvider

I had the same thought

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Mon Oct 17 23:38:19 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 17 Oct 2022 23:38:19 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher
In-Reply-To: <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
Message-ID: <krxCXLu3ID3zy4wFdNFKBXcTfv8QrukrSNFJ5E26sgI=.fbaf7752-3815-4dc4-b119-98cb6667df83@github.com>

On Mon, 17 Oct 2022 22:18:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> test/jdk/java/util/Formatter/Basic.java line 93:
> 
>> 91:                                        + fail + " failure(s), first", first);
>> 92:         else
>> 93:             System.out.println("all " + (fail + pass) + " tests passed");
> 
> Perhaps use System.out.printf vs println and "fail" should not be needed as all tests passed

Thank you Lance, will take a look at this and the rest of the comments

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

PR: https://git.openjdk.org/jdk/pull/10715

From iris at openjdk.org  Tue Oct 18 00:01:02 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 18 Oct 2022 00:01:02 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher
In-Reply-To: <krxCXLu3ID3zy4wFdNFKBXcTfv8QrukrSNFJ5E26sgI=.fbaf7752-3815-4dc4-b119-98cb6667df83@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
 <krxCXLu3ID3zy4wFdNFKBXcTfv8QrukrSNFJ5E26sgI=.fbaf7752-3815-4dc4-b119-98cb6667df83@github.com>
Message-ID: <2_hO38mZMubniHflGyz9lEdd46P4O8RtSTCcotUGock=.5e54fceb-8379-4fc0-9bcf-78d79b868b4b@github.com>

On Mon, 17 Oct 2022 23:34:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic.java line 93:
>> 
>>> 91:                                        + fail + " failure(s), first", first);
>>> 92:         else
>>> 93:             System.out.println("all " + (fail + pass) + " tests passed");
>> 
>> Perhaps use System.out.printf vs println and "fail" should not be needed as all tests passed
>
> Thank you Lance, will take a look at this and the rest of the comments

Careful.  I suspect that "fail" is the number of tests that are expected to fail.

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 00:08:53 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 00:08:53 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher
In-Reply-To: <2_hO38mZMubniHflGyz9lEdd46P4O8RtSTCcotUGock=.5e54fceb-8379-4fc0-9bcf-78d79b868b4b@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
 <krxCXLu3ID3zy4wFdNFKBXcTfv8QrukrSNFJ5E26sgI=.fbaf7752-3815-4dc4-b119-98cb6667df83@github.com>
 <2_hO38mZMubniHflGyz9lEdd46P4O8RtSTCcotUGock=.5e54fceb-8379-4fc0-9bcf-78d79b868b4b@github.com>
Message-ID: <BSe_yN_ZXaR6lxDCOhrymi59AuUfOVbwM6h5olLDkMc=.dea96b57-1ea7-4408-b418-d9beaf1b55a4@github.com>

On Mon, 17 Oct 2022 23:57:11 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Thank you Lance, will take a look at this and the rest of the comments
>
> Careful.  I suspect that "fail" is the number of tests that are expected to fail.

Thanks Iris,
It got hidden in the code snippet, but line 89 is `if (fail != 0)`,
so I do believe fail is redundant in 93.

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

PR: https://git.openjdk.org/jdk/pull/10715

From prr at openjdk.org  Tue Oct 18 16:49:10 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 18 Oct 2022 16:49:10 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v11]
In-Reply-To: <qBSXGkjfwNWatB2ur-Lr_FcPctqCFo0XlyjJfcM6hfo=.df53e761-0ba4-47f7-917e-61ec70ffc721@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <qBSXGkjfwNWatB2ur-Lr_FcPctqCFo0XlyjJfcM6hfo=.df53e761-0ba4-47f7-917e-61ec70ffc721@github.com>
Message-ID: <u69_ioy7ox5H4LiEfST4n9sW-U3f62MIenuQMj2A2mg=.06751863-a9ac-466b-aa78-58bb47390cac@github.com>

On Wed, 12 Oct 2022 11:24:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 40 more: https://git.openjdk.org/jdk/compare/bdb4ed0f...e2d0979f

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/8328

From duke at openjdk.org  Tue Oct 18 17:05:08 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 17:05:08 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Use data provider, drop exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/f750adb6..1cbca6eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=00-01

  Stats: 26 lines in 2 files changed: 5 ins; 17 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 17:05:09 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 17:05:09 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <EHnJYJ7PlmwIN4QzgGCeLbJC9izbrabKqvFUi6EF0A0=.08e0a8e6-1b9e-4cbc-8487-4dd77ce3c63d@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
 <EHnJYJ7PlmwIN4QzgGCeLbJC9izbrabKqvFUi6EF0A0=.08e0a8e6-1b9e-4cbc-8487-4dd77ce3c63d@github.com>
Message-ID: <DnK0vOBZI5AuZ8EQgWcY3TdyVi-IVqH2BOPPwEgzSyY=.90c07423-80a8-411b-a572-3ed04881208e@github.com>

On Mon, 17 Oct 2022 22:39:22 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/BasicTestLauncher.java line 52:
>> 
>>> 50: 
>>> 51:     @Test
>>> 52:     public void testUsPac() throws IOException{
>> 
>> You could use a DataProvider
>
> I had the same thought

Thanks Lance and Brent, replaced it with a JUnit parametrized test (DataProvider equivalent)

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 17:05:11 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 17:05:11 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
Message-ID: <iQHxcRZcIRnygmSKygD95ESkGGH8m4DdDeLYeHFpIiY=.8559724e-fd4e-4a46-bfb6-3381e3f51388@github.com>

On Mon, 17 Oct 2022 22:22:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider, drop exception
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 99:
> 
>> 97:         }catch(RuntimeException err){
>> 98:             throw new RuntimeException(String.format("$$$ %s: Test(s) failed or TestJVM did not build correctly." +
>> 99:                     " Check stderr output from diagnostics summary above%n",  err.getMessage()));
> 
> Do you need to catch the RuntimeException and then throw a new RuntimeException?  I think you might want to consider reworking this

Thank you Lance, I dropped the catch altogether as there is already enough info in the test log output

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

PR: https://git.openjdk.org/jdk/pull/10715

From ihse at openjdk.org  Tue Oct 18 17:13:15 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 17:13:15 GMT
Subject: <i18n dev> Integrated: 8285306: Fix typos in java.desktop
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <DH7sHDlZa7CvNfM33RvFIvJdLvgSJKDFkELt7eygEJw=.e0b40813-e25a-4ff1-8e53-156258d97aa5@github.com>

On Thu, 21 Apr 2022 08:35:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

This pull request has now been integrated.

Changeset: 2a799e5c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a799e5c82395919b807561da4a062e0fe6da31d
Stats:     1017 lines in 483 files changed: 0 ins; 0 del; 1017 mod

8285306: Fix typos in java.desktop

Co-authored-by: Andrey Turbanov <aturbanov at openjdk.org>
Reviewed-by: aturbanov, prr

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

PR: https://git.openjdk.org/jdk/pull/8328

From bchristi at openjdk.org  Tue Oct 18 17:39:21 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 17:39:21 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
Message-ID: <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>

On Tue, 18 Oct 2022 17:05:08 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use data provider, drop exception

Changes requested by bchristi (Reviewer).

test/jdk/java/util/Formatter/Basic.java line 93:

> 91:                                        + fail + " failure(s), first", first);
> 92:         else
> 93:             System.out.printf("all " + pass + " tests passed");

This line is missing a newline; add a \n, or use println().

test/jdk/java/util/Formatter/BasicTestLauncher.java line 35:

> 33:  * @summary Unit tests for formatter
> 34:  * @library /test/lib
> 35:  * @compile Basic.java

For the record, I've not deduced how/why the rest of the .java files in the test get compiled to .class files...

test/jdk/java/util/Formatter/BasicTestLauncher.java line 47:

> 45:     private static final String TZ_UP = "US/Pacific";
> 46:     // Asia/Novosibirsk time zone
> 47:     private static final String TZ_AN = "Asia/Novosibirsk";

IMO it's not necessary to create constants if they'll only be used as a ValueSource

test/jdk/java/util/Formatter/BasicTestLauncher.java line 49:

> 47:     private static final String TZ_AN = "Asia/Novosibirsk";
> 48:     // Locale flag for testJVM
> 49:     private static final String LOCALE_PROV = "-Djava.locale.providers=CLDR";

A name like "JAVA_OPTS" would better express how this value is used.

test/jdk/java/util/Formatter/BasicTestLauncher.java line 51:

> 49:     private static final String LOCALE_PROV = "-Djava.locale.providers=CLDR";
> 50:     // Test class
> 51:     private static final String SOURCE_CLASS = "Basic";

This is the name of a compiled class to be run, not a source file, so perhaps, "TEST_CLASS"?

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

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Tue Oct 18 17:52:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Oct 2022 17:52:06 GMT
Subject: <i18n dev> RFR: 8295372: CompactNumberFormat handling of number one
 with decimal part
Message-ID: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>

Plurals were determined only by looking at the integer part of the compact number. Changed to consider the fraction digits as well.

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

Commit messages:
 - 8295372: CompactNumberFormat handling of number one with decimal part

Changes: https://git.openjdk.org/jdk/pull/10748/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10748&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295372
  Stats: 80 lines in 2 files changed: 35 ins; 2 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/10748.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10748/head:pull/10748

PR: https://git.openjdk.org/jdk/pull/10748

From lancea at openjdk.org  Tue Oct 18 18:02:12 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 18:02:12 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
Message-ID: <Fa9Ns8kiIdrCq9QtyKEZqtq6t-FL7gFOMQMjtBoozQ0=.6bf20414-f30b-4f02-8254-bffd225e43a7@github.com>

On Tue, 18 Oct 2022 17:05:08 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use data provider, drop exception

Hi Justin,

We are getting close ;-) 

Please see below

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

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Tue Oct 18 18:02:13 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 18:02:13 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
Message-ID: <zQaCQeA5m8yDIg86oC_ggJHswNYPpN0Y0eu_ZpE6NSo=.7fdd7ec3-9178-4a6e-acf9-ae970f29a8d9@github.com>

On Tue, 18 Oct 2022 17:26:52 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider, drop exception
>
> test/jdk/java/util/Formatter/Basic.java line 93:
> 
>> 91:                                        + fail + " failure(s), first", first);
>> 92:         else
>> 93:             System.out.printf("all " + pass + " tests passed");
> 
> This line is missing a newline; add a \n, or use println().

I would suggest rewriting as System.out.printf("all %s tests passed%n", pass);

You could make a similar change to line 90 using String.format as done in the line 98 which was deleted

> test/jdk/java/util/Formatter/BasicTestLauncher.java line 51:
> 
>> 49:     private static final String LOCALE_PROV = "-Djava.locale.providers=CLDR";
>> 50:     // Test class
>> 51:     private static final String SOURCE_CLASS = "Basic";
> 
> This is the name of a compiled class to be run, not a source file, so perhaps, "TEST_CLASS"?

agree

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:09:18 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:09:18 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v3]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <H3jOjZm6D6XFrFadzkmwFln25NuyYWbfSkgQMsg-m88=.b5990ab5-41d9-4bc7-a787-7dd559aa8ea5@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Adjust constant names
 - Remove time zone constants (using ValueSource)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/1cbca6eb..bb01f86d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=01-02

  Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:09:19 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:09:19 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <zQaCQeA5m8yDIg86oC_ggJHswNYPpN0Y0eu_ZpE6NSo=.7fdd7ec3-9178-4a6e-acf9-ae970f29a8d9@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
 <zQaCQeA5m8yDIg86oC_ggJHswNYPpN0Y0eu_ZpE6NSo=.7fdd7ec3-9178-4a6e-acf9-ae970f29a8d9@github.com>
Message-ID: <XT0pOqfnmvL8SuNZNR5HATC1E3l08773JYX8WO8z4SM=.62c2a94e-a9e6-4be9-8274-1ebd9e99c300@github.com>

On Tue, 18 Oct 2022 17:49:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic.java line 93:
>> 
>>> 91:                                        + fail + " failure(s), first", first);
>>> 92:         else
>>> 93:             System.out.printf("all " + pass + " tests passed");
>> 
>> This line is missing a newline; add a \n, or use println().
>
> I would suggest rewriting as System.out.printf("all %s tests passed%n", pass);
> 
> You could make a similar change to line 90 using String.format as done in the line 98 which was deleted

I dropped the new line since when the output comes out of the sub process log

Without the newline it looks like 
[ ... ] 

vs

[...
]

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

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Tue Oct 18 18:09:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 18:09:20 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
Message-ID: <mCb3lV37VzGZjtbc2zn1IUPUgq5u6RWompBQtmofEAA=.1c0ae535-234a-4f4f-a8f9-0c562740793c@github.com>

On Tue, 18 Oct 2022 17:28:49 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider, drop exception
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 47:
> 
>> 45:     private static final String TZ_UP = "US/Pacific";
>> 46:     // Asia/Novosibirsk time zone
>> 47:     private static final String TZ_AN = "Asia/Novosibirsk";
> 
> IMO it's not necessary to create constants if they'll only be used as a ValueSource

True, but really a personal choice as it makes the ValueSource less wordy ;-)

> test/jdk/java/util/Formatter/BasicTestLauncher.java line 49:
> 
>> 47:     private static final String TZ_AN = "Asia/Novosibirsk";
>> 48:     // Locale flag for testJVM
>> 49:     private static final String LOCALE_PROV = "-Djava.locale.providers=CLDR";
> 
> A name like "JAVA_OPTS" would better express how this value is used.

agree

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:24:56 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:24:56 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v4]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust output formating in Basic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/bb01f86d..fe67e050

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Tue Oct 18 18:24:58 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 18:24:58 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
Message-ID: <j5QqnaWB9HgNP7REkX8kHB0dKJh1lGsF3MF8X0Fl__0=.b1922438-88e4-4bcc-934a-deb2eb94d3d8@github.com>

On Tue, 18 Oct 2022 17:36:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider, drop exception
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 35:
> 
>> 33:  * @summary Unit tests for formatter
>> 34:  * @library /test/lib
>> 35:  * @compile Basic.java
> 
> For the record, I've not deduced how/why the rest of the .java files in the test get compiled to .class files...

I suspect because the other classes are in the test.src directory they are being compiled which can be verified by Justin looking at the jtr log for the test

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

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 18:29:32 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 18:29:32 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v2]
In-Reply-To: <mCb3lV37VzGZjtbc2zn1IUPUgq5u6RWompBQtmofEAA=.1c0ae535-234a-4f4f-a8f9-0c562740793c@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
 <mCb3lV37VzGZjtbc2zn1IUPUgq5u6RWompBQtmofEAA=.1c0ae535-234a-4f4f-a8f9-0c562740793c@github.com>
Message-ID: <ODHnFhRHM-zY2NrPHQ1luXFCxOqGsG3uTiX8mdLICxw=.9563b312-0472-4ef3-b24e-1ea701d95b2c@github.com>

On Tue, 18 Oct 2022 18:03:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/BasicTestLauncher.java line 47:
>> 
>>> 45:     private static final String TZ_UP = "US/Pacific";
>>> 46:     // Asia/Novosibirsk time zone
>>> 47:     private static final String TZ_AN = "Asia/Novosibirsk";
>> 
>> IMO it's not necessary to create constants if they'll only be used as a ValueSource
>
> True, but really a personal choice as it makes the ValueSource less wordy ;-)

Also, when reading through a ValueSource / DataProvider, it's nice to see the actual values (vs variable/constant names) when practical/possible.

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

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 18:52:04 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 18:52:04 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v4]
In-Reply-To: <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>
Message-ID: <A_qrSB_ft6hCQ0mqau-_JPLgGJYFOQUJyvbXSqvFrRc=.1154e396-40ed-413d-a0c6-3e69d4e7f1c1@github.com>

On Tue, 18 Oct 2022 18:24:56 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust output formating in Basic

Changes requested by bchristi (Reviewer).

test/jdk/java/util/Formatter/Basic.java line 93:

> 91:                     ", first" , fail+pass, fail), first);
> 92:         else
> 93:             System.out.printf("All %s tests passed", pass);

%d, yes?

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:54:58 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:54:58 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v5]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <xmij-VRlk_6LiEbmponaHufTxW1xnCpG2t889DCqViU=.1315a7a5-5dc9-4177-a700-023243f4499f@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Add curly braces to Basic if else

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/fe67e050..5b9225c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=03-04

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:56:31 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:56:31 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v4]
In-Reply-To: <A_qrSB_ft6hCQ0mqau-_JPLgGJYFOQUJyvbXSqvFrRc=.1154e396-40ed-413d-a0c6-3e69d4e7f1c1@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>
 <A_qrSB_ft6hCQ0mqau-_JPLgGJYFOQUJyvbXSqvFrRc=.1154e396-40ed-413d-a0c6-3e69d4e7f1c1@github.com>
Message-ID: <YM3u5g-fkHasZC94xv5F-OEzmwlTc0WwNLc3MIdMfpw=.a157e5e2-d260-44c7-b1c6-2f6a5bc7e841@github.com>

On Tue, 18 Oct 2022 18:46:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust output formating in Basic
>
> test/jdk/java/util/Formatter/Basic.java line 93:
> 
>> 91:                     ", first" , fail+pass, fail), first);
>> 92:         else
>> 93:             System.out.printf("All %s tests passed", pass);
> 
> %d, yes?

Right, will change that

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 19:04:29 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 19:04:29 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v6]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Remove testing change
 - Fix formatter in Basic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/5b9225c9..9483f16c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 19:04:29 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:04:29 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v5]
In-Reply-To: <xmij-VRlk_6LiEbmponaHufTxW1xnCpG2t889DCqViU=.1315a7a5-5dc9-4177-a700-023243f4499f@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <xmij-VRlk_6LiEbmponaHufTxW1xnCpG2t889DCqViU=.1315a7a5-5dc9-4177-a700-023243f4499f@github.com>
Message-ID: <mYhmreOPyZGrb8pwOu7AS8fYit6nOj4_PQsSHFaw1Dg=.688d0af8-ad6d-4da8-a5e4-16b16d57688e@github.com>

On Tue, 18 Oct 2022 18:54:58 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add curly braces to Basic if else

Changes requested by bchristi (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 19:04:30 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:04:30 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v4]
In-Reply-To: <YM3u5g-fkHasZC94xv5F-OEzmwlTc0WwNLc3MIdMfpw=.a157e5e2-d260-44c7-b1c6-2f6a5bc7e841@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>
 <A_qrSB_ft6hCQ0mqau-_JPLgGJYFOQUJyvbXSqvFrRc=.1154e396-40ed-413d-a0c6-3e69d4e7f1c1@github.com>
 <YM3u5g-fkHasZC94xv5F-OEzmwlTc0WwNLc3MIdMfpw=.a157e5e2-d260-44c7-b1c6-2f6a5bc7e841@github.com>
Message-ID: <o7sVHNzkm9DCDXtA3g9YEOsjTNHggOcDDEudR-mkkfQ=.221db7bf-9242-4234-ae71-f7503ec4433c@github.com>

On Tue, 18 Oct 2022 18:54:03 GMT, Justin Lu <duke at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic.java line 93:
>> 
>>> 91:                     ", first" , fail+pass, fail), first);
>>> 92:         else
>>> 93:             System.out.printf("All %s tests passed", pass);
>> 
>> %d, yes?
>
> Right, will change that

And one on the previous line

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

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 19:14:16 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:14:16 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
Message-ID: <DyBtVRxm3XlzIgDXAVuvezh8TO3eIFRfWf7sEBruqw8=.c3a2b31a-576e-4aea-a322-6b236ccf77c3@github.com>

On Thu, 13 Oct 2022 01:02:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
> 
> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
> 
> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

Changes requested by bchristi (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10684

From bchristi at openjdk.org  Tue Oct 18 19:14:17 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:14:17 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>
Message-ID: <3u_74MLLkI-yUgNgR5JnSEhmezKCVaw16T_BZuNX9dA=.7b0049e2-6cec-4080-a37e-5398851221a6@github.com>

On Fri, 14 Oct 2022 00:37:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
>> 
>> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
>> 
>> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.
>
> test/jdk/java/util/Formatter/BasicByteObject.java line 232:
> 
>> 230: 
>> 231:     private static Byte negate(Byte v) {
>> 232:         return (byte) -v.byteValue();
> 
> We want to be returning a `Byte`, so casting to `(byte)` doesn't seem right to me.
> 
> `Byte.valueOf()` takes a `byte` and returns a `Byte`, so using that as the replacement for `new Byte`, we get:
> `return Byte.valueOf(-v.byteValue());`
> Is there a way to get the template to do that?

So, the above suggestion gives explicit auto-boxing, though some might find it wordier than necessary.

Since `v.byteValue()` already returns a `byte`, the `(byte)` cast doesn't seem necessary. I see that L242 does:
> `return -v.intValue();`

which is a pretty clean look. So `return -v.byteValue();` would be an option, too.

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

PR: https://git.openjdk.org/jdk/pull/10684

From bchristi at openjdk.org  Tue Oct 18 19:24:45 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:24:45 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v6]
In-Reply-To: <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
Message-ID: <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>

On Tue, 18 Oct 2022 19:04:29 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove testing change
>  - Fix formatter in Basic

Changes requested by bchristi (Reviewer).

test/jdk/java/util/Formatter/Basic.java line 90:

> 88: 
> 89:         if (fail != 0) {
> 90:             throw new RuntimeException(String.format("%d tests: %d failure(s)" +

You might consider including `", first"` with the rest of the message string, instead of concatenating it. That line might end up slightly long, but it may be worth it.

Also, use `%s` for`first`, as it's a `Throwable` ;)
(You could also perhaps change `first` -> `first.toString()` in the final argument to format, to clarify.)

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 19:28:52 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 19:28:52 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v6]
In-Reply-To: <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
 <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>
Message-ID: <nfbc6yKQD6JvZG45WtW9fU5LHw9NUAw5yeNiu9nA2YA=.58823605-49e5-4c00-ab90-06ddcba2a6c5@github.com>

On Tue, 18 Oct 2022 19:20:58 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove testing change
>>  - Fix formatter in Basic
>
> test/jdk/java/util/Formatter/Basic.java line 90:
> 
>> 88: 
>> 89:         if (fail != 0) {
>> 90:             throw new RuntimeException(String.format("%d tests: %d failure(s)" +
> 
> You might consider including `", first"` with the rest of the message string, instead of concatenating it. That line might end up slightly long, but it may be worth it.
> 
> Also, use `%s` for`first`, as it's a `Throwable` ;)
> (You could also perhaps change `first` -> `first.toString()` in the final argument to format, to clarify.)

Good point, will reassign it to one line.

"Also, use %s forfirst, as it's a Throwable", 
I believe I am assigning %d to pass+fail and fail. I pass first as a Throwable to the runtime exception constructor.

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

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 19:41:05 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:41:05 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v6]
In-Reply-To: <nfbc6yKQD6JvZG45WtW9fU5LHw9NUAw5yeNiu9nA2YA=.58823605-49e5-4c00-ab90-06ddcba2a6c5@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
 <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>
 <nfbc6yKQD6JvZG45WtW9fU5LHw9NUAw5yeNiu9nA2YA=.58823605-49e5-4c00-ab90-06ddcba2a6c5@github.com>
Message-ID: <C4YrbILqOwzVtX3g0B5g9Q7BVFCNpBG3eLFLhMPjGT8=.32540bb8-f33e-4d14-901b-c397f306b114@github.com>

On Tue, 18 Oct 2022 19:25:01 GMT, Justin Lu <duke at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic.java line 90:
>> 
>>> 88: 
>>> 89:         if (fail != 0) {
>>> 90:             throw new RuntimeException(String.format("%d tests: %d failure(s)" +
>> 
>> You might consider including `", first"` with the rest of the message string, instead of concatenating it. That line might end up slightly long, but it may be worth it.
>> 
>> Also, use `%s` for`first`, as it's a `Throwable` ;)
>> (You could also perhaps change `first` -> `first.toString()` in the final argument to format, to clarify.)
>
> Good point, will reassign it to one line.
> 
> "Also, use %s forfirst, as it's a Throwable", 
> I believe I am assigning %d to pass+fail and fail. I pass first as a Throwable to the runtime exception constructor.

Oh, right. Carry on.

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 19:52:01 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 19:52:01 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <3u_74MLLkI-yUgNgR5JnSEhmezKCVaw16T_BZuNX9dA=.7b0049e2-6cec-4080-a37e-5398851221a6@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>
 <3u_74MLLkI-yUgNgR5JnSEhmezKCVaw16T_BZuNX9dA=.7b0049e2-6cec-4080-a37e-5398851221a6@github.com>
Message-ID: <jwZy6LBJu3MbIM4rk6W3w1lMzsVE95Avv8NXOsG08yI=.83c3f2c6-17dd-43b5-9c42-169775ed3a91@github.com>

On Tue, 18 Oct 2022 19:10:00 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/BasicByteObject.java line 232:
>> 
>>> 230: 
>>> 231:     private static Byte negate(Byte v) {
>>> 232:         return (byte) -v.byteValue();
>> 
>> We want to be returning a `Byte`, so casting to `(byte)` doesn't seem right to me.
>> 
>> `Byte.valueOf()` takes a `byte` and returns a `Byte`, so using that as the replacement for `new Byte`, we get:
>> `return Byte.valueOf(-v.byteValue());`
>> Is there a way to get the template to do that?
>
> So, the above suggestion gives explicit auto-boxing, though some might find it wordier than necessary.
> 
> Since `v.byteValue()` already returns a `byte`, the `(byte)` cast doesn't seem necessary. I see that L242 does:
>> `return -v.intValue();`
> 
> which is a pretty clean look. So `return -v.byteValue();` would be an option, too.

Negating v.byteValue() promotes it into an int. So then casting to byte would be necessary.

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

PR: https://git.openjdk.org/jdk/pull/10684

From bchristi at openjdk.org  Tue Oct 18 19:59:08 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:59:08 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <jwZy6LBJu3MbIM4rk6W3w1lMzsVE95Avv8NXOsG08yI=.83c3f2c6-17dd-43b5-9c42-169775ed3a91@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>
 <3u_74MLLkI-yUgNgR5JnSEhmezKCVaw16T_BZuNX9dA=.7b0049e2-6cec-4080-a37e-5398851221a6@github.com>
 <jwZy6LBJu3MbIM4rk6W3w1lMzsVE95Avv8NXOsG08yI=.83c3f2c6-17dd-43b5-9c42-169775ed3a91@github.com>
Message-ID: <9_CUfgZm7LqpDpuhaArfmVRjgzdl7eIjaDvNFV-sVv0=.bbf823eb-6f31-4be5-b003-e929434150bd@github.com>

On Tue, 18 Oct 2022 19:48:15 GMT, Justin Lu <duke at openjdk.org> wrote:

>> So, the above suggestion gives explicit auto-boxing, though some might find it wordier than necessary.
>> 
>> Since `v.byteValue()` already returns a `byte`, the `(byte)` cast doesn't seem necessary. I see that L242 does:
>>> `return -v.intValue();`
>> 
>> which is a pretty clean look. So `return -v.byteValue();` would be an option, too.
>
> Negating v.byteValue() promotes it into an int. So then casting to byte would be necessary.

Oh yeah...oops.

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

PR: https://git.openjdk.org/jdk/pull/10684

From duke at openjdk.org  Tue Oct 18 20:26:09 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 20:26:09 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v7]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <arbJeJtZZMwY15VAB6FBA0Ua_b4wbD0ww5CMIENhRiM=.53079b27-4f6d-4667-9bfb-eeebdaad6204@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove @compile
  
  Everything under test.src compiled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/9483f16c..81fc6a31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From joehw at openjdk.org  Tue Oct 18 20:29:04 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 18 Oct 2022 20:29:04 GMT
Subject: <i18n dev> RFR: 8295372: CompactNumberFormat handling of number
 one with decimal part
In-Reply-To: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>
References: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>
Message-ID: <5csrI7j110kB1pY6AKViyN9833k_XuAy8yOAkqnKLX0=.72100841-a977-4a5b-94a0-5e39bdf982ca@github.com>

On Tue, 18 Oct 2022 17:44:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Plurals were determined only by looking at the integer part of the compact number. Changed to consider the fraction digits as well.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10748

From naoto at openjdk.org  Tue Oct 18 21:02:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Oct 2022 21:02:09 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v6]
In-Reply-To: <C4YrbILqOwzVtX3g0B5g9Q7BVFCNpBG3eLFLhMPjGT8=.32540bb8-f33e-4d14-901b-c397f306b114@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
 <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>
 <nfbc6yKQD6JvZG45WtW9fU5LHw9NUAw5yeNiu9nA2YA=.58823605-49e5-4c00-ab90-06ddcba2a6c5@github.com>
 <C4YrbILqOwzVtX3g0B5g9Q7BVFCNpBG3eLFLhMPjGT8=.32540bb8-f33e-4d14-901b-c397f306b114@github.com>
Message-ID: <9KAHQ-aN7Jj_Yg7l-MEWpvQszQV6me8wf3_zPNyIWUU=.5992304c-a786-4177-88b9-926a4cb25d8e@github.com>

On Tue, 18 Oct 2022 19:37:17 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Good point, will reassign it to one line.
>> 
>> "Also, use %s forfirst, as it's a Throwable", 
>> I believe I am assigning %d to pass+fail and fail. I pass first as a Throwable to the runtime exception constructor.
>
> Oh, right. Carry on.

Instead of using String.format() static method, using "...".formatted() is slightly shorter/concise.

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 21:26:09 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 21:26:09 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v8]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <D-3bUqCk6VJu-Jp5ZyKaARQNfWZ1gFHH0d4tHX5Xbw8=.b9be98ce-85aa-47d6-9054-7f2b399e87f0@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Add all BasicXXX files to @compile for clarity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/81fc6a31..00c32ee2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=06-07

  Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 23:03:16 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 23:03:16 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v9]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <ytOn2N-rvAPIxOthSW6qhIzzeeo686MLQHnaTucZea4=.a1c10d17-8f55-473a-8d57-a3b8ba3c9e06@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Additional cleanup and string formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/00c32ee2..56eae09a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=07-08

  Stats: 19 lines in 2 files changed: 5 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Wed Oct 19 16:27:29 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Oct 2022 16:27:29 GMT
Subject: <i18n dev> Integrated: 8295372: CompactNumberFormat handling of
 number one with decimal part
In-Reply-To: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>
References: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>
Message-ID: <0yaW1P0RkTh7l3CbwuvYC8gu_DA3PJkxmubNn66AmuY=.4b08d6ea-ee18-46d0-add3-d1022cc6276a@github.com>

On Tue, 18 Oct 2022 17:44:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Plurals were determined only by looking at the integer part of the compact number. Changed to consider the fraction digits as well.

This pull request has now been integrated.

Changeset: e238920b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e238920bb69836e982138cb7e1fed2a39182df8f
Stats:     80 lines in 2 files changed: 35 ins; 2 del; 43 mod

8295372: CompactNumberFormat handling of number one with decimal part

Reviewed-by: joehw

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

PR: https://git.openjdk.org/jdk/pull/10748

From naoto at openjdk.org  Wed Oct 19 19:14:04 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Oct 2022 19:14:04 GMT
Subject: <i18n dev> RFR: 8295564: Norwegian Nynorsk Locale is missing
 formatting
Message-ID: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>

This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
It's amazing to see this bug has been lurking unnoticed till now.

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

Commit messages:
 - 8295564: Norwegian Nynorsk Locale is missing formatting

Changes: https://git.openjdk.org/jdk/pull/10774/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295564
  Stats: 12 lines in 3 files changed: 8 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10774.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10774/head:pull/10774

PR: https://git.openjdk.org/jdk/pull/10774

From iris at openjdk.org  Wed Oct 19 20:52:00 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 19 Oct 2022 20:52:00 GMT
Subject: <i18n dev> RFR: 8295564: Norwegian Nynorsk Locale is missing
 formatting
In-Reply-To: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
References: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
Message-ID: <UHMoeLlIKng7twRJv8JjR7viJyt_rpfewmVMYuR8NOc=.c0bd9c7b-55b9-45e4-9613-9352660d139d@github.com>

On Wed, 19 Oct 2022 19:04:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
> It's amazing to see this bug has been lurking unnoticed till now.

I like changes that reduce code while resulting in more correct behaviour.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10774

From joehw at openjdk.org  Wed Oct 19 21:45:59 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Oct 2022 21:45:59 GMT
Subject: <i18n dev> RFR: 8295564: Norwegian Nynorsk Locale is missing
 formatting
In-Reply-To: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
References: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
Message-ID: <9bM7bM3GrBUSL5B94rawrPMULXe74THCViIEe2f5QQo=.9aaa8a0e-4745-4b86-a542-6207d5a81a8c@github.com>

On Wed, 19 Oct 2022 19:04:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
> It's amazing to see this bug has been lurking unnoticed till now.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10774

From bchristi at openjdk.org  Wed Oct 19 22:25:07 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 19 Oct 2022 22:25:07 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v9]
In-Reply-To: <ytOn2N-rvAPIxOthSW6qhIzzeeo686MLQHnaTucZea4=.a1c10d17-8f55-473a-8d57-a3b8ba3c9e06@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <ytOn2N-rvAPIxOthSW6qhIzzeeo686MLQHnaTucZea4=.a1c10d17-8f55-473a-8d57-a3b8ba3c9e06@github.com>
Message-ID: <ZEULntdAZ-UaQjJ89sYJN1KVocbGZazoWgBc_mbBMgg=.3aaf35bb-5164-40bd-841d-fa9a07c3da52@github.com>

On Tue, 18 Oct 2022 23:03:16 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional cleanup and string formatting

test/jdk/java/util/Formatter/BasicTestLauncher.java line 90:

> 88:             ProcessBuilder pb = ProcessTools.createTestJvm(JAVA_OPTS, TEST_CLASS);
> 89:             pb.environment().put("TZ", timeZone);
> 90:             Process process = pb.start();

Nit: indentation

test/jdk/java/util/Formatter/BasicTestLauncher.java line 102:

> 100:     private static void CheckTest(OutputAnalyzer output){
> 101:             output.shouldHaveExitValue(0)
> 102:                     .reportDiagnosticSummary();

Nit: indentation

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Wed Oct 19 22:36:07 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 19 Oct 2022 22:36:07 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v10]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <HMF74-B4H_V6RfMfZn3J-Ju5-cCg7uVjg_aPzkIjYlk=.983b5e05-9aa2-437d-b1db-4fc8ee71ee67@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/56eae09a..5a0ee74f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=08-09

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From ihse at openjdk.org  Thu Oct 20 12:06:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 12:06:27 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
Message-ID: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>

Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).

The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

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

Commit messages:
 - 8295729: Add jcheck whitespace checking for properties files

Changes: https://git.openjdk.org/jdk/pull/10792/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295729
  Stats: 1105 lines in 368 files changed: 0 ins; 0 del; 1105 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Thu Oct 20 16:03:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 16:03:56 GMT
Subject: <i18n dev> Integrated: 8295564: Norwegian Nynorsk Locale is missing
 formatting
In-Reply-To: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
References: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
Message-ID: <zvahMEJvmX67hhnk43uXXN9O7ceKqoH7FNo0iTNog7w=.61b56729-44bd-41f0-bf37-8171d8787e9a@github.com>

On Wed, 19 Oct 2022 19:04:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
> It's amazing to see this bug has been lurking unnoticed till now.

This pull request has now been integrated.

Changeset: b37421e7
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b37421e7578c108df87c24c93dcbc1f358f6c257
Stats:     12 lines in 3 files changed: 8 ins; 2 del; 2 mod

8295564: Norwegian Nynorsk Locale is missing formatting

Reviewed-by: iris, joehw

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

PR: https://git.openjdk.org/jdk/pull/10774

From duke at openjdk.org  Thu Oct 20 17:12:54 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 17:12:54 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v9]
In-Reply-To: <ZEULntdAZ-UaQjJ89sYJN1KVocbGZazoWgBc_mbBMgg=.3aaf35bb-5164-40bd-841d-fa9a07c3da52@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <ytOn2N-rvAPIxOthSW6qhIzzeeo686MLQHnaTucZea4=.a1c10d17-8f55-473a-8d57-a3b8ba3c9e06@github.com>
 <ZEULntdAZ-UaQjJ89sYJN1KVocbGZazoWgBc_mbBMgg=.3aaf35bb-5164-40bd-841d-fa9a07c3da52@github.com>
Message-ID: <Efqtg7DKHtIrsxMM5trF7CZRrp72h9-eP9HKwMwYleI=.8c36ab5b-6656-40ae-837c-f8840d2a0a84@github.com>

On Wed, 19 Oct 2022 22:20:56 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional cleanup and string formatting
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 90:
> 
>> 88:             ProcessBuilder pb = ProcessTools.createTestJvm(JAVA_OPTS, TEST_CLASS);
>> 89:             pb.environment().put("TZ", timeZone);
>> 90:             Process process = pb.start();
> 
> Nit: indentation

Fixed, thanks!

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

PR: https://git.openjdk.org/jdk/pull/10715

From erikj at openjdk.org  Thu Oct 20 18:26:46 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:26:46 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <NObZDn88VUQ8fHaLhcrqe0wkth0EfVAwjWA7K4eAY2k=.0c70399e-f307-4ca4-a637-e2f1ebedf960@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Nice job!

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Thu Oct 20 18:33:47 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 18:33:47 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <0VhVC2dpGOdpE3OL1278r0iCVXO1Jd_83Q4kszfikjY=.fecfe4ed-9a48-4fe4-827a-7ab1bc2defa2@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

LGTM. Haven't looked at all the l10n files.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Thu Oct 20 18:40:47 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:40:47 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I would vote against this change.  Per java properties spec
https://github.com/openjdk/jdk/pull/10792


White space following the property value is not ignored, and is treated as part of the property value.


This change might break localization or messages where trailing whitespace is important (example: "Label: ")

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Thu Oct 20 18:48:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:48:17 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> I would vote against this change.  Per java properties spec
> https://github.com/openjdk/jdk/pull/10792
> 
> 
> White space following the property value is not ignored, and is treated as part of the property value.
> 
> 
> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
> 
> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
> 
> 
> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;

@andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

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

PR: https://git.openjdk.org/jdk/pull/10792

From erikj at openjdk.org  Thu Oct 20 18:53:49 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:53:49 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <qf8daMUSgSlaXN3bROLfbFbpzrDJh5wSJdnTYQdol64=.df762075-9646-4aab-ab95-ead96e45936a@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Given that trailing whitespace may be part of a property value, then I take back my review.

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

Changes requested by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From cjplummer at openjdk.org  Thu Oct 20 18:53:50 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Oct 2022 18:53:50 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <uNs096Y7_C0U9CTifzO1PL71uAgKv0RwAxTfOuL5LGw=.e8e725f6-3fac-4b54-b406-111628923ae8@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> `White space following the property value is not ignored, and is treated as part of the property value.`

Although I didn't know this was in the spec, I suspected it might be the case. When looking at the jdk.management.agent changes, it looked like the extra space was actually a typo and was copied into all the localized versions (and not actually localized for unicode locales). In this case removing the white space is the right thing to do. It is in fact fixing an actual bug.

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

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Thu Oct 20 18:53:51 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:53:51 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
 <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
Message-ID: <HJm4YG5tr3dJ4SeXPS58BEpkBqzUEk7QwX6Cmf5x8JA=.7076b0a9-6fe2-4e0a-99f9-d3ca8a828a5a@github.com>

On Thu, 20 Oct 2022 18:46:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I would vote against this change.  Per java properties spec
>> https://github.com/openjdk/jdk/pull/10792
>> 
>> 
>> White space following the property value is not ignored, and is treated as part of the property value.
>> 
>> 
>> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
>> 
>> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
>> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
>> 
>> 
>> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;
>
> @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

@magicus  : 
no, this is how Properties were working from day one.


package goryachev.research;

import java.io.IOException;
import java.io.StringReader;
import java.util.Properties;

public class TestProperties {
    public static void main(String[] args) throws IOException {
        String text = "key= value ";
        Properties p = new Properties();
        p.load(new StringReader(text));
        System.out.println("value=["  +p.getProperty("key") + "]");
    }
}


outputs:

value=[value ]

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Thu Oct 20 19:07:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:07:52 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <vN85_fh3ocln38nEOKYh1GBwW5xzb3nIo_jYOQYqiLY=.6e65e099-3d3c-40fe-8cfa-1acf25fdd0a7@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Okay. That definitely rules out adding .properties to the whitespace jcheck verification.

However, I think that instead opens up a ton of more individual problems, since I think most (if perhaps not all) of these trailing whitespaces are incidental, and thus might be bugs. Perhaps no-one really noticed a double whitespace where it were not supposed to be, etc, especially not if it was just for a translated language.

I'm thinking I should redirect this PR to skip the jcheck requirement, and revert all changes to property values, but keep the part of the patch that removes trailing spaces in `#` comment lines. That seems to account for a majority of the changes.

For the remaining properties files with trailing spaces in the actual values, I'll make a sanity check if it seems correct or not, and if it looks fishy, I'll open bugs on the respective component teams to verify that their property values are indeed correct.

Does that sound reasonable?

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

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Thu Oct 20 19:29:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:29:51 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <iu-qPLbaWYYTSq2jVgsGXDGt8Weqq2RVuoaHyuI0YRg=.f4131b5a-9685-4246-bbac-85b776fee6e3@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Retracting my approval too. Thanks for the catch, Andy!
That sounds reasonable > Magnus

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

PR: https://git.openjdk.org/jdk/pull/10792

From bchristi at openjdk.org  Thu Oct 20 19:38:51 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 20 Oct 2022 19:38:51 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v10]
In-Reply-To: <HMF74-B4H_V6RfMfZn3J-Ju5-cCg7uVjg_aPzkIjYlk=.983b5e05-9aa2-437d-b1db-4fc8ee71ee67@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <HMF74-B4H_V6RfMfZn3J-Ju5-cCg7uVjg_aPzkIjYlk=.983b5e05-9aa2-437d-b1db-4fc8ee71ee67@github.com>
Message-ID: <ZKQGr4LnCQZ67AwQ3ZW42SG_ZdjHr51MSOTsY6UqQM4=.ca93e2e5-3af6-4d19-bc3f-d4fa2450078f@github.com>

On Wed, 19 Oct 2022 22:36:07 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Marked as reviewed by bchristi (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Thu Oct 20 19:40:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:40:55 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <eJ0YaIIkCYOV7stEG2AEVx05evyYix9H9Zp2eAlJsjA=.2e14e322-75f6-4651-bb96-c24cf2f10391@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

(retracting approval)

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

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Thu Oct 20 19:56:04 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 19:56:04 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v11]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <6HfArHy7s1R2gdxJfHWbyTgnfqNsZhhgGkVjF1Kp1ZY=.ec84bdd8-a449-4ec7-96c6-d9063f18f7a7@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Spacing conventions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/5a0ee74f..676a1025

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Thu Oct 20 20:14:58 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 20 Oct 2022 20:14:58 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v11]
In-Reply-To: <6HfArHy7s1R2gdxJfHWbyTgnfqNsZhhgGkVjF1Kp1ZY=.ec84bdd8-a449-4ec7-96c6-d9063f18f7a7@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <6HfArHy7s1R2gdxJfHWbyTgnfqNsZhhgGkVjF1Kp1ZY=.ec84bdd8-a449-4ec7-96c6-d9063f18f7a7@github.com>
Message-ID: <Yj6SsiV8p-lfIk2J9aIrBFQNo6qLMDqIh67WfYU9Ops=.dcfdc4cf-eaf1-46f2-8d7b-e2a456ecf317@github.com>

On Thu, 20 Oct 2022 19:56:04 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spacing conventions

Marked as reviewed by lancea (Reviewer).

test/jdk/java/util/Formatter/Basic.java line 94:

> 92:             var tests_message = "%d tests: %d failure(s)%n".formatted(fail + pass, fail);
> 93:             var trace_message = "Traceback of the first error located";
> 94:             String message = "%s %s".formatted(tests_message, trace_message);

could use "var" as the previous statements ;-)

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

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Thu Oct 20 20:17:59 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 20:17:59 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v12]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Format with var

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/676a1025..781b352d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Thu Oct 20 20:19:37 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 20:19:37 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v12]
In-Reply-To: <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>
Message-ID: <y6OSTdxkbn6QGtCeEruqrthA-heF8NrmuXHKyujRKC4=.6ed49649-d319-4ae0-8ec2-7961ed834713@github.com>

On Thu, 20 Oct 2022 20:17:59 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format with var

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Thu Oct 20 21:11:53 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 20 Oct 2022 21:11:53 GMT
Subject: <i18n dev> RFR: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher [v12]
In-Reply-To: <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>
Message-ID: <xB6wr-uSyKTl-VmVlWAUn2N3Iu5R-Z8JrFqEiq5f8Xs=.c5ee450f-3eb3-483e-ab08-a71eeac9c4c0@github.com>

On Thu, 20 Oct 2022 20:17:59 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format with var

Marked as reviewed by bchristi (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10715

From ihse at openjdk.org  Fri Oct 21 08:17:46 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:17:46 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v2]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove check for .properties from jcheck
 - Restore trailing whitespace for property values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/e33c0765..c91fdaa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00-01

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Oct 21 08:31:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:31:59 GMT
Subject: <i18n dev> RFR: 8295729: Remove trailing whitespace from
 non-value lines in properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <1mu65mMxl2Nf-mwa4iZczOBqJbPdutKpL6dE_3vMWcg=.c03430ed-70df-40fa-994e-700080b7b8fa@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Ok, I repurposed this PR to deal only with trailing space on non-value lines (comments and empty lines). This should be trivial, and will reduce the trailing spaces to only the value lines.

I believe most, but perhaps not all, trailing spaces in the value lines are actually bugs, but that will need further scrutiny by the owners of the properties files. Expect follow up bugs on this.

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

PR: https://git.openjdk.org/jdk/pull/10792

From erikj at openjdk.org  Fri Oct 21 12:59:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 12:59:48 GMT
Subject: <i18n dev> RFR: 8295729: Remove trailing whitespace from
 non-value lines in properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <AoFGXlCHPgwZa3u0Kwp6W-h5k-I_Malb2gWa3tSxSbw=.500a110c-0c73-4205-9a2e-e281bfb3a730@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Fri Oct 21 16:09:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 16:09:28 GMT
Subject: <i18n dev> RFR: 8295729: Remove trailing whitespace from
 non-value lines in properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

One possible solution to this is to replace those dangling white spaces with explicit Unicode escapes, i.e. "\u0009" and "\u0020".  This way jcheck can safely be enabled to detect future unwanted trailing spaces, and possibly existing ones can be visually recognizable by the engineers to correct them.

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

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Fri Oct 21 16:09:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Oct 2022 16:09:29 GMT
Subject: <i18n dev> RFR: 8295729: Remove trailing whitespace from
 non-value lines in properties files [v2]
In-Reply-To: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
Message-ID: <khuIARsEyKMyIfUxBD69kijyjnwDFCzAra51YwctMyY=.71b00eb7-1312-4db9-a6a5-ff85f7635132@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> replace those dangling white spaces with explicit Unicode escapes

this is a *very good* idea.

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

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Fri Oct 21 17:03:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 17:03:15 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
Message-ID: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>

This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:

https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)

Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

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

Commit messages:
 - Merge branch 'master' into cldr+
 - 8284840: Update CLDR to Version 42.0
 - CLDR v42 release
 - v42 beta5
 - v42 beta3
 - v42 beta1
 - v42 alpha
 - alpha1b
 - v42 alpha1b
 - cldr v42 alpha1
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9612cf99...2d86b3c8

Changes: https://git.openjdk.org/jdk/pull/10820/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10820&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284840
  Stats: 99164 lines in 377 files changed: 68223 ins; 2820 del; 28121 mod
  Patch: https://git.openjdk.org/jdk/pull/10820.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10820/head:pull/10820

PR: https://git.openjdk.org/jdk/pull/10820

From erikj at openjdk.org  Fri Oct 21 17:36:26 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 17:36:26 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <zBQjCxYhczKsyNq1Pxy9QWV5FHvqUUWc4jl8-lpHOpI=.9c78ed55-cff6-412c-a765-fccef81e4282@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10820

From iris at openjdk.org  Fri Oct 21 19:02:53 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 21 Oct 2022 19:02:53 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <OwWUFy4vsIhZhu3c10e5ICNeQn8m3gDld0Hq9hni5z8=.a5f4a70b-b501-4a86-ade8-6c907fe9a777@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10820

From joehw at openjdk.org  Fri Oct 21 19:20:52 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 21 Oct 2022 19:20:52 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Are the first two items (CLDR-14032, CLDR-14831) considered a behavior change (e.g. the format string will be different) that could use a CSR or the release notes to document it? I see the later points to the CLDR release notes, but maybe a statement in our release notes could be clearer?

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

PR: https://git.openjdk.org/jdk/pull/10820

From naoto at openjdk.org  Fri Oct 21 19:48:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 19:48:48 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
Message-ID: <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>

On Fri, 21 Oct 2022 19:16:57 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Are the first two items (CLDR-14032, CLDR-14831) considered a behavior change (e.g. the format string will be different) that could use a CSR or the release notes to document it? I see the later points to the CLDR release notes, but maybe a statement in our release notes could be clearer?

Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.

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

PR: https://git.openjdk.org/jdk/pull/10820

From naoto at openjdk.org  Fri Oct 21 20:25:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 20:25:51 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <I2D8h7jYM6Ui_dIwrG18ubpDbgCbuWK7z6TMrdzzXM4=.a418362e-8486-406c-941e-915a373d426a@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Draft release notes: https://bugs.openjdk.org/browse/JDK-8284841

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

PR: https://git.openjdk.org/jdk/pull/10820

From joehw at openjdk.org  Fri Oct 21 21:20:45 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 21 Oct 2022 21:20:45 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <ouIQerKy4eztpVMUk81sgJ3S5Pl0dWzZ1YmHBKAWIv4=.17d18acf-61d2-41cc-bbec-e0c3e11621d9@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Release notes look good to me.

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

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Fri Oct 21 21:25:49 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Fri, 21 Oct 2022 21:25:49 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <5wDxwNmRqMrWUBsDY7cqbSpQkBzEObD77phocsEsZSI=.d6461367-1ae8-4506-8cfb-98755c35adaf@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

hi folks ? looking good??congats on the quick update!

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

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Fri Oct 21 23:02:01 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 23:02:01 GMT
Subject: <i18n dev> Integrated: 8295239: Refactor java/util/Formatter/Basic
 script into a Java native test launcher
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <sc6EDb3g0FIYkYiCUKOCEEfEsyS-kwz4KvkNNffMVvI=.d788e5ad-ce30-4c9a-b53c-4dfb5d423c18@github.com>

On Fri, 14 Oct 2022 20:38:32 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

This pull request has now been integrated.

Changeset: 902162ca
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/902162ca9f0fc589b888e73862275554691697f4
Stats:     185 lines in 3 files changed: 106 ins; 63 del; 16 mod

8295239: Refactor java/util/Formatter/Basic script into a Java native test launcher

Reviewed-by: lancea, bchristi, naoto

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

PR: https://git.openjdk.org/jdk/pull/10715

From alanb at openjdk.org  Sat Oct 22 08:17:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Oct 2022 08:17:34 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
 <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
Message-ID: <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>

On Fri, 21 Oct 2022 19:46:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.

Indeed and periodically CLDR upgrades do cause breakage somewhere, often it will be a library or application tests that compare some result that is outdated due to changes that impact the formatting.

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

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Sat Oct 22 17:59:48 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Sat, 22 Oct 2022 17:59:48 GMT
Subject: <i18n dev> RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
 <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
 <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>
Message-ID: <3h39a2Y21Xh4WUIRBcmMXobOLrhe98C49Enk7kgsNeQ=.7a052b5b-f434-44cf-ae96-729a2993597a@github.com>

On Sat, 22 Oct 2022 08:14:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.
> 
> Indeed and periodically CLDR upgrades do cause breakage somewhere, often it will be a library or application tests that compare some result that is outdated due to changes that impact the formatting.

Yes, although libraries and tests shouldn't be testing against cultural formatting whose goal is to produce the updated best result, not the same result.  For example we had an internal corporate client which needed to use fixed formatting, instead of culturally sensitive formatting, because they really wanted exactly the same output every time, because the output data was going to be consumed by machine and not just by humans.

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

PR: https://git.openjdk.org/jdk/pull/10820

From prr at openjdk.org  Mon Oct 24 03:55:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:55:56 GMT
Subject: <i18n dev> RFR: 8295729: Remove trailing whitespace from
 non-value lines in properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <6Nga-zBIoxnexiDJp-uJqSHjkki2U2n6y5WW9chvPz0=.f389c36c-e6bd-4b32-81a2-0304f23ba6a2@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Mon Oct 24 15:52:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 15:52:38 GMT
Subject: <i18n dev> Integrated: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <8rhViPJXiQ9dJKOsX7pQaNU4YbABVGT0vUFbU38vI3o=.a26bd3d6-51d7-4960-bdf0-aaffef5ff474@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

This pull request has now been integrated.

Changeset: 5b3de6e1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b3de6e143e370272c36383adac3e31f359bc686
Stats:     99164 lines in 377 files changed: 68223 ins; 2820 del; 28121 mod

8284840: Update CLDR to Version 42.0

Reviewed-by: erikj, iris, joehw

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

PR: https://git.openjdk.org/jdk/pull/10820

From naoto at openjdk.org  Mon Oct 24 19:09:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 19:09:44 GMT
Subject: <i18n dev> RFR: 8284842: Update Unicode Data Files to Version 15.0.0
Message-ID: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>

Updates the JDK to use the latest Unicode 15, which also updates the ICU4J along with it (8284844: Update ICU4J to Version 72.1). The corresponding CSR has already been approved.

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

Commit messages:
 - 8284842: Update Unicode Data Files to Version 15.0.0

Changes: https://git.openjdk.org/jdk/pull/10839/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284842
  Stats: 1125 lines in 29 files changed: 821 ins; 33 del; 271 mod
  Patch: https://git.openjdk.org/jdk/pull/10839.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10839/head:pull/10839

PR: https://git.openjdk.org/jdk/pull/10839

From ihse at openjdk.org  Mon Oct 24 19:21:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:21:07 GMT
Subject: <i18n dev> RFR: 8295729: Remove trailing whitespace from
 non-value lines in properties files [v3]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Remove check for .properties from jcheck"
   
   This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
 - Change trailing space and tab in values to unicode encoding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/c91fdaa1..f4f94341

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01-02

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:22:38 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:22:38 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:25:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:25:38 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <yZpwsDUeKIrGQT3tvyGfGHFjIOuQTOBfRyvV7b-uArA=.077497ab-51b8-4346-b67d-9838e3419964@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I agree, that was an excellent idea Naoto! In my last commit, I have converted all trailing spaces/tabs in value lines into explicit unicode characters. Since that means we have no trailing spaces (from a jcheck perspective), I could also restore the jcheck that was the original driver behind this bug. (And also restore the bug/PR title to show the original intent.)

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:31:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:31:26 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v2]
In-Reply-To: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
Message-ID: <HmB2uBGv-fQnz3Kn7yEA0yIR4akDfM4tmso3sgA4-aQ=.d84de722-5d04-4aad-8ba3-572eea3cacc1@github.com>

On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove check for .properties from jcheck
>>  - Restore trailing whitespace for property values
>
> 368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

@andy-goryachev-oracle They are all automatically processed. There are two kinds of changes: Non-value lines have their trailing whitespace removed. You can verify that part of the PR by looking here: https://github.com/openjdk/jdk/pull/10792/files/c91fdaa19dc06351598bd1c0614e1af3bfa08ae2

This was the state of the PR as of three days ago. The most numerous number of changed files are here, but you can just scroll through the change and verify quickly that it is trivial.

The second change is the one suggested by Naoti; I have replaced all trailing tabs (there were just one) with `\u0009` and all trailing spaces with `\u0020`. That part was just pushed by me now. You can see that part separately here: https://github.com/openjdk/jdk/pull/10792/commits/a509b90f1b7f833924493fbd28b3cbb1a85c1f21

This affects far fewer files. And once again, it was mechanically generated. You can once again just scroll through and verify that all changes are due to the trailing whitespace being converted to unicode sequences.

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

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Started looking at whether certain trailing spaces can be (and/or should be) removed, but it quickly became apparent that we should just keep these properties as is (with the unicode escapes), rather than risk regression.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:

> 185: ### Button Demo ###
> 186: 
> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020

trailing whitespace looks unnecessary (accessible description?)

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Fehler beim Umbenennen von Datei oder Ordner
> 66: FileChooser.renameError.textAndMnemonic={0} kann nicht umbenannt werden
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0} kann nicht umbenannt werden: Es ist bereits eine Datei mit dem angegebenen Namen vorhanden. Geben Sie einen anderen Dateinamen an.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Error al cambiar el nombre del archivo o carpeta
> 66: FileChooser.renameError.textAndMnemonic=No se puede cambiar el nombre de {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=No se puede cambiar el nombre de {0}: ya existe un archivo con el nombre especificado. Especifique otro nombre de archivo.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Erreur lors du changement de nom du fichier ou du dossier
> 66: FileChooser.renameError.textAndMnemonic=Impossible de renommer {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossible de renommer {0} : il existe d\u00E9j\u00E0 un fichier portant le nom indiqu\u00E9. Indiquez-en un autre.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Errore durante la ridenominazione del file o della cartella
> 66: FileChooser.renameError.textAndMnemonic=Impossibile rinominare {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossibile rinominare {0}: esiste gi\u00E0 un file con il nome specificato. Specificare un altro nome.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=\u30D5\u30A1\u30A4\u30EB\u307E\u305F\u306F\u30D5\u30A9\u30EB\u30C0\u306E\u540D\u524D\u5909\u66F4\u30A8\u30E9\u30FC
> 66: FileChooser.renameError.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093: \u6307\u5B9A\u3057\u305F\u540D\u524D\u306E\u30D5\u30A1\u30A4\u30EB\u306F\u3059\u3067\u306B\u5B58\u5728\u3057\u307E\u3059\u3002\u5225\u306E\u30D5\u30A1\u30A4\u30EB\u540D\u3092\u6307\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Ett fel intr\u00E4ffade vid f\u00F6rs\u00F6k att \u00E4ndra namn p\u00E5 fil eller mapp
> 66: FileChooser.renameError.textAndMnemonic=Kan inte namn\u00E4ndra {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Kan inte namn\u00E4ndra {0}: En fil med angivet namn finns redan. Ange ett annat filnamn.\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat failed on value ( {0} ) in column {1}
> 43: cachedrowsetimpl.doublefail = getDouble failed on value ( {0} ) in column {1}
> 44: cachedrowsetimpl.dtypemismt = Data Type Mismatch\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative : Invalid cursor operation\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0}\u0020
> 127: crswriter.params2 = Value of params2 : {0}\u0020
> 128: crswriter.conflictsno =  conflicts while synchronizing\u0020

this is tricky.  if this value is a part of a sentence (i.e. something like "5 conflicts..."), the localization is likely to be wrong.  it's hard to tell without looking further into the code.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 43: cachedrowsetimpl.doublefail = getDouble bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 44: cachedrowsetimpl.dtypemismt = Keine Datentyp\u00FCbereinstimmung\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 73:

> 71: cachedrowsetimpl.numrows = Zeilenanzahl ist kleiner als null oder kleiner als Abrufgr\u00F6\u00DFe
> 72: cachedrowsetimpl.startpos = Startposition darf keinen Negativwert aufweisen
> 73: cachedrowsetimpl.nextpage = Daten m\u00FCssen vor dem Aufruf ausgef\u00FCllt werden\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative: Ung\u00FCltiger Cursorvorgang\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Indexwert liegt au\u00DFerhalb des Bereichs\u0020\u0020

prob. unnecessary

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

Marked as reviewed by angorya (no project role).

PR: https://git.openjdk.org/jdk/pull/10792

From jjg at openjdk.org  Mon Oct 24 19:45:01 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. I did not think it was a good idea to hold this PR, waiting for component teams to do the whitespace check first, for two reasons:

1) Now the trailing whitespace will be obvious, and any intended whitespace will not be accidentally stripped by an editor, so it will be easier for engineers to fix any problems.

2) I know from experience that this kind of cleaning-up has a very low priority for many engineers. If this PR were dependent on all JDK groups going through their properties files, it would basically never be closed.

And finally: Here is a complete list of the files which has trailing "unicode whitespace" in values. I will try to figure out to which components these belongs and open corresponding bugs.


src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties
src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties
test/jdk/javax/net/ssl/Stapling/TEST.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties
test/jdk/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties

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

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
Message-ID: <cuJYgquzi3I4fULUZZz_G_ZjmEd_wDsUPw2mzCceM_w=.ad366bc4-db7f-48ad-9d3f-a8d0ba9e1820@github.com>

On Mon, 24 Oct 2022 19:34:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed.

probably not needed - if nobody noticed anything until now we have no problem.  the solution to escape whitespace in values is the right solution, solves both the jcheck and WS visibility issues.

good job!

(and we can ignore my "prob. unnecessary" comments)

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

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:02 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <cRpIep8vLpUKvRQH3e_vwTIqVChg5uSLhFH4sSCbmOQ=.9c8e6492-c665-4666-bba9-4947cd6059b1@github.com>

On Mon, 24 Oct 2022 19:23:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:
> 
>> 185: ### Button Demo ###
>> 186: 
>> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020
> 
> trailing whitespace looks unnecessary (accessible description?)

although this is in demo...

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

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Mon Oct 24 20:02:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:02:54 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

The problem here is that all those (unnecessary) trailing spaces are appended by the external translators, who are not aware those spaces should not be at the end. I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

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

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 20:12:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 20:12:02 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
Message-ID: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>

On Mon, 24 Oct 2022 19:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

Good idea! I wonder if this should be done as a unit test.  go through all the bundles and check leading/trailing whitespace.

in my experience, the translators also (unintentionally) change the quotes and other symbols, sometimes breaking the code.  I assume the JDK has been exhaustively tested and we have no such problems.

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

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Mon Oct 24 20:16:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:16:56 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
 <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
Message-ID: <go6bwGp8ro_LeVwOJyBes4PXwMBEGNyPvq43vxGmmLU=.ed6bfa15-4664-41ab-87a9-51609382b9cf@github.com>

On Mon, 24 Oct 2022 20:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace.

Right. Definitely not a job for `jcheck`, but it should be considered somewhere in the l10n process.

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 20:39:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:39:57 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
Message-ID: <HMdFi0RZ9_Jhobfq_DLpJY4wycMf6qXcIHo90U8sq80=.4a035bff-b633-400b-bbf4-c3e7111385f3@github.com>

On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

I respectfully disagree. I think changing a trailing " " into a "\u0020" is the opposite of hiding it; it is making it plainly visible. In fact, I believe most of these trailing spaces are the result of them not being visible enough (and the tooling not warning).

Secondly, there are a lot of definitely unintentional trailing spaces, in comments and blank lines. I'd say there is factor 10:1 more of these. Getting these out of the way allows developers to focus more clearly on the trailing whitespace that matters: those in the key-value pairs.

And as I said, I intend to file follow-up issues for all files where there is a trailing unicode-sequence whitespace, so it will definitely not be lost on the respective component teams that they have something they need to address.

> Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

That's probably a good idea, but I think we should leave that to each respective team. Just like Andy's and Naoto's suggestion of improving i18n tooling to detect issues like this earlier on. Good idea, but I'd like to see that implemented separated from this PR. This PR is already large. The only reason it makes sense is because all changes (except the one to jcheck) are automatically generated and trivial to verify correctness of. If we were to start adding individual, manual changes into this PR, it would be just a huge mess.

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

PR: https://git.openjdk.org/jdk/pull/10792

From cjplummer at openjdk.org  Tue Oct 25 03:16:49 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Oct 2022 03:16:49 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <qb_ryMLGem495x0rBbOxd4vVGYPmnRiOkynx6AmvZVE=.5c5d3ee8-8498-4d6d-bfec-04a075ab085c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Changes requested by cjplummer (Reviewer).

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Exception thrown by the agent\u0020

I believe this space was just a typo and should be removed. Same for `agent.err.agentclass.failed` below and in all the other management property files.

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

PR: https://git.openjdk.org/jdk/pull/10792

From weijun at openjdk.org  Tue Oct 25 13:30:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:30:53 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <c28cQxkcVp8YCkAe0wDP4b7cUvb424JsH9ls5bR3m48=.31cad672-bef6-4d55-983d-2cb32a0cafea@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

I'm quite sure this space can be safely removed.

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

PR: https://git.openjdk.org/jdk/pull/10792

From weijun at openjdk.org  Tue Oct 25 13:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:47:02 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I noticed another problem. In some English properties files (Ex: `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`), `\u0020` is already used today but it turns into a whitespace in the translated files. It looks like the translation tool (most likely written in Java) decoded it while reading the English file but was not able to encode it back in a translation. I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

I suggest we focus on the English files this time and file a bug to the translation tool.

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

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Tue Oct 25 17:31:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Oct 2022 17:31:52 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
Message-ID: <CWhtHdVfwiBt9m16ZvVgfFbu-h9bRwVLYmwORiLTSVA=.210b4cf3-7f67-4f32-9983-b9fe54bd1571@github.com>

On Tue, 25 Oct 2022 13:43:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

Good catch, Max. Yes, that should be dealt with in the translation process.

> I suggest we focus on the English files this time and file a bug to the translation tool.

Agree.

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

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Wed Oct 26 21:00:43 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 26 Oct 2022 21:00:43 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
 [v2]
In-Reply-To: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
Message-ID: <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>

> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
> 
> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
> 
> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

Justin Lu 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 four additional commits since the last revision:

 - Merge master
 - Adjust template to reduce whitespace
 - Re-add modified BasicDateTime test contents removed by generated template
 - Adjust template to cleanup errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10684/files
  - new: https://git.openjdk.org/jdk/pull/10684/files/026ca4c1..88ef21cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10684&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10684&range=00-01

  Stats: 170665 lines in 2048 files changed: 98332 ins; 37356 del; 34977 mod
  Patch: https://git.openjdk.org/jdk/pull/10684.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10684/head:pull/10684

PR: https://git.openjdk.org/jdk/pull/10684

From bchristi at openjdk.org  Wed Oct 26 21:57:29 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 26 Oct 2022 21:57:29 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
 [v2]
In-Reply-To: <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
Message-ID: <RAqv1g1uMXNlqJSTOq9zZb3W-Ea98ioM9xowZFIWO_M=.ccf28b42-5e87-4e06-bdb8-2afa6ccbecc5@github.com>

On Wed, 26 Oct 2022 21:00:43 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
>> 
>> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
>> 
>> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.
>
> Justin Lu 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 four additional commits since the last revision:
> 
>  - Merge master
>  - Adjust template to reduce whitespace
>  - Re-add modified BasicDateTime test contents removed by generated template
>  - Adjust template to cleanup errors

Marked as reviewed by bchristi (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10684

From naoto at openjdk.org  Wed Oct 26 22:53:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Oct 2022 22:53:41 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
 [v2]
In-Reply-To: <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
Message-ID: <7jIGMsIS71nsvInjYUbGu8O-3N72pDRJvMcocvaTtNU=.7aaaacc8-b715-45d4-908d-2ae4a1fd347c@github.com>

On Wed, 26 Oct 2022 21:00:43 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
>> 
>> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
>> 
>> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.
>
> Justin Lu 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 four additional commits since the last revision:
> 
>  - Merge master
>  - Adjust template to reduce whitespace
>  - Re-add modified BasicDateTime test contents removed by generated template
>  - Adjust template to cleanup errors

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10684

From lancea at openjdk.org  Thu Oct 27 17:15:32 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 27 Oct 2022 17:15:32 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
 [v2]
In-Reply-To: <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
Message-ID: <HmFoCJYYpvEH6zr0hW1BUdEV8wFhhHJAgtEP7erIAcU=.7273dbbd-fb60-41cd-ab42-ab59c1f927c2@github.com>

On Wed, 26 Oct 2022 21:00:43 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
>> 
>> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
>> 
>> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.
>
> Justin Lu 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 four additional commits since the last revision:
> 
>  - Merge master
>  - Adjust template to reduce whitespace
>  - Re-add modified BasicDateTime test contents removed by generated template
>  - Adjust template to cleanup errors

Hi Justin

I think this looks oK overall.  There is some additional cleanup that can be done at a later time as we discussed but should be separate from this issue

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10684

From duke at openjdk.org  Thu Oct 27 17:43:39 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 27 Oct 2022 17:43:39 GMT
Subject: <i18n dev> RFR: 8295000: java/util/Formatter/Basic test cleanup
 [v2]
In-Reply-To: <HmFoCJYYpvEH6zr0hW1BUdEV8wFhhHJAgtEP7erIAcU=.7273dbbd-fb60-41cd-ab42-ab59c1f927c2@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
 <HmFoCJYYpvEH6zr0hW1BUdEV8wFhhHJAgtEP7erIAcU=.7273dbbd-fb60-41cd-ab42-ab59c1f927c2@github.com>
Message-ID: <pLlBumLVLrG8sXoB_KlR7cdf11ZqR4HRknAFilvID7U=.3cdda749-a0ae-4cf4-bd97-955cf80d4f8d@github.com>

On Thu, 27 Oct 2022 17:13:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu 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 four additional commits since the last revision:
>> 
>>  - Merge master
>>  - Adjust template to reduce whitespace
>>  - Re-add modified BasicDateTime test contents removed by generated template
>>  - Adjust template to cleanup errors
>
> Hi Justin
> 
> I think this looks oK overall.  There is some additional cleanup that can be done at a later time as we discussed but should be separate from this issue

@LanceAndersen Thank you Lance, 

I made the other changes we discussed, it is currently in a separate draft PR

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

PR: https://git.openjdk.org/jdk/pull/10684

From duke at openjdk.org  Thu Oct 27 20:58:46 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 27 Oct 2022 20:58:46 GMT
Subject: <i18n dev> Integrated: 8295000: java/util/Formatter/Basic test
 cleanup
In-Reply-To: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
Message-ID: <6-Ljay6kMcBh3BNzzNY0MOLCXFYkyEYG2GlnU0GTtQU=.9a72b171-a371-40fe-86e8-ef7e00017b3f@github.com>

On Thu, 13 Oct 2022 01:02:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
> 
> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
> 
> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

This pull request has now been integrated.

Changeset: 78763fc8
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78763fc8e0d6940f1c85ff8705733b8e6ae8e945
Stats:     312 lines in 20 files changed: 205 ins; 6 del; 101 mod

8295000: java/util/Formatter/Basic test cleanup

Reviewed-by: bchristi, naoto, lancea

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

PR: https://git.openjdk.org/jdk/pull/10684

From jlaskey at openjdk.org  Thu Oct 27 22:27:47 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Oct 2022 22:27:47 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview)
Message-ID: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>

Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

Commit messages:
 - Tabs to spaces
 - Force processor before template string expression
 - Correct implNote
 - Add valueGetters method
 - Added RAW template processor
 - Merge branch 'master' into 8285932
 - Rename to ValidatingProcessor
 - Javadoc mistakes
 - Rename TemplateProcessor
 - Clean up tests
 - ... and 4 more: https://git.openjdk.org/jdk/compare/0c13d666...7b2011ac

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285932
  Stats: 7452 lines in 74 files changed: 7263 ins; 45 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Thu Oct 27 22:47:26 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Oct 2022 22:47:26 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview)
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>

On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115:

> 113:      * we do not use all those slots, to let the strategies with MethodHandle
> 114:      * combinators to use some arguments.
> 115:      */

Suggestion:

     *
     * @since 20
     */

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058:

> 1056:          * @throws Throwable if fails to prepend value (unusual).
> 1057:          */
> 1058:         long prepend(long lengthCoder, byte[] buffer) throws Throwable;

This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data.

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

The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package.

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

PR: https://git.openjdk.org/jdk/pull/10889

From cjplummer at openjdk.org  Fri Oct 28 00:55:44 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Oct 2022 00:55:44 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
Message-ID: <DIScQIcbKFsercPkoaABYXSmJznKrSSnJwhL-kJDSDU=.5be8456a-ce87-4b56-83f9-b397e2785402@github.com>

On Fri, 7 Oct 2022 12:51:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> src/java.se/share/data/jdwp/jdwp.spec line 101:
> 
>> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
>> 100:         "in the target VM. This includes platform threads created with the Thread "
>> 101:         "API and all native threads attached to the target VM with JNI code."
> 
> The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

Since this PR has gone stale, I'll be fixing this typo in jdwp.spec via [JDK-8294672](https://bugs.openjdk.org/browse/JDK-8294672).

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

PR: https://git.openjdk.org/jdk/pull/10029

From jlaskey at openjdk.org  Fri Oct 28 14:55:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 14:55:28 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Move StringConcatItem to FormatConcatItem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/7b2011ac..26485968

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00-01

  Stats: 239 lines in 6 files changed: 93 ins; 109 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 14:55:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 14:55:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>
Message-ID: <8KVfwqrbnCSF-80frLIKExvp7jih3Ltp-UY3eaHuTco=.2f87479c-39d9-4eda-87f4-832b6ac8b9cb@github.com>

On Thu, 27 Oct 2022 21:21:52 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115:
> 
>> 113:      * we do not use all those slots, to let the strategies with MethodHandle
>> 114:      * combinators to use some arguments.
>> 115:      */
> 
> Suggestion:
> 
>      *
>      * @since 20
>      */

Updated along with a couple @since 19

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058:
> 
>> 1056:          * @throws Throwable if fails to prepend value (unusual).
>> 1057:          */
>> 1058:         long prepend(long lengthCoder, byte[] buffer) throws Throwable;
> 
> This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data.
> 
> --------------------------------------------------------------------------------
> 
> The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package.

Went the sealed class route. Unfortunately, the permitted classes are all package private otherwise I would have moved to an internal package.

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

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 16:12:50 2022
From: duke at openjdk.org (j3graham)
Date: Fri, 28 Oct 2022 16:12:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
Message-ID: <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>

On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move StringConcatItem to FormatConcatItem

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365:

> 363:         Objects.requireNonNull(sts, "sts must not be null");
> 364:         if (sts.length == 0) {
> 365:             StringTemplate.of("");

Missing return?

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367:

> 365:             StringTemplate.of("");
> 366:         } else if (sts.length == 1) {
> 367:             return sts[0];

Check for null?

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 17:57:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 17:57:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update TemplateRuntime::combine

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/26485968..20f54dec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 18:01:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 18:01:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>
Message-ID: <HhGc5V1_nIfnkwUhoR0KXdaqK12XDy4UdCwfQpYIHoM=.07435759-8a04-4f58-b244-30d81576cc56@github.com>

On Fri, 28 Oct 2022 16:09:51 GMT, j3graham <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365:
> 
>> 363:         Objects.requireNonNull(sts, "sts must not be null");
>> 364:         if (sts.length == 0) {
>> 365:             StringTemplate.of("");
> 
> Missing return?

Yep - updated

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367:
> 
>> 365:             StringTemplate.of("");
>> 366:         } else if (sts.length == 1) {
>> 367:             return sts[0];
> 
> Check for null?

Added null checks

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

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Fri Oct 28 18:38:20 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:20 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <qXjmvDvCAAHmElOuzn4nEUEG3d9bBXRHzmJJZHpGt1o=.9d9eb47e-e661-468b-b1ef-658b3d62cf25@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

Added some comments - will probably have some more at a later point

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

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Fri Oct 28 18:38:26 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:26 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
Message-ID: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>

On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move StringConcatItem to FormatConcatItem

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631:

> 629:         stringTemplateType = enterClass("java.lang.template.StringTemplate");
> 630:         templateRuntimeType = enterClass("java.lang.template.TemplateRuntime");
> 631:         templateProcessorType = enterClass("java.lang.template.ValidatingProcessor");

Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106:

> 104:     private final Attr attr;
> 105:     private final Symtab syms;
> 106:     private final Types types;

Why this change?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974:

> 4972:         if (processor != null) {
> 4973:             resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType));
> 4974:             resultType = chk.checkProcessorType(processor, resultType, env);

It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:

> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
> 4138: 
> 4139:             if (typeArguments.size() == 2) {

Is this code correct? TemplateProcessor seems to have just one type argument.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1:

> 1: /*

This file shouldn't be here

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348:

> 346:                 try {
> 347:                     chk.disablePreviewCheck = true;
> 348:                     String autoImports = """

I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless.

What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there.

As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step).

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

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Fri Oct 28 18:38:27 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:27 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
Message-ID: <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>

On Fri, 28 Oct 2022 16:09:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:
> 
>> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
>> 4138: 
>> 4139:             if (typeArguments.size() == 2) {
> 
> Is this code correct? TemplateProcessor seems to have just one type argument.

Ah - `templateProcessorType` is not what it seems :-)

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 18:50:34 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 18:50:34 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32:

> 30: 
> 31: import java.io.IOException;
> 32: import java.util.*;

Please do not use import *.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36:

> 34: import java.lang.invoke.MethodHandles.Lookup;
> 35: import java.lang.template.StringTemplate;
> 36: import java.util.*;

Another import * here

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:

> 116:      * @since 20
> 117:      */
> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;

I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999:

> 997:      * Promote integral types to int.
> 998:      */
> 999:     private static Class<?> promoteIntType(Class<?> t) {

promoteToIntType ?

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:02:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:02:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:

> 1040:      * The number of fragments must be one more that the number of ptypes.
> 1041:      * The total number of slots used by the ptypes must be less than or equal
> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.

see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060:

> 1058:             throws StringConcatException
> 1059:     {
> 1060:         Objects.requireNonNull(fragments, "fragments is null");

I think you need to do some defensive copy here

  ptypes = List.copyOf(pTypes);

to avoid the types and fragments to be changed at the same time they are checked.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:

> 1175:      */
> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(

I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not

src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51:

> 49:     /**
> 50:      * Construct a {@link MethodHandle} that constructs a result based on the
> 51:      * bootstrap method information.

This comment is quite obscure if you have no idea how it works.
And the information that the returned method handle has the type of the MethodType passed as parameter is missing.

src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:

> 36: record SimpleStringTemplate(List<String> fragments,
> 37:                              List<Object> values
> 38: ) implements StringTemplate {}

A compact constructor doing defensive copies is missing

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:11:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:11:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:

> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 44: @FunctionalInterface
> 45: public interface StringProcessor extends TemplateProcessor<String> {}

The name should be `StringTemplateProcessor`.
And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 29:

> 27: 
> 28: import java.lang.invoke.MethodHandle;
> 29: import java.util.*;

Please fix.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:

> 147:      * {@return the interpolation of the StringTemplate}
> 148:      */
> 149:     default String interpolate() {

I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy

src/java.base/share/classes/java/lang/template/StringTemplate.java line 175:

> 173:      * method {@code processor.process(this)}.
> 174:      */
> 175:     default <R, E extends Throwable> R process(ValidatingProcessor<R, E> processor) throws E {

signature should be `ValidatingProcessor<? extends R, ? extends E> processor`

src/java.base/share/classes/java/lang/template/StringTemplate.java line 204:

> 202:      * embedded expressions fields, otherwise this method returns getters for the values list.
> 203:      */
> 204:     default public List<MethodHandle> valueGetters() {

I think i prefer the term accessors instead of getters

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:31:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:31:36 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/StringTemplate.java line 307:

> 305:             Objects.requireNonNull(fragment, "fragments elements must be non-null");
> 306:         }
> 307:         fragments = Collections.unmodifiableList(new ArrayList<>(fragments));

I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of().

src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:

> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 322:      */
> 323:     public static String interpolate(List<String> fragments, List<Object> values) {

This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 354:

> 352:      * @implNote The result of interpolation is not interned.
> 353:      */
> 354:     public static final StringProcessor STR = st -> st.interpolate();

Should be `StringTemplate::interpolate`.

src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38:

> 36:  * that do not throw checked exceptions. For example:
> 37:  * {@snippet :
> 38:  * TemplateProcessor<String> processor = st -> {

This is a good example of why having both way to describe a template processor of string, TemplateProcessor<String and `StringPorcessor` is a bad idea.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45:

> 43:  */
> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 45: public final class TemplateRuntime {

Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc)

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65:

> 63:      * @throws Throwable            if linkage fails
> 64:      */
> 65:     public static CallSite stringTemplateBSM(

I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79:

> 77:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
> 78:         ValidatingProcessor<?, ? extends Throwable> processor =
> 79:                 (ValidatingProcessor<?, ? extends Throwable>)processorGetter.asType(processorGetterType).invokeExact();

`ValidatingProcessor<?, ?>` should be enough ? No ?
Not using a "? extends Throwable" here make the type unchecked.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88:

> 86:      * Manages the boostrapping of {@link ProcessorLinkage} callsites.
> 87:      */
> 88:     private static class TemplateBootstrap {

This class should be `final`

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117:

> 115:          * Static final processor.
> 116:          */
> 117:         private final ValidatingProcessor<?, ? extends Throwable> processor;

Use `ValidatingProcessor<?, ?>` here

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145:

> 143:         private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type,
> 144:                                   List<String> fragments,
> 145:                                   ValidatingProcessor<?, ? extends Throwable> processor) {

Use ValidatingProcessor<?, ?> here

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:

> 209:     @SuppressWarnings("unchecked")
> 210:     public static <E> List<E> toList(E... elements) {
> 211:         return Collections.unmodifiableList(Arrays.asList(elements));

This is List.of(), please use List.of() instead

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:31:37 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:31:37 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
Message-ID: <NMJNYCbIc_ENhRzVNutxnKczkfNmxTs3dR6A1ExqFCA=.28e0b8ce-c7fd-466c-b523-ce79102ed487@github.com>

On Fri, 28 Oct 2022 16:33:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631:
> 
>> 629:         stringTemplateType = enterClass("java.lang.template.StringTemplate");
>> 630:         templateRuntimeType = enterClass("java.lang.template.TemplateRuntime");
>> 631:         templateProcessorType = enterClass("java.lang.template.ValidatingProcessor");
> 
> Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code.

Renaming.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106:
> 
>> 104:     private final Attr attr;
>> 105:     private final Symtab syms;
>> 106:     private final Types types;
> 
> Why this change?

Renaming. Was residual to some context based typing (StringTemplate vs String) Jan and I experimented with.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974:
> 
>> 4972:         if (processor != null) {
>> 4973:             resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType));
>> 4974:             resultType = chk.checkProcessorType(processor, resultType, env);
> 
> It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate.

Not sure where you get `StringTemplate`.  If you specify `TemplateProcessor<String>` the `resultType` will be `String`.  For example:


public class Processor implements TemplateProcessor<String> {
    @Override
    public String process(StringTemplate st) {
        return st.interpolate();
    }
}

and

public class Main {
    public static void main(String... args) throws Throwable {
        Processor processor = new Processor();
        System.out.println(processor."1234");
    }
}

works with "1234" as a result.

If you later change to


public class Processor implements TemplateProcessor<Integer> {
    @Override
    public Integer process(StringTemplate st) {
        return Integer.valueOf(st.interpolate());
    }
}


Then you get a `java.lang.ClassCastException` as you would expect.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1:
> 
>> 1: /*
> 
> This file shouldn't be here

oops - We should change the `.gitignore` to include `.orig` and `.rej`

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348:
> 
>> 346:                 try {
>> 347:                     chk.disablePreviewCheck = true;
>> 348:                     String autoImports = """
> 
> I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless.
> 
> What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there.
> 
> As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step).

This was recommended by Jan and the procedure used in other parts of the code.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:31:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:31:38 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
 <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>
Message-ID: <Bk1GNLr8K1rN6d6Puz8wVQKeOEUaWvVeK7jiM7wICTY=.fb15a02b-82ec-4c08-9e17-233dfa4fee79@github.com>

On Fri, 28 Oct 2022 16:33:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:
>> 
>>> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
>>> 4138: 
>>> 4139:             if (typeArguments.size() == 2) {
>> 
>> Is this code correct? TemplateProcessor seems to have just one type argument.
>
> Ah - `templateProcessorType` is not what it seems :-)

Renaming. I held off assuming that bike shedding would change it once again.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:41:33 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:41:33 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
Message-ID: <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>

On Fri, 28 Oct 2022 18:45:05 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32:
> 
>> 30: 
>> 31: import java.io.IOException;
>> 32: import java.util.*;
> 
> Please do not use import *.

Changing.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36:
> 
>> 34: import java.lang.invoke.MethodHandles.Lookup;
>> 35: import java.lang.template.StringTemplate;
>> 36: import java.util.*;
> 
> Another import * here

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:
> 
>> 116:      * @since 20
>> 117:      */
>> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;
> 
> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.

There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999:
> 
>> 997:      * Promote integral types to int.
>> 998:      */
>> 999:     private static Class<?> promoteIntType(Class<?> t) {
> 
> promoteToIntType ?

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060:
> 
>> 1058:             throws StringConcatException
>> 1059:     {
>> 1060:         Objects.requireNonNull(fragments, "fragments is null");
> 
> I think you need to do some defensive copy here
> 
>   ptypes = List.copyOf(pTypes);
> 
> to avoid the types and fragments to be changed at the same time they are checked.

Changing

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:41:34 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:41:34 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289:

> 287:         try {
> 288:             MethodHandles.Lookup lookup = MethodHandles.lookup();
> 289:             MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue",

This should be a constant (using the class holder idiom or not)

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302:

> 300: 
> 301:     /**
> 302:      * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)}

Private "method"

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325:

> 323:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 324:      */
> 325:     static String interpolate(List<String> fragments, List<Object> values) {

I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389:

> 387:             }
> 388:         }
> 389:         return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values));

It seems that IntelliJ was lot when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:51:49 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:51:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v4]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove .orig file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/20f54dec..347df715

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=02-03

  Stats: 4223 lines in 1 file changed: 0 ins; 4223 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:51:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:51:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/util/FormatProcessor.java line 198:

> 196:      * {@link FMT} uses the Locale.US {@link Locale}.
> 197:      */
> 198:     public static final FormatProcessor FMT = new FormatProcessor(Locale.US);

`Locale.US` or `Locale.ROOT` ??
see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:55:07 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:55:07 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
Message-ID: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>

On Fri, 28 Oct 2022 19:34:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:
>> 
>>> 116:      * @since 20
>>> 117:      */
>>> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;
>> 
>> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.
>
> There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.

But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area.

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

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 20:01:29 2022
From: duke at openjdk.org (Franz =?UTF-8?B?V2lsaGVsbXN0w7Z0dGVy?=)
Date: Fri, 28 Oct 2022 20:01:29 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>

On Fri, 28 Oct 2022 19:21:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:
> 
>> 209:     @SuppressWarnings("unchecked")
>> 210:     public static <E> List<E> toList(E... elements) {
>> 211:         return Collections.unmodifiableList(Arrays.asList(elements));
> 
> This is List.of(), please use List.of() instead

`List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:

public static <E> List<E> toList(E... elements) {
	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
}

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 20:01:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:01:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
Message-ID: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>

On Fri, 28 Oct 2022 19:51:21 GMT, Franz Wilhelmst?tter <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:
>> 
>>> 209:     @SuppressWarnings("unchecked")
>>> 210:     public static <E> List<E> toList(E... elements) {
>>> 211:         return Collections.unmodifiableList(Arrays.asList(elements));
>> 
>> This is List.of(), please use List.of() instead
>
> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:
> 
> public static <E> List<E> toList(E... elements) {
> 	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
> }

Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used).
Using that implementation will avoid a bunch of indirection

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 20:25:35 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:25:35 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
 <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
Message-ID: <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@github.com>

On Fri, 28 Oct 2022 19:52:14 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.
>
> But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area.

Anyway, i think you are right, this can be public

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 20:25:36 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 20:25:36 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
Message-ID: <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>

On Fri, 28 Oct 2022 18:52:28 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:
> 
>> 1040:      * The number of fragments must be one more that the number of ptypes.
>> 1041:      * The total number of slots used by the ptypes must be less than or equal
>> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.
> 
> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public

Disagree.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:
> 
>> 1175:      */
>> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(
> 
> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not

Use cases are very different.  The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input.

> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51:
> 
>> 49:     /**
>> 50:      * Construct a {@link MethodHandle} that constructs a result based on the
>> 51:      * bootstrap method information.
> 
> This comment is quite obscure if you have no idea how it works.
> And the information that the returned method handle has the type of the MethodType passed as parameter is missing.

Deliberate obscure for preview. Once we sort out the functional space you have been looking for, this will likely go away. ProcessorFactory and ProcessorBuilder are a couple of the possibilities.

> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:
> 
>> 36: record SimpleStringTemplate(List<String> fragments,
>> 37:                              List<Object> values
>> 38: ) implements StringTemplate {}
> 
> A compact constructor doing defensive copies is missing

The defensive copies are done by the callers.

> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:
> 
>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 44: @FunctionalInterface
>> 45: public interface StringProcessor extends TemplateProcessor<String> {}
> 
> The name should be `StringTemplateProcessor`.
> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.
> 
> see TemplateProcessor

Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 20:25:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:25:36 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
Message-ID: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>

On Fri, 28 Oct 2022 20:01:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:
>> 
>>> 1040:      * The number of fragments must be one more that the number of ptypes.
>>> 1041:      * The total number of slots used by the ptypes must be less than or equal
>>> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.
>> 
>> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public
>
> Disagree.

As i said above, i consider this thread as resolved

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:
>> 
>>> 1175:      */
>>> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(
>> 
>> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not
>
> Use cases are very different.  The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input.

yes, sorry for the noise.

>> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:
>> 
>>> 36: record SimpleStringTemplate(List<String> fragments,
>>> 37:                              List<Object> values
>>> 38: ) implements StringTemplate {}
>> 
>> A compact constructor doing defensive copies is missing
>
> The defensive copies are done by the callers.

In that case, i wonder if not not better to move that record inside another class, closer to where the callers are

>> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:
>> 
>>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 44: @FunctionalInterface
>>> 45: public interface StringProcessor extends TemplateProcessor<String> {}
>> 
>> The name should be `StringTemplateProcessor`.
>> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.
>> 
>> see TemplateProcessor
>
> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`

Is it that different from`TemplateProcessor<String> upper = st -> st.interpolate().toUpperCase();` ?

People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing.

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

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 21:59:53 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 28 Oct 2022 21:59:53 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java
Message-ID: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>

Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh

Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.

Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

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

Commit messages:
 - Add previous hard coded change into template
 - Remove duplicated methods, put into Basic
 - Toggle -nel for gen script

Changes: https://git.openjdk.org/jdk/pull/10910/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10910&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295670
  Stats: 29666 lines in 22 files changed: 1531 ins; 27888 del; 247 mod
  Patch: https://git.openjdk.org/jdk/pull/10910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10910/head:pull/10910

PR: https://git.openjdk.org/jdk/pull/10910

From bchristi at openjdk.org  Fri Oct 28 22:11:27 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 28 Oct 2022 22:11:27 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java
In-Reply-To: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
Message-ID: <KwHWlT4wYd9Z0nTPLOG_GMVv6iUdRmivM6ENIP3W9hw=.36e4de60-9c43-4d4c-9246-b41fd26b31bf@github.com>

On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
> 
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
> 
> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

Looks good. That sure was a lot of extra newlines!

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

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10910

From naoto at openjdk.org  Fri Oct 28 22:46:49 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Oct 2022 22:46:49 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java
In-Reply-To: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
Message-ID: <3nb6Mh7G9rTwkyxe9aF4mZCS9td26kHx_XkwMpksl98=.12751398-6095-44a9-a24b-da877874338d@github.com>

On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
> 
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
> 
> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

test/jdk/java/util/Formatter/Basic-X.java.template line 1612:

> 1610:         list.remove("America/WhiteHorse");
> 1611:         list.remove("Canada/Yukon");
> 1612:         ids = list.toArray(new String[list.size()]);

It's not your change but I just noticed this. Since we specifically test only for `CLDR` provider (as in `BasicTestLauncher`), I wonder we could remove this portion. Even if we do need this piece, it could be simplified as:

ids = Arrays.stream(ids).filter(tz -> !tz.equals(...)).toArray(String[]::new)

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

PR: https://git.openjdk.org/jdk/pull/10910

From duke at openjdk.org  Fri Oct 28 23:54:22 2022
From: duke at openjdk.org (j3graham)
Date: Fri, 28 Oct 2022 23:54:22 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v4]
In-Reply-To: <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
Message-ID: <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>

On Fri, 28 Oct 2022 19:51:49 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove .orig file

src/java.base/share/classes/java/util/FormatterBuilder.java line 470:

> 468:      */
> 469:     MethodHandle build() {
> 470:         Formatter.parse(format);

`Formatter.parse` is called here, and then again a few lines down.

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

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Sat Oct 29 01:03:23 2022
From: duke at openjdk.org (ExE Boss)
Date: Sat, 29 Oct 2022 01:03:23 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>

On Fri, 28 Oct 2022 19:13:54 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:
> 
>> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 322:      */
>> 323:     public static String interpolate(List<String> fragments, List<Object> values) {
> 
> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.

Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.

The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.

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

PR: https://git.openjdk.org/jdk/pull/10889

From aivanov at openjdk.org  Sat Oct 29 12:14:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 12:14:25 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <rzIw7fkMmSiQ4HJygtWh3SxVIIZg4QY0nvByxOYUyGs=.b878366e-a60f-410f-94ae-47b486f4e7b5@github.com>

On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:
> 
>> 132: 
>> 133: #SyncResolverImpl exceptions
>> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020
> 
> prob. unnecessary

This case is similar the one you mentioned below. If this value is used in a string template or concatenation, the trailing white-space could be necessary; however, one space is probably enough.

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

PR: https://git.openjdk.org/jdk/pull/10792

From aivanov at openjdk.org  Sat Oct 29 13:22:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 13:22:09 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <4Npxj4pEaiqkJ2UBTsYb3xTHYseNBoj_3yshwocOIxw=.c701af52-62db-40c2-b3a3-90e47c44ed76@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Trailing spaces in `LocaleNames_*` are only in two files:

- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties`
- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties`

It is very unlikely these spaces are part of a country or language name. The former file contains a few trailing spaces, the latter ? only one.

src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties line 238:

> 236: cpp=Kreolisch-Portugiesische Sprache
> 237: crh=Krimtatarisch
> 238: crp=Kreolische Sprache\u0020

I'm pretty sure locale names shouldn't contain trailing spaces.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Sat Oct 29 18:09:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 29 Oct 2022 18:09:25 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java
In-Reply-To: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
Message-ID: <fAtOoLlIqFr9KvcEARECu9ZoEIvOY_TWjEgz3VIP_6U=.d7121113-1ead-47a3-a447-41cea95878a1@github.com>

On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
> 
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
> 
> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

test/jdk/java/util/Formatter/Basic-X.java.template line 1608:

> 1606:         // time zone ID. See JDK-8254865.
> 1607:         final List<String> list =  new ArrayList<String>();
> 1608:         Collections.addAll(list, ids);

I think

final List<String> list =  new ArrayList<>(Arrays.asList(ids));

is going to be faster than

final List<String> list =  new ArrayList<String>();
Collections.addAll(list, ids);

Alternatively you can contruct presized ArrayList.

test/jdk/java/util/Formatter/Basic-X.java.template line 1612:

> 1610:         list.remove("America/WhiteHorse");
> 1611:         list.remove("Canada/Yukon");
> 1612:         ids = list.toArray(new String[list.size()]);

ids = list.toArray(new String[0]);

is likely to be faster, see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

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

PR: https://git.openjdk.org/jdk/pull/10910

From forax at openjdk.org  Mon Oct 31 07:17:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 07:17:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
Message-ID: <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>

On Sat, 29 Oct 2022 00:56:18 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:
>> 
>>> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>>> 322:      */
>>> 323:     public static String interpolate(List<String> fragments, List<Object> values) {
>> 
>> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.
>
> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.
> 
> The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.

Ok, get it.
I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`.

The less methods in the API, the better.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:39:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:39:28 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <EQVJmKVbtnwEXTfgghVb4mU5BE4xtbqoLDTOgwCmqDU=.73928cc8-ed53-4da1-81dd-a5b847aa9595@github.com>

On Fri, 28 Oct 2022 20:23:26 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`
>
> Is it that different from`TemplateProcessor<String> upper = st -> st.interpolate().toUpperCase();` ?
> 
> People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing.

Noted

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:53:29 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:53:29 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <OIUDXCNftOdGHiKS44vTdCuDosKklkect9B3NrfkNNk=.2a399201-95dd-4f7c-a768-14da71da6c41@github.com>

On Fri, 28 Oct 2022 20:07:35 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> The defensive copies are done by the callers.
>
> In that case, i wonder if not not better to move that record inside another class, closer to where the callers are

Moving to TemplateRuntime

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:53:32 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:53:32 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <hEQTvtQgMLQMCZHJWaVzJzCGo_H7PAYWpR_X8Vs3Hcw=.c9102791-3f62-4222-afea-3aba32323325@github.com>

On Fri, 28 Oct 2022 19:05:10 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 29:
> 
>> 27: 
>> 28: import java.lang.invoke.MethodHandle;
>> 29: import java.util.*;
> 
> Please fix.

Changing

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:59:36 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:59:36 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <ZE2vcmQWISh2duTMkVFwVLUj4JfRFSR5ZQ9gz8AWhgk=.e9946cbe-e5a4-4a9c-a2c6-f309bd536142@github.com>

On Fri, 28 Oct 2022 19:06:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 175:
> 
>> 173:      * method {@code processor.process(this)}.
>> 174:      */
>> 175:     default <R, E extends Throwable> R process(ValidatingProcessor<R, E> processor) throws E {
> 
> signature should be `ValidatingProcessor<? extends R, ? extends E> processor`

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 204:
> 
>> 202:      * embedded expressions fields, otherwise this method returns getters for the values list.
>> 203:      */
>> 204:     default public List<MethodHandle> valueGetters() {
> 
> I think i prefer the term accessors instead of getters

Changing

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:04:32 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:04:32 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>

On Fri, 28 Oct 2022 19:08:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:
> 
>> 147:      * {@return the interpolation of the StringTemplate}
>> 148:      */
>> 149:     default String interpolate() {
> 
> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy

Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage  of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor<JSONObject> JSON = st -> new JSONObject(st.interpolate());`

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:40:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:40:38 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <n5D2AKUK150bLdl1X1PAp8RZQ9Oo4EOJh863F8tMSMQ=.078b48c3-59bb-40c1-a3df-660242f8ae74@github.com>

On Fri, 28 Oct 2022 19:12:02 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 307:
> 
>> 305:             Objects.requireNonNull(fragment, "fragments elements must be non-null");
>> 306:         }
>> 307:         fragments = Collections.unmodifiableList(new ArrayList<>(fragments));
> 
> I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of().
> 
> Edit:
> fragments should use List.copyOf() but i suppose that a value inside values can be null, so you can not use List.copyOf() for the values.
> 
> There a little secret, the ImmutableList  has a special flag to represent an unmodifiable list that can access null, this implementation is used by `stream.toList()`, i think you should use a shared secret access to have have access to this implementation instead of relying on `Collections.unmodifiableList(new ArrayList<>(...))`.
> 
> @stuart-marks, do you think it's a good idea to use the null allowed ImmutableList here ?

Changing as recommended

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 354:
> 
>> 352:      * @implNote The result of interpolation is not interned.
>> 353:      */
>> 354:     public static final StringProcessor STR = st -> st.interpolate();
> 
> Should be `StringTemplate::interpolate`.

Yep

> src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38:
> 
>> 36:  * that do not throw checked exceptions. For example:
>> 37:  * {@snippet :
>> 38:  * TemplateProcessor<String> processor = st -> {
> 
> This is a good example of why having both way to describe a template processor of string, TemplateProcessor<String and `StringPorcessor` is a bad idea.

Noted

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:40:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:40:38 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
 <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>
Message-ID: <IQ1cw48hyO6eHZumI9fehaIEPEFhx4GHZaRtexHoW7k=.b9cb907b-f4f7-4bbb-ace7-32c86b86fdfe@github.com>

On Mon, 31 Oct 2022 07:14:45 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.
>> 
>> The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.
>
> Ok, get it.
> I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`.
> 
> The less methods in the API, the better.

Noted

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:49:18 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:49:18 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com>

On Fri, 28 Oct 2022 19:20:40 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45:
> 
>> 43:  */
>> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 45: public final class TemplateRuntime {
> 
> Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc)

Purely because of the BSM and BSMs access to internals of `java.lang.template`. I'll work on moving the BSM to `jdk.internal`. and access through `SharedSecrets`.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65:
> 
>> 63:      * @throws Throwable            if linkage fails
>> 64:      */
>> 65:     public static CallSite stringTemplateBSM(
> 
> I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added.

Will work on it.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:49:20 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:49:20 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
 <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>
Message-ID: <bGVojc8FhYiLJbpzQl5TyXcYKzEurvx_Sf9Mc0R5IkA=.c35beb5c-11d4-4413-a766-82e7fd200bdf@github.com>

On Fri, 28 Oct 2022 19:57:41 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:
>> 
>> public static <E> List<E> toList(E... elements) {
>> 	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
>> }
>
> Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used).
> Using that implementation will avoid a bunch of indirection

Changing to use `JUCA`.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:54:44 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:54:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <Z7QI2E1zswpmzuoUkBJzlEYAh1l9iOcTYwe82y4X2Uw=.0056169c-283a-4012-a943-c7223b67485e@github.com>

On Fri, 28 Oct 2022 19:26:20 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79:
> 
>> 77:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
>> 78:         ValidatingProcessor<?, ? extends Throwable> processor =
>> 79:                 (ValidatingProcessor<?, ? extends Throwable>)processorGetter.asType(processorGetterType).invokeExact();
> 
> `ValidatingProcessor<?, ?>` should be enough ? No ?
> Using a "? extends Throwable" here make the type unchecked.

That works. Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88:
> 
>> 86:      * Manages the boostrapping of {@link ProcessorLinkage} callsites.
>> 87:      */
>> 88:     private static class TemplateBootstrap {
> 
> This class should be `final`

Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117:
> 
>> 115:          * Static final processor.
>> 116:          */
>> 117:         private final ValidatingProcessor<?, ? extends Throwable> processor;
> 
> Use `ValidatingProcessor<?, ?>` here

That works. Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145:
> 
>> 143:         private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type,
>> 144:                                   List<String> fragments,
>> 145:                                   ValidatingProcessor<?, ? extends Throwable> processor) {
> 
> Use ValidatingProcessor&lt;?, ?&gt; here

That works. Changing.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:30:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:30:28 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <K46-FD72Mtz3zFIhWwj9_0QI100Sy4_XE2q34hxNyMU=.9e66b1d0-5031-4564-8404-e1b545f2fafa@github.com>

On Fri, 28 Oct 2022 19:33:38 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289:
> 
>> 287:         try {
>> 288:             MethodHandles.Lookup lookup = MethodHandles.lookup();
>> 289:             MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue",
> 
> This should be a constant (using the class holder idiom or not)

Changing

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302:
> 
>> 300: 
>> 301:     /**
>> 302:      * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)}
> 
> Private "method"

Changing

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:39:34 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:39:34 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <EprEHey_-RlxTSqSiEgb7upgHtblKqAQO6mM_Exgqjs=.eaf0be7b-85d2-4179-847c-da5d07c80eb7@github.com>

On Fri, 28 Oct 2022 19:39:01 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389:
> 
>> 387:             }
>> 388:         }
>> 389:         return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values));
> 
> It seems that IntelliJ was lost when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime.

Changing

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:49:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:49:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <hJKj6jjb0I6mnmYZW8CO7T_AfPDBzbz1B4xuG8mZ9Gc=.b156b047-8839-4447-b21f-fbe7b3b4eb8f@github.com>

On Fri, 28 Oct 2022 19:36:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325:
> 
>> 323:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 324:      */
>> 325:     static String interpolate(List<String> fragments, List<Object> values) {
> 
> I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element

Changing

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 15:01:35 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:01:35 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v4]
In-Reply-To: <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
 <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>
Message-ID: <HhniXeb1FMUt_2zLv1ioKD232wB4uGp6wNf06Lym3KI=.977dc53f-abe0-47dc-b06b-9475f919308c@github.com>

On Fri, 28 Oct 2022 23:50:11 GMT, j3graham <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove .orig file
>
> src/java.base/share/classes/java/util/FormatterBuilder.java line 470:
> 
>> 468:      */
>> 469:     MethodHandle build() {
>> 470:         Formatter.parse(format);
> 
> `Formatter.parse` is called here, and then again a few lines down.

Residue cruft. Thanks. Changing.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 15:01:31 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:01:31 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>
Message-ID: <YUiKJ6MKELuPwEDxpmhH3AEsMk8mG7vLANniLjwaGuM=.d88e51b7-a807-4892-8dd0-977ab9fa8037@github.com>

On Fri, 28 Oct 2022 19:45:55 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 198:
> 
>> 196:      * {@link FMT} uses the Locale.US {@link Locale}.
>> 197:      */
>> 198:     public static final FormatProcessor FMT = new FormatProcessor(Locale.US);
> 
> `Locale.US` or `Locale.ROOT` ??
> see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT

There was a bug in DecimalFormatSymbols when I started this work and Locale.ROOT was problematic. I didn't circle around to check later. Changing.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 15:38:42 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:38:42 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v5]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <UEq7NU7NgwbZA9fmIW88hdE8TtJfMV1xgTUoyT9UUGQ=.9fa69424-0a2f-4909-8f77-8b1109f407d0@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Requested changes #2
 - Requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/347df715..d30e6eff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=03-04

  Stats: 168 lines in 15 files changed: 60 ins; 60 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Mon Oct 31 15:55:28 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 15:55:28 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
 <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>
Message-ID: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com>

On Mon, 31 Oct 2022 13:02:18 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:
>> 
>>> 147:      * {@return the interpolation of the StringTemplate}
>>> 148:      */
>>> 149:     default String interpolate() {
>> 
>> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy
>
> Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage  of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor<JSONObject> JSON = st -> new JSONObject(st.interpolate());`

Interesting !
I believe the javadoc should mention that.

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

PR: https://git.openjdk.org/jdk/pull/10889

From aturbanov at openjdk.org  Mon Oct 31 17:35:16 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 31 Oct 2022 17:35:16 GMT
Subject: <i18n dev> RFR: 8296140: Drop unused field
 java.util.Calendar.DATE_MASK
Message-ID: <P7Lc7JlcC90i-4Chm5eEV2Kd7etfqQdY_5QLq_RHHME=.5f2d6083-b7f8-4065-9d2b-0ceb11c9e75a@github.com>

There is no usages for this field. As it has the same value as `DAY_OF_MONTH_MASK` we can drop it.

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

Commit messages:
 - [PATCH] Drop unused field java.util.Calendar.DATE_MASK

Changes: https://git.openjdk.org/jdk/pull/10888/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10888&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296140
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10888/head:pull/10888

PR: https://git.openjdk.org/jdk/pull/10888

From joehw at openjdk.org  Mon Oct 31 17:37:27 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 31 Oct 2022 17:37:27 GMT
Subject: <i18n dev> RFR: 8284842: Update Unicode Data Files to Version
 15.0.0
In-Reply-To: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>
References: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>
Message-ID: <A4Bs5Hqr5NbcJTyTVCx9XQ7pLAbdmfijavFbFdsZlDo=.3abb5f64-e34b-431d-badf-03730779b744@github.com>

On Mon, 24 Oct 2022 18:50:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updates the JDK to use the latest Unicode 15, which also updates the ICU4J along with it (8284844: Update ICU4J to Version 72.1). The corresponding CSR has already been approved.

LGTM. Sorry for the delay.

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

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10839

From jlaskey at openjdk.org  Mon Oct 31 17:39:58 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 17:39:58 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v6]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <DJB8X-GwBxtqwAX0Rv_zRn_GhLXHyCF2-1RszcbcVtc=.532ca016-1d04-40f1-8523-399e24d59d75@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Move template bootstrap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/d30e6eff..75fcc49a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=04-05

  Stats: 364 lines in 4 files changed: 210 ins; 147 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Mon Oct 31 17:50:47 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 31 Oct 2022 17:50:47 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
Message-ID: <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>

> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
> 
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
> 
> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove old ids hack, has no usage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10910/files
  - new: https://git.openjdk.org/jdk/pull/10910/files/8611e5b9..1bb22a2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10910&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10910&range=00-01

  Stats: 20 lines in 2 files changed: 0 ins; 20 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10910/head:pull/10910

PR: https://git.openjdk.org/jdk/pull/10910

From duke at openjdk.org  Mon Oct 31 17:50:47 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 31 Oct 2022 17:50:47 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <fAtOoLlIqFr9KvcEARECu9ZoEIvOY_TWjEgz3VIP_6U=.d7121113-1ead-47a3-a447-41cea95878a1@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
 <fAtOoLlIqFr9KvcEARECu9ZoEIvOY_TWjEgz3VIP_6U=.d7121113-1ead-47a3-a447-41cea95878a1@github.com>
Message-ID: <Zv1qEnKYZpgj7C3A5gF9j4U2RO1flTPHt-n3O8xNiFk=.4eb9b3c1-8209-4e79-a31d-106ada734c74@github.com>

On Sat, 29 Oct 2022 18:05:50 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove old ids hack, has no usage
>
> test/jdk/java/util/Formatter/Basic-X.java.template line 1608:
> 
>> 1606:         // time zone ID. See JDK-8254865.
>> 1607:         final List<String> list =  new ArrayList<String>();
>> 1608:         Collections.addAll(list, ids);
> 
> I think
> 
> final List<String> list =  new ArrayList<>(Arrays.asList(ids));
> 
> is going to be faster than
> 
> final List<String> list =  new ArrayList<String>();
> Collections.addAll(list, ids);
> 
> Alternatively you can contruct presized ArrayList.

Thank you,

I will be removing this portion since it is outdated. But I will consider this and your other comment for future uses of List and ArrayList :-)

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

PR: https://git.openjdk.org/jdk/pull/10910

From duke at openjdk.org  Mon Oct 31 17:50:48 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 31 Oct 2022 17:50:48 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <3nb6Mh7G9rTwkyxe9aF4mZCS9td26kHx_XkwMpksl98=.12751398-6095-44a9-a24b-da877874338d@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
 <3nb6Mh7G9rTwkyxe9aF4mZCS9td26kHx_XkwMpksl98=.12751398-6095-44a9-a24b-da877874338d@github.com>
Message-ID: <CUYHVpNUV6_Pj2-QvmzCP19AINGTZ4Credxnmc2k138=.a22d3ced-a7ae-45c1-8783-06d61ee998b6@github.com>

On Fri, 28 Oct 2022 22:43:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove old ids hack, has no usage
>
> test/jdk/java/util/Formatter/Basic-X.java.template line 1612:
> 
>> 1610:         list.remove("America/WhiteHorse");
>> 1611:         list.remove("Canada/Yukon");
>> 1612:         ids = list.toArray(new String[list.size()]);
> 
> It's not your change but I just noticed this. Since we specifically test only for `CLDR` provider (as in `BasicTestLauncher`), I wonder we could remove this portion. Even if we do need this piece, it could be simplified as:
> 
> ids = Arrays.stream(ids).filter(tz -> !tz.equals(...)).toArray(String[]::new)

Removing portion since it is no longer used/needed. Tests passing without.

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

PR: https://git.openjdk.org/jdk/pull/10910

From naoto at openjdk.org  Mon Oct 31 18:01:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 31 Oct 2022 18:01:10 GMT
Subject: <i18n dev> Integrated: 8284842: Update Unicode Data Files to
 Version 15.0.0
In-Reply-To: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>
References: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>
Message-ID: <CuarPvKm5xRbyAkIjuqKbyz3aKVfANERl2SWeFUMMck=.9b197e06-9ee8-4361-9ac3-6e7eee64c756@github.com>

On Mon, 24 Oct 2022 18:50:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updates the JDK to use the latest Unicode 15, which also updates the ICU4J along with it (8284844: Update ICU4J to Version 72.1). The corresponding CSR has already been approved.

This pull request has now been integrated.

Changeset: 590de37b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/590de37bd703bdae56e8b41c84f5fca5e5a00811
Stats:     1125 lines in 29 files changed: 821 ins; 33 del; 271 mod

8284842: Update Unicode Data Files to Version 15.0.0
8284844: Update ICU4J to Version 72.1

Reviewed-by: joehw

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

PR: https://git.openjdk.org/jdk/pull/10839

From lancea at openjdk.org  Mon Oct 31 18:09:21 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 31 Oct 2022 18:09:21 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
 <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>
Message-ID: <6sOHsa7Xcm9Xos-1zkf6pWrUqZ_8cUFOqfwXBrF66Ec=.cb1f49ca-4af6-4ef9-a89e-76d30aff8620@github.com>

On Mon, 31 Oct 2022 17:50:47 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
>> 
>> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
>> 
>> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove old ids hack, has no usage

thank you for the clean up Justin.  I think this looks much better and more maintainable

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10910

From naoto at openjdk.org  Mon Oct 31 18:40:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 31 Oct 2022 18:40:10 GMT
Subject: <i18n dev> RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
 <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>
Message-ID: <Xw5SQ8vCJisA_RbS5BF6J01ra2XsdSu-R0bpwdjSTGI=.3c2f899c-6491-4f93-9f5a-27bee0138d6d@github.com>

On Mon, 31 Oct 2022 17:50:47 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
>> 
>> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
>> 
>> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove old ids hack, has no usage

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10910

From jlaskey at openjdk.org  Mon Oct 31 20:11:34 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 20:11:34 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add @SafeVarargs declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/75fcc49a..6d1d902e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=05-06

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Mon Oct 31 20:49:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 20:49:36 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <ZMO73T5DijZRuY1syZG_RLF5MAYKZP6ExGtpTxCeToo=.a9194cfa-96f0-4a5d-af04-040b692f4842@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 132:

> 130:             return result;
> 131:         }
> 132:         for (Object value : st.values()) {

I think that valueTypes() should return the types of the values not the dynamic classes of the values.
Here there is no type information so it should be Object for all values.

It has also the nice property that the return type of the accessors returned by valueAccessors are the same as valueTypes() which is i believe more coherent.

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

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Mon Oct 31 20:54:33 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 20:54:33 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 119:

> 117:         Class<?> tsClass = st.getClass();
> 118:         if (tsClass.isSynthetic()) {
> 119:             try {

I do not know if this code is worth of optimizing but the way to avoid to recompute the List<Class<?>> each time is to use a java.lang.ClassValue and store the classes inside an unmodifiable List. (Field[] -> Class<?>[] -> List<Class<?>>) The last leg can be done just by calling List.of(), there is no need for an ArrayList here

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

PR: https://git.openjdk.org/jdk/pull/10889

From smarks at openjdk.org  Mon Oct 31 21:25:41 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 31 Oct 2022 21:25:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 99:

> 97:     private static <E> List<E> toList(E... elements) {
> 98:         return JUCA.listFromTrustedArrayNullsAllowed(elements);
> 99:     }

I'm ok with using JUCA to create an unmodifiable list that can contain nulls.

However, it "trusts" the argument array, meaning that the array is assumed to be referenced exclusively and so the array reference is used directly in the resulting List object. That implies that one needs to be very careful about the array that gets passed in, otherwise, the resulting List might not actually be unmodifiable.

In particular, the call site in StringTemplate.of()

https://github.com/openjdk/jdk/pull/10889/files#diff-d4e02e5ead5ad4f2cfe509c58d1145f599285cd6736bbf37e4116045b2fd50bcR309

passes the array obtained from a List parameter that comes directly from a public call, meaning that malicious code could keep a reference to the array returned by `toArray` and modify it later. You could clone the array, or just revert back to the slow path.

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

PR: https://git.openjdk.org/jdk/pull/10889