From duke at openjdk.org  Tue Nov  1 00:06:35 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 1 Nov 2022 00:06:35 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@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>
 <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@github.com>
Message-ID: <QTuXZCQBCHnfr-n7W3F7K3vEr88fCuQVsvRcikoTbOM=.020347ed-48ee-4beb-97e6-60ab0f5f4da9@github.com>

On Fri, 28 Oct 2022 20:04:18 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> 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

If this is a public int field, it will be inlined to class file byte code at compile time, which may not be what you want if this value needs to change in the future. If this needs to be exposed, should it be as a public method?

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

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

From duke at openjdk.org  Tue Nov  1 00:25:35 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 1 Nov 2022 00:25:35 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: <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@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/runtime/TemplateSupport.java line 201:

> 199:     @SuppressWarnings("unchecked")
> 200:     public static <E> List<E> toList(E... elements) {
> 201:         return JUCA.listFromTrustedArrayNullsAllowed(elements);

Is this public method leaking access to the JUCA shared secrets method here?

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

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

From mcimadamore at openjdk.org  Tue Nov  1 11:04:52 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 11:04:52 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v2]
In-Reply-To: <NMJNYCbIc_ENhRzVNutxnKczkfNmxTs3dR6A1ExqFCA=.28e0b8ce-c7fd-466c-b523-ce79102ed487@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>
 <NMJNYCbIc_ENhRzVNutxnKczkfNmxTs3dR6A1ExqFCA=.28e0b8ce-c7fd-466c-b523-ce79102ed487@github.com>
Message-ID: <2vjNyFDHkuJn2pRmWoJcBcUBkAA9IXtpSgkELnAq6zo=.8d159c9e-6779-4ddf-9c9e-f96b7efcfaae@github.com>

On Fri, 28 Oct 2022 19:18:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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.

I'm looking at this line:

Type resultType = syms.stringTemplateType;

This assumes that the result type of this AST node will be StringTemplate. Now, if a processor is set, we'll call `chk.checkProcessorType` which *might* set a new expected type (e.g. a string processor type). But if any error is found in that routine (e.g. use of raw string processor), we just log an error, and return the same expected type that was passed in - so the expected type stays `StringTemplate`.

Something like this:

public class Processor<X> implements TemplateProcessor<X> { ... }


Processor raw = new Processor();
String s = raw."1234".

This will probably print a spurious error like "expected String, found StringTemplate".

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

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

From mcimadamore at openjdk.org  Tue Nov  1 11:04:53 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 11:04:53 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: <S6-VeYs6tNcuaIQrAhTtdeqKKYWLQrf6uePPW8FcVhs=.47ea1f24-2f75-4919-b506-fd37ab972c71@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/jdk.compiler/share/classes/com/sun/tools/javac/parser/Scanner.java line 100:

> 98:         private void ensureLookahead(int lookahead) {
> 99:             for (int i = savedTokens.size() ; i < lookahead ; i++) {
> 100:                 Token ahead = tokenizer.readToken();

curious - why this change?

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

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

From dfuchs at openjdk.org  Tue Nov  1 12:21:13 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 12:21:13 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: <A4qnEed0y9IwAfcxrUtVyXLkcuaHKUlwps8MVVFUAyw=.042a86fd-8c9c-498d-8172-606712c83849@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 to java (resp sun) .util.logging tests and javax.management tests look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

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

From mcimadamore at openjdk.org  Tue Nov  1 13:04:27 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 13:04:27 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: <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@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/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 230:

> 228: 
> 229:     class TransStringTemplate {
> 230:         JCStringTemplate tree;

Presumably some of these can be `final` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 429:

> 427:         }
> 428: 
> 429:         private JCClassDecl newStringTemplateClass() {

I find it weird to have the compiler emit an implementation of StringTemplate just to capture what is there in the code. If there are many usages of string templates, this could lead to a proliferation of synthetic classes. Perhaps we should consider using a metafactory here, like we do for lambdas, so that we can return some private JDK StringTemplate implementation type.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 555:

> 553:                 if (varSym.flags() == (PUBLIC | FINAL | STATIC) &&
> 554:                         varSym.name == names.str &&
> 555:                         types.isSameType(varSym.owner.type, syms.stringTemplateType)) {

Are you 100% sure that this test works? When we see a statically imported member in Resolve, which is referred to by unqualified name, we "clone" its symbol into the importing class. That is, Resolve will set STR symbol as a symbol whose owner is the class that did the importing, possibly defeating this check. See Resolve::findVar (near the end):


if (bestSoFar.kind == VAR && bestSoFar.owner.type != origin.type)
            return bestSoFar.clone(origin);

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

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

From mcimadamore at openjdk.org  Tue Nov  1 13:16:40 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 13:16:40 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: <BHNtvQ5p7s-mcwUoI07O90IT4jSs7tOcAsL2oZx1DfQ=.6bf3bf5d-59ea-4dc0-b0b1-98396a054304@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/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 355:

> 353:         // If first embedded expression.
> 354:         if (!isStringTemplate) {
> 355:             checkSourceLevel(pos, Feature.STRING_TEMPLATES);

If we check source level inside the `if`, we would only issue a preview error/warning once, which seems to be against JEP 12?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244:

> 242:      *     mode |= NOLAMBDA     : lambdas are not allowed
> 243:      */
> 244:     protected static final int EXPR          = 1 << 0;

I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244:

> 242:      *     mode |= NOLAMBDA     : lambdas are not allowed
> 243:      */
> 244:     protected static final int EXPR          = 1 << 0;

I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here (perhaps we should consider factoring it out?)

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

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

From alanb at openjdk.org  Tue Nov  1 14:44:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 14:44:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <bGVojc8FhYiLJbpzQl5TyXcYKzEurvx_Sf9Mc0R5IkA=.c35beb5c-11d4-4413-a766-82e7fd200bdf@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>
 <bGVojc8FhYiLJbpzQl5TyXcYKzEurvx_Sf9Mc0R5IkA=.c35beb5c-11d4-4413-a766-82e7fd200bdf@github.com>
Message-ID: <Q7d2xx2hXPx4tY0Urt542HpC_ELdT16sbXObSrHtiNs=.3519f63e-f70b-4a1f-ba98-feda371c3a8d@github.com>

On Mon, 31 Oct 2022 13:45:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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`.

The change to JUCA means the suppress warnings will need to be extended to @SuppressWarnings({"unchecked", "varargs"}).

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

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

From jlahoda at openjdk.org  Tue Nov  1 15:33:38 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 1 Nov 2022 15:33:38 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: <4jrJpr-CNMkKjBDlIVscDNqLmxyt7mh_Oz5cU8vfRWY=.e1310ec2-f363-4016-818c-5c869abb270e@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/util/FormatConcatItem.java line 51:

> 49:  */
> 50: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 51: public sealed interface FormatConcatItem

I wonder why is this a public API - is there some way to use it from the client code?

Note that in named modules, the permitted subtypes don't need to be in the same package, so if this is not needed in the API, it probably can be moved into a non-API package.

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

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

From naoto at openjdk.org  Tue Nov  1 15:52:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 1 Nov 2022 15:52:52 GMT
Subject: <i18n dev> RFR: 8296140: Drop unused field
 java.util.Calendar.DATE_MASK
In-Reply-To: <P7Lc7JlcC90i-4Chm5eEV2Kd7etfqQdY_5QLq_RHHME=.5f2d6083-b7f8-4065-9d2b-0ceb11c9e75a@github.com>
References: <P7Lc7JlcC90i-4Chm5eEV2Kd7etfqQdY_5QLq_RHHME=.5f2d6083-b7f8-4065-9d2b-0ceb11c9e75a@github.com>
Message-ID: <XZUkB5oppPAjcpFLbRK8HUoKW2W_mq046quTc13KiQU=.564c55e5-b82d-4fd9-a461-bb12823ad143@github.com>

On Thu, 27 Oct 2022 19:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no usages for this field. As it has the same value as `DAY_OF_MONTH_MASK` we can drop it.

Marked as reviewed by naoto (Reviewer).

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

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

From mcimadamore at openjdk.org  Tue Nov  1 17:48:49 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 17:48:49 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: <4bgm2-JFThFb9QUw8ysIbkh7V4HX65CC5mInOeLn-dY=.168bd4bd-772f-46a6-920e-4ed616ba714b@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/util/FormatProcessor.java line 118:

> 116: 
> 117:     // %[argument_index$][flags][width][.precision][t]conversion
> 118:     private static final String formatSpecifier

Should this be all upper case?

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

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

From jlaskey at openjdk.org  Tue Nov  1 18:24:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Nov 2022 18:24:38 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@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>
 <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com>
Message-ID: <qeVWx0O3Uodm8cqI9DsQR-T9W6wtRhf7yDXJg4vSR74=.074252d7-22fb-4a82-bf11-d110eafabfe4@github.com>

On Mon, 31 Oct 2022 15:51:23 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> 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.

Will add

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

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

From jlaskey at openjdk.org  Tue Nov  1 18:24:39 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Nov 2022 18:24:39 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@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>
 <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com>
Message-ID: <d48-KkrDKD1cg9YNiUQFYZD-r659x0GrP3BCMQTB1w0=.32059cf8-4c92-49aa-a53d-a404126f6698@github.com>

On Mon, 31 Oct 2022 13:43:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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`.

Moved to internal class.

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

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

From jlaskey at openjdk.org  Tue Nov  1 18:24:40 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Nov 2022 18:24:40 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>
Message-ID: <sJ_JQLbsGTLg3GpeMd6h205DuElxFynL29KdPIVZdxA=.8f9cfbd5-ca51-48c3-8319-c2e095ba2931@github.com>

On Mon, 31 Oct 2022 20:50:49 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:
>> 
>>   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

Will use List.of. I think use case is raw and caching should be left to the user.

> 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.

Changing

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

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

From jlaskey at openjdk.org  Tue Nov  1 19:09:41 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Nov 2022 19:09:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>
Message-ID: <Dl3GU7GWMu6NP7rbyVcf40jToUYgB0k0i7lw9WuNR2Q=.ac7cc25b-96dd-4868-b991-132cf4b07cad@github.com>

On Mon, 31 Oct 2022 21:23:19 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> 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.

Changing caller

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

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

From ysatowse at openjdk.org  Wed Nov  2 04:21:24 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Wed, 2 Nov 2022 04:21:24 GMT
Subject: <i18n dev> RFR: 8296108: (tz) Update Timezone Data to 2022f
Message-ID: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>

Please review this PR.  The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga.

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

Commit messages:
 - 1st commit for tz2022f

Changes: https://git.openjdk.org/jdk/pull/10940/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10940&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296108
  Stats: 1362 lines in 25 files changed: 560 ins; 705 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/10940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10940/head:pull/10940

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

From ysatowse at openjdk.org  Wed Nov  2 04:21:24 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Wed, 2 Nov 2022 04:21:24 GMT
Subject: <i18n dev> RFR: 8296108: (tz) Update Timezone Data to 2022f
In-Reply-To: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>
References: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>
Message-ID: <_bDpWidUSH1vqv92HDarj8r4zkckxRJ9Q9oXghWQpNA=.66ae220a-e8cd-437a-a716-c76f5fd9b0c2@github.com>

On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga.

@naotoj Can I ask you to review the PR?

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

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

From serb at openjdk.org  Wed Nov  2 05:20:22 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 2 Nov 2022 05:20:22 GMT
Subject: <i18n dev> RFR: 8296108: (tz) Update Timezone Data to 2022f
In-Reply-To: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>
References: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>
Message-ID: <atiApbW672r3RIE2ip1MfsA9fsK8Zx6ygtElsn4obfk=.fd426a19-1e2d-4a81-a255-0ede891f608f@github.com>

On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga.

Looks fine

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

Marked as reviewed by serb (Reviewer).

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

From naoto at openjdk.org  Wed Nov  2 16:30:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Nov 2022 16:30:21 GMT
Subject: <i18n dev> RFR: 8296108: (tz) Update Timezone Data to 2022f
In-Reply-To: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>
References: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>
Message-ID: <J5C-CIl9rnRlvYlXUogCCuSTe1J--Xak3_mvzPiDB8c=.bd831932-ea00-44e2-8df0-601273620a85@github.com>

On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga.

LGTM

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

Marked as reviewed by naoto (Reviewer).

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

From duke at openjdk.org  Wed Nov  2 17:35:32 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 2 Nov 2022 17:35:32 GMT
Subject: <i18n dev> Integrated: 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: <V7-T3m5ieovbHW7A1B0St__b_7Yf2kLbtDnJ7Y2_A4A=.77dc0c62-87f8-4781-91f5-01146e078915@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

This pull request has now been integrated.

Changeset: f84b0ad0
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f84b0ad07c73c305d21c71ec6b8195dc1ee31a3e
Stats:     29646 lines in 22 files changed: 1511 ins; 27888 del; 247 mod

8295670: Remove duplication in java/util/Formatter/Basic*.java

Reviewed-by: bchristi, lancea, naoto

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

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

From jlaskey at openjdk.org  Wed Nov  2 17:49:58 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 17:49:58 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v8]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <DQKRI5LPtJFup-QUyd8qsd53bUJ60ZO8bTv26naMfGc=.667a52e7-4e5d-4fe7-8d11-29e5d295f7b5@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 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 22 additional commits since the last revision:

 - Merge branch 'master' into 8285932
 - Add @SafeVarargs declarations
 - Move template bootstrap
 - Requested changes #2
 - Requested changes
 - Remove .orig file
 - Update TemplateRuntime::combine
 - Move StringConcatItem to FormatConcatItem
 - Tabs to spaces
 - Force processor before template string expression
 - ... and 12 more: https://git.openjdk.org/jdk/compare/9bfd9379...6cea084b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/6d1d902e..6cea084b

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

  Stats: 145345 lines in 1262 files changed: 82705 ins; 31717 del; 30923 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  Wed Nov  2 17:50:00 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 2 Nov 2022 17:50:00 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <sJ_JQLbsGTLg3GpeMd6h205DuElxFynL29KdPIVZdxA=.8f9cfbd5-ca51-48c3-8319-c2e095ba2931@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>
 <sJ_JQLbsGTLg3GpeMd6h205DuElxFynL29KdPIVZdxA=.8f9cfbd5-ca51-48c3-8319-c2e095ba2931@github.com>
Message-ID: <W-RWTASOeh-drU1Xwwb6_TmJugIOxxpcRwrMm8945Uw=.2e29d570-95b9-4f0d-81ba-f3828ea2c458@github.com>

On Tue, 1 Nov 2022 18:22:07 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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
>
> Will use List.of. I think use case is raw and caching should be left to the user.

i agree

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

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

From jlaskey at openjdk.org  Wed Nov  2 17:56:14 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 17:56:14 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v9]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <JK6PQDjQapfwG8TpQil9rp-UcDTz3lWjZlL-ShX4nMg=.f1a2e6ca-c5b3-4427-9f9e-cc12f7c30ea9@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:

  Requested changes #3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/6cea084b..c81d0d20

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

  Stats: 104 lines in 7 files changed: 85 ins; 2 del; 17 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  Wed Nov  2 18:05:15 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 18:05:15 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@github.com>
Message-ID: <GcvzlZN91T5wJfS2VAk_OgHXqxg4Uh87N828bsiIWGo=.366d347f-d401-4a9b-b34d-ba089f2e9b51@github.com>

On Tue, 1 Nov 2022 12:41:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @SafeVarargs declarations
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 230:
> 
>> 228: 
>> 229:     class TransStringTemplate {
>> 230:         JCStringTemplate tree;
> 
> Presumably some of these can be `final` ?

Changing

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

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

From jlaskey at openjdk.org  Wed Nov  2 18:05:16 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 18:05:16 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <S6-VeYs6tNcuaIQrAhTtdeqKKYWLQrf6uePPW8FcVhs=.47ea1f24-2f75-4919-b506-fd37ab972c71@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <S6-VeYs6tNcuaIQrAhTtdeqKKYWLQrf6uePPW8FcVhs=.47ea1f24-2f75-4919-b506-fd37ab972c71@github.com>
Message-ID: <Q9cmrYpUQSF_rGx0dZzLeLt0cgQesQaOC_O3GItZvUs=.9e2fb3e1-c7e6-4fb8-a6b3-fafb7e70a046@github.com>

On Fri, 28 Oct 2022 18:47:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Scanner.java line 100:
> 
>> 98:         private void ensureLookahead(int lookahead) {
>> 99:             for (int i = savedTokens.size() ; i < lookahead ; i++) {
>> 100:                 Token ahead = tokenizer.readToken();
> 
> curious - why this change?

Residue from lookahead experiments. Will revert.

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

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

From jlaskey at openjdk.org  Wed Nov  2 18:20:39 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 18:20:39 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@github.com>
Message-ID: <rWLXrM3gxV_w1jvwfSF8y4KVYzZfAn8wRsBAlXgywfc=.7314726d-4bea-4c40-b5cd-2419017d77f0@github.com>

On Tue, 1 Nov 2022 12:50:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @SafeVarargs declarations
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 555:
> 
>> 553:                 if (varSym.flags() == (PUBLIC | FINAL | STATIC) &&
>> 554:                         varSym.name == names.str &&
>> 555:                         types.isSameType(varSym.owner.type, syms.stringTemplateType)) {
> 
> Are you 100% sure that this test works? When we see a statically imported member in Resolve, which is referred to by unqualified name, we "clone" its symbol into the importing class. That is, Resolve will set STR symbol as a symbol whose owner is the class that did the importing, possibly defeating this check. See Resolve::findVar (near the end):
> 
> 
> if (bestSoFar.kind == VAR && bestSoFar.owner.type != origin.type)
>             return bestSoFar.clone(origin);

Absolutely certain.

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

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

From jlaskey at openjdk.org  Wed Nov  2 18:31:14 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 18:31:14 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@github.com>
Message-ID: <TQNoVcZ8RC9oaqVUzp9_xKqjJHCd4iYWPYYaFc0gc00=.8d53d264-9dbb-4bd6-a0d1-d499823b4ae9@github.com>

On Tue, 1 Nov 2022 12:57:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @SafeVarargs declarations
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 429:
> 
>> 427:         }
>> 428: 
>> 429:         private JCClassDecl newStringTemplateClass() {
> 
> I find it weird to have the compiler emit an implementation of StringTemplate just to capture what is there in the code. If there are many usages of string templates, this could lead to a proliferation of synthetic classes. Perhaps we should consider using a metafactory here, like we do for lambdas, so that we can return some private JDK StringTemplate implementation type.

The main consideration is performance. I spent quite a bit of time playing around with different implementations including metafactories (hence the carrier class work.) Since a majority of use cases will be STR and FMT, the number of classes will likely be just a few per application. Because of the change to force processor always, I will be revisiting this during the preview period to work on other solutions (I mentioned ProcessorFactories/ProcessorBuilders earlier).

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244:
> 
>> 242:      *     mode |= NOLAMBDA     : lambdas are not allowed
>> 243:      */
>> 244:     protected static final int EXPR          = 1 << 0;
> 
> I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here (perhaps we should consider factoring it out?)

I agree. I haven't updated uses by others, so it would be good to coordinate.

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

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

From jlaskey at openjdk.org  Wed Nov  2 18:55:41 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 18:55:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <4bgm2-JFThFb9QUw8ysIbkh7V4HX65CC5mInOeLn-dY=.168bd4bd-772f-46a6-920e-4ed616ba714b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <4bgm2-JFThFb9QUw8ysIbkh7V4HX65CC5mInOeLn-dY=.168bd4bd-772f-46a6-920e-4ed616ba714b@github.com>
Message-ID: <mc7s28hF6S4UONp7VkN99XFZR97IKQjw6Z9a1Dn_QBo=.67b48095-ab0c-4bef-babc-814069a40aeb@github.com>

On Tue, 1 Nov 2022 17:33:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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/util/FormatProcessor.java line 118:
> 
>> 116: 
>> 117:     // %[argument_index$][flags][width][.precision][t]conversion
>> 118:     private static final String formatSpecifier
> 
> Should this be all upper case?

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 355:
> 
>> 353:         // If first embedded expression.
>> 354:         if (!isStringTemplate) {
>> 355:             checkSourceLevel(pos, Feature.STRING_TEMPLATES);
> 
> If we check source level inside the `if`, we would only issue a preview error/warning once, which seems to be against JEP 12?

The error is collated to the opening quote so one is sufficient. Embedded Expressions are not the feature. String templates is. The parser bails at that point.


>> cat Main.java
public class Main {
    public static void main(String... args) {
        int x = 10, y = 20;
        String s = STR."Adding {x} and {y} equals {x + y}";
        String t = STR."Adding {x} and {y} equals {x + y}";
    }
}
>> javac Main.java
Main.java:4: error: string templates are a preview feature and are disabled by default.
        String s = STR."Adding {x} and {y} equals {x + y}";
                       ^
  (use --enable-preview to enable string templates)
1 error

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

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

From forax at openjdk.org  Wed Nov  2 18:55:42 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 2 Nov 2022 18:55:42 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <TQNoVcZ8RC9oaqVUzp9_xKqjJHCd4iYWPYYaFc0gc00=.8d53d264-9dbb-4bd6-a0d1-d499823b4ae9@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@github.com>
 <TQNoVcZ8RC9oaqVUzp9_xKqjJHCd4iYWPYYaFc0gc00=.8d53d264-9dbb-4bd6-a0d1-d499823b4ae9@github.com>
Message-ID: <5oL6PHLa3_EJIOUaFfBkw2B6pbnoLhmDIasHPWYppfA=.6ab741a9-f0df-4076-a9b2-f82c10a45b9a@github.com>

On Wed, 2 Nov 2022 18:27:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 429:
>> 
>>> 427:         }
>>> 428: 
>>> 429:         private JCClassDecl newStringTemplateClass() {
>> 
>> I find it weird to have the compiler emit an implementation of StringTemplate just to capture what is there in the code. If there are many usages of string templates, this could lead to a proliferation of synthetic classes. Perhaps we should consider using a metafactory here, like we do for lambdas, so that we can return some private JDK StringTemplate implementation type.
>
> The main consideration is performance. I spent quite a bit of time playing around with different implementations including metafactories (hence the carrier class work.) Since a majority of use cases will be STR and FMT, the number of classes will likely be just a few per application. Because of the change to force processor always, I will be revisiting this during the preview period to work on other solutions (I mentioned ProcessorFactories/ProcessorBuilders earlier).

@JimLaskey, someone will implement a LOG at some point in the future and you will get many template classes per application class.
You mention the carrier but i believe you can implement something similar to a carrier erasing the type of the values but without using method handles to try to make it type safe and instead pass the real types as a class data of a hidden class and later as a type argument once the reified generics will be released.

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

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

From jlaskey at openjdk.org  Wed Nov  2 19:14:56 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 19:14:56 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v10]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <eIT3Un6bBxFvlAxauR8G0Zz4Bead1Luu9jL1QC903Co=.745d91e4-d32b-480b-a930-d9de087c4b16@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:

  Requested changes #4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/c81d0d20..7610dd0c

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

  Stats: 18 lines in 4 files changed: 0 ins; 12 del; 6 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 jvernee at openjdk.org  Wed Nov  2 19:24:40 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 19:24:40 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: <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@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/runtime/TemplateSupport.java line 74:

> 72: 
> 73:     /**
> 74:      * Static final processor.

Suggestion:

     * final processor.

src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 141:

> 139:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
> 140:         ValidatingProcessor<?, ?> processor =
> 141:                 (ValidatingProcessor<?, ?>)processorGetter.asType(processorGetterType).invokeExact();

Essentially the same as:
Suggestion:

        ValidatingProcessor<?, ?> processor = (ValidatingProcessor<?, ?>)processorGetter.invoke();

src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 184:

> 182:         MethodHandle mh = MethodHandles.insertArguments(DEFAULT_PROCESS_MH, 0, fragments, processor);
> 183:         mh = mh.withVarargs(true);
> 184:         mh = mh.asType(type);

I suggest doing:
Suggestion:

        mh = mh.asCollector(Object[].class, type.parameterCount());
        mh = mh.asType(type);

Instead, as it is more straightforward in terms of the code that gets called. (the impl of `withVarargs` + `asType` does the same thing in a more roundabout way).

src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 60:

> 58:      * @throws NullPointerException if any of the arguments are null
> 59:      */
> 60:     MethodHandle linkage(List<String> fragments, MethodType type);

I suggest changing the protocol here to be able to take all bootstrap arguments into account, and return a `CallSite` instead. That will allow a `ProcessorLinkage` to take the lookup and name into account as well, and allows returning e.g. a `MutableCallSite` as well.

Maybe this can still be changed later as well though, since the interface is sealed.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 103:

> 101:  * // check or manipulate the fragments and/or values
> 102:  * ...
> 103:  * String result = StringTemplate.interpolate(fragments, values);;

Suggestion:

 * String result = StringTemplate.interpolate(fragments, values);

src/java.base/share/classes/java/lang/template/StringTemplate.java line 117:

> 115:  */
> 116: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 117: public interface StringTemplate {

What is the reason for having this open to extension? Rather than just being a final class or sealed interface?

(I think it is so that implementations can provide a more efficient layout rather than using Lists?)

src/java.base/share/classes/java/lang/template/StringTemplate.java line 246:

> 244:         Objects.requireNonNull(stringTemplate, "stringTemplate should not be null");
> 245:         return Objects.hashCode(stringTemplate.fragments()) ^
> 246:                Objects.hashCode(stringTemplate.values());

Could also (which is also `null` safe):
Suggestion:

        return Objects.hash(stringTemplate.fragments(), stringTemplate.values());

src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 149:

> 147: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 148: @FunctionalInterface
> 149: public interface ValidatingProcessor<R, E extends Throwable> {

I suggest moving the doc that gives an overview of the API here to the `package-info` file. The package-info file is a better place to provide an overview of the API I think. (that's what we do for `java.lang.foreign` as well: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/foreign/package-summary.html)

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

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

From jvernee at openjdk.org  Wed Nov  2 19:24:41 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 19:24:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com>
Message-ID: <lk6Ohi1WaylwI8W10VHv1TPRN2hXn5RST6g_oY2R_hA=.98de2cea-f2f2-4515-8e49-8c5bf29be04b@github.com>

On Tue, 1 Nov 2022 00:09:21 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> 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/runtime/TemplateSupport.java line 201:
> 
>> 199:     @SuppressWarnings("unchecked")
>> 200:     public static <E> List<E> toList(E... elements) {
>> 201:         return JUCA.listFromTrustedArrayNullsAllowed(elements);
> 
> Is this public method leaking access to the JUCA shared secrets method here?

Yes, this is leaking access. I suppose this is public because it is called from `javac` generated code. But, from the perspective of the runtime, code generated by `javac` is the same as any other arbitrary non-trusted bytecode.

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

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

From jvernee at openjdk.org  Wed Nov  2 19:24:41 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 19:24:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@github.com>
Message-ID: <IPGJPhIdyO-rPDfRabanjsN0kzilm80wvCQx8Dz2kZQ=.5af43ffb-1aa9-4cee-bb13-ca79f93957a5@github.com>

On Wed, 2 Nov 2022 17:21:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 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/runtime/TemplateSupport.java line 184:
> 
>> 182:         MethodHandle mh = MethodHandles.insertArguments(DEFAULT_PROCESS_MH, 0, fragments, processor);
>> 183:         mh = mh.withVarargs(true);
>> 184:         mh = mh.asType(type);
> 
> I suggest doing:
> Suggestion:
> 
>         mh = mh.asCollector(Object[].class, type.parameterCount());
>         mh = mh.asType(type);
> 
> Instead, as it is more straightforward in terms of the code that gets called. (the impl of `withVarargs` + `asType` does the same thing in a more roundabout way).

As a side note: I think we can add an overload to `asCollector` that takes a `MethodType`, and does the 2 lines above in one. (the array type would be the return type of the method type).

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

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

From jvernee at openjdk.org  Wed Nov  2 19:24:50 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 19:24:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v8]
In-Reply-To: <DQKRI5LPtJFup-QUyd8qsd53bUJ60ZO8bTv26naMfGc=.667a52e7-4e5d-4fe7-8d11-29e5d295f7b5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <DQKRI5LPtJFup-QUyd8qsd53bUJ60ZO8bTv26naMfGc=.667a52e7-4e5d-4fe7-8d11-29e5d295f7b5@github.com>
Message-ID: <pqVUBB9fllsFQKJj4q8gZM_E2_y8RS4g_3nlOyGWxbM=.2b46ea0e-a627-456a-8cad-00f0da0cabbc@github.com>

On Wed, 2 Nov 2022 17:49:58 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 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 22 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8285932
>  - Add @SafeVarargs declarations
>  - Move template bootstrap
>  - Requested changes #2
>  - Requested changes
>  - Remove .orig file
>  - Update TemplateRuntime::combine
>  - Move StringConcatItem to FormatConcatItem
>  - Tabs to spaces
>  - Force processor before template string expression
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/7a2dcaba...6cea084b

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 118:

> 116:         List<Class<?>> result = new ArrayList<>();
> 117:         Class<?> tsClass = st.getClass();
> 118:         if (tsClass.isSynthetic()) {

This check seems pretty ad-hoc... What happens if a synthetic class is passed that declares some `x0` field that doesn't correspond to the type of the value? i.e. someone could generating an implementation of `StringTemplate`, slap `ACC_SYNTHETIC` on it, and it seems that could have the potential to break this code.

I suggest generating an override of `valueTypes` in the synthetic class emitted by javac instead.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 160:

> 158:                 for (int i = 0; ; i++) {
> 159:                     Field field = tsClass.getDeclaredField("x" + i);
> 160:                     MethodHandle mh = JLIA.unreflectField(field, false);

This by-passes any access checks by using `IMPL_LOOKUP`.

This seems problematic. e.g. there's a class that has some `x0` field that I can't access, but the class is not `final`. I generate an impl of `StringTemplate` that extends that class (with `ACC_SYNTHETIC`), and call `valueAccessors` to get a getter that bypasses all access checks.

I think the synthetic class generated by javac should generate an override of this method as well.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 175:

> 173:             int size = st.values().size();
> 174:             for (int index = 0; index < size; index++) {
> 175:                 result.add(MethodHandles.insertArguments(GET_VALUE_MH, 0, index));

The returned method handle takes a `StringTemplate` as an argument, but doesn't guard against the fact that a different string template instance can be passed than the one used here, which can lead to errors when invoking the method handle (e.g. out of bounds access, or cast failures when the value types are different).

I was gonna suggest using `List::get` as a method handle instead, and then binding the `values()` list and the index to that. That would drop the `StringTemplate` param, which I suppose is important for `javac` generated code? Could add a `dropArguments` for that, but then the argument would always be ignored.

Maybe alternatively, the `getValue` method could do a check that the `StringTemplate` instance passed to it is the same instance as the one used here.

I don't know...

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

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

From jlaskey at openjdk.org  Wed Nov  2 19:44:00 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Nov 2022 19:44:00 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@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:

  Internalize TemplateSupport

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/7610dd0c..2cf00caa

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

  Stats: 4 lines in 3 files 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 jvernee at openjdk.org  Wed Nov  2 20:13:22 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 20:13:22 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
Message-ID: <bhxIO_P85-ulO9bhuGS4mdOnZAlH8L-LCVZ9E-fzLfc=.17f8f48a-8fbc-420a-8310-4c1662db40b5@github.com>

On Wed, 2 Nov 2022 19:44:00 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:
> 
>   Internalize TemplateSupport

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1103:

> 1101:         }
> 1102: 
> 1103:         MethodHandle mh = MethodHandles.dropArguments(newString(), 2, ttypes);

The code here us pretty dense. I suggest adding comments that show the type of `mh` as far as it is known. I think it makes it a much easier to keep track of what all the argument indexes mean. e.g.
Suggestion:

        // (byte[],long,ttypes...) -> String
        MethodHandle mh = MethodHandles.dropArguments(newString(), 2, ttypes);

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1118:

> 1116:             MethodHandle prepender = prepender(lastFragment.isEmpty() ? null : fragment, ttype);
> 1117:             initialLengthCoder = JLA.stringConcatMix(initialLengthCoder, fragment);
> 1118:             mh = MethodHandles.filterArgumentsWithCombiner(mh, 1, prepender,1, 0, 2 + pos);

Suggestion:

            Class<?> ttype = ttypes[pos];
            // (long,byte[],ttype) -> String
            MethodHandle prepender = prepender(lastFragment.isEmpty() ? null : fragment, ttype);
            initialLengthCoder = JLA.stringConcatMix(initialLengthCoder, fragment);
            // (byte[],long,ttypes...) -> String (unchanged)
            mh = MethodHandles.filterArgumentsWithCombiner(mh, 1, prepender,1, 0, 2 + pos);

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1125:

> 1123:         MethodHandle newArrayCombinator = lastFragment.isEmpty() ? newArray() :
> 1124:                 newArrayWithSuffix(lastFragment);
> 1125:         mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, newArrayCombinator,

Suggestion:

        // (long,ttypes...) -> String
        mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, newArrayCombinator,

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1143:

> 1141:                         0, // old-index
> 1142:                         1 + pos // selected argument
> 1143:                 );

Suggestion:

            // (long,ttype) -> long
            MethodHandle mix = mixer(ttypes[pos]);
            boolean lastPType = pos == ttypes.length - 1;

            if (lastPType) {
                // (ttype) -> long
                mix = MethodHandles.insertArguments(mix, 0, initialLengthCoder);
                // (ttypes...) -> String
                mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, mix,
                        1 + pos // selected argument
                );
            } else {
                // (long,ttypes...) -> String
                mh = MethodHandles.filterArgumentsWithCombiner(mh, 0, mix,
                        0, // old-index
                        1 + pos // selected argument
                );

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

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

From jvernee at openjdk.org  Wed Nov  2 21:34:45 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 21:34:45 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
Message-ID: <O2CCxscV2PbPqbhjE79-7jRx1C5XUle7niPjr3hSBj8=.394fa7d0-258e-4d29-9042-ac6869cec8ef@github.com>

On Wed, 2 Nov 2022 19:44:00 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:
> 
>   Internalize TemplateSupport

src/java.base/share/classes/jdk/internal/template/TemplateSupport.java line 147:

> 145: 
> 146:         return support.processWithProcessor();
> 147:     }

Thinking about this protocol some more: this seems to depend on the processor being a constant, which precludes specialized linking of call sites where the processor is a dynamic argument.

The returned method handle/call site could maybe be changed to take the processor instance as a leading argument instead. The processor can then be used to pass additional arguments to the processing code (like the DB example in the JEP). (and, AFAICS, that will also allow using calls to this BSM as the sole translation strategy for every type of processor, which seems more robust if types are changed later on to (un-)implement `ProcessorLinkage`)

The `linkage` method could instead be a `static` method, which is somehow tied to the type of the processor. Since it's currently a sealed interface you could have a mapping from each implementer to the `linkage` method for the types you care about (only `FormatProcessor` atm). If that is to be opened up to public extension in the future, something like type classes would be needed I think, so that the runtime can reliably map from the processor type to the static `linkage` method.

WDYT?

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

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

From duke at openjdk.org  Wed Nov  2 21:42:42 2022
From: duke at openjdk.org (Sam Pullara)
Date: Wed, 2 Nov 2022 21:42:42 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com>
Message-ID: <umwOCdIYC9lD_XYnOrbCxLorQtjpk9XvWErfs_RAcLU=.2201c963-3f91-4de8-9f71-76398551f9d4@github.com>

On Tue, 1 Nov 2022 00:09:21 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> 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/runtime/TemplateSupport.java line 201:
> 
>> 199:     @SuppressWarnings("unchecked")
>> 200:     public static <E> List<E> toList(E... elements) {
>> 201:         return JUCA.listFromTrustedArrayNullsAllowed(elements);
> 
> Is this public method leaking access to the JUCA shared secrets method here?

It is also a duplicate of a private method in TemplateRuntime

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

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

From jvernee at openjdk.org  Wed Nov  2 21:55:40 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 21:55:40 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <O2CCxscV2PbPqbhjE79-7jRx1C5XUle7niPjr3hSBj8=.394fa7d0-258e-4d29-9042-ac6869cec8ef@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
 <O2CCxscV2PbPqbhjE79-7jRx1C5XUle7niPjr3hSBj8=.394fa7d0-258e-4d29-9042-ac6869cec8ef@github.com>
Message-ID: <PhqE1GjWxkH1i8Fmwinn81tHLhUGRGokSFaT5rHy1Hw=.f32c2be7-9d0a-4768-b73a-ff7a7134a53c@github.com>

On Wed, 2 Nov 2022 21:30:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internalize TemplateSupport
>
> src/java.base/share/classes/jdk/internal/template/TemplateSupport.java line 147:
> 
>> 145: 
>> 146:         return support.processWithProcessor();
>> 147:     }
> 
> Thinking about this protocol some more: this seems to depend on the processor being a constant, which precludes specialized linking of call sites where the processor is a dynamic argument.
> 
> The returned method handle/call site could maybe be changed to take the processor instance as a leading argument instead. The processor can then be used to pass additional arguments to the processing code (like the DB example in the JEP). (and, AFAICS, that will also allow using calls to this BSM as the sole translation strategy for every type of processor, which seems more robust if types are changed later on to (un-)implement `ProcessorLinkage`)
> 
> The `linkage` method could instead be a `static` method, which is somehow tied to the type of the processor. Since it's currently a sealed interface you could have a mapping from each implementer to the `linkage` method for the types you care about (only `FormatProcessor` atm). If that is to be opened up to public extension in the future, something like type classes would be needed I think, so that the runtime can reliably map from the processor type to the static `linkage` method.
> 
> WDYT?

(FWIW, I don't see this as prohibitive for this PR to go ahead, but maybe something to consider before finalizing the feature)

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

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

From vlivanov at openjdk.org  Wed Nov  2 22:54:53 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 2 Nov 2022 22:54:53 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
Message-ID: <yRjL1eC-e_VHdFAu86LhU6qhKPXCr5ZG-l3qcwKnnvI=.3ff1906b-1215-42cf-b1a9-b311e14a661d@github.com>

On Wed, 2 Nov 2022 19:44:00 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:
> 
>   Internalize TemplateSupport

src/java.base/share/classes/java/lang/StringConcatHelper.java line 359:

> 357:      * @since 19
> 358:      */
> 359:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)

Just a passerby question: what's the point in marking non-public methods with `@PreviewFeature`?

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

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

From jlaskey at openjdk.org  Thu Nov  3 14:27:50 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 14:27:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@github.com>
Message-ID: <WjDiVtRyJJxHaS-9-2CNCKdZ8Ev2w-PWWOcGD3JzqTM=.c1f652d1-ae0f-476b-b24c-10f50ee1369f@github.com>

On Wed, 2 Nov 2022 17:04:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 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/runtime/TemplateSupport.java line 74:
> 
>> 72: 
>> 73:     /**
>> 74:      * Static final processor.
> 
> Suggestion:
> 
>      * final processor.

"The static final processor that triggered the BSM generation." - Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 103:
> 
>> 101:  * // check or manipulate the fragments and/or values
>> 102:  * ...
>> 103:  * String result = StringTemplate.interpolate(fragments, values);;
> 
> Suggestion:
> 
>  * String result = StringTemplate.interpolate(fragments, values);

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 117:
> 
>> 115:  */
>> 116: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 117: public interface StringTemplate {
> 
> What is the reason for having this open to extension? Rather than just being a final class or sealed interface?
> 
> (I think it is so that implementations can provide a more efficient layout rather than using Lists?)

Generally yes, specializations of the template. Another possibility is other languages can map their template implementations.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 246:
> 
>> 244:         Objects.requireNonNull(stringTemplate, "stringTemplate should not be null");
>> 245:         return Objects.hashCode(stringTemplate.fragments()) ^
>> 246:                Objects.hashCode(stringTemplate.values());
> 
> Could also (which is also `null` safe):
> Suggestion:
> 
>         return Objects.hash(stringTemplate.fragments(), stringTemplate.values());

Changing

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

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

From jlaskey at openjdk.org  Thu Nov  3 14:46:46 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 14:46:46 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@github.com>
Message-ID: <8Z6JILAAjo3h5wRJrgtjKq_g1r3d6av5pPSNPlaAtb0=.32268df7-ecfb-4549-999a-d3a2783389ef@github.com>

On Wed, 2 Nov 2022 17:06:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 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/runtime/TemplateSupport.java line 141:
> 
>> 139:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
>> 140:         ValidatingProcessor<?, ?> processor =
>> 141:                 (ValidatingProcessor<?, ?>)processorGetter.asType(processorGetterType).invokeExact();
> 
> Essentially the same as:
> Suggestion:
> 
>         ValidatingProcessor<?, ?> processor = (ValidatingProcessor<?, ?>)processorGetter.invoke();

Changing

> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 60:
> 
>> 58:      * @throws NullPointerException if any of the arguments are null
>> 59:      */
>> 60:     MethodHandle linkage(List<String> fragments, MethodType type);
> 
> I suggest changing the protocol here to be able to take all bootstrap arguments into account, and return a `CallSite` instead. That will allow a `ProcessorLinkage` to take the lookup and name into account as well, and allows returning e.g. a `MutableCallSite` as well.
> 
> Maybe this can still be changed later as well though, since the interface is sealed.

Yes - this will all go away during preview.

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

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

From jlaskey at openjdk.org  Thu Nov  3 14:46:47 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 14:46:47 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <IPGJPhIdyO-rPDfRabanjsN0kzilm80wvCQx8Dz2kZQ=.5af43ffb-1aa9-4cee-bb13-ca79f93957a5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@github.com>
 <IPGJPhIdyO-rPDfRabanjsN0kzilm80wvCQx8Dz2kZQ=.5af43ffb-1aa9-4cee-bb13-ca79f93957a5@github.com>
Message-ID: <YrQBVfG52pI4wHa8KWibnngb9g0PfdcpT9q8YCCZI88=.f6920d00-3df9-45fe-a343-dfeafd5f2a35@github.com>

On Wed, 2 Nov 2022 17:23:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 184:
>> 
>>> 182:         MethodHandle mh = MethodHandles.insertArguments(DEFAULT_PROCESS_MH, 0, fragments, processor);
>>> 183:         mh = mh.withVarargs(true);
>>> 184:         mh = mh.asType(type);
>> 
>> I suggest doing:
>> Suggestion:
>> 
>>         mh = mh.asCollector(Object[].class, type.parameterCount());
>>         mh = mh.asType(type);
>> 
>> Instead, as it is more straightforward in terms of the code that gets called. (the impl of `withVarargs` + `asType` does the same thing in a more roundabout way).
>
> As a side note: I think we can add an overload to `asCollector` that takes a `MethodType`, and does the 2 lines above in one. (the array type would be the return type of the method type).

Changing

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

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

From jlaskey at openjdk.org  Thu Nov  3 14:46:56 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 14:46:56 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v8]
In-Reply-To: <pqVUBB9fllsFQKJj4q8gZM_E2_y8RS4g_3nlOyGWxbM=.2b46ea0e-a627-456a-8cad-00f0da0cabbc@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <DQKRI5LPtJFup-QUyd8qsd53bUJ60ZO8bTv26naMfGc=.667a52e7-4e5d-4fe7-8d11-29e5d295f7b5@github.com>
 <pqVUBB9fllsFQKJj4q8gZM_E2_y8RS4g_3nlOyGWxbM=.2b46ea0e-a627-456a-8cad-00f0da0cabbc@github.com>
Message-ID: <QnOCxMHYxzrpQyTEyJKuCJInM3qnmWy6AQzT8uwq4nI=.4644343d-db4f-4d58-b36a-58c465943d4e@github.com>

On Wed, 2 Nov 2022 17:53:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jim Laskey 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 22 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Add @SafeVarargs declarations
>>  - Move template bootstrap
>>  - Requested changes #2
>>  - Requested changes
>>  - Remove .orig file
>>  - Update TemplateRuntime::combine
>>  - Move StringConcatItem to FormatConcatItem
>>  - Tabs to spaces
>>  - Force processor before template string expression
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ab757cc6...6cea084b
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 118:
> 
>> 116:         List<Class<?>> result = new ArrayList<>();
>> 117:         Class<?> tsClass = st.getClass();
>> 118:         if (tsClass.isSynthetic()) {
> 
> This check seems pretty ad-hoc... What happens if a synthetic class is passed that declares some `x0` field that doesn't correspond to the type of the value? i.e. someone could generating an implementation of `StringTemplate`, slap `ACC_SYNTHETIC` on it, and it seems that could have the potential to break this code.
> 
> I suggest generating an override of `valueTypes` in the synthetic class emitted by javac instead.

I've mentioned TemplateProcessorFactorys and TemplateProcessorBuilders as the long term solution. I think I'll just pull these methods. Optimizing processors is something that needs more discussion.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 160:
> 
>> 158:                 for (int i = 0; ; i++) {
>> 159:                     Field field = tsClass.getDeclaredField("x" + i);
>> 160:                     MethodHandle mh = JLIA.unreflectField(field, false);
> 
> This by-passes any access checks by using `IMPL_LOOKUP`.
> 
> This seems problematic. e.g. there's a class that has some `x0` field that I can't access, but the class is not `final`. I generate an impl of `StringTemplate` that extends that class (with `ACC_SYNTHETIC`), and call `valueAccessors` to get a getter that bypasses all access checks.
> 
> I think the synthetic class generated by javac should generate an override of this method as well.

See previous.

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

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

From jlaskey at openjdk.org  Thu Nov  3 14:52:50 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 14:52:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <W-RWTASOeh-drU1Xwwb6_TmJugIOxxpcRwrMm8945Uw=.2e29d570-95b9-4f0d-81ba-f3828ea2c458@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>
 <sJ_JQLbsGTLg3GpeMd6h205DuElxFynL29KdPIVZdxA=.8f9cfbd5-ca51-48c3-8319-c2e095ba2931@github.com>
 <W-RWTASOeh-drU1Xwwb6_TmJugIOxxpcRwrMm8945Uw=.2e29d570-95b9-4f0d-81ba-f3828ea2c458@github.com>
Message-ID: <BrTanOhonsXg-yxKvUK2Qo2gZZwtVt8aGoD64Svhqfk=.eef4753e-e599-4efb-95f3-452872804f28@github.com>

On Wed, 2 Nov 2022 17:44:24 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Will use List.of. I think use case is raw and caching should be left to the user.
>
> i agree

I agree. Need a balance of performance and #classes. Just something I'll work on during preview.

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

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

From jlaskey at openjdk.org  Thu Nov  3 14:52:59 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 14:52:59 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v8]
In-Reply-To: <pqVUBB9fllsFQKJj4q8gZM_E2_y8RS4g_3nlOyGWxbM=.2b46ea0e-a627-456a-8cad-00f0da0cabbc@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <DQKRI5LPtJFup-QUyd8qsd53bUJ60ZO8bTv26naMfGc=.667a52e7-4e5d-4fe7-8d11-29e5d295f7b5@github.com>
 <pqVUBB9fllsFQKJj4q8gZM_E2_y8RS4g_3nlOyGWxbM=.2b46ea0e-a627-456a-8cad-00f0da0cabbc@github.com>
Message-ID: <UlV3dQgD8eddRFi3EW3FBrGtXfIoGtNqQfZGL-eBdbY=.1ff0bf6f-5ce7-4e2f-909c-15824e2ca0e4@github.com>

On Wed, 2 Nov 2022 18:01:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jim Laskey 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 22 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Add @SafeVarargs declarations
>>  - Move template bootstrap
>>  - Requested changes #2
>>  - Requested changes
>>  - Remove .orig file
>>  - Update TemplateRuntime::combine
>>  - Move StringConcatItem to FormatConcatItem
>>  - Tabs to spaces
>>  - Force processor before template string expression
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/882a8efa...6cea084b
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 175:
> 
>> 173:             int size = st.values().size();
>> 174:             for (int index = 0; index < size; index++) {
>> 175:                 result.add(MethodHandles.insertArguments(GET_VALUE_MH, 0, index));
> 
> The returned method handle takes a `StringTemplate` as an argument, but doesn't guard against the fact that a different string template instance can be passed than the one used here, which can lead to errors when invoking the method handle (e.g. out of bounds access, or cast failures when the value types are different).
> 
> I was gonna suggest using `List::get` as a method handle instead, and then binding the `values()` list and the index to that. That would drop the `StringTemplate` param, which I suppose is important for `javac` generated code? Could add a `dropArguments` for that, but then the argument would always be ignored.
> 
> Maybe alternatively, the `getValue` method could do a check that the `StringTemplate` instance passed to it is the same instance as the one used here.
> 
> I don't know...

Pulled method

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

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

From jlaskey at openjdk.org  Thu Nov  3 15:09:46 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 15:09:46 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <bhxIO_P85-ulO9bhuGS4mdOnZAlH8L-LCVZ9E-fzLfc=.17f8f48a-8fbc-420a-8310-4c1662db40b5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
 <bhxIO_P85-ulO9bhuGS4mdOnZAlH8L-LCVZ9E-fzLfc=.17f8f48a-8fbc-420a-8310-4c1662db40b5@github.com>
Message-ID: <5sTm6SXnv2pN72X7RO_dEajB5VJqPwzjew8oep4NVPQ=.ee7c52aa-448b-49cc-a076-dbdccbe11c9f@github.com>

On Wed, 2 Nov 2022 20:07:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internalize TemplateSupport
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1103:
> 
>> 1101:         }
>> 1102: 
>> 1103:         MethodHandle mh = MethodHandles.dropArguments(newString(), 2, ttypes);
> 
> The code here us pretty dense. I suggest adding comments that show the type of `mh` as far as it is known. I think it makes it a much easier to keep track of what's going on (esp. what all the argument indexes mean). e.g.
> Suggestion:
> 
>         // (byte[],long,ttypes...) -> String
>         MethodHandle mh = MethodHandles.dropArguments(newString(), 2, ttypes);

Noted

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

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

From jlaskey at openjdk.org  Thu Nov  3 15:11:52 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 15:11:52 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <yRjL1eC-e_VHdFAu86LhU6qhKPXCr5ZG-l3qcwKnnvI=.3ff1906b-1215-42cf-b1a9-b311e14a661d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
 <yRjL1eC-e_VHdFAu86LhU6qhKPXCr5ZG-l3qcwKnnvI=.3ff1906b-1215-42cf-b1a9-b311e14a661d@github.com>
Message-ID: <M_toN1w-7r3IcKcCQjipY05L9TWSgSqsSvybhRcdGkw=.dee592f5-982f-4c79-9bb5-14e1f8aa7c6b@github.com>

On Wed, 2 Nov 2022 22:50:29 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internalize TemplateSupport
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 359:
> 
>> 357:      * @since 19
>> 358:      */
>> 359:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 
> Just a passerby question: what's the point in marking non-public methods with `@PreviewFeature`?

It also lets JDK developers know that the methods are transitional.

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

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

From jlaskey at openjdk.org  Thu Nov  3 15:47:49 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 15:47:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <bhxIO_P85-ulO9bhuGS4mdOnZAlH8L-LCVZ9E-fzLfc=.17f8f48a-8fbc-420a-8310-4c1662db40b5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
 <bhxIO_P85-ulO9bhuGS4mdOnZAlH8L-LCVZ9E-fzLfc=.17f8f48a-8fbc-420a-8310-4c1662db40b5@github.com>
Message-ID: <tgyQh8aSTTNLUgEveOckw8rxgG8pCYqXRLW2Y2skAQ4=.b31a8b31-c64c-440a-b156-78b88037408d@github.com>

On Wed, 2 Nov 2022 20:07:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internalize TemplateSupport
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1118:
> 
>> 1116:             MethodHandle prepender = prepender(lastFragment.isEmpty() ? null : fragment, ttype);
>> 1117:             initialLengthCoder = JLA.stringConcatMix(initialLengthCoder, fragment);
>> 1118:             mh = MethodHandles.filterArgumentsWithCombiner(mh, 1, prepender,1, 0, 2 + pos);
> 
> Suggestion:
> 
>             Class<?> ttype = ttypes[pos];
>             // (long,byte[],ttype) -> long
>             MethodHandle prepender = prepender(lastFragment.isEmpty() ? null : fragment, ttype);
>             initialLengthCoder = JLA.stringConcatMix(initialLengthCoder, fragment);
>             // (byte[],long,ttypes...) -> String (unchanged)
>             mh = MethodHandles.filterArgumentsWithCombiner(mh, 1, prepender,1, 0, 2 + pos);

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1125:
> 
>> 1123:         MethodHandle newArrayCombinator = lastFragment.isEmpty() ? newArray() :
>> 1124:                 newArrayWithSuffix(lastFragment);
>> 1125:         mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, newArrayCombinator,
> 
> Suggestion:
> 
>         // (long,ttypes...) -> String
>         mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, newArrayCombinator,

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1143:
> 
>> 1141:                         0, // old-index
>> 1142:                         1 + pos // selected argument
>> 1143:                 );
> 
> Suggestion:
> 
>             // (long,ttype) -> long
>             MethodHandle mix = mixer(ttypes[pos]);
>             boolean lastPType = pos == ttypes.length - 1;
> 
>             if (lastPType) {
>                 // (ttype) -> long
>                 mix = MethodHandles.insertArguments(mix, 0, initialLengthCoder);
>                 // (ttypes...) -> String
>                 mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, mix,
>                         1 + pos // selected argument
>                 );
>             } else {
>                 // (long,ttypes...) -> String
>                 mh = MethodHandles.filterArgumentsWithCombiner(mh, 0, mix,
>                         0, // old-index
>                         1 + pos // selected argument
>                 );

Changing

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

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

From jlaskey at openjdk.org  Thu Nov  3 16:13:01 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 16:13:01 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v12]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <UfK0O_yb3iIw9rvrfgbYeteFAJlCY2yMWALUQgL4xIc=.13472541-a022-42fb-a883-725aef8404ad@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:

  Requested changes #5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/2cf00caa..7f3d6526

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

  Stats: 172 lines in 5 files changed: 7 ins; 160 del; 5 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  Thu Nov  3 17:23:53 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 17:23:53 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@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:

  Internalize FormatConcatItem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/7f3d6526..b35ed665

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

  Stats: 151 lines in 7 files changed: 62 ins; 86 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  Thu Nov  3 17:23:54 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 3 Nov 2022 17:23:54 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <4jrJpr-CNMkKjBDlIVscDNqLmxyt7mh_Oz5cU8vfRWY=.e1310ec2-f363-4016-818c-5c869abb270e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <4jrJpr-CNMkKjBDlIVscDNqLmxyt7mh_Oz5cU8vfRWY=.e1310ec2-f363-4016-818c-5c869abb270e@github.com>
Message-ID: <ppU0e1wBplhwObOhMa2FGCKCxJHkEwN2DcaJbj66eug=.ed5d0a53-016d-4702-8995-896ff5a69afd@github.com>

On Tue, 1 Nov 2022 15:31:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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/util/FormatConcatItem.java line 51:
> 
>> 49:  */
>> 50: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 51: public sealed interface FormatConcatItem
> 
> I wonder why is this a public API - is there some way to use it from the client code?
> 
> Note that in named modules, the permitted subtypes don't need to be in the same package, so if this is not needed in the API, it probably can be moved into a non-API package.

Moved

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

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

From ysatowse at openjdk.org  Fri Nov  4 02:27:40 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 4 Nov 2022 02:27:40 GMT
Subject: <i18n dev> Integrated: 8296108: (tz) Update Timezone Data to 2022f
In-Reply-To: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>
References: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com>
Message-ID: <KQiDf2V0Vb051FNIQFu7KSezZ5NqMGWXIZCU8P2hdEE=.49fa6961-353c-4beb-8650-a6c0adf628d3@github.com>

On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga.

This pull request has now been integrated.

Changeset: 9d3b4ef2
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d3b4ef2ad658afb5379796b7224458c12c81f5d
Stats:     1362 lines in 25 files changed: 560 ins; 705 del; 97 mod

8296108: (tz) Update Timezone Data to 2022f

Reviewed-by: serb, naoto

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

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

From forax at openjdk.org  Fri Nov  4 08:30:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 4 Nov 2022 08:30:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v11]
In-Reply-To: <PhqE1GjWxkH1i8Fmwinn81tHLhUGRGokSFaT5rHy1Hw=.f32c2be7-9d0a-4768-b73a-ff7a7134a53c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BeQUNg2QWNfNBY7Z2OpTjYBDDxI3gVUeQ1aHRx6W4sA=.7a60c53f-a6ac-4c31-baee-1cc654534e10@github.com>
 <O2CCxscV2PbPqbhjE79-7jRx1C5XUle7niPjr3hSBj8=.394fa7d0-258e-4d29-9042-ac6869cec8ef@github.com>
 <PhqE1GjWxkH1i8Fmwinn81tHLhUGRGokSFaT5rHy1Hw=.f32c2be7-9d0a-4768-b73a-ff7a7134a53c@github.com>
Message-ID: <TvBUy72Uf37oH5yTxnJcVoDQi1K2_Bg8gYj4u_UkaFk=.0dbc17c0-901a-4a2d-9728-52083e2007e8@github.com>

On Wed, 2 Nov 2022 21:53:00 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/template/TemplateSupport.java line 147:
>> 
>>> 145: 
>>> 146:         return support.processWithProcessor();
>>> 147:     }
>> 
>> Thinking about this protocol some more: this seems to depend on the processor being a constant, which precludes specialized linking of call sites where the processor is a dynamic argument.
>> 
>> The returned method handle/call site could maybe be changed to take the processor instance as a leading argument instead. The processor can then be used to pass additional arguments to the processing code (like the DB example in the JEP). (and, AFAICS, that will also allow using calls to this BSM as the sole translation strategy for every type of processor, which seems more robust if types are changed later on to (un-)implement `ProcessorLinkage`)
>> 
>> The `linkage` method could instead be a `static` method, which is somehow tied to the type of the processor. Since it's currently a sealed interface you could have a mapping from each implementer to the `linkage` method for the types you care about (only `FormatProcessor` atm). If that is to be opened up to public extension in the future, something like type classes would be needed I think, so that the runtime can reliably map from the processor type to the static `linkage` method.
>> 
>> WDYT?
>
> (FWIW, I don't see this as prohibitive for this PR to go ahead, but maybe something to consider before finalizing the feature)

Yes, the current code only supports processors with no fields, which is Okay given that the interface  `ProcessorLinkage` is sealed.

If/When the processor linkage API is open for everyone as you said the design will have to be changed.
But going the other way, creates a general mechanism is painful because either you have an adhoc way to associate  the processor to a BSM-like method or you have to delay until runtime the linkage using a monomorphic/polymorphic cache (I know Jim has tested that before back-pedaling to a simpler more constrained good enough solution).

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

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

From forax at openjdk.org  Fri Nov  4 08:38:42 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 4 Nov 2022 08:38:42 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <8Z6JILAAjo3h5wRJrgtjKq_g1r3d6av5pPSNPlaAtb0=.32268df7-ecfb-4549-999a-d3a2783389ef@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <Nj2PsBnKgBtTDnpvBivPZ06g3UZK2PraE5E07NQ5t7w=.b91a4cb1-0c7d-4582-8d0e-647412f7402b@github.com>
 <8Z6JILAAjo3h5wRJrgtjKq_g1r3d6av5pPSNPlaAtb0=.32268df7-ecfb-4549-999a-d3a2783389ef@github.com>
Message-ID: <N7bxpsnl2IIeEYoF-agZFUsILhlzSE_QZVT_Ax3rXKk=.b737645c-231d-4d9c-8370-896c6968c140@github.com>

On Thu, 3 Nov 2022 14:37:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 60:
>> 
>>> 58:      * @throws NullPointerException if any of the arguments are null
>>> 59:      */
>>> 60:     MethodHandle linkage(List<String> fragments, MethodType type);
>> 
>> I suggest changing the protocol here to be able to take all bootstrap arguments into account, and return a `CallSite` instead. That will allow a `ProcessorLinkage` to take the lookup and name into account as well, and allows returning e.g. a `MutableCallSite` as well.
>> 
>> Maybe this can still be changed later as well though, since the interface is sealed.
>
> Yes - this will all go away during preview.

I disagree with Jorn,
- CallSite.dynamicInvoker() can be used to see a `MutableCallSite` as a `MethodHandle` so returning a `MethodHandle` is as powerful as returning a `CallSite`.
- Having a `ProcessorLinkage` that takes a Lookup as parameter is a security risk because it means that a processor have full access to the user code that calls the processor at runtime.

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

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

From forax at openjdk.org  Sat Nov  5 22:27:39 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 5 Nov 2022 22:27:39 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
Message-ID: <nbA8ir9hwuMeATDFIii4CU5nMz8_bGUDh5vTRLNV6pc=.2a63344d-d723-4c94-9768-64dd6cd1b0fa@github.com>

On Thu, 3 Nov 2022 17:23:53 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:
> 
>   Internalize FormatConcatItem

src/java.base/share/classes/java/lang/template/StringTemplate.java line 276:

> 274:      * @implNote Contents of both lists are copied to construct immutable lists.
> 275:      */
> 276:     public static StringTemplate of(List<String> fragments, List<Object> values) {

Should be `StringTemplate of(List<String> fragments, List<?> values) {`

The call to List.copyOf() will change the List<?> to List<Object>.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 299:

> 297:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 298:      */
> 299:     public static String interpolate(List<String> fragments, List<Object> values) {

Should be `String interpolate(List<String> fragments, List<?> values) {` as above

src/java.base/share/classes/java/lang/template/StringTemplate.java line 305:

> 303:         int valuesSize = values.size();
> 304:         if (fragmentsSize != valuesSize + 1) {
> 305:             throw new RuntimeException("fragments must have one more element than values");

Should be IllegalArgumentException (see method of() above)

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

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

From forax at openjdk.org  Sat Nov  5 22:32:35 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 5 Nov 2022 22:32:35 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
Message-ID: <z24IbiO00FtvNa592FjUQKGlXL2PpIyYrHcAqtnlmas=.551360a1-57d0-4149-b704-11ae0a5a0ddf@github.com>

On Thu, 3 Nov 2022 17:23:53 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:
> 
>   Internalize FormatConcatItem

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 159:

> 157:             }
> 158:         }
> 159:         return new SimpleStringTemplate(TemplateRuntime.toList(fragments), TemplateRuntime.toList(values));

Should be
  `return new SimpleStringTemplate(List.copyOf(fragments), TemplateRuntime.toList(values));`
because only a value can be null, a fragment should not be null

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

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

From forax at openjdk.org  Sat Nov  5 22:38:06 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 5 Nov 2022 22:38:06 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
Message-ID: <ouQ16sGzyauEvYa665eCuPrwSoFMg8X5vKo9r8PsNWw=.7bc86c2e-9d54-4fe7-9b3f-a465ea38c853@github.com>

On Thu, 3 Nov 2022 17:23:53 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:
> 
>   Internalize FormatConcatItem

src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 100:

> 98:  *     // check or manipulate the fragments and/or values
> 99:  *     ...
> 100:  *     return StringTemplate.interpolate(fragments, values);;

There is two semicolons instead of one at the end of this line

src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 126:

> 124:  * }
> 125:  * The {@link StringTemplate#interpolate()} method is available for those processors
> 126:  * that just need to work with the interpolatation;

type `interpolatation`-> `interpolation`

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

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

From forax at openjdk.org  Sat Nov  5 23:13:37 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 5 Nov 2022 23:13:37 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
Message-ID: <ExHLSZ3nnCFzsK_g-FpRWySJvR1rXNKsrgjIU9BwJvM=.f962f484-6286-4247-87dd-b40478231f7f@github.com>

On Thu, 3 Nov 2022 17:23:53 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:
> 
>   Internalize FormatConcatItem

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 158:

> 156:                 values[j++] = value;
> 157:             }
> 158:         }

The sides effects `fragments[i++] += fragmentIter.next();` and `i--` are ugly and can easily be overlook.
Also there is no need to use an iterator here, we know that the fragments have a List.get() in O(1).
The idea is to concat the last fragment of a template with the first one of the next template, so i propose

        ...
        String[] fragments = new String[size + 1];
        String last = "";
        int i = 0, j = 0;
        for (StringTemplate st : sts) {
            List<String> templateFragments = st.fragments();
            fragments[i++] = last.concat(templateFragments.get(0));  // concat last fragment with first new fragment
            int k = 0;
            for(; k < templateFragments.size() - 1; k++) {
              fragments[i++] = templateFragments.get(k);
            }
            last = templateFragments.get(k);
            for (Object value : st.values()) {
                values[j++] = value;
            }
        }
        fragments[i] = last;

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

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

From duke at openjdk.org  Sun Nov  6 11:37:32 2022
From: duke at openjdk.org (duke)
Date: Sun, 6 Nov 2022 11:37:32 GMT
Subject: <i18n dev> Withdrawn: 8291916: Unexpected output on Windows command
 prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <MfceMKtCzCBIV6J13OIWK9m8uFK_XtvsxAa0D37UD40=.eead23b5-ab92-4581-a21a-b4880f044148@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Sun Nov  6 13:34:20 2022
From: duke at openjdk.org (ExE Boss)
Date: Sun, 6 Nov 2022 13:34:20 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
Message-ID: <YDSVJXl7hCAIaE-npeD30AiKs-i6ffGfN5Exc06qm1g=.e4f143df-d293-4856-82ac-2aa42665d4e7@github.com>

On Thu, 3 Nov 2022 17:23:53 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:
> 
>   Internalize FormatConcatItem

src/java.base/share/classes/java/util/FormatItem.java line 75:

> 73:         try {
> 74:             return (long)CHAR_MIX.invokeExact(lengthCoder, value);
> 75:         } catch (RuntimeException ex) {

This?should also?rethrow `Error`?instances:
Suggestion:

        } catch (Error | RuntimeException ex) {

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

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

From darcy at openjdk.org  Sun Nov  6 22:18:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 6 Nov 2022 22:18:20 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
Message-ID: <gmSZZADjXMwU37RzrZ6NjacBL6WHwemrGm4NEIarXIY=.9b67d235-73fa-4b0e-a242-c7c151a8d435@github.com>

On Thu, 3 Nov 2022 17:23:53 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:
> 
>   Internalize FormatConcatItem

src/java.base/share/classes/java/util/FormatProcessor.java line 38:

> 36: 
> 37: /**
> 38:  * This {@linkplain ValidatingProcessor yemplate processor} constructs a String

Typo: "yemplate processor".

src/java.base/share/classes/java/util/FormatProcessor.java line 56:

> 54:  * to produce a more performant formatter.
> 55:  *
> 56:  * @implSpec Since, values are in situ, argument indexing is unsupported.

Please avoid Latin phrases like "in situ" in the javadoc.

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

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

From naoto at openjdk.org  Mon Nov  7 18:16:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 7 Nov 2022 18:16:38 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
Message-ID: <zLdlvfKS_6jgWFuWW8sPCeI734i8VgMMYOJJo3szmlE=.7f78f8ee-60e5-4c8f-90e8-ee0e67cc2e42@github.com>

On Thu, 3 Nov 2022 17:23:53 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:
> 
>   Internalize FormatConcatItem

src/java.base/share/classes/java/util/FormatItem.java line 540:

> 538:                 char ch = (char)getCharMH.invokeExact(buffer, start + i);
> 539:                 putCharMH.invokeExact(buffer, start + i, (int)Character.toUpperCase(ch));
> 540:             }

Some characters may produce multiple uppercase characters, such as "fi" ligature ('\ufb01' -> "FI"), also this should consider locale, e.g. the case for Turkish dotless i.

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

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

From duke at openjdk.org  Mon Nov  7 22:36:57 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 7 Nov 2022 22:36:57 GMT
Subject: <i18n dev> RFR: 8296239: ISO 4217 Amendment 174 Update
Message-ID: <fg2V3eIPc6q2yjZeOL5Y-8GRMCHYxllVtHaEGL4BN3s=.6aa78d64-cabd-4792-aae8-3439b15c22d4@github.com>

Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023).

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

Commit messages:
 - Actually change to GMT+1
 - Convert time to Croatia/GMT+1
 - Reflect future change date in table
 - Add future date, remove localedata changes
 - Initial changes for ISO 174

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

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

From naoto at openjdk.org  Mon Nov  7 22:37:00 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 7 Nov 2022 22:37:00 GMT
Subject: <i18n dev> RFR: 8296239: ISO 4217 Amendment 174 Update
In-Reply-To: <fg2V3eIPc6q2yjZeOL5Y-8GRMCHYxllVtHaEGL4BN3s=.6aa78d64-cabd-4792-aae8-3439b15c22d4@github.com>
References: <fg2V3eIPc6q2yjZeOL5Y-8GRMCHYxllVtHaEGL4BN3s=.6aa78d64-cabd-4792-aae8-3439b15c22d4@github.com>
Message-ID: <gbW4OE9OFq8LAmXnRcQEE7kbUAYe1eJB04qchucCTAE=.d6fbc9c6-86b4-4302-a22b-9aa0d8cc288f@github.com>

On Fri, 4 Nov 2022 17:21:04 GMT, Justin Lu <duke at openjdk.org> wrote:

> Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023).

Changes requested by naoto (Reviewer).

src/java.base/share/data/currency/CurrencyData.properties line 192:

> 190: CI=XOF
> 191: # CROATIA
> 192: HR=HRK;2022-12-31-21-00-00;EUR

Since Croatian time is `GMT+1`, the cutover time should be `2022-12-31-23-00-00` in GMT

test/jdk/java/util/Currency/tablea1.txt line 70:

> 68: CR	CRC	188	2
> 69: CI	XOF	952	0
> 70: HR	HRK	191	2	2022-12-31-21-00-00	EUR	978	2

Same as above

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

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

From duke at openjdk.org  Mon Nov  7 22:37:02 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 7 Nov 2022 22:37:02 GMT
Subject: <i18n dev> RFR: 8296239: ISO 4217 Amendment 174 Update
In-Reply-To: <gbW4OE9OFq8LAmXnRcQEE7kbUAYe1eJB04qchucCTAE=.d6fbc9c6-86b4-4302-a22b-9aa0d8cc288f@github.com>
References: <fg2V3eIPc6q2yjZeOL5Y-8GRMCHYxllVtHaEGL4BN3s=.6aa78d64-cabd-4792-aae8-3439b15c22d4@github.com>
 <gbW4OE9OFq8LAmXnRcQEE7kbUAYe1eJB04qchucCTAE=.d6fbc9c6-86b4-4302-a22b-9aa0d8cc288f@github.com>
Message-ID: <KtDsWwNyPLI_90ExZs_mo_xK1AHH3zwH2VEXpZyDfcQ=.d05170be-7b25-431a-940f-a0c27def3313@github.com>

On Fri, 4 Nov 2022 17:40:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023).
>
> src/java.base/share/data/currency/CurrencyData.properties line 192:
> 
>> 190: CI=XOF
>> 191: # CROATIA
>> 192: HR=HRK;2022-12-31-21-00-00;EUR
> 
> Since Croatian time is `GMT+1`, the cutover time should be `2022-12-31-23-00-00` in GMT

Made the change thank you

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

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

From naoto at openjdk.org  Tue Nov  8 16:27:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Nov 2022 16:27:42 GMT
Subject: <i18n dev> RFR: 8296239: ISO 4217 Amendment 174 Update
In-Reply-To: <fg2V3eIPc6q2yjZeOL5Y-8GRMCHYxllVtHaEGL4BN3s=.6aa78d64-cabd-4792-aae8-3439b15c22d4@github.com>
References: <fg2V3eIPc6q2yjZeOL5Y-8GRMCHYxllVtHaEGL4BN3s=.6aa78d64-cabd-4792-aae8-3439b15c22d4@github.com>
Message-ID: <GBhTLk-kLKMspcE-bKjAEI2l1U2Aq5gUNCvPRKrasTM=.d73cb562-b990-4db9-82d6-ddec7224aef2@github.com>

On Fri, 4 Nov 2022 17:21:04 GMT, Justin Lu <duke at openjdk.org> wrote:

> Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023).

Marked as reviewed by naoto (Reviewer).

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

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

From duke at openjdk.org  Wed Nov  9 01:22:24 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 9 Nov 2022 01:22:24 GMT
Subject: <i18n dev> Integrated: 8296239: ISO 4217 Amendment 174 Update
In-Reply-To: <fg2V3eIPc6q2yjZeOL5Y-8GRMCHYxllVtHaEGL4BN3s=.6aa78d64-cabd-4792-aae8-3439b15c22d4@github.com>
References: <fg2V3eIPc6q2yjZeOL5Y-8GRMCHYxllVtHaEGL4BN3s=.6aa78d64-cabd-4792-aae8-3439b15c22d4@github.com>
Message-ID: <RS_jN-R1dNY4pZ-T-KUpLlSYzGlXEqNA3-wYQM-vWqg=.7d9d7411-f9a5-4c0c-a56c-fa8e1308193c@github.com>

On Fri, 4 Nov 2022 17:21:04 GMT, Justin Lu <duke at openjdk.org> wrote:

> Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023).

This pull request has now been integrated.

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

8296239: ISO 4217 Amendment 174 Update

Reviewed-by: naoto

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

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

From aturbanov at openjdk.org  Wed Nov  9 09:02:27 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 9 Nov 2022 09:02:27 GMT
Subject: <i18n dev> Integrated: 8296140: Drop unused field
 java.util.Calendar.DATE_MASK
In-Reply-To: <P7Lc7JlcC90i-4Chm5eEV2Kd7etfqQdY_5QLq_RHHME=.5f2d6083-b7f8-4065-9d2b-0ceb11c9e75a@github.com>
References: <P7Lc7JlcC90i-4Chm5eEV2Kd7etfqQdY_5QLq_RHHME=.5f2d6083-b7f8-4065-9d2b-0ceb11c9e75a@github.com>
Message-ID: <1HU0aCYgnpFc5x9vDE2Q4GrmHEfFWZuCtWW3Zk4Rumc=.7e1ee1e6-7e63-469b-add8-cbb0dbcea433@github.com>

On Thu, 27 Oct 2022 19:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no usages for this field. As it has the same value as `DAY_OF_MONTH_MASK` we can drop it.

This pull request has now been integrated.

Changeset: 82cbfb5f
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82cbfb5fb0db61f3f1d9f0ceeed20c1cf5474652
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8296140: Drop unused field java.util.Calendar.DATE_MASK

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Wed Nov  9 19:29:08 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 9 Nov 2022 19:29:08 GMT
Subject: <i18n dev> RFR: 8296715: CLDR v42 update for tzdata 2022f
Message-ID: <K4Kt0Xp8bYkrMUMu8VnCtptboDrkDT8l7svwRpAjzXU=.e139951b-bec6-4007-93ce-5e17b2d6f10d@github.com>

Pick up the fix in the upstream CLDR v42 maintenance branch for their tzdata2022f changes.

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

Commit messages:
 - 8296715: CLDR v42 update for tzdata 2022f

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

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

From jlaskey at openjdk.org  Wed Nov  9 21:07:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 21:07:48 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: <0Ob9mnmmVia6pC-tdUTgDZRtj9ix9SRnv4UCKbtB3OE=.5c48122a-ef5a-443a-aa6c-c410e66bce0b@github.com>

On Fri, 28 Oct 2022 19:38:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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.

Changing

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

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

From jlaskey at openjdk.org  Wed Nov  9 21:16:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 21:16:38 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: <x63vBIall8jxjAsw6oLF5MDOyVZ3tBj_rkDGEEpeF5M=.b1362965-b153-4ca8-9bdb-3a023afd43b8@github.com>

On Fri, 28 Oct 2022 19:38:26 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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

Raw list?

>> 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

Raw list?

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

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

From jlaskey at openjdk.org  Wed Nov  9 21:16:40 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 21:16:40 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <Dl3GU7GWMu6NP7rbyVcf40jToUYgB0k0i7lw9WuNR2Q=.ac7cc25b-96dd-4868-b991-132cf4b07cad@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>
 <Dl3GU7GWMu6NP7rbyVcf40jToUYgB0k0i7lw9WuNR2Q=.ac7cc25b-96dd-4868-b991-132cf4b07cad@github.com>
Message-ID: <x8lPo_pyfuem5rs_xZ5XSUdsf5OQQWKo6aFiKXdSsKg=.77098179-eaf7-4c05-a080-739e7a303818@github.com>

On Tue, 1 Nov 2022 19:06:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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.
>
> Changing caller

Changing

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

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

From jlaskey at openjdk.org  Wed Nov  9 21:16:40 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 21:16:40 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <BrTanOhonsXg-yxKvUK2Qo2gZZwtVt8aGoD64Svhqfk=.eef4753e-e599-4efb-95f3-452872804f28@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>
 <sJ_JQLbsGTLg3GpeMd6h205DuElxFynL29KdPIVZdxA=.8f9cfbd5-ca51-48c3-8319-c2e095ba2931@github.com>
 <W-RWTASOeh-drU1Xwwb6_TmJugIOxxpcRwrMm8945Uw=.2e29d570-95b9-4f0d-81ba-f3828ea2c458@github.com>
 <BrTanOhonsXg-yxKvUK2Qo2gZZwtVt8aGoD64Svhqfk=.eef4753e-e599-4efb-95f3-452872804f28@github.com>
Message-ID: <mOAL0loJ4gIhXc9jksfTZrsvukSKrDXWGKujckaWvF8=.f74053ed-59ee-45e8-8ec6-b2f99406c64f@github.com>

On Thu, 3 Nov 2022 14:48:25 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> i agree
>
> I agree. Need a balance of performance and #classes. Just something I'll work on during preview.

Changing

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

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

From jlaskey at openjdk.org  Wed Nov  9 21:52:49 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 21:52:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v7]
In-Reply-To: <lk6Ohi1WaylwI8W10VHv1TPRN2hXn5RST6g_oY2R_hA=.98de2cea-f2f2-4515-8e49-8c5bf29be04b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com>
 <lk6Ohi1WaylwI8W10VHv1TPRN2hXn5RST6g_oY2R_hA=.98de2cea-f2f2-4515-8e49-8c5bf29be04b@github.com>
Message-ID: <UlUssswEDCJ4wrRAxC9V4Olq6rQouV017HzwDpybJEA=.d87ce6ef-579d-4b30-bc17-3b2b196b2a11@github.com>

On Wed, 2 Nov 2022 17:41:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> It is also a duplicate of a private method in TemplateRuntime
>
> Yes, this is leaking access. I suppose this is public because it is called from `javac` generated code. But, from the perspective of the runtime, code generated by `javac` is the same as any other arbitrary non-trusted bytecode.

Reasonable. Changing

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

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

From forax at openjdk.org  Wed Nov  9 21:52:50 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 9 Nov 2022 21:52:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v3]
In-Reply-To: <x63vBIall8jxjAsw6oLF5MDOyVZ3tBj_rkDGEEpeF5M=.b1362965-b153-4ca8-9bdb-3a023afd43b8@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>
 <x63vBIall8jxjAsw6oLF5MDOyVZ3tBj_rkDGEEpeF5M=.b1362965-b153-4ca8-9bdb-3a023afd43b8@github.com>
Message-ID: <DmmYWBdoZh2M-7CgNB6g4-xr0gbJ36W7Szy66wjfGVs=.d4b7f51a-2e8b-4851-9563-36e576160c93@github.com>

On Wed, 9 Nov 2022 21:12:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Changing
>
> Raw list?

I think this comment is not on the right part of the code.

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

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

From forax at openjdk.org  Wed Nov  9 21:57:53 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 9 Nov 2022 21:57:53 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <nbA8ir9hwuMeATDFIii4CU5nMz8_bGUDh5vTRLNV6pc=.2a63344d-d723-4c94-9768-64dd6cd1b0fa@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <nbA8ir9hwuMeATDFIii4CU5nMz8_bGUDh5vTRLNV6pc=.2a63344d-d723-4c94-9768-64dd6cd1b0fa@github.com>
Message-ID: <y7xVcGJZFN9-I3SxXv6ViqT8Ai9sN0U4duNmZhebvbA=.dafd67e7-e914-4c3b-a871-ceb551de18b2@github.com>

On Sat, 5 Nov 2022 22:23:23 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:
>> 
>>   Internalize FormatConcatItem
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 276:
> 
>> 274:      * @implNote Contents of both lists are copied to construct immutable lists.
>> 275:      */
>> 276:     public static StringTemplate of(List<String> fragments, List<Object> values) {
> 
> Should be `StringTemplate of(List<String> fragments, List<?> values) {`
> 
> The call to List.copyOf() will change the List<?> to List<Object>.

> raw List ?

oops, formatting issue.

The idea is that `values` can be typed `List<?>` because the call to List.copyOf() will take the `List<?>` and return a `List<Object>`.

And as a type of a parameter `List<?>` is better than `List<Object>` because `List<String>` is a subtype of `List<?>` but not a subtype of `List<Object>`.

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

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

From jlaskey at openjdk.org  Wed Nov  9 22:13:43 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 22:13:43 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <y7xVcGJZFN9-I3SxXv6ViqT8Ai9sN0U4duNmZhebvbA=.dafd67e7-e914-4c3b-a871-ceb551de18b2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <nbA8ir9hwuMeATDFIii4CU5nMz8_bGUDh5vTRLNV6pc=.2a63344d-d723-4c94-9768-64dd6cd1b0fa@github.com>
 <y7xVcGJZFN9-I3SxXv6ViqT8Ai9sN0U4duNmZhebvbA=.dafd67e7-e914-4c3b-a871-ceb551de18b2@github.com>
Message-ID: <QECzLUK1SLfwSI2rqTcpmd3JRI6JjQNMfjQQeAOFPL4=.4e952d8a-7372-4dbf-80c9-f077249b375d@github.com>

On Wed, 9 Nov 2022 21:55:24 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 276:
>> 
>>> 274:      * @implNote Contents of both lists are copied to construct immutable lists.
>>> 275:      */
>>> 276:     public static StringTemplate of(List<String> fragments, List<Object> values) {
>> 
>> Should be `StringTemplate of(List<String> fragments, List<?> values) {`
>> 
>> The call to List.copyOf() will change the List<?> to List<Object>.
>
>> raw List ?
> 
> oops, formatting issue.
> 
> The idea is that `values` can be typed `List<?>` because the call to List.copyOf() will take the `List<?>` and return a `List<Object>`.
> 
> And as a type of a parameter `List<?>` is better than `List<Object>` because `List<String>` is a subtype of `List<?>` but not a subtype of `List<Object>`.

Got you. Changing.

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

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

From jlaskey at openjdk.org  Wed Nov  9 22:48:47 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 22:48:47 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <nbA8ir9hwuMeATDFIii4CU5nMz8_bGUDh5vTRLNV6pc=.2a63344d-d723-4c94-9768-64dd6cd1b0fa@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <nbA8ir9hwuMeATDFIii4CU5nMz8_bGUDh5vTRLNV6pc=.2a63344d-d723-4c94-9768-64dd6cd1b0fa@github.com>
Message-ID: <t7pb_AZz0_l7HTVre2FOdZ4cH4oxh6Qxwj8-41Y1eyc=.3234c14d-d170-4560-b986-8e53d25e0dba@github.com>

On Sat, 5 Nov 2022 22:23: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:
>> 
>>   Internalize FormatConcatItem
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 299:
> 
>> 297:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 298:      */
>> 299:     public static String interpolate(List<String> fragments, List<Object> values) {
> 
> Should be `String interpolate(List<String> fragments, List<?> values) {` as above

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 305:
> 
>> 303:         int valuesSize = values.size();
>> 304:         if (fragmentsSize != valuesSize + 1) {
>> 305:             throw new RuntimeException("fragments must have one more element than values");
> 
> Should be IllegalArgumentException (see method of() above)

Changing

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

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

From jlaskey at openjdk.org  Wed Nov  9 22:48:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 22:48:48 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <YDSVJXl7hCAIaE-npeD30AiKs-i6ffGfN5Exc06qm1g=.e4f143df-d293-4856-82ac-2aa42665d4e7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <YDSVJXl7hCAIaE-npeD30AiKs-i6ffGfN5Exc06qm1g=.e4f143df-d293-4856-82ac-2aa42665d4e7@github.com>
Message-ID: <MRu9qdwlo6sP8wht81DLUaoiaazGdlj1bk4nDbtJ13E=.6249d107-bd1b-4121-8908-db640235753c@github.com>

On Sun, 6 Nov 2022 13:28:18 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internalize FormatConcatItem
>
> src/java.base/share/classes/java/util/FormatItem.java line 75:
> 
>> 73:         try {
>> 74:             return (long)CHAR_MIX.invokeExact(lengthCoder, value);
>> 75:         } catch (RuntimeException ex) {
> 
> This?should also?rethrow `Error`?instances:
> Suggestion:
> 
>         } catch (Error | RuntimeException ex) {

Changing

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

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

From jlaskey at openjdk.org  Wed Nov  9 22:48:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 22:48:48 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <gmSZZADjXMwU37RzrZ6NjacBL6WHwemrGm4NEIarXIY=.9b67d235-73fa-4b0e-a242-c7c151a8d435@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <gmSZZADjXMwU37RzrZ6NjacBL6WHwemrGm4NEIarXIY=.9b67d235-73fa-4b0e-a242-c7c151a8d435@github.com>
Message-ID: <jmjb0HXagualKvyhqaShxIi5C-wJs4ITM6ivN1xz7wY=.d2b1b4c8-c9b7-477d-901f-e8b89d35b2d9@github.com>

On Sun, 6 Nov 2022 22:14:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internalize FormatConcatItem
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 38:
> 
>> 36: 
>> 37: /**
>> 38:  * This {@linkplain ValidatingProcessor yemplate processor} constructs a String
> 
> Typo: "yemplate processor".

Changing

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

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

From jlaskey at openjdk.org  Wed Nov  9 22:55:44 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 22:55:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <gmSZZADjXMwU37RzrZ6NjacBL6WHwemrGm4NEIarXIY=.9b67d235-73fa-4b0e-a242-c7c151a8d435@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <gmSZZADjXMwU37RzrZ6NjacBL6WHwemrGm4NEIarXIY=.9b67d235-73fa-4b0e-a242-c7c151a8d435@github.com>
Message-ID: <CreDQvBE6-O2J8A18VRKoHTG7nPuyoCULO7nY0o44x0=.84c0e28f-8ded-4236-9ac6-809e08ce181b@github.com>

On Sun, 6 Nov 2022 22:15:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internalize FormatConcatItem
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 56:
> 
>> 54:  * to produce a more performant formatter.
>> 55:  *
>> 56:  * @implSpec Since, values are in situ, argument indexing is unsupported.
> 
> Please avoid Latin phrases like "in situ" in the javadoc.

Changing

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

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

From joehw at openjdk.org  Wed Nov  9 23:11:28 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 9 Nov 2022 23:11:28 GMT
Subject: <i18n dev> RFR: 8296715: CLDR v42 update for tzdata 2022f
In-Reply-To: <K4Kt0Xp8bYkrMUMu8VnCtptboDrkDT8l7svwRpAjzXU=.e139951b-bec6-4007-93ce-5e17b2d6f10d@github.com>
References: <K4Kt0Xp8bYkrMUMu8VnCtptboDrkDT8l7svwRpAjzXU=.e139951b-bec6-4007-93ce-5e17b2d6f10d@github.com>
Message-ID: <q9z_2phNEVzEWX155iy-tsySzelnnr49WsvLtqiph9Y=.2c4f669b-ee4c-4dea-81e0-3fd9c894df18@github.com>

On Wed, 9 Nov 2022 18:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Pick up the fix in the upstream CLDR v42 maintenance branch for their tzdata2022f changes.

Marked as reviewed by joehw (Reviewer).

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

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

From jlaskey at openjdk.org  Wed Nov  9 23:26:39 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 23:26:39 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <t7pb_AZz0_l7HTVre2FOdZ4cH4oxh6Qxwj8-41Y1eyc=.3234c14d-d170-4560-b986-8e53d25e0dba@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <nbA8ir9hwuMeATDFIii4CU5nMz8_bGUDh5vTRLNV6pc=.2a63344d-d723-4c94-9768-64dd6cd1b0fa@github.com>
 <t7pb_AZz0_l7HTVre2FOdZ4cH4oxh6Qxwj8-41Y1eyc=.3234c14d-d170-4560-b986-8e53d25e0dba@github.com>
Message-ID: <8rt4_oTHk-TqYvpbPDO4WzPGYHZroDXlbc2vbgCCKV0=.2ba76eb3-6c46-4d91-9262-7293da6168a2@github.com>

On Wed, 9 Nov 2022 22:42:29 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 299:
>> 
>>> 297:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>>> 298:      */
>>> 299:     public static String interpolate(List<String> fragments, List<Object> values) {
>> 
>> Should be `String interpolate(List<String> fragments, List<?> values) {` as above
>
> Changing

Have to backtrack short term. This change forces StringTemplate.values() to return List<?>. Will have to think this through (affects the JLS et al)

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

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

From jlaskey at openjdk.org  Wed Nov  9 23:41:41 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 23:41:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v14]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <6ixtWOJLlNS7SlOF1HOKzGE_O2prcZht_OO5koFX5TA=.a2efe47f-a381-4a26-864a-4f6a4d1e71db@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 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 28 additional commits since the last revision:

 - Merge branch 'master' into 8285932
 - Internalize FormatConcatItem
 - Requested changes #5
 - Internalize TemplateSupport
 - Requested changes #4
 - Requested changes #3
 - Merge branch 'master' into 8285932
 - Add @SafeVarargs declarations
 - Move template bootstrap
 - Requested changes #2
 - ... and 18 more: https://git.openjdk.org/jdk/compare/d0a14fab...c8412eb5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/b35ed665..c8412eb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=12-13

  Stats: 44455 lines in 484 files changed: 8506 ins; 33629 del; 2320 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  Wed Nov  9 23:48:57 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 23:48:57 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v15]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <hskkpP3c_A8mZLreQyPKV8OmiX0YcJmojlgwZ8GOQYI=.1782b23a-4756-4a1a-be8f-03ab60e0d70b@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:

  Switch from anonymous classes  to carrier based StringTemplate implementation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/c8412eb5..1af7dc15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=13-14

  Stats: 3438 lines in 30 files changed: 2670 ins; 688 del; 80 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  Wed Nov  9 23:49:01 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Nov 2022 23:49:01 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <zLdlvfKS_6jgWFuWW8sPCeI734i8VgMMYOJJo3szmlE=.7f78f8ee-60e5-4c8f-90e8-ee0e67cc2e42@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <zLdlvfKS_6jgWFuWW8sPCeI734i8VgMMYOJJo3szmlE=.7f78f8ee-60e5-4c8f-90e8-ee0e67cc2e42@github.com>
Message-ID: <OJr2aFekO3ZXnGv8sGgGBa-oaIGbUK6ytN9HblMS8N8=.1cd706a9-e2f5-4384-a0fa-5769d1ac5a98@github.com>

On Mon, 7 Nov 2022 18:12:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internalize FormatConcatItem
>
> src/java.base/share/classes/java/util/FormatItem.java line 540:
> 
>> 538:                 char ch = (char)getCharMH.invokeExact(buffer, start + i);
>> 539:                 putCharMH.invokeExact(buffer, start + i, (int)Character.toUpperCase(ch));
>> 540:             }
> 
> Some characters may produce multiple uppercase characters, such as "fi" ligature ('\ufb01' -> "FI"), also this should consider locale, e.g. the case for Turkish dotless i.

Switch to Formatter if upper selected

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

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

From jlaskey at openjdk.org  Thu Nov 10 00:04:49 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 10 Nov 2022 00:04:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v15]
In-Reply-To: <hskkpP3c_A8mZLreQyPKV8OmiX0YcJmojlgwZ8GOQYI=.1782b23a-4756-4a1a-be8f-03ab60e0d70b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <hskkpP3c_A8mZLreQyPKV8OmiX0YcJmojlgwZ8GOQYI=.1782b23a-4756-4a1a-be8f-03ab60e0d70b@github.com>
Message-ID: <SC7CdmgLxMaDVZs7MuV1jNvfqgxHx8h60rfLbs8bJx8=.f8ffd521-bb07-4261-9f15-d652be841a56@github.com>

On Wed, 9 Nov 2022 23:48:57 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:
> 
>   Switch from anonymous classes  to carrier based StringTemplate implementation

Interesting few days. Several reviewers have asked that I don't use anonymous classes to implement string templates; concern about producing lots of little classes. I dusted off the carrier code that I abandoned as non-performant and came up with an idea to make carriers faster (remove a level of indirection). The result is we can now use carriers for compiler generated string templates which can interpolate as fast as the anonymous classes and string concatenation. Now there is only two classes representing compiler generated string templates; one carrier based and one generic array based used when the number of values exceed method max arg count.  Along with this change is some significant clean up of the organization; more in line with other systems in the JDK.

Most of the files related to templates are now in java.lang.template (moved from jdk.internal). java.lang.template.TemplateSupport containing the template bootstrap methods is renamed to TemplateRuntime and moved to java.lang.runtime along with the other java.lang bootstrap classes. java.lang.template.TemplateRuntime is renamed to TemplateSupport to be more in line with what it represents.

Three new files, java.lang.template.Carriers, java.lang.template.ReferencedKeyMap and java.lang.template.ReferenceKey, have been added to support carriers.

I've integrated almost all your recommendations. Thank you for your reviews. Keep them coming. I hope this is the last major change required before preview.

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

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

From jjg at openjdk.org  Thu Nov 10 01:21:09 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 01:21:09 GMT
Subject: <i18n dev> RFR: JDK-8296547: Add @spec tags to API
Message-ID: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>

Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.

"Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.

"Normalized" means...
* Use `https:` where possible (includes pretty much all cases)
* Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
* Point to the root page of a multi-page spec
* Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)

In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.

The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.

That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.

Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.

To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/

In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

Commit messages:
 - JDK-8296547: Add @spec tags to API

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

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

From dfuchs at openjdk.org  Thu Nov 10 11:34:25 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Nov 2022 11:34:25 GMT
Subject: <i18n dev> RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Hi Jon,

When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:

http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html

External Specifications
    [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)

You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing.
Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.

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

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

From alanb at openjdk.org  Thu Nov 10 11:49:21 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Nov 2022 11:49:21 GMT
Subject: <i18n dev> RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>

On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:

I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example:

http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html

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

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

From alanb at openjdk.org  Thu Nov 10 12:04:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Nov 2022 12:04:51 GMT
Subject: <i18n dev> RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

I'm just trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same will spec linked from "See also" and "External Specifications", e.g.
http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY
so the `@see` ref can be dropped.

In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication?

There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs.

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

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

From jlaskey at openjdk.org  Thu Nov 10 15:09:14 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 10 Nov 2022 15:09:14 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v16]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <2YyIw9ZZ7H2Tj2yDWgNBZ8Uy31Q9OgIL_frX4O8o9BY=.b8603328-a6b4-4099-b67a-2cdb3487517b@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:

  Clean up new StringTemplate creation
  
  Centralized StringTemplate creation in StringTemplateImplFactory. Added consistent defensive copying of lists. Changed List<Object> to List<?> on StringTemplate.interpolate and StringTemplate.of.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/1af7dc15..39c63c01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=14-15

  Stats: 189 lines in 6 files changed: 103 ins; 52 del; 34 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  Thu Nov 10 15:09:16 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 10 Nov 2022 15:09:16 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v13]
In-Reply-To: <8rt4_oTHk-TqYvpbPDO4WzPGYHZroDXlbc2vbgCCKV0=.2ba76eb3-6c46-4d91-9262-7293da6168a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <nbA8ir9hwuMeATDFIii4CU5nMz8_bGUDh5vTRLNV6pc=.2a63344d-d723-4c94-9768-64dd6cd1b0fa@github.com>
 <t7pb_AZz0_l7HTVre2FOdZ4cH4oxh6Qxwj8-41Y1eyc=.3234c14d-d170-4560-b986-8e53d25e0dba@github.com>
 <8rt4_oTHk-TqYvpbPDO4WzPGYHZroDXlbc2vbgCCKV0=.2ba76eb3-6c46-4d91-9262-7293da6168a2@github.com>
Message-ID: <-EkZU7-ytGRcWsg3g5T9oCV1Kshru-Sjl-PZjRve1hI=.b902f3a2-71fc-42c4-8b90-1ddad398200b@github.com>

On Wed, 9 Nov 2022 23:24:32 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Changing
>
> Have to backtrack short term. This change forces StringTemplate.values() to return List<?>. Will have to think this through (affects the JLS et al)

Worked this through for both StringTemplate.of and StringTemplate.interpolate

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

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

From weijun at openjdk.org  Thu Nov 10 16:24:26 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 16:24:26 GMT
Subject: <i18n dev> RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <YsQZKL7FoweoqYLwGrMarDb92lTrfeAWksgmD2tTktc=.424afc93-1eb4-42ef-8f1a-81a9db5e000e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

I see https://www.ietf.org/rfc/rfc0822.html. Should be https://www.ietf.org/rfc/rfc822.html

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

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

From duke at openjdk.org  Thu Nov 10 16:35:32 2022
From: duke at openjdk.org (AJ1062910)
Date: Thu, 10 Nov 2022 16:35:32 GMT
Subject: <i18n dev> RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

did you changed 420 files ?

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

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

From forax at openjdk.org  Thu Nov 10 16:47:00 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 10 Nov 2022 16:47:00 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v16]
In-Reply-To: <2YyIw9ZZ7H2Tj2yDWgNBZ8Uy31Q9OgIL_frX4O8o9BY=.b8603328-a6b4-4099-b67a-2cdb3487517b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <2YyIw9ZZ7H2Tj2yDWgNBZ8Uy31Q9OgIL_frX4O8o9BY=.b8603328-a6b4-4099-b67a-2cdb3487517b@github.com>
Message-ID: <exLu2R6S2yNjUz143LPoHo1Pjt1bL0MBKq8PwFUNKBk=.aed2fb7a-0c54-4d6d-9a30-a86c9176f0d2@github.com>

On Thu, 10 Nov 2022 15:09: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).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up new StringTemplate creation
>   
>   Centralized StringTemplate creation in StringTemplateImplFactory. Added consistent defensive copying of lists. Changed List<Object> to List<?> on StringTemplate.interpolate and StringTemplate.of.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 36:

> 34: import java.lang.template.StringTemplate;
> 35: import java.lang.template.ValidatingProcessor;
> 36: import java.util.*;

They come back :)

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

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

From naoto at openjdk.org  Thu Nov 10 16:54:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Nov 2022 16:54:41 GMT
Subject: <i18n dev> Integrated: 8296715: CLDR v42 update for tzdata 2022f
In-Reply-To: <K4Kt0Xp8bYkrMUMu8VnCtptboDrkDT8l7svwRpAjzXU=.e139951b-bec6-4007-93ce-5e17b2d6f10d@github.com>
References: <K4Kt0Xp8bYkrMUMu8VnCtptboDrkDT8l7svwRpAjzXU=.e139951b-bec6-4007-93ce-5e17b2d6f10d@github.com>
Message-ID: <a3B8wqZcnY4tLv-UPhTNXvhufq74mk874vJVPyMqJEc=.0b5b8b02-06a1-4537-9e56-3e870ca4ec1e@github.com>

On Wed, 9 Nov 2022 18:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Pick up the fix in the upstream CLDR v42 maintenance branch for their tzdata2022f changes.

This pull request has now been integrated.

Changeset: 54c986e7
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54c986e7d5d0b48a22b4da81c13153ce431c9f2f
Stats:     16 lines in 6 files changed: 6 ins; 6 del; 4 mod

8296715: CLDR v42 update for tzdata 2022f

Reviewed-by: joehw

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

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

From jlaskey at openjdk.org  Thu Nov 10 17:08:54 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 10 Nov 2022 17:08:54 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v16]
In-Reply-To: <exLu2R6S2yNjUz143LPoHo1Pjt1bL0MBKq8PwFUNKBk=.aed2fb7a-0c54-4d6d-9a30-a86c9176f0d2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <2YyIw9ZZ7H2Tj2yDWgNBZ8Uy31Q9OgIL_frX4O8o9BY=.b8603328-a6b4-4099-b67a-2cdb3487517b@github.com>
 <exLu2R6S2yNjUz143LPoHo1Pjt1bL0MBKq8PwFUNKBk=.aed2fb7a-0c54-4d6d-9a30-a86c9176f0d2@github.com>
Message-ID: <FYIJaQAcLmhfbmT4keLTcai_lVr6GAh711hslxGTMl0=.b6296945-16d6-4c50-a61e-2d9095ca6ad9@github.com>

On Thu, 10 Nov 2022 16:44:18 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:
>> 
>>   Clean up new StringTemplate creation
>>   
>>   Centralized StringTemplate creation in StringTemplateImplFactory. Added consistent defensive copying of lists. Changed List<Object> to List<?> on StringTemplate.interpolate and StringTemplate.of.
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 36:
> 
>> 34: import java.lang.template.StringTemplate;
>> 35: import java.lang.template.ValidatingProcessor;
>> 36: import java.util.*;
> 
> They come back :)

Should turn off that inspector. Changing.

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

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

From jlaskey at openjdk.org  Thu Nov 10 17:42:04 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 10 Nov 2022 17:42:04 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v17]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@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:

  Requested changes #5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/39c63c01..ac5402ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=15-16

  Stats: 13 lines in 3 files changed: 9 ins; 0 del; 4 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 jvernee at openjdk.org  Thu Nov 10 19:56:45 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 10 Nov 2022 19:56:45 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v17]
In-Reply-To: <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
Message-ID: <YtZ2Fv61doGFp-3geUfZm1q7WBoxHRCMmT7nnEqSkq0=.ce04d56a-f157-4bf6-8899-1f1ac5e3da95@github.com>

On Thu, 10 Nov 2022 17:42:04 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:
> 
>   Requested changes #5

src/java.base/share/classes/java/lang/template/Carriers.java line 415:

> 413:          */
> 414:         @Stable
> 415:         private final Object[] objects;

Looking at all this, I'm skeptical that carriers are worth the complexity for the performance gain they give. AFAICS the fast paths for `FMT` and `STR` avoid boxing values into a StringTemplate instance altogether. So carriers only seem to help cases where processing goes through the default `process` method on a user-defined processor?

AFAIK `@Stable` will not do anything here. It only helps constant folding from a constant root object and in general StringTemplate instances are not constant. (and, AFAIK there are also JIT caveats with storing everything in arrays like this).

I suggest maybe keeping things simple in this PR, and having a `StringTemplateImpl` with just a `List<Object>` for the values. Public support for the linkage-based fast path can be used to avoid the boxing for user defined processors in the future as well, and that seems like a much better way to get performance to me.

If carriers are added to improve performance, I'd personally like to see that in a separate PR that's only focused on that, with more benchmarks/bench marking results included as well.

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

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

From mullan at openjdk.org  Thu Nov 10 21:34:30 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 21:34:30 GMT
Subject: <i18n dev> RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
Message-ID: <9dD51N9kpu4MV5_oJ1e6lxsYLxnk6mG5mQeH_SAzWqA=.71dcec22-0ad2-41f2-89e3-8c9964db61cb@github.com>

On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When referencing an RFC, it might be good to keep the RFC number in the text link.

+1.

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

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

From jjg at openjdk.org  Thu Nov 10 21:58:28 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 21:58:28 GMT
Subject: <i18n dev> RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>

On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Jon,
> 
> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
> 
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html
> 
> External Specifications [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)
> 
> You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing. Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.

On keeping RFC in the title, I'll go with the team preference. I note that not all spec authorities have such a well-defined naming/numbering scheme, so it does make the summary page a bit inconsistent. Also, the entries under "R" dominate the list, which may not be what you want.

On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec.

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

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

From jjg at openjdk.org  Thu Nov 10 22:03:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:03:32 GMT
Subject: <i18n dev> RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
Message-ID: <jribbsj15UipAgtqxLmb156zaVOdJJU4zaukxrE-8Bg=.7b4f4219-ceb9-4173-a341-6d6fe2229ddd@github.com>

On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
> 
> I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example:
> 
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html

I can change the doclet to use a bulleted list when any spec titles contain a comma.

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

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

From jjg at openjdk.org  Thu Nov 10 22:11:30 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:11:30 GMT
Subject: <i18n dev> RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>
Message-ID: <K4Z5QVATg9JlpZKp2HyIaHcMz_u24yhBOmw7RFkVmMo=.58dbad2c-e6cb-4fa5-857b-8c5bfb5007f0@github.com>

On Thu, 10 Nov 2022 12:01:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same spec will be linked from "See also" and "External Specifications", e.g. http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY so the `@see` ref can be dropped.
> 
> In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication?
> 
> There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs.

The utility I mentioned has the (optional) ability to remove `@see` links when the text of the link exactly matches that used by the `@spec` tag.  Unfortunately, the text is typically not exactly the same, and would require manual analysis to see if the `@see` tag can be removed.

When inline references are used, the wording is very rarely the primary title of the spec: it is more likely to be a word or phrase that makes sense in the context of the enclosing sentence.

_History: version 1 of this feature tried replacing inline links and `@see` tags with a bi-modal `@spec` tag. The results were "not good", especially in the generated external-specs page.  Version 2 used a side file to provide the definitive title for each spec, but that was deemed to be too much of a maintenance issue. This is version 3, in which we've eliminated the side-file in favor of duplicating the title in each `@spec` tag._

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

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

From jjg at openjdk.org  Thu Nov 10 22:19:26 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:19:26 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API
In-Reply-To: <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>
Message-ID: <Dt2pqnepgR8UMT5ypzYkvgJRKKxNg8K8m-vu3OdEFg4=.2c04027c-f939-4972-8eca-345fc6f923bc@github.com>

On Thu, 10 Nov 2022 16:33:09 GMT, AJ1062910 <duke at openjdk.org> wrote:

> did you changed 420 files ?

I ran a custom utility that edited these files, yes.

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

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

From jlaskey at openjdk.org  Thu Nov 10 22:59:03 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 10 Nov 2022 22:59:03 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v17]
In-Reply-To: <YtZ2Fv61doGFp-3geUfZm1q7WBoxHRCMmT7nnEqSkq0=.ce04d56a-f157-4bf6-8899-1f1ac5e3da95@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
 <YtZ2Fv61doGFp-3geUfZm1q7WBoxHRCMmT7nnEqSkq0=.ce04d56a-f157-4bf6-8899-1f1ac5e3da95@github.com>
Message-ID: <AqHX1wRzucnFAw9AJ-fXpu-T7FFH_rlFntiAGX-or-U=.2cf0bb68-aaf4-4545-8985-62f007988911@github.com>

On Thu, 10 Nov 2022 19:54:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Requested changes #5
>
> src/java.base/share/classes/java/lang/template/Carriers.java line 415:
> 
>> 413:          */
>> 414:         @Stable
>> 415:         private final Object[] objects;
> 
> Looking at all this, I'm skeptical that carriers are worth the complexity for the performance gain they give. AFAICS the fast paths for `FMT` and `STR` avoid boxing values into a StringTemplate instance altogether. So carriers only seem to help cases where processing goes through the default `process` method on a user-defined processor?
> 
> AFAIK `@Stable` will not do anything here. It only helps constant folding from a constant root object and in general StringTemplate instances are not constant. (and, AFAIK there are also JIT caveats with storing everything in arrays like this).
> 
> I suggest maybe keeping things simple in this PR, and having just `SimpleStringTemplate`. Public support for the linkage-based fast path can be used to avoid the boxing for user defined processors in the future as well, and that seems like a much better way to get performance to me.
> 
> If carriers are added to improve performance, I'd personally like to see that in a separate PR that's only focused on that, with more benchmarks/bench marking results included as well.

Fair comment. Initially, 99% of template processing will be through `STR``. However, that
will likely change as libraries expand to include template processing. In fact, creating
processors is so trivially easy that users will likely start using template processing for
every day tasks.

During the preview, string templates will be evaluatedby Java influencers for use in
future applications. If we come out of the gate with a less than stellar feature
then string templates will not gain traction.

Several reviewers, including most of the compiler team, had a problem with the use of
anonymous classes for each and every string template. Carriers were introduced as an
alternative. The fact that they perform well is an added bonus. Note Carriers are not a
last minute thing. I've been using them off/on for much of the project.

Carriers also have a place in future planned projects. It was Brian that inspired the idea.

Carriers, as well as the FormatProcessor, are indeed projects unto themselves, but are a
important part of the string template project. Breaking those projects out separately
would risk not making preview. It's important to get these classes tested in real use
cases during preview. In the balance, as you indicated, STR and FMT are the show. Carriers
are low risk with big win.

The linkage stuff will likely dissolve into something that doesn't require a lot of 
MethodHandle experience, something like a TemplateProcessorFactory.

I whipped up a trivial JMH benchmark to give a sense of Carrier worth. Note I'm not a
performance engineer and milage may vary, but this will give you the sense of degree
difference between Carriers and a list implementation.



public class MyBenchmark {
    // Declared globally to spoil optimization.
    static int x = 10, y = 20;
    static String result;
    static StringProcessor INTERPOLATE = st -> st.interpolate();
    static List<String> FRAGMENTS = List.of("", " + ", " = ", "");

    // String concatenation as a baseline.
    @Benchmark
    public void concat() {
        result = x + " + " + y + " = " + (x + y);
    }

    // STR is effectively String concatenation.
    @Benchmark
    public void str() {
        result = STR."{x} + {y} = {x + y}";
    }

    // StringTemplate using a carrier and thus the constructed interpolate.
    @Benchmark
    public void carrier() {
        result = INTERPOLATE."{x} + {y} = {x + y}";
    }

    // StringTemplates using lists for fragments and values. 
    // Note that FRAGMENTS is only constructed once as it would be in the wilds.
    @Benchmark
    public void lists() {
        StringTemplate st = StringTemplate.of(FRAGMENTS, List.of(x, y, x + y));
        result = st.interpolate();
    }

    // Formatting can be effectively String concatenation.
    @Benchmark
    public void format() {
        result = FMT."%d{x} + %d{y} = %d{x + y}";
    }

}




Benchmark                   Mode  Cnt         Score         Error  Units
MyBenchmark.concat         thrpt   25  52570142.770 ? 5373985.927  ops/s
MyBenchmark.str            thrpt   25  52569879.770 ? 2787317.140  ops/s
MyBenchmark.carrier        thrpt   25  54161402.682 ? 4587727.795  ops/s
MyBenchmark.lists          thrpt   25   9260123.476 ?  189741.261  ops/s
MyBenchmark.format         thrpt   25  50847393.625 ?  135673.614  ops/s


Thanks for pointing out the @Stable issue.

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

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

From naoto at openjdk.org  Thu Nov 10 23:55:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Nov 2022 23:55:34 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

src/java.base/share/classes/java/lang/Character.java line 172:

> 170:  * occur. For example, in a future release, synchronization may fail.
> 171:  *
> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0

This should probably be removed, as the original link (explaining `U+n` notation) is broken.

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

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

From jvernee at openjdk.org  Fri Nov 11 00:57:44 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 11 Nov 2022 00:57:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v17]
In-Reply-To: <AqHX1wRzucnFAw9AJ-fXpu-T7FFH_rlFntiAGX-or-U=.2cf0bb68-aaf4-4545-8985-62f007988911@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
 <YtZ2Fv61doGFp-3geUfZm1q7WBoxHRCMmT7nnEqSkq0=.ce04d56a-f157-4bf6-8899-1f1ac5e3da95@github.com>
 <AqHX1wRzucnFAw9AJ-fXpu-T7FFH_rlFntiAGX-or-U=.2cf0bb68-aaf4-4545-8985-62f007988911@github.com>
Message-ID: <t785BhHdz-JoFGRBaYU4Xdf0dL8qQ4H5luTZzWMK970=.ef9f6858-1f20-4548-970e-a00218924c47@github.com>

On Thu, 10 Nov 2022 22:56:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/Carriers.java line 415:
>> 
>>> 413:          */
>>> 414:         @Stable
>>> 415:         private final Object[] objects;
>> 
>> Looking at all this, I'm skeptical that carriers are worth the complexity for the performance gain they give. AFAICS the fast paths for `FMT` and `STR` avoid boxing values into a StringTemplate instance altogether. So carriers only seem to help cases where processing goes through the default `process` method on a user-defined processor?
>> 
>> AFAIK `@Stable` will not do anything here. It only helps constant folding from a constant root object and in general StringTemplate instances are not constant. (and, AFAIK there are also JIT caveats with storing everything in arrays like this).
>> 
>> I suggest maybe keeping things simple in this PR, and having just `SimpleStringTemplate`. Public support for the linkage-based fast path can be used to avoid the boxing for user defined processors in the future as well, and that seems like a much better way to get performance to me.
>> 
>> If carriers are added to improve performance, I'd personally like to see that in a separate PR that's only focused on that, with more benchmarks/bench marking results included as well.
>
> Fair comment. Initially, 99% of template processing will be through `STR``. However, that
> will likely change as libraries expand to include template processing. In fact, creating
> processors is so trivially easy that users will likely start using template processing for
> every day tasks.
> 
> During the preview, string templates will be evaluatedby Java influencers for use in
> future applications. If we come out of the gate with a less than stellar feature
> then string templates will not gain traction.
> 
> Several reviewers, including most of the compiler team, had a problem with the use of
> anonymous classes for each and every string template. Carriers were introduced as an
> alternative. The fact that they perform well is an added bonus. Note Carriers are not a
> last minute thing. I've been using them off/on for much of the project.
> 
> Carriers also have a place in future planned projects. It was Brian that inspired the idea.
> 
> Carriers, as well as the FormatProcessor, are indeed projects unto themselves, but are a
> important part of the string template project. Breaking those projects out separately
> would risk not making preview. It's important to get these classes tested in real use
> cases during preview. In the balance, as you indicated, STR and FMT are the show. Carriers
> are low risk with big win.
> 
> The linkage stuff will likely dissolve into something that doesn't require a lot of 
> MethodHandle experience, something like a TemplateProcessorFactory.
> 
> I whipped up a trivial JMH benchmark to give a sense of Carrier worth. Note I'm not a
> performance engineer and milage may vary, but this will give you the sense of degree
> difference between Carriers and a list implementation.
> 
> 
> 
> public class MyBenchmark {
>     // Declared globally to spoil optimization.
>     static int x = 10, y = 20;
>     static String result;
>     static StringProcessor INTERPOLATE = st -> st.interpolate();
>     static List<String> FRAGMENTS = List.of("", " + ", " = ", "");
> 
>     // String concatenation as a baseline.
>     @Benchmark
>     public void concat() {
>         result = x + " + " + y + " = " + (x + y);
>     }
> 
>     // STR is effectively String concatenation.
>     @Benchmark
>     public void str() {
>         result = STR."{x} + {y} = {x + y}";
>     }
> 
>     // StringTemplate using a carrier and thus the constructed interpolate.
>     @Benchmark
>     public void carrier() {
>         result = INTERPOLATE."{x} + {y} = {x + y}";
>     }
> 
>     // StringTemplates using lists for fragments and values. 
>     // Note that FRAGMENTS is only constructed once as it would be in the wilds.
>     @Benchmark
>     public void lists() {
>         StringTemplate st = StringTemplate.of(FRAGMENTS, List.of(x, y, x + y));
>         result = st.interpolate();
>     }
> 
>     // Formatting can be effectively String concatenation.
>     @Benchmark
>     public void format() {
>         result = FMT."%d{x} + %d{y} = %d{x + y}";
>     }
> 
> }
> 
> 
> 
> 
> Benchmark                   Mode  Cnt         Score         Error  Units
> MyBenchmark.concat         thrpt   25  52570142.770 ? 5373985.927  ops/s
> MyBenchmark.str            thrpt   25  52569879.770 ? 2787317.140  ops/s
> MyBenchmark.carrier        thrpt   25  54161402.682 ? 4587727.795  ops/s
> MyBenchmark.lists          thrpt   25   9260123.476 ?  189741.261  ops/s
> MyBenchmark.format         thrpt   25  50847393.625 ?  135673.614  ops/s
> 
> 
> Thanks for pointing out the @Stable issue.

Thanks, I think benchmarks like this are useful. The `interpolate()` case is not something I considered when I made my earlier comment. Please add any benchmarks to the patch as well, so that performance experiments can be  reliably reproduced.

I think what this benchmark mainly shows is the benefit of carriers in combination with the instance `interpolate()` method. I expect most custom string processors will interact with string template instances through the `fragments()` and `values()` methods, though (I don't think there is an alternative?). i.e. in the end, we still end up boxing everything into a couple of lists any ways. `interpolate()` also has another leg up in that it knows the shape of the template when the string template instance is constructed, and can use a specialized method handle to do the processing.

If I change the benchmark to rely on the `fragments()` and `values()` accessors (which I think the majority/all of the custom processor will have to do), for instance by using `st -> StringTemplate.interpolate(st.fragments(), st.values())` as a custom processor, and I tweak `StringTemplateImplFactory::newStringTemplate` to use `List::copyOf` instead of the stream it uses now [1], then the list based implementation is slightly faster than the carriers based implementation on my machine:


Benchmark              Mode  Cnt   Score   Error  Units
Carriers.carrier       avgt   15  69.946 ? 0.599  ns/op
Carriers.carrier_inst  avgt   15  15.014 ? 0.106  ns/op
Carriers.concat        avgt   15   8.441 ? 0.021  ns/op
Carriers.format        avgt   15   9.314 ? 0.172  ns/op
Carriers.lists         avgt   15  61.131 ? 0.401  ns/op
Carriers.str           avgt   15   8.547 ? 0.145  ns/op


It makes me wonder if carriers are worth it at this stage (hard to say...), or if it's better to go all-in on custom linkage, which should give custom processors performance that is comparable with `STR` and `FMT`.

Maybe the instance `interpolate()` method is an important enough use-case to add carriers though. I can't really say.

I appreciate the fact that carriers will see use in future projects as well, but at face value, it doesn't seem like they add that much for string templates (rather, on the contrary in some cases it seems).

[1]: http://cr.openjdk.java.net/~jvernee/bench.diff

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

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

From jlaskey at openjdk.org  Fri Nov 11 01:43:57 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 11 Nov 2022 01:43:57 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v17]
In-Reply-To: <t785BhHdz-JoFGRBaYU4Xdf0dL8qQ4H5luTZzWMK970=.ef9f6858-1f20-4548-970e-a00218924c47@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
 <YtZ2Fv61doGFp-3geUfZm1q7WBoxHRCMmT7nnEqSkq0=.ce04d56a-f157-4bf6-8899-1f1ac5e3da95@github.com>
 <AqHX1wRzucnFAw9AJ-fXpu-T7FFH_rlFntiAGX-or-U=.2cf0bb68-aaf4-4545-8985-62f007988911@github.com>
 <t785BhHdz-JoFGRBaYU4Xdf0dL8qQ4H5luTZzWMK970=.ef9f6858-1f20-4548-970e-a00218924c47@github.com>
Message-ID: <Q-_kZipk2tT3zoSRBfS5iMtuQTcq35_GUDxTCyPbQyI=.2d1b0abb-a10f-40fb-9b7f-a87aa9eb30ef@github.com>

On Fri, 11 Nov 2022 00:55:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Fair comment. Initially, 99% of template processing will be through `STR``. However, that
>> will likely change as libraries expand to include template processing. In fact, creating
>> processors is so trivially easy that users will likely start using template processing for
>> every day tasks.
>> 
>> During the preview, string templates will be evaluatedby Java influencers for use in
>> future applications. If we come out of the gate with a less than stellar feature
>> then string templates will not gain traction.
>> 
>> Several reviewers, including most of the compiler team, had a problem with the use of
>> anonymous classes for each and every string template. Carriers were introduced as an
>> alternative. The fact that they perform well is an added bonus. Note Carriers are not a
>> last minute thing. I've been using them off/on for much of the project.
>> 
>> Carriers also have a place in future planned projects. It was Brian that inspired the idea.
>> 
>> Carriers, as well as the FormatProcessor, are indeed projects unto themselves, but are a
>> important part of the string template project. Breaking those projects out separately
>> would risk not making preview. It's important to get these classes tested in real use
>> cases during preview. In the balance, as you indicated, STR and FMT are the show. Carriers
>> are low risk with big win.
>> 
>> The linkage stuff will likely dissolve into something that doesn't require a lot of 
>> MethodHandle experience, something like a TemplateProcessorFactory.
>> 
>> I whipped up a trivial JMH benchmark to give a sense of Carrier worth. Note I'm not a
>> performance engineer and milage may vary, but this will give you the sense of degree
>> difference between Carriers and a list implementation.
>> 
>> 
>> 
>> public class MyBenchmark {
>>     // Declared globally to spoil optimization.
>>     static int x = 10, y = 20;
>>     static String result;
>>     static StringProcessor INTERPOLATE = st -> st.interpolate();
>>     static List<String> FRAGMENTS = List.of("", " + ", " = ", "");
>> 
>>     // String concatenation as a baseline.
>>     @Benchmark
>>     public void concat() {
>>         result = x + " + " + y + " = " + (x + y);
>>     }
>> 
>>     // STR is effectively String concatenation.
>>     @Benchmark
>>     public void str() {
>>         result = STR."{x} + {y} = {x + y}";
>>     }
>> 
>>     // StringTemplate using a carrier and thus the constructed interpolate.
>>     @Benchmark
>>     public void carrier() {
>>         result = INTERPOLATE."{x} + {y} = {x + y}";
>>     }
>> 
>>     // StringTemplates using lists for fragments and values. 
>>     // Note that FRAGMENTS is only constructed once as it would be in the wilds.
>>     @Benchmark
>>     public void lists() {
>>         StringTemplate st = StringTemplate.of(FRAGMENTS, List.of(x, y, x + y));
>>         result = st.interpolate();
>>     }
>> 
>>     // Formatting can be effectively String concatenation.
>>     @Benchmark
>>     public void format() {
>>         result = FMT."%d{x} + %d{y} = %d{x + y}";
>>     }
>> 
>> }
>> 
>> 
>> 
>> 
>> Benchmark                   Mode  Cnt         Score         Error  Units
>> MyBenchmark.concat         thrpt   25  52570142.770 ? 5373985.927  ops/s
>> MyBenchmark.str            thrpt   25  52569879.770 ? 2787317.140  ops/s
>> MyBenchmark.carrier        thrpt   25  54161402.682 ? 4587727.795  ops/s
>> MyBenchmark.lists          thrpt   25   9260123.476 ?  189741.261  ops/s
>> MyBenchmark.format         thrpt   25  50847393.625 ?  135673.614  ops/s
>> 
>> 
>> Thanks for pointing out the @Stable issue.
>
> Thanks, I think benchmarks like this are useful. The `interpolate()` case is not something I considered when I made my earlier comment. Please add any benchmarks to the patch as well, so that performance experiments can be  reliably reproduced.
> 
> I think what this benchmark mainly shows is the benefit of carriers in combination with the instance `interpolate()` method. I expect most custom string processors will interact with string template instances through the `fragments()` and `values()` methods, though (I don't think there is an alternative?). i.e. in the end, we still end up boxing everything into a couple of lists any ways. `interpolate()` also has another leg up in that it knows the shape of the template when the string template instance is constructed, and can use a specialized method handle to do the processing.
> 
> If I change the benchmark to rely on the `fragments()` and `values()` accessors (which I think the majority/all of the custom processor will have to do), for instance by using `st -> StringTemplate.interpolate(st.fragments(), st.values())` as a custom processor, and I tweak `StringTemplateImplFactory::newStringTemplate` to use `List::copyOf` instead of the stream it uses now ([1]), then the list based implementation is slightly faster than the carriers based implementation on my machine:
> 
> 
> Benchmark              Mode  Cnt   Score   Error  Units
> Carriers.carrier       avgt   15  69.946 ? 0.599  ns/op
> Carriers.carrier_inst  avgt   15  15.014 ? 0.106  ns/op
> Carriers.concat        avgt   15   8.441 ? 0.021  ns/op
> Carriers.format        avgt   15   9.314 ? 0.172  ns/op
> Carriers.lists         avgt   15  61.131 ? 0.401  ns/op
> Carriers.str           avgt   15   8.547 ? 0.145  ns/op
> 
> 
> It makes me wonder if carriers are worth it at this stage (hard to say... performance is usually a long string to pull), or if it's better to go all-in on custom linkage, which should give custom processors performance that is comparable with `STR` and `FMT`.
> 
> Maybe the instance `interpolate()` method is an important enough use-case to add carriers though. I can't really say.
> 
> I appreciate the fact that carriers will see use in future projects as well, but at face value, it doesn't seem like they add that much for string templates (rather, on the contrary in some cases it seems).
> 
> [1]: http://cr.openjdk.java.net/~jvernee/bench.diff

Something like a StringProcessorFactory could produce the same structures as as interpolate without the boxing issues.

There are generally two main types of processors (there are others but they would require specialization anyway). The first type doesn't really care about the construction of the string. It just wants to get the interpolation and work with the result. A JSON processor might fall into that category. 

The second type wants to transform (MH filter args) the fragments or the values or both and then get an interpolation (and maybe work with that result). This is where the StringProcessorFactory would kick in and automate the process and in the end get similar performance as interpolate. No lists or boxing. A formatter processor might fall into that category. 

What I think you are really objecting to is the existence of StringTemplate objects. Why not just BSM everything?  The problem is that processors can be swapped out and can have state. So you need a user model where the what object (StringTemplate) is separate from the how object (TemplateProcessor).

Try working through some examples and it will become clearer.

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

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

From jvernee at openjdk.org  Fri Nov 11 02:43:46 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 11 Nov 2022 02:43:46 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v17]
In-Reply-To: <Q-_kZipk2tT3zoSRBfS5iMtuQTcq35_GUDxTCyPbQyI=.2d1b0abb-a10f-40fb-9b7f-a87aa9eb30ef@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
 <YtZ2Fv61doGFp-3geUfZm1q7WBoxHRCMmT7nnEqSkq0=.ce04d56a-f157-4bf6-8899-1f1ac5e3da95@github.com>
 <AqHX1wRzucnFAw9AJ-fXpu-T7FFH_rlFntiAGX-or-U=.2cf0bb68-aaf4-4545-8985-62f007988911@github.com>
 <t785BhHdz-JoFGRBaYU4Xdf0dL8qQ4H5luTZzWMK970=.ef9f6858-1f20-4548-970e-a00218924c47@github.com>
 <Q-_kZipk2tT3zoSRBfS5iMtuQTcq35_GUDxTCyPbQyI=.2d1b0abb-a10f-40fb-9b7f-a87aa9eb30ef@github.com>
Message-ID: <jaokyvaqJE-upcGTA5bgEZ9die1Gc0QfrlmiV0oGxdU=.ea970a5a-4852-4865-a112-2a261de5b08f@github.com>

On Fri, 11 Nov 2022 01:41:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Thanks, I think benchmarks like this are useful. The `interpolate()` case is not something I considered when I made my earlier comment. Please add any benchmarks to the patch as well, so that performance experiments can be  reliably reproduced.
>> 
>> I think what this benchmark mainly shows is the benefit of carriers in combination with the instance `interpolate()` method. I expect most custom string processors will interact with string template instances through the `fragments()` and `values()` methods, though (I don't think there is an alternative?). i.e. in the end, we still end up boxing everything into a couple of lists any ways. `interpolate()` also has another leg up in that it knows the shape of the template when the string template instance is constructed, and can use a specialized method handle to do the processing.
>> 
>> If I change the benchmark to rely on the `fragments()` and `values()` accessors (which I think the majority/all of the custom processor will have to do), for instance by using `st -> StringTemplate.interpolate(st.fragments(), st.values())` as a custom processor, and I tweak `StringTemplateImplFactory::newStringTemplate` to use `List::copyOf` instead of the stream it uses now ([1]), then the list based implementation is slightly faster than the carriers based implementation on my machine:
>> 
>> 
>> Benchmark              Mode  Cnt   Score   Error  Units
>> Carriers.carrier       avgt   15  69.946 ? 0.599  ns/op
>> Carriers.carrier_inst  avgt   15  15.014 ? 0.106  ns/op
>> Carriers.concat        avgt   15   8.441 ? 0.021  ns/op
>> Carriers.format        avgt   15   9.314 ? 0.172  ns/op
>> Carriers.lists         avgt   15  61.131 ? 0.401  ns/op
>> Carriers.str           avgt   15   8.547 ? 0.145  ns/op
>> 
>> 
>> It makes me wonder if carriers are worth it at this stage (hard to say... performance is usually a long string to pull), or if it's better to go all-in on custom linkage, which should give custom processors performance that is comparable with `STR` and `FMT`.
>> 
>> Maybe the instance `interpolate()` method is an important enough use-case to add carriers though. I can't really say.
>> 
>> I appreciate the fact that carriers will see use in future projects as well, but at face value, it doesn't seem like they add that much for string templates (rather, on the contrary in some cases it seems).
>> 
>> [1]: http://cr.openjdk.java.net/~jvernee/bench.diff
>
> Something like a StringProcessorFactory could produce the same structures as as interpolate without the boxing issues.
> 
> There are generally two main types of processors (there are others but they would require specialization anyway). The first type doesn't really care about the construction of the string. It just wants to get the interpolation and work with the result. A JSON processor might fall into that category. 
> 
> The second type wants to transform (MH filter args) the fragments or the values or both and then get an interpolation (and maybe work with that result). This is where the StringProcessorFactory would kick in and automate the process and in the end get similar performance as interpolate. No lists or boxing. A formatter processor might fall into that category. 
> 
> What I think you are really objecting to is the existence of StringTemplate objects. Why not just BSM everything?  The problem is that processors can be swapped out and can have state. So you need a user model where the what object (StringTemplate) is separate from the how object (TemplateProcessor).
> 
> Try working through some examples and it will become clearer.

I guess I'm not sure what you have in mind with `StringProcessorFactory`, but I think it's starting to become clearer. I expected it to return a method handle that took all the dynamic values as arguments (similar to the callsites return by the current BSMs), i.e. it would completely bypass `StringTemplate`, but it sounds like it will instead take just a `StringTemplate` instance as argument?

In that case carriers make sense to me, as the accesses to the fragments and values would be funneled through the StringTemplate instance, and a StringProcessorFactory could generate 'sharp' accesses to those values (rather than going through `StringTemplate::fragments()` and `StringTemplate::values()`, which would box things into lists any ways).

Thanks

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

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

From cjplummer at openjdk.org  Fri Nov 11 04:18:30 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Nov 2022 04:18:30 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <FVrTbaSxMtpBDeg9b-elYkMoCM_M72PLSAQGVplwe1Q=.44879b38-e84d-436d-a23c-43f2522acf9e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/Connection.java line 105:

> 103:      *          If the length of the packet (as indictaed by the first
> 104:      *          4 bytes) is less than 11 bytes, or an I/O error occurs.
> 105:      * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/com/sun/jdi/connect/spi/Connection.html#readPacket()

Within this javadoc page the jdwp-spec.html references are titled "JDWP Specification", but these `@spec` references are titled "Java Debug Wire Protocol". I suggest making them more consistent. There is one more case below and this same issue also applies to TransportService.java. Perhaps the title in jdwp-spec.html should be updated. I think "Java Debug Wire Protocol (JDWP) Specification" would be good.

src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java line 79:

> 77:  * target VM.
> 78:  *
> 79:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol

See above comment for Connection.java.

src/jdk.jdi/share/classes/module-info.java line 107:

> 105:  *
> 106:  *
> 107:  * @spec jpda/jpda.html Java Platform Debugger Architecture

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/module-summary.html

`@spec` and `@see` sections end up one right after the other with the same content, except the `@see` section has the preferred hyperlink title. Suggest you remove the `@see` section and also update `@spec` hyperlink title to include "(JPDA)", or update the actual title in the jpda.html doc so it includes "(JPDA)" in it and then rerun your tool.

src/jdk.jdwp.agent/share/classes/module-info.java line 30:

> 28:  *
> 29:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 30:  * @spec jdwp/jdwp-transport.html Java Debug Wire Protocol Transport Interface (jdwpTransport)

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdwp.agent/module-summary.html

The end result here is not very clean. You have the same two specs being referred to just a few lines apart, and the hyperlink titles are not even close to be the same, even though the links are the same. Maybe the "@see" section should be removed.

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

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

From dfuchs at openjdk.org  Fri Nov 11 10:29:33 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 10:29:33 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API
In-Reply-To: <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>
Message-ID: <WspQupF8fnStNO87pH42-2xTdbEwWYmiAcWuG2m3PSQ=.2d639a08-534c-4e41-aef9-287e4ab11a54@github.com>

On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec.

It's not uncommon for a newer version of a RFC to change its number but keep its title. I see that the links in the class level API documentation both have the RFC number in their link text. Somehow that was stripped by your tool - possibly because it tried to extract some meta information from the linked page itself?

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

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

From lancea at openjdk.org  Fri Nov 11 11:49:32 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 11 Nov 2022 11:49:32 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Hi Jon,

I only looked at the jar specific updates but there is some duplication leftovers.

It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs

src/java.base/share/classes/java/util/jar/Attributes.java line 58:

> 56:  * order that keys were inserted into the map, as with {@link LinkedHashMap}.
> 57:  *
> 58:  * @spec jar/jar.html JAR File Specification

Line 52 should be removed

src/java.base/share/classes/java/util/jar/Attributes.java line 450:

> 448:      * <a href="{@docRoot}/../specs/jar/jar.html">JAR File Specification</a>
> 449:      * for more information about valid attribute names and values.
> 450:      * @spec jar/jar.html JAR File Specification

Line 448 should be removed

src/java.base/share/classes/java/util/jar/Manifest.java line 47:

> 45:  * Manifest format specification</a>.
> 46:  *
> 47:  * @spec jar/jar.html JAR File Specification

Line 44 should be removed

src/java.base/share/classes/java/util/jar/package-info.java line 47:

> 45:  * </ul>
> 46:  *
> 47:  * @spec jar/jar.html JAR File Specification

Line 43 should be removed

src/java.base/share/classes/java/util/zip/package-info.java line 75:

> 73:  * </ul>
> 74:  *
> 75:  * @spec https://www.ietf.org/rfc/rfc1951.html DEFLATE Compressed Data Format Specification version 1.3

The above references should be removed as they duplicate the` @spec` tags

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

Changes requested by lancea (Reviewer).

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

From dfuchs at openjdk.org  Fri Nov 11 12:01:42 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 12:01:42 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API
In-Reply-To: <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>
Message-ID: <siwyjzUschdL9bJ_M4fdQDfY59oCJ0aAZGwncWho3cM=.8fd36fb3-4f95-4f55-a353-d15df9e4078f@github.com>

On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs

Leaving out the non-public and non-exported classes would also reduce the PR size.

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

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

From duke at openjdk.org  Sat Nov 12 07:19:41 2022
From: duke at openjdk.org (danieljarabek)
Date: Sat, 12 Nov 2022 07:19:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v17]
In-Reply-To: <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
Message-ID: <qE_VNvuoP-mvJN88OYC0z024kCAQ3OguZAVHl7jo_l0=.202f94c4-57fd-48e2-8de3-a02301fcc191@github.com>

On Thu, 10 Nov 2022 17:42:04 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:
> 
>   Requested changes #5

src/java.base/share/classes/java/util/FormatterBuilder.java line 52:

> 50: /**
> 51:  * This package private class supports the construction of the {@link MethodHandle}
> 52:  * returned by {@Link Formatter#formatFactory}.

Suggestion:

 * returned by {@link Formatter#formatFactory}.

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

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

From jlaskey at openjdk.org  Sat Nov 12 15:46:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 12 Nov 2022 15:46:48 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v17]
In-Reply-To: <qE_VNvuoP-mvJN88OYC0z024kCAQ3OguZAVHl7jo_l0=.202f94c4-57fd-48e2-8de3-a02301fcc191@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <FDWvPqEgUbHsABk4gT3PthXwDXKfrftBPs5kaP0z0Wo=.b08fc4bd-17a3-4c3b-b9d4-afd99862e332@github.com>
 <qE_VNvuoP-mvJN88OYC0z024kCAQ3OguZAVHl7jo_l0=.202f94c4-57fd-48e2-8de3-a02301fcc191@github.com>
Message-ID: <-JDH0Yc-zlRdN_7CTe6pVBhAFqqo1sdx8SBYn6iXhUE=.d03f0002-a92f-4fd7-9ef8-f431d5590717@github.com>

On Sat, 12 Nov 2022 07:17:30 GMT, danieljarabek <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Requested changes #5
>
> src/java.base/share/classes/java/util/FormatterBuilder.java line 52:
> 
>> 50: /**
>> 51:  * This package private class supports the construction of the {@link MethodHandle}
>> 52:  * returned by {@Link Formatter#formatFactory}.
> 
> Suggestion:
> 
>  * returned by {@link Formatter#formatFactory}.

Changing

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

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

From jlaskey at openjdk.org  Mon Nov 14 12:48:50 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 14 Nov 2022 12:48:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v18]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <3LrmIC3Q0YpqZVfaQw5q4t3moloj7cl81H4iOomail4=.e7bc7f08-6520-4aa2-995a-e97b1f103c0c@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:

  Requested changes #7
  
  @Stable removal
  process decl in TemplateProcessor and StringProcessor for specialized javadoc
  clean up FormatterBuilder javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/ac5402ed..2dc2cad2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=16-17

  Stats: 31 lines in 6 files changed: 20 ins; 7 del; 4 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  Mon Nov 14 16:36:21 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 14 Nov 2022 16:36:21 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v19]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <DuPmxBiO2ceBwYFln-ddTdhvSkPaCSQ1xPpppQm6agE=.518d7d99-2a69-4e0c-9c4a-0a810d684384@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 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 33 additional commits since the last revision:

 - Merge branch 'master' into 8285932
 - Requested changes #7
   
   @Stable removal
   process decl in TemplateProcessor and StringProcessor for specialized javadoc
   clean up FormatterBuilder javadoc
 - Requested changes #5
 - Clean up new StringTemplate creation
   
   Centralized StringTemplate creation in StringTemplateImplFactory. Added consistent defensive copying of lists. Changed List<Object> to List<?> on StringTemplate.interpolate and StringTemplate.of.
 - Switch from anonymous classes  to carrier based StringTemplate implementation
 - Merge branch 'master' into 8285932
 - Internalize FormatConcatItem
 - Requested changes #5
 - Internalize TemplateSupport
 - Requested changes #4
 - ... and 23 more: https://git.openjdk.org/jdk/compare/bd45530e...c15142a3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/2dc2cad2..c15142a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=17-18

  Stats: 3753 lines in 329 files changed: 2217 ins; 766 del; 770 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  Mon Nov 14 17:42:08 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 14 Nov 2022 17:42:08 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v20]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <60MJvn-JZ5LfcY9EUIoyU_B9oPeQrfmZatvAjoCWEjw=.b0f4dd27-bfff-4d95-a2c8-7b05764cc325@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:

  Wrong line separator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/c15142a3..59d70376

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=18-19

  Stats: 230 lines in 1 file changed: 0 ins; 0 del; 230 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  Mon Nov 14 17:51:24 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 14 Nov 2022 17:51:24 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v21]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@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:

  Wrong line separator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/59d70376..e4812ee5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=19-20

  Stats: 336 lines in 1 file changed: 0 ins; 0 del; 336 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  Tue Nov 15 20:27:09 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 15 Nov 2022 20:27:09 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v21]
In-Reply-To: <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
Message-ID: <xpXFzdVQrSGH4_qjNwF0N3PQF8ilzvVTCnkSima3SI8=.a1408e0f-a640-481b-ab77-71a800f3e210@github.com>

On Mon, 14 Nov 2022 17:51:24 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:
> 
>   Wrong line separator

Could we get some review completions so we can move forward? Thank you.

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

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

From duke at openjdk.org  Tue Nov 15 21:26:47 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 15 Nov 2022 21:26:47 GMT
Subject: <i18n dev> RFR: 8287180: Update IANA Language Subtag Registry to
 Version 2022-08-08
Message-ID: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>

Problem: IANA Language subtag registry is outdated
Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)

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

Commit messages:
 - Update date for IANA test
 - Merge branch 'master' into 8287180-IANA
 - update IANA

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

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

From naoto at openjdk.org  Tue Nov 15 21:26:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Nov 2022 21:26:48 GMT
Subject: <i18n dev> RFR: 8287180: Update IANA Language Subtag Registry
 to Version 2022-08-08
In-Reply-To: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
References: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
Message-ID: <lhSMIkVlMVjCVjpJtZRJK9ybEY1sZM8j7LINPz4DdPM=.ae9f9816-8e9f-4b50-b705-b15a0a25deb6@github.com>

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

> Problem: IANA Language subtag registry is outdated
> Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)

Although there aren't actual code changes, I believe the test `test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java` should be modified as well.

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

Changes requested by naoto (Reviewer).

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

From mcimadamore at openjdk.org  Wed Nov 16 16:04:45 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 16:04:45 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v21]
In-Reply-To: <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
Message-ID: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>

On Mon, 14 Nov 2022 17:51:24 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:
> 
>   Wrong line separator

Compiler changes look good to me. I've left some comments on API javadoc, as well as other minor issues. It would be great to address them now, but I understand if there's no time.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 115:

> 113:      * @throws Throwable            if linkage fails
> 114:      */
> 115:     public static CallSite stringTemplateBSM(

In other classes in this package we never use `BSM` in the bootstrap name. Instead, we make some attempt to describe what the BSM does by picking some meaningful name (see SwitchBootstrap::typeSwitch). I think `newStringTemplate` (or `make`, `create`) would work here?

src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 48:

> 46:  */
> 47: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 48: public sealed interface ProcessorLinkage permits FormatProcessor {

Does this need to be exposed? FormatProcessor is the only permitted type, so javac could detect that (or have an internal list of supported optimized processors).

src/java.base/share/classes/java/lang/template/StringProcessor.java line 31:

> 29: 
> 30: /**
> 31:  * This interface simplifies declaration of

Suggestion:

 * This interface simplifies the declaration of

src/java.base/share/classes/java/lang/template/StringTemplate.java line 28:

> 26: package java.lang.template;
> 27: 
> 28: import java.lang.invoke.MethodHandle;

Watch out for unused imports - I've seen them here and eslewhere

src/java.base/share/classes/java/lang/template/StringTemplate.java line 38:

> 36: 
> 37: /**
> 38:  * The Java compiler produces implementations of {@link StringTemplate} to

I believe this descripton is now out of date - the compiler doesn't create implementations of StringTemplate, TemplateRuntime does -  the compiler just request them.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 49:

> 47:  * The {@link StringTemplate#fragments()} method must return an immutable
> 48:  * {@code List<String>} consistent with the string template body. The list
> 49:  * contains the string of characters preceeding each of the embedded expressions

Suggestion:

 * contains the string of characters preceding each of the embedded expressions

src/java.base/share/classes/java/lang/template/StringTemplate.java line 73:

> 71:  * {@code values} will be the equivalent of <code>List.of(x, y, x + y)</code>.
> 72:  * <p>
> 73:  * {@link StringTemplate StringTemplates} are primarily used in conjuction

Suggestion:

 * {@link StringTemplate StringTemplates} are primarily used in conjunction

src/java.base/share/classes/java/lang/template/StringTemplate.java line 106:

> 104:  * }
> 105:  *
> 106:  * @implSpec An instance of {@link StringTemplate} is immutatble. Also, the

Suggestion:

 * @implSpec An instance of {@link StringTemplate} is immutable. Also, the

src/java.base/share/classes/java/lang/template/StringTemplate.java line 120:

> 118:     /**
> 119:      * Returns an immutable list of string fragments consisting of the string
> 120:      * of characters preceeding each of the embedded expressions plus the

Suggestion:

     * of characters preceding each of the embedded expressions plus the

src/java.base/share/classes/java/lang/template/StringTemplate.java line 138:

> 136:      * Returns an immutable list of embedded expression results. In the example:
> 137:      * {@snippet :
> 138:      * StringTemplate st = RAW."\{x} + \{y} = \{x + y}";

Would it make sense to use the same student/teacher example as above? Or, perhaps, we should use x and y everywhere?

src/java.base/share/classes/java/lang/template/StringTemplate.java line 150:

> 148: 
> 149:     /**
> 150:      * {@return the interpolation of the StringTemplate}

A `@link` or `@code` is missing around `StringTemplate`. I think this method needs an example for what interpolation means. Also, in the class javadoc we use the term `string interpolation` which is more specific and I prefer. We should probably use that term everywhere in this class.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 173:

> 171:      * @param <E>  Exception thrown type.
> 172:      *
> 173:      * @return constructed object of type R

Missing `@code` or `@link` around `R`

src/java.base/share/classes/java/lang/template/StringTemplate.java line 198:

> 196:      * @throws NullPointerException if stringTemplate is null
> 197:      */
> 198:     public static String toString(StringTemplate stringTemplate) {

`public` is redundant (here and elsewhere)

src/java.base/share/classes/java/lang/template/StringTemplate.java line 208:

> 206: 
> 207:     /**
> 208:      * Returns a StringTemplate composed from a string.

is `composed` the best term here?  E.g. I'd prefer if this method actually told me what the properties of the returned template were - e.g. that it has one fragment (the string) and zero values.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 222:

> 220: 
> 221:     /**
> 222:      * Returns a StringTemplate composed from fragments and values.

Suggestion:

     * Returns a StringTemplate with the given fragments and values.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 273:

> 271: 
> 272:     /**
> 273:       * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}.

Suggestion:

      * Combine one or more {@link StringTemplate StringTemplates} into a single {@link StringTemplate}.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 302:

> 300: 
> 301:     /**
> 302:      * No-op template processor. Used to highlight that non-processing of the StringTemplate

I wonder if there's a play to call this the "identity" processor. In the sense that it takes a template and just returns that unchanged. That would also help with calling it "raw" which creates confusion with some compiler messages.

src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 31:

> 29: 
> 30: /**
> 31:  * This interface simplifies declaration of

Suggestion:

 * This interface simplifies the declaration of

src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 44:

> 42:  * }
> 43:  *
> 44:  * @param <R>  Processor's process result type.

Some code block/link missing?

src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 28:

> 26: package java.lang.template;
> 27: 
> 28: import java.util.Objects;

Watch out for unused imports

src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 41:

> 39:  * This interface describes the methods provided by a generalized string template processor. The
> 40:  * primary method {@link ValidatingProcessor#process(StringTemplate)} is used to validate
> 41:  * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.

`compose` as in `produce` ?

src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 86:

> 84:  * Composing allows user control over how the result is assembled. Most often, a
> 85:  * user will construct a new string from the template string, with placeholders
> 86:  * replaced by stringified objects from the values list.

stringified looks funny - but have no idea on how to replace it

src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 126:

> 124:  * }
> 125:  * The {@link StringTemplate#interpolate()} method is available for those processors
> 126:  * that just need to work with the interpolation;

again, would be better to replace all bare occurrence of "interpolation" with "string interpolation"

src/java.base/share/classes/java/util/FormatProcessor.java line 38:

> 36: 
> 37: /**
> 38:  * This {@linkplain ValidatingProcessor template processor} constructs a String

`String` is missing some javadoc wrapping

src/java.base/share/classes/java/util/FormatProcessor.java line 39:

> 37: /**
> 38:  * This {@linkplain ValidatingProcessor template processor} constructs a String
> 39:  * result using {@link Formatter}. Unlike {@link Formatter}, FormatProcessor uses the value from

And `FormatProcessor` too

src/java.base/share/classes/java/util/FormatProcessor.java line 42:

> 40:  * the embedded expression that follows immediately after the
> 41:  * <a href="../util/Formatter.html#syntax">format specifier</a>.
> 42:  * StringTemplate expressions without a preceeding specifier, use "%s" by

Suggestion:

 * StringTemplate expressions without a preceding specifier, use "%s" by

src/java.base/share/classes/java/util/FormatProcessor.java line 51:

> 49:  * result is: <code>00010 + 00020 = 00030</code>
> 50:  *
> 51:  * @implNote When used in conjunction with a compiler generated {@link

Is this comment still relevant? E.g. the `When used in conjunction with compiler generated...` part. Doesn't javac always emit a call to the optimized linkage entry if it sees that the processor used is a ProcessorLinkage?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 125:

> 123:     }
> 124: 
> 125:     Type makeListType(Type elemType) {

Unused

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 136:

> 134:     }
> 135: 
> 136:     JCVariableDecl makeField(JCClassDecl cls, long flags, Name name, Type type, JCExpression init) {

Unused

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 145:

> 143:     }
> 144: 
> 145:     MethodType makeMethodType(Type returnType, List<Type> argTypes) {

Unused

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 149:

> 147:     }
> 148: 
> 149:     JCFieldAccess makeThisFieldSelect(Type owner, JCVariableDecl field) {

Unused

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 156:

> 154:     }
> 155: 
> 156:     JCIdent makeParamIdent(List<JCVariableDecl> params, Name name) {

Unused

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 171:

> 169:     }
> 170: 
> 171:     JCMethodInvocation makeApply(JCFieldAccess method, List<JCExpression> args) {

Unused

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 179:

> 177:     }
> 178: 
> 179:     JCFieldAccess makeFieldAccess(JCClassDecl owner, Name name) {

Unused

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 223:

> 221:         JCStringTemplate tree;
> 222:         JCExpression processor;
> 223:         List<String> fragments;

I still believe some of these fields could be final

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 318:

> 316:                         staticArgValues, staticArgsTypes);
> 317:             } else {
> 318:                 VarSymbol processorSym = (VarSymbol)TreeInfo.symbol(processor);

This seems unused

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1301:

> 1299: # 0: symbol
> 1300: compiler.err.raw.template.processor.type=\
> 1301:     raw template processor type: {0}

This error message can be confusing now that we have a RAW processor type. I'd suggest maybe rephrasing to `template processor type cannot be a raw type`

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java line 227:

> 225:     // templated string
> 226:     public final Name process;
> 227:     public final Name str;

We have precedents for using capital variable names in this class, and we should probably do so here (for `str` and `raw`).

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.org  Wed Nov 16 16:04:47 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 16:04:47 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <nisWsPx-lijx5dxbf76OXYOk3FzDdmIsSQ9QUIGTidM=.ef5f242d-35bc-413c-b3dd-e3989cf7d00f@github.com>

On Wed, 16 Nov 2022 15:41:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 273:
> 
>> 271: 
>> 272:     /**
>> 273:       * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}.
> 
> Suggestion:
> 
>       * Combine one or more {@link StringTemplate StringTemplates} into a single {@link StringTemplate}.

Should we say more about what the properties of the returned template are? E.g. that the fragments are concatenated (in which order?) and values are also concatenated.

> src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 41:
> 
>> 39:  * This interface describes the methods provided by a generalized string template processor. The
>> 40:  * primary method {@link ValidatingProcessor#process(StringTemplate)} is used to validate
>> 41:  * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 
> `compose` as in `produce` ?

This use of the word `compose` occurs in other places. While I'm not opposed to it, it has not to do with function composition in mathematical sense (unlike StringTemplate::compose), so I'd stay clear.

> src/java.base/share/classes/java/util/FormatProcessor.java line 42:
> 
>> 40:  * the embedded expression that follows immediately after the
>> 41:  * <a href="../util/Formatter.html#syntax">format specifier</a>.
>> 42:  * StringTemplate expressions without a preceeding specifier, use "%s" by
> 
> Suggestion:
> 
>  * StringTemplate expressions without a preceding specifier, use "%s" by

And, `StringTemplate` is missing a surrounding code/link tag

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

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

From jlaskey at openjdk.org  Wed Nov 16 16:28:20 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 16:28:20 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <p_7ZZLkqP_8IbXM1TZ7H5HCh1N9LZ3P70ANf9YNdMQ8=.dd4f821f-d4eb-44e6-99d2-f81598f9ee78@github.com>

On Wed, 16 Nov 2022 13:12:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 115:
> 
>> 113:      * @throws Throwable            if linkage fails
>> 114:      */
>> 115:     public static CallSite stringTemplateBSM(
> 
> In other classes in this package we never use `BSM` in the bootstrap name. Instead, we make some attempt to describe what the BSM does by picking some meaningful name (see SwitchBootstrap::typeSwitch). I think `newStringTemplate` (or `make`, `create`) would work here?

Reasonable. Changing.

> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java line 227:
> 
>> 225:     // templated string
>> 226:     public final Name process;
>> 227:     public final Name str;
> 
> We have precedents for using capital variable names in this class, and we should probably do so here (for `str` and `raw`).

Changing.

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

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

From jlaskey at openjdk.org  Wed Nov 16 16:48:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 16:48:48 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <rAXQtHnw0BQOmVpxTR27zGbMEhNT_cXBvza73HjSNHk=.f80b81bc-8bf4-4777-9117-e61e43ffd64b@github.com>

On Wed, 16 Nov 2022 15:22:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 125:
> 
>> 123:     }
>> 124: 
>> 125:     Type makeListType(Type elemType) {
> 
> Unused

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 136:
> 
>> 134:     }
>> 135: 
>> 136:     JCVariableDecl makeField(JCClassDecl cls, long flags, Name name, Type type, JCExpression init) {
> 
> Unused

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 149:
> 
>> 147:     }
>> 148: 
>> 149:     JCFieldAccess makeThisFieldSelect(Type owner, JCVariableDecl field) {
> 
> Unused

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 156:
> 
>> 154:     }
>> 155: 
>> 156:     JCIdent makeParamIdent(List<JCVariableDecl> params, Name name) {
> 
> Unused

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 171:
> 
>> 169:     }
>> 170: 
>> 171:     JCMethodInvocation makeApply(JCFieldAccess method, List<JCExpression> args) {
> 
> Unused

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 179:
> 
>> 177:     }
>> 178: 
>> 179:     JCFieldAccess makeFieldAccess(JCClassDecl owner, Name name) {
> 
> Unused

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 223:
> 
>> 221:         JCStringTemplate tree;
>> 222:         JCExpression processor;
>> 223:         List<String> fragments;
> 
> I still believe some of these fields could be final

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 318:
> 
>> 316:                         staticArgValues, staticArgsTypes);
>> 317:             } else {
>> 318:                 VarSymbol processorSym = (VarSymbol)TreeInfo.symbol(processor);
> 
> This seems unused

Changing

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

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

From jlaskey at openjdk.org  Wed Nov 16 17:03:41 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 17:03:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <LD5mDvWWxvF816aUbhLwLm5EZp2e8zbfuPKOYQ3A99Q=.23c8176c-a2b8-4b41-9f49-76fb8c6014fe@github.com>

On Wed, 16 Nov 2022 15:26:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1301:
> 
>> 1299: # 0: symbol
>> 1300: compiler.err.raw.template.processor.type=\
>> 1301:     raw template processor type: {0}
> 
> This error message can be confusing now that we have a RAW processor type. I'd suggest maybe rephrasing to `template processor type cannot be a raw type`

Agree. Changing.

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

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

From jlaskey at openjdk.org  Wed Nov 16 17:14:07 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 17:14:07 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <ZozQw6yNol7adU91FcJuAvGfZl6WwKiz3A2qXYimKM0=.7724da22-ece3-4144-866e-b63353f403e1@github.com>

On Wed, 16 Nov 2022 15:26:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 28:
> 
>> 26: package java.lang.template;
>> 27: 
>> 28: import java.lang.invoke.MethodHandle;
> 
> Watch out for unused imports - I've seen them here and eslewhere

Cleaning up.

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

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

From naoto at openjdk.org  Wed Nov 16 17:22:03 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Nov 2022 17:22:03 GMT
Subject: <i18n dev> RFR: 8287180: Update IANA Language Subtag Registry
 to Version 2022-08-08
In-Reply-To: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
References: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
Message-ID: <fIo2CNPeWJVMr0krHEQ6F3PzMLVp5jQOvfPrwpV66Dg=.52c18105-15b6-45c4-b574-047c0c846094@github.com>

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

> Problem: IANA Language subtag registry is outdated
> Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)

Marked as reviewed by naoto (Reviewer).

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

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

From jlaskey at openjdk.org  Wed Nov 16 17:33:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 17:33:38 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <gzUxtepEUh36OfGngtAJLoEg9nzkZm6xhia6cqdJp7E=.87da645d-c217-4e3d-9ac4-e066514352b3@github.com>

On Wed, 16 Nov 2022 15:27:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 38:
> 
>> 36: 
>> 37: /**
>> 38:  * The Java compiler produces implementations of {@link StringTemplate} to
> 
> I believe this descripton is now out of date - the compiler doesn't create implementations of StringTemplate, TemplateRuntime does -  the compiler just request them.

Changing.

`{@link StringTemplate StringTemplates} are runtime representations of Java string templates and text block templates`

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 49:
> 
>> 47:  * The {@link StringTemplate#fragments()} method must return an immutable
>> 48:  * {@code List<String>} consistent with the string template body. The list
>> 49:  * contains the string of characters preceeding each of the embedded expressions
> 
> Suggestion:
> 
>  * contains the string of characters preceding each of the embedded expressions

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 73:
> 
>> 71:  * {@code values} will be the equivalent of <code>List.of(x, y, x + y)</code>.
>> 72:  * <p>
>> 73:  * {@link StringTemplate StringTemplates} are primarily used in conjuction
> 
> Suggestion:
> 
>  * {@link StringTemplate StringTemplates} are primarily used in conjunction

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 106:
> 
>> 104:  * }
>> 105:  *
>> 106:  * @implSpec An instance of {@link StringTemplate} is immutatble. Also, the
> 
> Suggestion:
> 
>  * @implSpec An instance of {@link StringTemplate} is immutable. Also, the

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 138:
> 
>> 136:      * Returns an immutable list of embedded expression results. In the example:
>> 137:      * {@snippet :
>> 138:      * StringTemplate st = RAW."\{x} + \{y} = \{x + y}";
> 
> Would it make sense to use the same student/teacher example as above? Or, perhaps, we should use x and y everywhere?

At least for the fragments and values snippets. Changing.

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

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

From jlaskey at openjdk.org  Wed Nov 16 17:46:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 17:46:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <TilsN1niKVj98vWhPBbdAWEmwI2PIyD0NR05NV3Bmx4=.28381437-01eb-40f3-a830-59e78c7d0dc9@github.com>

On Wed, 16 Nov 2022 15:32:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 120:
> 
>> 118:     /**
>> 119:      * Returns an immutable list of string fragments consisting of the string
>> 120:      * of characters preceeding each of the embedded expressions plus the
> 
> Suggestion:
> 
>      * of characters preceding each of the embedded expressions plus the

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 173:
> 
>> 171:      * @param <E>  Exception thrown type.
>> 172:      *
>> 173:      * @return constructed object of type R
> 
> Missing `@code` or `@link` around `R`

Changing.

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

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

From jlaskey at openjdk.org  Wed Nov 16 17:50:21 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 17:50:21 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <38UI4LMzuSzoMTSR5_zThCxtwLtKcaFvhtqDgMhLwO0=.8b5e9e49-2f84-4994-ac6a-92694df10b8d@github.com>

On Wed, 16 Nov 2022 15:36:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 198:
> 
>> 196:      * @throws NullPointerException if stringTemplate is null
>> 197:      */
>> 198:     public static String toString(StringTemplate stringTemplate) {
> 
> `public` is redundant (here and elsewhere)

Changing

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

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

From jlaskey at openjdk.org  Wed Nov 16 17:56:41 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 17:56:41 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <nisWsPx-lijx5dxbf76OXYOk3FzDdmIsSQ9QUIGTidM=.ef5f242d-35bc-413c-b3dd-e3989cf7d00f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
 <nisWsPx-lijx5dxbf76OXYOk3FzDdmIsSQ9QUIGTidM=.ef5f242d-35bc-413c-b3dd-e3989cf7d00f@github.com>
Message-ID: <ydgt3Stg8RdVtYfn-swy-Fofo0949DbIUQdOIvjJ85U=.43561981-44a5-40c4-8ba1-202b2ef21b94@github.com>

On Wed, 16 Nov 2022 15:41:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 273:
>> 
>>> 271: 
>>> 272:     /**
>>> 273:       * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}.
>> 
>> Suggestion:
>> 
>>       * Combine one or more {@link StringTemplate StringTemplates} into a single {@link StringTemplate}.
>
> Should we say more about what the properties of the returned template are? E.g. that the fragments are concatenated (in which order?) and values are also concatenated.

Changing.

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

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

From jlaskey at openjdk.org  Wed Nov 16 17:56:37 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 17:56:37 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <nOrs231r7WvTDVuhlhT_KRjC1lGg61Fv08X_e2zSgmY=.61b3da02-f01f-4020-8fbf-de7ebe8ce7d2@github.com>

On Wed, 16 Nov 2022 15:37:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 208:
> 
>> 206: 
>> 207:     /**
>> 208:      * Returns a StringTemplate composed from a string.
> 
> is `composed` the best term here?  E.g. I'd prefer if this method actually told me what the properties of the returned template were - e.g. that it has one fragment (the string) and zero values.

`Returns a StringTemplate as if constructed by invoking <code>StringTemplate.of(List.of(string), List.of())</code>.`

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 222:
> 
>> 220: 
>> 221:     /**
>> 222:      * Returns a StringTemplate composed from fragments and values.
> 
> Suggestion:
> 
>      * Returns a StringTemplate with the given fragments and values.

Changing.

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

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

From lancea at openjdk.org  Wed Nov 16 17:58:00 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 16 Nov 2022 17:58:00 GMT
Subject: <i18n dev> RFR: 8287180: Update IANA Language Subtag Registry
 to Version 2022-08-08
In-Reply-To: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
References: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
Message-ID: <c9hBS2wJ4dxgtHT5fY45ZEr5gpEOq7h3M65aYmy1K0k=.38d1bd20-166c-438c-a81f-4ec965736eec@github.com>

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

> Problem: IANA Language subtag registry is outdated
> Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)

Marked as reviewed by lancea (Reviewer).

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

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

From jlaskey at openjdk.org  Wed Nov 16 18:08:24 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 18:08:24 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <0aWXRpDkrrAKDAJMbeS9DCSWXu50yewb9HS_qIk2NlI=.3fdd1c46-85d7-4ba4-80d2-b6b113c458f7@github.com>

On Wed, 16 Nov 2022 15:43:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 302:
> 
>> 300: 
>> 301:     /**
>> 302:      * No-op template processor. Used to highlight that non-processing of the StringTemplate
> 
> I wonder if there's a play to call this the "identity" processor. In the sense that it takes a template and just returns that unchanged. That would also help with calling it "raw" which creates confusion with some compiler messages.

It's a reasonable suggestion. This processor would used rarely, so calling it IDENTITY (more than 3 characters) is not an impediment. However, IDENTITY doesn't really speak to what it does. RAW was chosen primarily because it is what other languages use. (I had used NOOP  earlier.)

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

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

From jlaskey at openjdk.org  Wed Nov 16 18:15:23 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 18:15:23 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <lxuEjegfTDUXoXI8P1Vour5lue0iPg8xLoEr_WsB9QI=.a2a8d91e-0e51-4f2c-90b7-4e447350de53@github.com>

On Wed, 16 Nov 2022 15:44:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * This interface simplifies declaration of
> 
> Suggestion:
> 
>  * This interface simplifies the declaration of

Changing.

> src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 44:
> 
>> 42:  * }
>> 43:  *
>> 44:  * @param <R>  Processor's process result type.
> 
> Some code block/link missing?

`};` is in the snippet. `}` is the end of the snippet.

> src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 28:
> 
>> 26: package java.lang.template;
>> 27: 
>> 28: import java.util.Objects;
> 
> Watch out for unused imports

Went through and did the import clean up en masse.

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

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

From jlaskey at openjdk.org  Wed Nov 16 18:27:35 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 18:27:35 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <lmqEzME7qTOT81R2NcenB-N7vlk6SS8bSlWHZCDRebY=.ea6de4b7-fa10-40c9-a8ec-edd16d45ad9f@github.com>

On Wed, 16 Nov 2022 15:54:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 48:
> 
>> 46:  */
>> 47: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 48: public sealed interface ProcessorLinkage permits FormatProcessor {
> 
> Does this need to be exposed? FormatProcessor is the only permitted type, so javac could detect that (or have an internal list of supported optimized processors).

Not worth changing at this point. The plan is to replace with TemplateProcessorFactories.

> src/java.base/share/classes/java/lang/template/StringProcessor.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * This interface simplifies declaration of
> 
> Suggestion:
> 
>  * This interface simplifies the declaration of

Changing.

> src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 86:
> 
>> 84:  * Composing allows user control over how the result is assembled. Most often, a
>> 85:  * user will construct a new string from the template string, with placeholders
>> 86:  * replaced by stringified objects from the values list.
> 
> stringified looks funny - but have no idea on how to replace it

* Composing allows user control over how the result is assembled. Most often, a
 * user will construct a new string from the string template, with placeholders
 * replaced by string representations of value list elements. These string
 * representations are created as if invoking {@link String#valueOf}.

> src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 126:
> 
>> 124:  * }
>> 125:  * The {@link StringTemplate#interpolate()} method is available for those processors
>> 126:  * that just need to work with the interpolation;
> 
> again, would be better to replace all bare occurrence of "interpolation" with "string interpolation"

Changing.

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

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

From iris at openjdk.org  Wed Nov 16 18:35:03 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 16 Nov 2022 18:35:03 GMT
Subject: <i18n dev> RFR: 8287180: Update IANA Language Subtag Registry
 to Version 2022-08-08
In-Reply-To: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
References: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
Message-ID: <8H7rDCCAyKCXQFBW6tzJ7E_PO92o0zGsSEOf-xqvaVY=.b1347130-e029-44bf-a6ad-019f8f43b97e@github.com>

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

> Problem: IANA Language subtag registry is outdated
> Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)

Marked as reviewed by iris (Reviewer).

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

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

From jlaskey at openjdk.org  Wed Nov 16 18:36:06 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 18:36:06 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <nisWsPx-lijx5dxbf76OXYOk3FzDdmIsSQ9QUIGTidM=.ef5f242d-35bc-413c-b3dd-e3989cf7d00f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
 <nisWsPx-lijx5dxbf76OXYOk3FzDdmIsSQ9QUIGTidM=.ef5f242d-35bc-413c-b3dd-e3989cf7d00f@github.com>
Message-ID: <fOtMxqQcu6o2a-RyRXOvdykV2eAVj04rHSZBHnkCxRA=.6d3e26ed-547f-42fd-964e-22565683899b@github.com>

On Wed, 16 Nov 2022 15:56:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/FormatProcessor.java line 42:
>> 
>>> 40:  * the embedded expression that follows immediately after the
>>> 41:  * <a href="../util/Formatter.html#syntax">format specifier</a>.
>>> 42:  * StringTemplate expressions without a preceeding specifier, use "%s" by
>> 
>> Suggestion:
>> 
>>  * StringTemplate expressions without a preceding specifier, use "%s" by
>
> And, `StringTemplate` is missing a surrounding code/link tag

Changing.

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

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

From jlaskey at openjdk.org  Wed Nov 16 18:36:03 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 18:36:03 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <I1_RRiPREUYT4MHCclWeDLS65Miaf-q08pWwqBK9XuU=.1fb574e8-f8a4-485a-b430-a77afd96beef@github.com>

On Wed, 16 Nov 2022 15:55:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 38:
> 
>> 36: 
>> 37: /**
>> 38:  * This {@linkplain ValidatingProcessor template processor} constructs a String
> 
> `String` is missing some javadoc wrapping

Changing.

> src/java.base/share/classes/java/util/FormatProcessor.java line 39:
> 
>> 37: /**
>> 38:  * This {@linkplain ValidatingProcessor template processor} constructs a String
>> 39:  * result using {@link Formatter}. Unlike {@link Formatter}, FormatProcessor uses the value from
> 
> And `FormatProcessor` too

Changing.

> src/java.base/share/classes/java/util/FormatProcessor.java line 51:
> 
>> 49:  * result is: <code>00010 + 00020 = 00030</code>
>> 50:  *
>> 51:  * @implNote When used in conjunction with a compiler generated {@link
> 
> Is this comment still relevant? E.g. the `When used in conjunction with compiler generated...` part. Doesn't javac always emit a call to the optimized linkage entry if it sees that the processor used is a ProcessorLinkage?

Changing.

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

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

From jlaskey at openjdk.org  Wed Nov 16 18:47:51 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 18:47:51 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v22]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <WI2pk1sRGgd97VciQgPxlD-QsHC2zoTCNIK67BN8aWk=.37e6c8b9-41bd-4a1e-a8a3-09b0915758f3@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:

  Requested changes #8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/e4812ee5..dcceb671

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=20-21

  Stats: 231 lines in 13 files changed: 32 ins; 113 del; 86 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  Wed Nov 16 19:08:26 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 19:08:26 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
Message-ID: <O16Hkzm9yScyIBtR4vvJqGvpJ-9bQX1U1dMjEjUfjfc=.c14f1db6-2ef0-406f-979d-5c53bbe8238f@github.com>

On Wed, 16 Nov 2022 16:01:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> Compiler changes look good to me. I've left some comments on API javadoc, as well as other minor issues. It would be great to address them now, but I understand if there's no time.

Thanks @mcimadamore. I think I've integrated most of your points.

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

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

From jlahoda at openjdk.org  Wed Nov 16 19:21:28 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Nov 2022 19:21:28 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
Message-ID: <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>

On Mon, 14 Nov 2022 17:51:24 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:
> 
>   Wrong line separator

I've looked at the javac part, and added a few mostly minor comments.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 77:

> 75: import static com.sun.tools.javac.code.TypeTag.METHOD;
> 76: import static com.sun.tools.javac.code.TypeTag.VOID;
> 77: import com.sun.tools.javac.code.Types;

This change is probably unnecessary?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 31:

> 29: import java.util.stream.Collectors;
> 30: 
> 31: import com.sun.tools.javac.code.*;

There seem to be changes in this file that are not related to this patch (import section re-organization, addition of empty lines, but possibly also changes to `makeIndyQualifier`) - could these be, please, undone?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 231:

> 229:         JCVariableDecl valuesVar;
> 230:         List<JCVariableDecl> fields;
> 231:         MethodInfo interpolateMethod;

Some of the field here appear to be unused? Probably `stringTemplateClass`, `fragmentsVar`, `valuesVar`, `fields`, `interpolateMethod`.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 700:

> 698:             S.setPrevToken(stringToken);
> 699:         }
> 700:         JCExpression t = F.at(pos).StringTemplate(processor, fragments, expressions);

Should there be something like `toP(...)` around the `F.at...`, to set the end position of the tree?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1487:

> 1485:                                 if (typeArgs != null) return illegal();
> 1486:                                 t = stringTemplate(t);
> 1487:                                 typeArgs = null;

`typeArgs = null;` is unnecessary here, correct?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1715:

> 1713:                     }
> 1714:                     t = stringTemplate(t);
> 1715:                     typeArgs = null;

`typeArgs = null;` unnecessary?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1716:

> 1714:                     t = stringTemplate(t);
> 1715:                     typeArgs = null;
> 1716:                     // Uncomment to not allow follow on DOT

What is the reason for this comment? Seems like it should be removed?

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

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

From jlaskey at openjdk.org  Wed Nov 16 20:16:00 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 20:16:00 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
Message-ID: <rXJ7MrsHHDsmO1SIrKjSWuSF-nQYxnD2qFcSG8WEMEY=.21072c3b-9728-4c08-b39d-ba5e9ddbcc07@github.com>

On Wed, 16 Nov 2022 16:07:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 77:
> 
>> 75: import static com.sun.tools.javac.code.TypeTag.METHOD;
>> 76: import static com.sun.tools.javac.code.TypeTag.VOID;
>> 77: import com.sun.tools.javac.code.Types;
> 
> This change is probably unnecessary?

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 231:
> 
>> 229:         JCVariableDecl valuesVar;
>> 230:         List<JCVariableDecl> fields;
>> 231:         MethodInfo interpolateMethod;
> 
> Some of the field here appear to be unused? Probably `stringTemplateClass`, `fragmentsVar`, `valuesVar`, `fields`, `interpolateMethod`.

Cleaned up earlier.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1716:
> 
>> 1714:                     t = stringTemplate(t);
>> 1715:                     typeArgs = null;
>> 1716:                     // Uncomment to not allow follow on DOT
> 
> What is the reason for this comment? Seems like it should be removed?

Not sure. Note to future self that if we allow relaxed use of processors, this is where to make change. Open to alternate methodology.

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

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

From jlaskey at openjdk.org  Wed Nov 16 20:20:02 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 20:20:02 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
Message-ID: <-saM3CI4tVMG5xi1DE0XcDRCCT_ixtSJkKTza8X-Tng=.0f3e13c6-c393-4137-b2d3-ef62c99f9d9d@github.com>

On Wed, 16 Nov 2022 19:16:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 700:
> 
>> 698:             S.setPrevToken(stringToken);
>> 699:         }
>> 700:         JCExpression t = F.at(pos).StringTemplate(processor, fragments, expressions);
> 
> Should there be something like `toP(...)` around the `F.at...`, to set the end position of the tree?

Added.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1715:
> 
>> 1713:                     }
>> 1714:                     t = stringTemplate(t);
>> 1715:                     typeArgs = null;
> 
> `typeArgs = null;` unnecessary?

Will remove the section for now and make a note elsewhere.

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

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

From jlaskey at openjdk.org  Wed Nov 16 20:20:04 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 20:20:04 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <rXJ7MrsHHDsmO1SIrKjSWuSF-nQYxnD2qFcSG8WEMEY=.21072c3b-9728-4c08-b39d-ba5e9ddbcc07@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
 <rXJ7MrsHHDsmO1SIrKjSWuSF-nQYxnD2qFcSG8WEMEY=.21072c3b-9728-4c08-b39d-ba5e9ddbcc07@github.com>
Message-ID: <bFArSMIE4HXHljsereNX1S-y4b-3XHLpZLWa5ntRIwE=.e823e9b4-65ca-426d-ba60-e661f9ff073c@github.com>

On Wed, 16 Nov 2022 20:12:11 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1716:
>> 
>>> 1714:                     t = stringTemplate(t);
>>> 1715:                     typeArgs = null;
>>> 1716:                     // Uncomment to not allow follow on DOT
>> 
>> What is the reason for this comment? Seems like it should be removed?
>
> Not sure. Note to future self that if we allow relaxed use of processors, this is where to make change. Open to alternate methodology.

Will drop for now.

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

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

From jlaskey at openjdk.org  Wed Nov 16 20:28:14 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 20:28:14 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
Message-ID: <AKCuT8WLvyZzDw8G02IJYCn8AlAzyDgVyRyL8Jsznb0=.2ab3ba51-c9d6-4291-b564-2f20f8873a2c@github.com>

On Wed, 16 Nov 2022 18:52:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 31:
> 
>> 29: import java.util.stream.Collectors;
>> 30: 
>> 31: import com.sun.tools.javac.code.*;
> 
> There seem to be changes in this file that are not related to this patch (import section re-organization, addition of empty lines, but possibly also changes to `makeIndyQualifier`) - could these be, please, undone?

Reverting.

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

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

From jlaskey at openjdk.org  Wed Nov 16 20:33:50 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 20:33:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v23]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <G8ewvmN2YJZVucF1UaTh_6M-6hChxmwdIeNvVtmkziY=.01f1cb3a-5658-497b-951c-79521426dc76@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 #8
 - Update StringTemplate javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/dcceb671..2edc7925

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=21-22

  Stats: 119 lines in 4 files changed: 42 ins; 43 del; 34 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 rriggs at openjdk.org  Wed Nov 16 20:40:24 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Nov 2022 20:40:24 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
Message-ID: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>

On Mon, 14 Nov 2022 17:51:24 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:
> 
>   Wrong line separator

Mostly comments to make the code easier to read and understand.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1826:

> 1824: 
> 1825:     // Used by StringConcatHelper via JLA.
> 1826:     long mix(long lengthCoder) {

`mix` is not a very descriptive name (in all of the places it is used).
Perhaps a name that captures the combination of coder and length.

`coderAndLength()` or similar

The implementation here can do the wrong thing if the `lengthCoder` already includes the bit for UTF16
and the coder for the AbstractStringBuilder is LATIN1. Or is intentional that it will upgrade to UTF16?
That could definately use a comment.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 58:

> 56:  * optimized {@link StringTemplate StringTemplates} based on StringTemplateImpl.
> 57:  * <p>
> 58:  * Bootstraps in the for of (Lookup, String, MethodType, MethodHandle, String...)

"in the for" -> "in the form"

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 116:

> 114:      */
> 115:     public static CallSite stringTemplateBSM(
> 116:             MethodHandles.Lookup lookup,

The predominate style for method declarations puts the first argument on the same line as the method name
and the closing ")" on the same line with the last argument and exceptions.

src/java.base/share/classes/java/lang/template/Carriers.java line 628:

> 626:      * types.
> 627:      */
> 628:     private static class CarrierShape {

Is this a candidate to be a Record?

src/java.base/share/classes/java/lang/template/StringProcessor.java line 31:

> 29: 
> 30: /**
> 31:  * This interface simplifies declaration of

The first sentence should describe the purpose or function of the interface.
The "simplify declaration" language is a design rationale, not a functional description of the interface.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 38:

> 36: 
> 37: /**
> 38:  * The Java compiler produces implementations of {@link StringTemplate} to

I'd rather see a first sentence that says what a StringTemplate is, not who produces it.
For example, a StringTemplate holds and controls the processing of the fragments and expressions of a string template.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 189:

> 187: 
> 188:     /**
> 189:      * Produces a diagnostic string representing the supplied

The description should include that it describe the fragments and values.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 208:

> 206: 
> 207:     /**
> 208:      * Returns a StringTemplate composed from a string.

and no values.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 249:

> 247: 
> 248:     /**
> 249:      * Creates a string that interleaves the elements of values between the

It might be worth noting that this is the same as STR::interpolate.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 273:

> 271: 
> 272:     /**
> 273:       * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}.

The description should be more specific about how the lists of fragments and values are combined.
For example, is each StringTemplate well formed and have the required string and value counts.
(Or when combined, is it only the case that the total number of strings and values meet the n+1/n requirement.


I'm not sure this API point pulls it weight in the API.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 291:

> 289: 
> 290:     /**
> 291:      * Interpolation template processor instance.

Flesh out this description since it is automatically imported and will appear in user code, it should have a clear description. (Same for RAW, expand the description).

src/java.base/share/classes/java/lang/template/StringTemplateImpl.java line 35:

> 33: 
> 34: /**
> 35:  * This class implements specialized {@link StringTemplate StringTemplates} produced by

A cross reference to the public api the compiler uses to create these would be useful.
So the reader can find the place to start reading.

src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 187:

> 185:     @Override
> 186:     public StringTemplate newStringTemplate(List<String> fragments, List<?> values) {
> 187:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));

`values.toArray()` returns a new array; no need to stream the list content.
Alt: `Arrays.asList(values.toArray())`

src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 202:

> 200:     @SuppressWarnings({"unchecked", "varargs"})
> 201:     private static <E> List<E> toList(E... elements) {
> 202:         return Collections.unmodifiableList(Arrays.asList(elements));

Is a defensive copy needed here?
The caller of `newStringTemplate` could retain a reference to the Object[] array and modify it later.

src/java.base/share/classes/java/util/FormatProcessor.java line 102:

> 100:      *          specifier that is incompatible with the given arguments,
> 101:      *          insufficient arguments given the format string, or other
> 102:      *          illegal conditions.  For specification of all possible

This fragment "For specification of all possible formatting errors."
seems to be incomplete or unnecessary.

src/java.base/share/classes/java/util/FormatProcessor.java line 154:

> 152: 
> 153:     /**
> 154:      * Convert a {@link StringTemplate} fragments, containing format specifications,

Extraneous "a".

src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 51:

> 49:      *
> 50:      * @param lengthCoder current value of the length + coder
> 51:      * @param buffer      buffer to right into

right -> write

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

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

From tvaleev at openjdk.org  Wed Nov 16 21:21:42 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 16 Nov 2022 21:21:42 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <YBJ1r7Z_vgX7-38FMrbPTqHdkLSWrpHmNhDvjZRF-Pk=.c2e3c97d-99a1-4112-9f65-27a3daaf43be@github.com>

On Wed, 16 Nov 2022 20:25:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 202:
> 
>> 200:     @SuppressWarnings({"unchecked", "varargs"})
>> 201:     private static <E> List<E> toList(E... elements) {
>> 202:         return Collections.unmodifiableList(Arrays.asList(elements));
> 
> Is a defensive copy needed here?
> The caller of `newStringTemplate` could retain a reference to the Object[] array and modify it later.

Alternatively, `SharedSecrets.getJavaUtilCollectionAccess().listFromTrustedArrayNullsAllowed(elements)` (or `elements.clone()`) could be used here, to reduce amount of wrappers.

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

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

From mcimadamore at openjdk.org  Wed Nov 16 22:30:32 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 22:30:32 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v23]
In-Reply-To: <G8ewvmN2YJZVucF1UaTh_6M-6hChxmwdIeNvVtmkziY=.01f1cb3a-5658-497b-951c-79521426dc76@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <G8ewvmN2YJZVucF1UaTh_6M-6hChxmwdIeNvVtmkziY=.01f1cb3a-5658-497b-951c-79521426dc76@github.com>
Message-ID: <Di9V86tqktmFv8RAcE6TSAL8kvwHTi_Yi7QGmQaEKPg=.49f70708-162a-4830-96ec-5a5dd49389f0@github.com>

On Wed, 16 Nov 2022 20:33:50 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 two additional commits since the last revision:
> 
>  - Requested changes #8
>  - Update StringTemplate javadoc

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/java/lang/template/StringTemplate.java line 34:

> 32: 
> 33: /**
> 34:  * {@link StringTemplate StringTemplates} is the run-time representation of a

Suggestion:

 * {@link StringTemplate StringTemplate} is the run-time representation of a

src/java.base/share/classes/java/lang/template/StringTemplate.java line 218:

> 216: 
> 217:     /**
> 218:      * Returns a StringTemplate as if constructed by invoking

Suggestion:

     * Returns a {@code StringTemplate} as if constructed by invoking

src/java.base/share/classes/java/lang/template/StringTemplate.java line 233:

> 231: 
> 232:     /**
> 233:      * Returns a StringTemplate with the given fragments and values.

Suggestion:

     * Returns a {@code StringTemplate} with the given fragments and values.

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

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

From jlaskey at openjdk.org  Thu Nov 17 13:13:52 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 13:13:52 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <ocXvJUvP1LveBdzELB7EyA9yyWO5aczO7RBTELjKqTE=.8a31bd72-18a7-44a5-9865-906e4011d3e5@github.com>
Message-ID: <uuBXrZe8ILx6ngFLYY6pv7_vgrM_0Ia-2lXWKXhHCnA=.075e7f95-3fa7-4f5e-845b-1403a276031b@github.com>

On Wed, 16 Nov 2022 19:04:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1487:
> 
>> 1485:                                 if (typeArgs != null) return illegal();
>> 1486:                                 t = stringTemplate(t);
>> 1487:                                 typeArgs = null;
> 
> `typeArgs = null;` is unnecessary here, correct?

Changing.

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

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

From jlaskey at openjdk.org  Thu Nov 17 13:16:58 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 13:16:58 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <HynCZiiQrEAaKN-5-3fnrgXZlyuYX4PQ8YCXg9KQjxg=.15096675-d294-4beb-9312-b54d2b0cdf3b@github.com>

On Tue, 15 Nov 2022 19:40:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 102:
> 
>> 100:      *          specifier that is incompatible with the given arguments,
>> 101:      *          insufficient arguments given the format string, or other
>> 102:      *          illegal conditions.  For specification of all possible
> 
> This fragment "For specification of all possible formatting errors."
> seems to be incomplete or unnecessary.

Changing.

> src/java.base/share/classes/java/util/FormatProcessor.java line 154:
> 
>> 152: 
>> 153:     /**
>> 154:      * Convert a {@link StringTemplate} fragments, containing format specifications,
> 
> Extraneous "a".

Changing.

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

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

From jlaskey at openjdk.org  Thu Nov 17 13:20:08 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 13:20:08 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <qvf36blDG2lf3Muz4BBJwvSJPg_1FXGL6aPHe7Wxhg0=.bc3af033-ff9e-4acc-a7c5-3592efee188f@github.com>

On Tue, 15 Nov 2022 20:12:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 51:
> 
>> 49:      *
>> 50:      * @param lengthCoder current value of the length + coder
>> 51:      * @param buffer      buffer to right into
> 
> right -> write

Guilty, Changing.

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

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

From jlaskey at openjdk.org  Thu Nov 17 13:40:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 13:40:48 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <ZDMlgXrKA2EvivSbk3l0v2CsSp-2liR3Uw7YDF0qwaM=.e91440c8-18a1-4137-ac8e-74bad6e6b597@github.com>

On Tue, 15 Nov 2022 20:34:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 58:
> 
>> 56:  * optimized {@link StringTemplate StringTemplates} based on StringTemplateImpl.
>> 57:  * <p>
>> 58:  * Bootstraps in the for of (Lookup, String, MethodType, MethodHandle, String...)
> 
> "in the for" -> "in the form"

Changing.

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

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

From jlaskey at openjdk.org  Thu Nov 17 13:43:51 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 13:43:51 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <2Rf45bOhZrlM54_zIUPiwSOmQnDHZ631bQv5bmobpLs=.8647917f-ab40-4352-b5ea-0f3690f0108b@github.com>

On Tue, 15 Nov 2022 20:37:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 116:
> 
>> 114:      */
>> 115:     public static CallSite stringTemplateBSM(
>> 116:             MethodHandles.Lookup lookup,
> 
> The predominate style for method declarations puts the first argument on the same line as the method name
> and the closing ")" on the same line with the last argument and exceptions.

Changing.

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

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

From jlaskey at openjdk.org  Thu Nov 17 14:33:53 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 14:33:53 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <3N4k5AKwRqG2zYSKEI0geox6jj311x7Sm06gYzTOkto=.269f6bb0-bef9-49ee-8904-1c2ba560b513@github.com>

On Tue, 15 Nov 2022 22:12:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 291:
> 
>> 289: 
>> 290:     /**
>> 291:      * Interpolation template processor instance.
> 
> Flesh out this description since it is automatically imported and will appear in user code, it should have a clear description. (Same for RAW, expand the description).

Changing.

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

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

From jlaskey at openjdk.org  Thu Nov 17 14:40:06 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 14:40:06 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <ziZMuhzhB6uAwzo_eIL0875A38VyZeyTfRSO-_-uRXo=.76895c7a-542f-42d9-8b9c-0ef91ea52b8c@github.com>

On Tue, 15 Nov 2022 21:31:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/Carriers.java line 628:
> 
>> 626:      * types.
>> 627:      */
>> 628:     private static class CarrierShape {
> 
> Is this a candidate to be a Record?

I think the balance between what is supplied and what is computed leans heavily toward a class.

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

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

From jlaskey at openjdk.org  Thu Nov 17 15:13:00 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 15:13:00 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <Qw9on2MM6oFI9cK9wi4rTkkuZ_6c9XK21TvcJTEH90I=.03fac17e-809f-4480-b6d2-4d924ec5804f@github.com>

On Tue, 15 Nov 2022 21:56:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 38:
> 
>> 36: 
>> 37: /**
>> 38:  * The Java compiler produces implementations of {@link StringTemplate} to
> 
> I'd rather see a first sentence that says what a StringTemplate is, not who produces it.
> For example, a StringTemplate holds and controls the processing of the fragments and expressions of a string template.

Cleaned up ValidatingProcessor, TemplateProcessor and StringProcessor.

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

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

From jlaskey at openjdk.org  Thu Nov 17 15:17:56 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 15:17:56 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <1P9c6UcuLG_33tRPFU-NxDhYmJ8kxLQqGPJGHA4Ipvk=.00e98f52-0fa1-4c98-9ec9-763c099fdc61@github.com>

On Tue, 15 Nov 2022 22:02:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 189:
> 
>> 187: 
>> 188:     /**
>> 189:      * Produces a diagnostic string representing the supplied
> 
> The description should include that it describe the fragments and values.

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 208:
> 
>> 206: 
>> 207:     /**
>> 208:      * Returns a StringTemplate composed from a string.
> 
> and no values.

Changing.

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

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

From jlaskey at openjdk.org  Thu Nov 17 15:27:44 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 15:27:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <pCgbjbmnon28-IBOrPKqXBc8qBs_ZTRVPkRJ5oo1gZM=.99262557-5242-408b-ad1b-112503a1e9a8@github.com>

On Tue, 15 Nov 2022 22:05:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 249:
> 
>> 247: 
>> 248:     /**
>> 249:      * Creates a string that interleaves the elements of values between the
> 
> It might be worth noting that this is the same as STR::interpolate.

I think you mean `STR.process` but that might be misleading. `interpolate(List<String> fragments, List<?> values)` is actually the fallback method invoked by `STR.process`.

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

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

From jlaskey at openjdk.org  Thu Nov 17 15:34:44 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 15:34:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <KmeOi_zxlFF0mr5vyCoqnSoq4rQxb7pWl5O1sb4iNCU=.96b5484e-1594-4def-b882-ee0c84d16eb1@github.com>

On Tue, 15 Nov 2022 22:10:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 273:
> 
>> 271: 
>> 272:     /**
>> 273:       * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}.
> 
> The description should be more specific about how the lists of fragments and values are combined.
> For example, is each StringTemplate well formed and have the required string and value counts.
> (Or when combined, is it only the case that the total number of strings and values meet the n+1/n requirement.
> 
> 
> I'm not sure this API point pulls it weight in the API.

I think this javadoc was updated since.  What is happening here is non-trivial.  The use cases are primarily composing documents from several parts. Ex. an SQL PreparedStatement. You don's want to convert to string before processing, so concatenation won't do.

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

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

From jlaskey at openjdk.org  Thu Nov 17 15:47:57 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 15:47:57 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <7lw_BsakseQkwCJO2F5exX1WEf6g_d11AkLAp0C40pE=.2c967025-4dcf-4e90-a07d-c18fd95874b8@github.com>

On Tue, 15 Nov 2022 22:15:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplateImpl.java line 35:
> 
>> 33: 
>> 34: /**
>> 35:  * This class implements specialized {@link StringTemplate StringTemplates} produced by
> 
> A cross reference to the public api the compiler uses to create these would be useful.
> So the reader can find the place to start reading.

Links added.

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

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

From jlaskey at openjdk.org  Thu Nov 17 15:59:49 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 15:59:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <DlRhL3Z55wMbFu6ql4vlDqXQHXmCJ91_xSwzGDnoE0Q=.64766a9a-be88-4eac-9226-76e02689a56f@github.com>

On Tue, 15 Nov 2022 22:23:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1826:
> 
>> 1824: 
>> 1825:     // Used by StringConcatHelper via JLA.
>> 1826:     long mix(long lengthCoder) {
> 
> `mix` is not a very descriptive name (in all of the places it is used).
> Perhaps a name that captures the combination of coder and length.
> 
> `coderAndLength()` or similar
> 
> The implementation here can do the wrong thing if the `lengthCoder` already includes the bit for UTF16
> and the coder for the AbstractStringBuilder is LATIN1. Or is intentional that it will upgrade to UTF16?
> That could definately use a comment.

The goal here is to take the contents of a `StringBuilder/StringBuffer `without first converting to a string when referenced by `StringConcatFactory`. So the terminology is a carry over from `StringConcatFactory` and `StringConcatHelper`.

I agree `mix` is weird but historically, it is what it is. Maybe a separate task to rename is in order.

The implementation is deliberate. If something in the list of things being concatenated is UTF16, then everything being concatenated is upgraded to UTF16.

I'll add commentary.

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

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

From jlaskey at openjdk.org  Thu Nov 17 16:24:11 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 16:24:11 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <XIEloBbQu5ANBgUfRcpBnJzixlhc4G21GXqmFW3_dNo=.e5ee40b9-feac-42ff-aa15-8dd43a97be1f@github.com>

On Wed, 16 Nov 2022 20:22:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 187:
> 
>> 185:     @Override
>> 186:     public StringTemplate newStringTemplate(List<String> fragments, List<?> values) {
>> 187:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));
> 
> `values.toArray()` returns a new array; no need to stream the list content.
> Alt: `Arrays.asList(values.toArray())`

This is to ensure type Object[]. Ex,. if the user passes in a List<String>.

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

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

From duke at openjdk.org  Thu Nov 17 16:58:26 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 17 Nov 2022 16:58:26 GMT
Subject: <i18n dev> Integrated: 8287180: Update IANA Language Subtag
 Registry to Version 2022-08-08
In-Reply-To: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
References: <BBcOX-VUNuDfKu7bBKToRDJ-vkUNDMtoSq92iFhDamk=.b9d9f098-25ca-458c-9653-90b1988d0f61@github.com>
Message-ID: <JJOY8jyD0luFuJQ0tat3h8CeMwD6HjOCqmGaXd1u3oM=.9ee32e24-49fc-4106-8013-f0e68d7c04cb@github.com>

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

> Problem: IANA Language subtag registry is outdated
> Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)

This pull request has now been integrated.

Changeset: 992f209d
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/992f209deffac50635646b42ec4220bfbfc96d39
Stats:     16 lines in 2 files changed: 14 ins; 0 del; 2 mod

8287180: Update IANA Language Subtag Registry to Version 2022-08-08

Reviewed-by: naoto, lancea, iris

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

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

From jlaskey at openjdk.org  Thu Nov 17 17:09:52 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 17:09:52 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <YBJ1r7Z_vgX7-38FMrbPTqHdkLSWrpHmNhDvjZRF-Pk=.c2e3c97d-99a1-4112-9f65-27a3daaf43be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
 <YBJ1r7Z_vgX7-38FMrbPTqHdkLSWrpHmNhDvjZRF-Pk=.c2e3c97d-99a1-4112-9f65-27a3daaf43be@github.com>
Message-ID: <b-XkOcnKNJ2wnYYSICrbiEPzRHcqiFnMvEC6mTaAwWE=.50ca7a21-91c5-493b-bf13-8f7344139041@github.com>

On Wed, 16 Nov 2022 21:19:21 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 202:
>> 
>>> 200:     @SuppressWarnings({"unchecked", "varargs"})
>>> 201:     private static <E> List<E> toList(E... elements) {
>>> 202:         return Collections.unmodifiableList(Arrays.asList(elements));
>> 
>> Is a defensive copy needed here?
>> The caller of `newStringTemplate` could retain a reference to the Object[] array and modify it later.
>
> Alternatively, `SharedSecrets.getJavaUtilCollectionAccess().listFromTrustedArrayNullsAllowed(elements)` (or `elements.clone()`) could be used here, to reduce amount of wrappers.

The `newStringTemplate` methods are internal and elements is safe. Will get rid of the generics and varargs.  

@amaembo I was using listFromTrustedArrayNullsAllowed early on but ran into an edge case (crash). Will try again.

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

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

From jlaskey at openjdk.org  Thu Nov 17 17:15:53 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 17:15:53 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v23]
In-Reply-To: <Di9V86tqktmFv8RAcE6TSAL8kvwHTi_Yi7QGmQaEKPg=.49f70708-162a-4830-96ec-5a5dd49389f0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <G8ewvmN2YJZVucF1UaTh_6M-6hChxmwdIeNvVtmkziY=.01f1cb3a-5658-497b-951c-79521426dc76@github.com>
 <Di9V86tqktmFv8RAcE6TSAL8kvwHTi_Yi7QGmQaEKPg=.49f70708-162a-4830-96ec-5a5dd49389f0@github.com>
Message-ID: <RWZQNYTnFHCivREBqyxqoW5hXfoUj77ypPsxjbpvC-4=.34510118-f3af-42ad-ac67-8a5f287a877c@github.com>

On Wed, 16 Nov 2022 21:43:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Requested changes #8
>>  - Update StringTemplate javadoc
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 34:
> 
>> 32: 
>> 33: /**
>> 34:  * {@link StringTemplate StringTemplates} is the run-time representation of a
> 
> Suggestion:
> 
>  * {@link StringTemplate StringTemplate} is the run-time representation of a

Stale.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 218:
> 
>> 216: 
>> 217:     /**
>> 218:      * Returns a StringTemplate as if constructed by invoking
> 
> Suggestion:
> 
>      * Returns a {@code StringTemplate} as if constructed by invoking

Stale

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 233:
> 
>> 231: 
>> 232:     /**
>> 233:      * Returns a StringTemplate with the given fragments and values.
> 
> Suggestion:
> 
>      * Returns a {@code StringTemplate} with the given fragments and values.

Stale.

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

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

From jlaskey at openjdk.org  Thu Nov 17 17:31:09 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 17:31:09 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v24]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <UMQd8Q8L4lCQB6hRBUxletcj69nsuCn1Sls-8ucSyzY=.9f06f852-a2f3-4fcf-b60d-8897a0d03f55@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:

  Requested changes #9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/2edc7925..89f9ac02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=22-23

  Stats: 170 lines in 10 files changed: 66 ins; 28 del; 76 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  Thu Nov 17 17:31:11 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 17 Nov 2022 17:31:11 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <PPsKoHPCqPJ14eXAt-dM79lw_eBJ727LNJrk8vXXbcA=.dfc7d49a-2183-4909-bade-2f44413ed77f@github.com>
Message-ID: <Gk4PKWncB_AaMH32XNJh3n-BPeHIi_o4xvfCvq3G6PA=.8f42e2de-12cf-4fdb-9eaf-2e08b5aead2b@github.com>

On Tue, 15 Nov 2022 21:47:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrong line separator
>
> src/java.base/share/classes/java/lang/template/StringProcessor.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * This interface simplifies declaration of
> 
> The first sentence should describe the purpose or function of the interface.
> The "simplify declaration" language is a design rationale, not a functional description of the interface.

Changing.

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

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

From rriggs at openjdk.org  Thu Nov 17 22:36:52 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Nov 2022 22:36:52 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v23]
In-Reply-To: <G8ewvmN2YJZVucF1UaTh_6M-6hChxmwdIeNvVtmkziY=.01f1cb3a-5658-497b-951c-79521426dc76@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <G8ewvmN2YJZVucF1UaTh_6M-6hChxmwdIeNvVtmkziY=.01f1cb3a-5658-497b-951c-79521426dc76@github.com>
Message-ID: <W4hhM4GvVl39R_IPZ0hOjh4qePXFY0H26QfuSK4eIGw=.abd2a254-923b-445f-8ad2-ffc89bbf781a@github.com>

On Wed, 16 Nov 2022 20:33:50 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 two additional commits since the last revision:
> 
>  - Requested changes #8
>  - Update StringTemplate javadoc

src/java.base/share/classes/java/lang/template/StringTemplate.java line 87:

> 85:  * alternative to using string template expressions.
> 86:  * {@snippet :
> 87:  * StringTemplate st = RAW."\{x} + \{y} = \{x + y}";

RAW and STR are used in similar ways in the examples but RAW produces a compilation error.
Somewhere obvious there should be an API note that RAW needs an explicit import static whereas STR is imported automatically.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 120:

> 118:      * String student = "Mary";
> 119:      * String teacher = "Johnson";
> 120:      * StringTemplate st = RAW."The student \{student} is in \{teacher}'s class room.";

typo?  "class room" -> "classroom" or just "class"
Also below.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 176:

> 174:      * String result2 = RAW."The student \{student} is in \{teacher}'s class room.".process(STR); // @highlight substring="process"
> 175:      * }
> 176:      * produces an equivalent result for both {@code result1} and {@code result2}.

Capitalize this sentence.  "Produces"...

src/java.base/share/classes/java/lang/template/StringTemplate.java line 188:

> 186:      * @throws NullPointerException if processor is null
> 187:      *
> 188:      * @implNote The default implementation invokes the processor's process

too many processes...
Perhaps:

... `invokes the {@code processor.process(this)} method.`

src/java.base/share/classes/java/lang/template/StringTemplate.java line 298:

> 296:      *
> 297:      * @throws NullPointerException if sts is null or if any of the elements are null
> 298:      * @throws RuntimeException if sts has zero elements

The RuntimeException may be a leftover; TemplateSupport.combine(sts) allows there to be zero elements.
(And RuntimeException is too general for the described case, perhaps IllegalArgumentException)

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

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

From jlaskey at openjdk.org  Fri Nov 18 13:19:04 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 18 Nov 2022 13:19:04 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v23]
In-Reply-To: <W4hhM4GvVl39R_IPZ0hOjh4qePXFY0H26QfuSK4eIGw=.abd2a254-923b-445f-8ad2-ffc89bbf781a@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <G8ewvmN2YJZVucF1UaTh_6M-6hChxmwdIeNvVtmkziY=.01f1cb3a-5658-497b-951c-79521426dc76@github.com>
 <W4hhM4GvVl39R_IPZ0hOjh4qePXFY0H26QfuSK4eIGw=.abd2a254-923b-445f-8ad2-ffc89bbf781a@github.com>
Message-ID: <rQl5XAQyDspgsRcjFN2zNWu2jxk3e61KgLiI2oWOEPE=.e88cb935-500b-4095-9afd-372959d0d994@github.com>

On Thu, 17 Nov 2022 15:46:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Requested changes #8
>>  - Update StringTemplate javadoc
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 188:
> 
>> 186:      * @throws NullPointerException if processor is null
>> 187:      *
>> 188:      * @implNote The default implementation invokes the processor's process
> 
> too many processes...
> Perhaps:
> 
> ... `invokes the {@code processor.process(this)} method.`

Changing.

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

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

From jlaskey at openjdk.org  Fri Nov 18 13:19:07 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 18 Nov 2022 13:19:07 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v13]
In-Reply-To: <MRu9qdwlo6sP8wht81DLUaoiaazGdlj1bk4nDbtJ13E=.6249d107-bd1b-4121-8908-db640235753c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <YDSVJXl7hCAIaE-npeD30AiKs-i6ffGfN5Exc06qm1g=.e4f143df-d293-4856-82ac-2aa42665d4e7@github.com>
 <MRu9qdwlo6sP8wht81DLUaoiaazGdlj1bk4nDbtJ13E=.6249d107-bd1b-4121-8908-db640235753c@github.com>
Message-ID: <ymK1w3jTNKDiHPQBpoXluZgtPBWR-qqeCRZaaMQhamM=.666e11cb-3a77-4bfb-97ed-430142c3a1cd@github.com>

On Wed, 9 Nov 2022 22:43:40 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/FormatItem.java line 75:
>> 
>>> 73:         try {
>>> 74:             return (long)CHAR_MIX.invokeExact(lengthCoder, value);
>>> 75:         } catch (RuntimeException ex) {
>> 
>> This?should also?rethrow `Error`?instances:
>> Suggestion:
>> 
>>         } catch (Error | RuntimeException ex) {
>
> Changing

Changing.

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

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

From jlaskey at openjdk.org  Fri Nov 18 13:19:10 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 18 Nov 2022 13:19:10 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v13]
In-Reply-To: <jmjb0HXagualKvyhqaShxIi5C-wJs4ITM6ivN1xz7wY=.d2b1b4c8-c9b7-477d-901f-e8b89d35b2d9@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <V4jJxWappjx2D-5et-S72MqG80Hd_RaaIpB3ew9K55I=.bdf64e36-1f94-4140-af26-5390b62766d2@github.com>
 <gmSZZADjXMwU37RzrZ6NjacBL6WHwemrGm4NEIarXIY=.9b67d235-73fa-4b0e-a242-c7c151a8d435@github.com>
 <jmjb0HXagualKvyhqaShxIi5C-wJs4ITM6ivN1xz7wY=.d2b1b4c8-c9b7-477d-901f-e8b89d35b2d9@github.com>
Message-ID: <ipdHct7WXGSVckMknIKJm58n0SS16J_oP3MsHTlmHBY=.99ea5b54-8741-45e5-bc42-d9bd67d08390@github.com>

On Wed, 9 Nov 2022 22:44:38 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/FormatProcessor.java line 38:
>> 
>>> 36: 
>>> 37: /**
>>> 38:  * This {@linkplain ValidatingProcessor yemplate processor} constructs a String
>> 
>> Typo: "yemplate processor".
>
> Changing

Changing.

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

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

From jlaskey at openjdk.org  Fri Nov 18 13:27:53 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 18 Nov 2022 13:27:53 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <I1_RRiPREUYT4MHCclWeDLS65Miaf-q08pWwqBK9XuU=.1fb574e8-f8a4-485a-b430-a77afd96beef@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
 <I1_RRiPREUYT4MHCclWeDLS65Miaf-q08pWwqBK9XuU=.1fb574e8-f8a4-485a-b430-a77afd96beef@github.com>
Message-ID: <GmPcatVHORukD_L54Z8G8Xc6gryeIy7c5LxTXuFYkXo=.b7985aa2-4cef-4b77-98f0-40d754990bf1@github.com>

On Wed, 16 Nov 2022 18:31:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/FormatProcessor.java line 39:
>> 
>>> 37: /**
>>> 38:  * This {@linkplain ValidatingProcessor template processor} constructs a String
>>> 39:  * result using {@link Formatter}. Unlike {@link Formatter}, FormatProcessor uses the value from
>> 
>> And `FormatProcessor` too
>
> Changing.

Changing.

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

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

From jlaskey at openjdk.org  Fri Nov 18 13:37:50 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 18 Nov 2022 13:37:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v21]
In-Reply-To: <fOtMxqQcu6o2a-RyRXOvdykV2eAVj04rHSZBHnkCxRA=.6d3e26ed-547f-42fd-964e-22565683899b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <QAj4I-mZdUSr9AKZmwvYCGv8xhri2ZJlWGT0iITKsrw=.00df40f4-7013-44f5-913b-2161e75ecb08@github.com>
 <OSLQBFDmtWI0i7tbnZOetae3vjjAyfpYv2fSY_LqgsY=.b7f8a1a0-8b47-467c-a0dc-f2ec61c221a2@github.com>
 <nisWsPx-lijx5dxbf76OXYOk3FzDdmIsSQ9QUIGTidM=.ef5f242d-35bc-413c-b3dd-e3989cf7d00f@github.com>
 <fOtMxqQcu6o2a-RyRXOvdykV2eAVj04rHSZBHnkCxRA=.6d3e26ed-547f-42fd-964e-22565683899b@github.com>
Message-ID: <64AZLdWKu5YREx2-YJMax9nl66Uo5ONl__B49aWa1TM=.df4d78ea-ddf7-47f3-804f-b78e28153174@github.com>

On Wed, 16 Nov 2022 18:32:19 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> And, `StringTemplate` is missing a surrounding code/link tag
>
> Changing.

Changing.

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

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

From jlaskey at openjdk.org  Fri Nov 18 13:53:37 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 18 Nov 2022 13:53:37 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v25]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <x3uNd6_VnHn5mNTHDQpRr2n3sW0IW0_WWD_59o0akSE=.722444a1-1f0c-4261-84cb-b91f23f087ae@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:

  Requested changes #10

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/89f9ac02..fc679656

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=23-24

  Stats: 26 lines in 1 file changed: 10 ins; 2 del; 14 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 Nov 18 14:10:11 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 18 Nov 2022 14:10:11 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@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:

  Typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/fc679656..c51f88c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=24-25

  Stats: 1 line in 1 file changed: 0 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 rriggs at openjdk.org  Fri Nov 18 23:10:09 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Nov 2022 23:10:09 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
Message-ID: <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>

On Fri, 18 Nov 2022 14:10:11 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:
> 
>   Typo

src/java.base/share/classes/java/lang/template/StringProcessor.java line 49:

> 47:  * @implNote Implementations using {@link StringProcessor} are equivalent to implementations using
> 48:  * {@code TemplateProcessor<String>} or {@code ValidatingProcessor<String, RuntimeException>},
> 49:  * however the dominance of {@link String} producing template processors supercedes the redundancy.

Amusing to read...  
Perhaps just,  "however, StringProcessor is clearer and easier to understand".

src/java.base/share/classes/java/lang/template/StringTemplate.java line 35:

> 33: /**
> 34:  * {@link StringTemplate} is the run-time representation of a string template or
> 35:  * text block template in a template expression.

Can the link to the JLS 15.8.6 be included earlier so the definition of "template expression" isn't hanging until the end of the class javadoc.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 115:

> 113: public interface StringTemplate {
> 114:     /**
> 115:      * Returns s list of fragment literals for this {@link StringTemplate}.

Suggestion:

     * Returns a list of fragment literals for this {@link StringTemplate}.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 155:

> 153:      * For better visibility and when practical, it is recommended that users use the
> 154:      * {@link StringTemplate#STR} processor instead of invoking the
> 155:      * {@link StringTemplate#interpolate()} method directly.

Removing "users use"...

Suggestion:

     * For better visibility and when practical, it is recommended to use the
     * {@link StringTemplate#STR} processor instead of invoking the
     * {@link StringTemplate#interpolate()} method.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 206:

> 204:      * @param stringTemplate  the {@link StringTemplate} to represent
> 205:      *
> 206:      * @return diagnostic string representing the supplied templated string

Suggestion:

     * @return diagnostic string representing the supplied string template

src/java.base/share/classes/java/lang/template/StringTemplate.java line 300:

> 298:      * {@link StringTemplate StringTemplates}.
> 299:      *
> 300:      * @param stringTemplates  one or more {@link StringTemplate}

Suggestion:

     * @param stringTemplates  zero or more {@link StringTemplate}


Also the comment in `TemplateSupport.combine` should say zero or more.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 317:

> 315:     /**
> 316:      * The {@link StringProcessor} instance conventionally used for the string interpolation
> 317:      * of a supplied {@link StringTemplate}.

Suggestion:

     * The {@link StringProcessor} instance is conventionally used for the string interpolation
     * of a supplied {@link StringTemplate}.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 334:

> 332:     /**
> 333:      * The {@link TemplateProcessor} instance conventionally used to indicate that the
> 334:      * processing of the {@link StringTemplate} is to be deferred to a later time. Deferred

Suggestion:

     * The {@link TemplateProcessor} instance is conventionally used to indicate that the
     * processing of the {@link StringTemplate} is to be deferred to a later time. Deferred

src/java.base/share/classes/java/lang/template/package-info.java line 27:

> 25: 
> 26: /**
> 27:  * Provides support for string templates and template processors.

Not just support...

String templates are provided by {@link StringTemplate} and supporting interfaces and classes.
It might also be helpful to include a link to the JLS 15.8.6 Template Expression spec.

A brief example here (drawn from the JEP or StringTemplate would provide a good hook for the reader to get started.

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

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

From rriggs at openjdk.org  Fri Nov 18 23:10:12 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Nov 2022 23:10:12 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v23]
In-Reply-To: <RWZQNYTnFHCivREBqyxqoW5hXfoUj77ypPsxjbpvC-4=.34510118-f3af-42ad-ac67-8a5f287a877c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <G8ewvmN2YJZVucF1UaTh_6M-6hChxmwdIeNvVtmkziY=.01f1cb3a-5658-497b-951c-79521426dc76@github.com>
 <Di9V86tqktmFv8RAcE6TSAL8kvwHTi_Yi7QGmQaEKPg=.49f70708-162a-4830-96ec-5a5dd49389f0@github.com>
 <RWZQNYTnFHCivREBqyxqoW5hXfoUj77ypPsxjbpvC-4=.34510118-f3af-42ad-ac67-8a5f287a877c@github.com>
Message-ID: <w5fa7-tklitlpg1rhGnJbTOdazbYU1YSbVf-dk1WMIM=.99383012-734e-4eca-96dc-14c4760034c2@github.com>

On Thu, 17 Nov 2022 17:12:53 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 233:
>> 
>>> 231: 
>>> 232:     /**
>>> 233:      * Returns a StringTemplate with the given fragments and values.
>> 
>> Suggestion:
>> 
>>      * Returns a {@code StringTemplate} with the given fragments and values.
>
> Stale.

Seems not to have been addressed, the previous `of` method uses {@link...}

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

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

From jlaskey at openjdk.org  Mon Nov 21 12:47:45 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 21 Nov 2022 12:47:45 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
 <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
Message-ID: <6ZJz5F38mg_IpViGodZp7sCIgD06ELqefF89iIzK-IE=.0695a46a-613d-44d9-9a10-33c2e39b5b4a@github.com>

On Fri, 18 Nov 2022 23:05:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/java.base/share/classes/java/lang/template/StringProcessor.java line 49:
> 
>> 47:  * @implNote Implementations using {@link StringProcessor} are equivalent to implementations using
>> 48:  * {@code TemplateProcessor<String>} or {@code ValidatingProcessor<String, RuntimeException>},
>> 49:  * however the dominance of {@link String} producing template processors supercedes the redundancy.
> 
> Amusing to read...  
> Perhaps just,  "however, StringProcessor is clearer and easier to understand".

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 115:
> 
>> 113: public interface StringTemplate {
>> 114:     /**
>> 115:      * Returns s list of fragment literals for this {@link StringTemplate}.
> 
> Suggestion:
> 
>      * Returns a list of fragment literals for this {@link StringTemplate}.

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 155:
> 
>> 153:      * For better visibility and when practical, it is recommended that users use the
>> 154:      * {@link StringTemplate#STR} processor instead of invoking the
>> 155:      * {@link StringTemplate#interpolate()} method directly.
> 
> Removing "users use"...
> 
> Suggestion:
> 
>      * For better visibility and when practical, it is recommended to use the
>      * {@link StringTemplate#STR} processor instead of invoking the
>      * {@link StringTemplate#interpolate()} method.

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 206:
> 
>> 204:      * @param stringTemplate  the {@link StringTemplate} to represent
>> 205:      *
>> 206:      * @return diagnostic string representing the supplied templated string
> 
> Suggestion:
> 
>      * @return diagnostic string representing the supplied string template

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 317:
> 
>> 315:     /**
>> 316:      * The {@link StringProcessor} instance conventionally used for the string interpolation
>> 317:      * of a supplied {@link StringTemplate}.
> 
> Suggestion:
> 
>      * The {@link StringProcessor} instance is conventionally used for the string interpolation
>      * of a supplied {@link StringTemplate}.

Same issue as `STR`.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 334:
> 
>> 332:     /**
>> 333:      * The {@link TemplateProcessor} instance conventionally used to indicate that the
>> 334:      * processing of the {@link StringTemplate} is to be deferred to a later time. Deferred
> 
> Suggestion:
> 
>      * The {@link TemplateProcessor} instance is conventionally used to indicate that the
>      * processing of the {@link StringTemplate} is to be deferred to a later time. Deferred

Interestingly enough, someone asked me to remove the 'is'. If you leave the 'is' in it read as 'The TemplateProcessor instance is used to indicate that the' vs 'The TemplateProcessor instance used to indicate that the' which makes more sense. Maybe 'This TemplateProcessor instance is used to indicate that the'. Changing.

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

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

From jlaskey at openjdk.org  Mon Nov 21 12:54:52 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 21 Nov 2022 12:54:52 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
 <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
Message-ID: <zxsom3Cbu9TwfMhaKpSE5awJyldRPkOov0GKtire9tY=.b847ab11-0c12-411f-86aa-a301228d7e4e@github.com>

On Fri, 18 Nov 2022 23:00:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 35:
> 
>> 33: /**
>> 34:  * {@link StringTemplate} is the run-time representation of a string template or
>> 35:  * text block template in a template expression.
> 
> Can the link to the JLS 15.8.6 be included earlier so the definition of "template expression" isn't hanging until the end of the class javadoc.

Didn't know that it was positional. Will change.

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

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

From jlaskey at openjdk.org  Mon Nov 21 13:42:15 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 21 Nov 2022 13:42:15 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
 <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
Message-ID: <rn7X31KiMcctpEcEuFi4cV4FvIQneO-ga9iUGio46aY=.c6567cf9-191f-46c3-b203-a0a108f0bb38@github.com>

On Fri, 18 Nov 2022 22:25:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/java.base/share/classes/java/lang/template/package-info.java line 27:
> 
>> 25: 
>> 26: /**
>> 27:  * Provides support for string templates and template processors.
> 
> Not just support...
> 
> String templates are provided by {@link StringTemplate} and supporting interfaces and classes.
> It might also be helpful to include a link to the JLS 15.8.6 Template Expression spec.
> 
> A brief example here (drawn from the JEP or StringTemplate would provide a good hook for the reader to get started.

Will expand.

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

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

From jlaskey at openjdk.org  Mon Nov 21 14:58:47 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 21 Nov 2022 14:58:47 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <zxsom3Cbu9TwfMhaKpSE5awJyldRPkOov0GKtire9tY=.b847ab11-0c12-411f-86aa-a301228d7e4e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
 <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
 <zxsom3Cbu9TwfMhaKpSE5awJyldRPkOov0GKtire9tY=.b847ab11-0c12-411f-86aa-a301228d7e4e@github.com>
Message-ID: <4F14OGh3NmKE0zOCPRRn9FWFzDmwWZAA7Jzy1868NhY=.91b4c725-67e2-409b-ab3b-d6307159bd24@github.com>

On Mon, 21 Nov 2022 12:52:42 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 35:
>> 
>>> 33: /**
>>> 34:  * {@link StringTemplate} is the run-time representation of a string template or
>>> 35:  * text block template in a template expression.
>> 
>> Can the link to the JLS 15.8.6 be included earlier so the definition of "template expression" isn't hanging until the end of the class javadoc.
>
> Didn't know that it was positional. Will change.

Turns out that @jls is sensitive to its position.

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

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

From redestad at openjdk.org  Mon Nov 21 14:58:49 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 21 Nov 2022 14:58:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
Message-ID: <bgcsajWvpsy5B4M1hyy_ToOEeTnt4TiWMoKEgttW_pc=.83523ccb-8d04-4855-9907-bdfa23b48f3d@github.com>

On Fri, 18 Nov 2022 14:10:11 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:
> 
>   Typo

src/java.base/share/classes/java/util/Digits.java line 39:

> 37:  */
> 38: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 39: interface Digits {

Should this be modeled as an `abstract sealed` class hierarchy instead?

test/micro/org/openjdk/bench/java/lang/template/StringTemplateFMT.java line 41:

> 39: /*
> 40:  * This benchmark measures StringTemplate.FMT FormatProcessor performance;
> 41:  * exactly mirroring {@link org.openjdk.bench.java.lang.StringFormat} benchmark

While it's good to mirror the `StringFormat` benchmark, I think we'd see benefit from building this out to be a bit more comprehensive and for example cover `FormatConcatItem` cases. What you have here is probably good enough for first integration, though.

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

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

From jlaskey at openjdk.org  Mon Nov 21 15:42:55 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 21 Nov 2022 15:42:55 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
 <aPSRrhujt-e25jM5fA6L_PS8cIjTFsuBNLRJew9B6BU=.395e43b2-23d6-4a18-92a0-3140741e5f74@github.com>
Message-ID: <wOzKZPSgf9Y_p0S9myYMhWorai4EtujX2OEVKgP30fs=.56555ca8-b3b0-4373-a218-109f0fbd213f@github.com>

On Fri, 18 Nov 2022 22:34:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 300:
> 
>> 298:      * {@link StringTemplate StringTemplates}.
>> 299:      *
>> 300:      * @param stringTemplates  one or more {@link StringTemplate}
> 
> Suggestion:
> 
>      * @param stringTemplates  zero or more {@link StringTemplate}
> 
> 
> Also the comment in `TemplateSupport.combine` should say zero or more.

Changing.

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

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

From jlaskey at openjdk.org  Mon Nov 21 16:22:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 21 Nov 2022 16:22:28 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v27]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <PkcxE57gmoIMvqqo9QuQBBLp-DRHL9iQ1T8kOXowHLY=.47094f88-8090-4770-856b-d317f60fbf85@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:

  Requested changes #11

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/c51f88c7..f2562ab3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=25-26

  Stats: 85 lines in 6 files changed: 73 ins; 2 del; 10 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  Mon Nov 21 17:43:16 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 21 Nov 2022 17:43:16 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v28]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@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:

  Seal Digits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f2562ab3..da3ea20d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=26-27

  Stats: 1 line in 1 file changed: 0 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 jlaskey at openjdk.org  Mon Nov 21 17:43:20 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 21 Nov 2022 17:43:20 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v26]
In-Reply-To: <bgcsajWvpsy5B4M1hyy_ToOEeTnt4TiWMoKEgttW_pc=.83523ccb-8d04-4855-9907-bdfa23b48f3d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Cnh6z1kaGvOZYPR2g3GsqiPq4FcuX9BrEhpwDEYwoGQ=.a727a55f-1931-4181-baca-2ea2545c6508@github.com>
 <bgcsajWvpsy5B4M1hyy_ToOEeTnt4TiWMoKEgttW_pc=.83523ccb-8d04-4855-9907-bdfa23b48f3d@github.com>
Message-ID: <7kOOlCeqtY0VNYWGrxWKkU9bDAHsf8HK_Fc4cqdpEN8=.4dbbf505-2b12-431c-b701-0080dedd16d9@github.com>

On Mon, 21 Nov 2022 13:38:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/java.base/share/classes/java/util/Digits.java line 39:
> 
>> 37:  */
>> 38: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 39: interface Digits {
> 
> Should this be modeled as an `abstract sealed` class hierarchy instead?

Changing

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

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

From rriggs at openjdk.org  Tue Nov 22 19:33:07 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Nov 2022 19:33:07 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v28]
In-Reply-To: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com>
Message-ID: <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>

On Mon, 21 Nov 2022 17:43:16 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:
> 
>   Seal Digits

Javadoc suggestions around readability, linking.

src/java.base/share/classes/java/lang/template/StringProcessor.java line 58:

> 56:     /**
> 57:      * Constructs a {@link String} based on the template fragments and values in the
> 58:      * supplied {@link StringTemplate stringTemplate} object.

When reading the javadoc, I expected the type name, not the variable name.
Suggestion:

     * supplied {@link StringTemplate StringTemplate} object.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 52:

> 50:  * given by the template expression.
> 51:  * <p>
> 52:  * For example, the following code contains a template expression that uses the template

Though this is trying to explain the general mechanism, it might be more useful to readers to start with the most common use case, that of using a string processor. Swapping the order of the examples possibly.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 63:

> 61:  * {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
> 62:  * which includes the empty first and last fragments. {@code values} will be the
> 63:  * equivalent of {@code List.of(10, 20, 30)}.

Find a way to capitalize the first word of the sentence.
Suggestion:

 * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
 * which includes the empty first and last fragments. The {@code values} will be the
 * equivalent of {@code List.of(10, 20, 30)}.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 66:

> 64:  * <p>
> 65:  * The following code contains a template expression with the same template but a
> 66:  * different template processor:

Suggestion:

 * The following code contains a template expression with the same template but a
 * string template processor:

src/java.base/share/classes/java/lang/template/StringTemplate.java line 75:

> 73:  * produced that returns the same lists from {@link StringTemplate#fragments()} and
> 74:  * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template
> 75:  * processor uses these lists to yield an interpolated string. {@code s} will be equivalent to

Suggestion:

 * processor uses these lists to yield an interpolated string. The value of {@code s} will be equivalent to

src/java.base/share/classes/java/lang/template/StringTemplate.java line 319:

> 317:      * This {@link StringProcessor} instance is conventionally used for the string interpolation
> 318:      * of a supplied {@link StringTemplate}.
> 319:      * <p>

It should be mentioned that the string representations are created as if invoking {@link String#valueOf}.
An perhaps a link/@see to `FMT` for control over formatting.  

Also include it in the javadoc for `interpolate`.

src/java.base/share/classes/java/lang/template/package-info.java line 57:

> 55:  *{@link java.lang.template.StringTemplate}. The end result of the process template
> 56:  * expression is the value that is produced by invoking the processor's
> 57:  *{@link java.lang.template.ValidatingProcessor#process(StringTemplate)}

I would reduce the use of "proper", it should be sufficient to describe them without the qualifier.
The single use of "improper" is fine to warn of compilation errors.

Also, add a space between "*" and "{".

src/java.base/share/classes/java/lang/template/package-info.java line 61:

> 59:  * improper processor arguments result in compilation errors.
> 60:  * <p>
> 61:  * In the example, {@code STR."The result of adding \{x} and \{y} is \{x + y}."},

Maybe avoid the repetition of the example.
Suggestion:

 * In the example above,

src/java.base/share/classes/java/lang/template/package-info.java line 76:

> 74:  * String literals and text blocks can be used as proper processor arguments as
> 75:  * well. This is automatically facilitated by the Java compiler converted the
> 76:  * strings to {@link java.lang.template.StringTemplate StringTemplate} using the

Suggestion:

 * well. This is automatically facilitated by the Java compiler converting the
 * strings to {@link java.lang.template.StringTemplate StringTemplate} using the

src/java.base/share/classes/java/lang/template/package-info.java line 79:

> 77:  * {@link java.lang.template.StringTemplate#of(String)} method.
> 78:  * <p>
> 79:  * Users can create their own template processors by implementing either

Suggestion:

 * Users can create their own template processors by implementing one of

src/java.base/share/classes/java/lang/template/package-info.java line 83:

> 81:  * {@link java.lang.template.TemplateProcessor} or
> 82:  * {@link java.lang.template.StringProcessor} interfaces.
> 83:  * See {@link java.lang.template.ValidatingProcessor} for examples and details.

I would give the reader a firm what to read next suggestion.
It may be useful to mention and link to the `FMT` processor as a way to control the formatting of the values.
Suggestion:

 * For more examples and details see  {@link java.lang.template.StringTemplate} and 
 * {@link java.lang.template.ValidatingProcessor}.

src/java.base/share/classes/java/util/FormatProcessor.java line 64:

> 62:  *
> 63:  * @implSpec Since, values are found within the string template, argument indexing
> 64:  * specifiers are unsupported.

What is the behavior of a format that references an index?  Ignored, throw?
I can see an argument for simplicity, but the values are a sequential list similar to that of a varargs call to format("xx", x, y, z, ...) so it can be well defined to what value an index in the format refers.

src/java.base/share/classes/java/util/FormatProcessor.java line 196:

> 194:      * <a href="../../util/Formatter.html#syntax">format specifier</a>.
> 195:      * StringTemplate expressions without a preceeding specifier, use "%s" by
> 196: 

Its worth specifying the locale that is used by FMT, is it `Locale.ROOT`?
If it is `Locale.default`, the results may vary from run to run.

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

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

From jlaskey at openjdk.org  Tue Nov 22 19:58:59 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 22 Nov 2022 19:58:59 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v28]
In-Reply-To: <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com>
 <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
Message-ID: <txXMZJ_a4LMyMtslZIL0hYFOICSuvm38c_TWU-OVwgM=.a7476e74-faab-40e5-99ad-725698d3f0d1@github.com>

On Tue, 22 Nov 2022 18:17:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Seal Digits
>
> src/java.base/share/classes/java/lang/template/package-info.java line 57:
> 
>> 55:  *{@link java.lang.template.StringTemplate}. The end result of the process template
>> 56:  * expression is the value that is produced by invoking the processor's
>> 57:  *{@link java.lang.template.ValidatingProcessor#process(StringTemplate)}
> 
> I would reduce the use of "proper", it should be sufficient to describe them without the qualifier.
> The single use of "improper" is fine to warn of compilation errors.
> 
> Also, add a space between "*" and "{".

Changing.

> src/java.base/share/classes/java/lang/template/package-info.java line 61:
> 
>> 59:  * improper processor arguments result in compilation errors.
>> 60:  * <p>
>> 61:  * In the example, {@code STR."The result of adding \{x} and \{y} is \{x + y}."},
> 
> Maybe avoid the repetition of the example.
> Suggestion:
> 
>  * In the example above,

Changing.

> src/java.base/share/classes/java/lang/template/package-info.java line 76:
> 
>> 74:  * String literals and text blocks can be used as proper processor arguments as
>> 75:  * well. This is automatically facilitated by the Java compiler converted the
>> 76:  * strings to {@link java.lang.template.StringTemplate StringTemplate} using the
> 
> Suggestion:
> 
>  * well. This is automatically facilitated by the Java compiler converting the
>  * strings to {@link java.lang.template.StringTemplate StringTemplate} using the

Changing.

> src/java.base/share/classes/java/lang/template/package-info.java line 79:
> 
>> 77:  * {@link java.lang.template.StringTemplate#of(String)} method.
>> 78:  * <p>
>> 79:  * Users can create their own template processors by implementing either
> 
> Suggestion:
> 
>  * Users can create their own template processors by implementing one of

Changing.

> src/java.base/share/classes/java/lang/template/package-info.java line 83:
> 
>> 81:  * {@link java.lang.template.TemplateProcessor} or
>> 82:  * {@link java.lang.template.StringProcessor} interfaces.
>> 83:  * See {@link java.lang.template.ValidatingProcessor} for examples and details.
> 
> I would give the reader a firm what to read next suggestion.
> It may be useful to mention and link to the `FMT` processor as a way to control the formatting of the values.
> Suggestion:
> 
>  * For more examples and details see  {@link java.lang.template.StringTemplate} and 
>  * {@link java.lang.template.ValidatingProcessor}.

Changing.

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

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

From jlaskey at openjdk.org  Tue Nov 22 20:09:11 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 22 Nov 2022 20:09:11 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v28]
In-Reply-To: <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com>
 <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
Message-ID: <B8n1rPWTXMy2KBjNJmDpZIkGoIK0NXK5XzZHcN0E-qI=.2d02c541-ccb0-4197-b672-b45d772c736c@github.com>

On Tue, 22 Nov 2022 18:33:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Seal Digits
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 52:
> 
>> 50:  * given by the template expression.
>> 51:  * <p>
>> 52:  * For example, the following code contains a template expression that uses the template
> 
> Though this is trying to explain the general mechanism, it might be more useful to readers to start with the most common use case, that of using a string processor. Swapping the order of the examples possibly.

The issue is that most users will not see a StringTemplate object. If they've come here then they want to see the inner workings.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 63:
> 
>> 61:  * {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
>> 62:  * which includes the empty first and last fragments. {@code values} will be the
>> 63:  * equivalent of {@code List.of(10, 20, 30)}.
> 
> Find a way to capitalize the first word of the sentence.
> Suggestion:
> 
>  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
>  * which includes the empty first and last fragments. The {@code values} will be the
>  * equivalent of {@code List.of(10, 20, 30)}.

Changing.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 66:
> 
>> 64:  * <p>
>> 65:  * The following code contains a template expression with the same template but a
>> 66:  * different template processor:
> 
> Suggestion:
> 
>  * The following code contains a template expression with the same template but a
>  * string template processor:

Changing. Missing "with" as well.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 75:
> 
>> 73:  * produced that returns the same lists from {@link StringTemplate#fragments()} and
>> 74:  * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template
>> 75:  * processor uses these lists to yield an interpolated string. {@code s} will be equivalent to
> 
> Suggestion:
> 
>  * processor uses these lists to yield an interpolated string. The value of {@code s} will be equivalent to

Changing.

> src/java.base/share/classes/java/util/FormatProcessor.java line 196:
> 
>> 194:      * <a href="../../util/Formatter.html#syntax">format specifier</a>.
>> 195:      * StringTemplate expressions without a preceeding specifier, use "%s" by
>> 196: 
> 
> Its worth specifying the locale that is used by FMT, is it `Locale.ROOT`?
> If it is `Locale.default`, the results may vary from run to run.

Okay.

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

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

From jlaskey at openjdk.org  Tue Nov 22 20:19:02 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 22 Nov 2022 20:19:02 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v28]
In-Reply-To: <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com>
 <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
Message-ID: <2GJrLatDQGRght0hyld2P5-AQfPrTvcshddE93uT5Oo=.85cc51dc-32eb-4bb5-b10b-5708b74c0776@github.com>

On Tue, 22 Nov 2022 18:43:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Seal Digits
>
> src/java.base/share/classes/java/lang/template/StringProcessor.java line 58:
> 
>> 56:     /**
>> 57:      * Constructs a {@link String} based on the template fragments and values in the
>> 58:      * supplied {@link StringTemplate stringTemplate} object.
> 
> When reading the javadoc, I expected the type name, not the variable name.
> Suggestion:
> 
>      * supplied {@link StringTemplate StringTemplate} object.

Changing.

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

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

From jjg at openjdk.org  Tue Nov 22 22:04:57 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 22 Nov 2022 22:04:57 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Prefix RFC titles with `RFC NNNN:`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/30ce235f..c29092d8

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

  Stats: 325 lines in 165 files changed: 4 ins; 4 del; 317 mod
  Patch: https://git.openjdk.org/jdk/pull/11073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073

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

From dfuchs at openjdk.org  Wed Nov 23 12:47:43 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:47:43 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
Message-ID: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>

On Tue, 22 Nov 2022 22:04:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefix RFC titles with `RFC NNNN:`

Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

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

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

From jlaskey at openjdk.org  Wed Nov 23 12:58:04 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 23 Nov 2022 12:58:04 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v28]
In-Reply-To: <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com>
 <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
Message-ID: <PqCFiiw3A0rhu_DRdTiyd7OlAztGokMfN6WkGlmwC9I=.a515e0d8-fb94-4526-a36f-26c45f656ecb@github.com>

On Tue, 22 Nov 2022 19:09:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Seal Digits
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 319:
> 
>> 317:      * This {@link StringProcessor} instance is conventionally used for the string interpolation
>> 318:      * of a supplied {@link StringTemplate}.
>> 319:      * <p>
> 
> It should be mentioned that the string representations are created as if invoking {@link String#valueOf}.
> An perhaps a link/@see to `FMT` for control over formatting.  
> 
> Also include it in the javadoc for `interpolate`.

Changing.

> src/java.base/share/classes/java/util/FormatProcessor.java line 64:
> 
>> 62:  *
>> 63:  * @implSpec Since, values are found within the string template, argument indexing
>> 64:  * specifiers are unsupported.
> 
> What is the behavior of a format that references an index?  Ignored, throw?
> I can see an argument for simplicity, but the values are a sequential list similar to that of a varargs call to format("xx", x, y, z, ...) so it can be well defined to what value an index in the format refers.

Kind of blows the whole concept of embedded expressions. This is one of those, just because you can, doesn't mean you should.

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

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

From jlaskey at openjdk.org  Wed Nov 23 13:16:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 23 Nov 2022 13:16:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v29]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <hPtg-v2tCatm1Xuof2iM4P90IuKUwUdzLimMoY_H69c=.46a6adf1-72b2-4126-83dc-ed0a72e4a1a6@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:

  Requested changes #12

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/da3ea20d..e9f52f2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=27-28

  Stats: 32 lines in 4 files changed: 12 ins; 1 del; 19 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  Wed Nov 23 13:55:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 23 Nov 2022 13:55:38 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v30]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@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 @since

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/e9f52f2f..09f1ac08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=28-29

  Stats: 27 lines in 19 files changed: 0 ins; 0 del; 27 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 rriggs at openjdk.org  Wed Nov 23 15:41:12 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Nov 2022 15:41:12 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v30]
In-Reply-To: <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
Message-ID: <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>

On Wed, 23 Nov 2022 13:55:38 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 @since

> /issue add JDK-8296302

The BOT comment at the top says /issue cannot refer to a CSR. You'll need to /issue remove it before integration.

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

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

From rriggs at openjdk.org  Wed Nov 23 16:01:04 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Nov 2022 16:01:04 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v28]
In-Reply-To: <PqCFiiw3A0rhu_DRdTiyd7OlAztGokMfN6WkGlmwC9I=.a515e0d8-fb94-4526-a36f-26c45f656ecb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com>
 <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
 <PqCFiiw3A0rhu_DRdTiyd7OlAztGokMfN6WkGlmwC9I=.a515e0d8-fb94-4526-a36f-26c45f656ecb@github.com>
Message-ID: <fsXnC0QNxbcmBS4IqCjGHweuElIAth2PAVzJhu197Ig=.4ddac57e-1a57-4102-9c42-7063812e6ff2@github.com>

On Tue, 22 Nov 2022 20:17:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/FormatProcessor.java line 64:
>> 
>>> 62:  *
>>> 63:  * @implSpec Since, values are found within the string template, argument indexing
>>> 64:  * specifiers are unsupported.
>> 
>> What is the behavior of a format that references an index?  Ignored, throw?
>> I can see an argument for simplicity, but the values are a sequential list similar to that of a varargs call to format("xx", x, y, z, ...) so it can be well defined to what value an index in the format refers.
>
> Kind of blows the whole concept of embedded expressions. This is one of those, just because you can, doesn't mean you should.

ok, still what is the behavior if the format includes an index?
The pattern scanner in FormatProcessor permits an index and does not cause an error.

Also, there might be a small benefit to using the existing compiled pattern in Formatter.java.  (make it package private and rename to uppercase).

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

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

From jlaskey at openjdk.org  Wed Nov 23 16:20:27 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 23 Nov 2022 16:20:27 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v28]
In-Reply-To: <fsXnC0QNxbcmBS4IqCjGHweuElIAth2PAVzJhu197Ig=.4ddac57e-1a57-4102-9c42-7063812e6ff2@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com>
 <p1DtacZXWZH_-xrBAt2NA_xNhq2hWTq324DLQMizgck=.9d56085d-7aca-44df-b52d-d2ab57311094@github.com>
 <PqCFiiw3A0rhu_DRdTiyd7OlAztGokMfN6WkGlmwC9I=.a515e0d8-fb94-4526-a36f-26c45f656ecb@github.com>
 <fsXnC0QNxbcmBS4IqCjGHweuElIAth2PAVzJhu197Ig=.4ddac57e-1a57-4102-9c42-7063812e6ff2@github.com>
Message-ID: <CZMoi40c6ua-R4B6nwnfE2h1sZfVRweMc69wuGFlt4M=.8356869e-9bed-48c0-a64f-cbce04e00a48@github.com>

On Wed, 23 Nov 2022 15:57:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kind of blows the whole concept of embedded expressions. This is one of those, just because you can, doesn't mean you should.
>
> ok, still what is the behavior if the format includes an index?
> The pattern scanner in FormatProcessor permits an index and does not cause an error.
> 
> Also, there might be a small benefit to using the existing compiled pattern in Formatter.java.  (make it package private and rename to uppercase).

Currently it issues an `MissingFormatArgumentException` which I guess could be confusing.  Changing to IllegalFormatFlagsException with a descriptive message.

Re: Pattern - I was originally trying to minimize changes to Formatter, but considering what I did change...

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

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

From rriggs at openjdk.org  Wed Nov 23 16:20:30 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Nov 2022 16:20:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v30]
In-Reply-To: <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
Message-ID: <AHyvIcvK9RMEEMIGlfkU3N87JbMKyuGCq12hXXBkNHo=.beb2bc69-a99c-4f54-bbb5-6d0b64c5a8e5@github.com>

On Wed, 23 Nov 2022 13:55:38 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 @since

src/java.base/share/classes/java/util/FormatProcessor.java line 85:

> 83: 
> 84:     /**
> 85:      * {@inheritDoc}

The javadoc should describe in more detail what `process` does and the errors than can occur.
That will help developers understand the errors that come out of Formatter in the context of FMT.
That will help even if that is just to describe how the format string passed to j.u.Formatter is constructed.
The javadoc should warn that the fragment should contain only a single format string and it must be at the end of the fragment.
For example, if multiple format strings appear in the fragment they are all passed to Formatter.
If the last format string is not the last in the fragment (for example, followed by a space) then a %s is appended and there are two formatters for a single value.  For example,

   int x = 1;
   FMT."x: %s {x}";  // extra space

It is unfortunate that the exception reported (in the case of a mismatch in the number for format strings vs values) is a BootStrapMethodError with a cause of MissingFormatArgument.  That's exposing the implementation and may look like a bug in the FMT.

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

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

From jlaskey at openjdk.org  Wed Nov 23 16:43:03 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 23 Nov 2022 16:43:03 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v30]
In-Reply-To: <AHyvIcvK9RMEEMIGlfkU3N87JbMKyuGCq12hXXBkNHo=.beb2bc69-a99c-4f54-bbb5-6d0b64c5a8e5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <AHyvIcvK9RMEEMIGlfkU3N87JbMKyuGCq12hXXBkNHo=.beb2bc69-a99c-4f54-bbb5-6d0b64c5a8e5@github.com>
Message-ID: <jjNB6nIhgSsA0xi30tAn3Hm0XxKHvOXydjG7wsdYqms=.75bc8a32-c384-4867-bd07-92f9abd68a1e@github.com>

On Wed, 23 Nov 2022 16:08:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update @since
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 85:
> 
>> 83: 
>> 84:     /**
>> 85:      * {@inheritDoc}
> 
> The javadoc should describe in more detail what `process` does and the errors than can occur.
> That will help developers understand the errors that come out of Formatter in the context of FMT.
> That will help even if that is just to describe how the format string passed to j.u.Formatter is constructed.
> The javadoc should warn that the fragment should contain only a single format string and it must be at the end of the fragment.
> For example, if multiple format strings appear in the fragment they are all passed to Formatter.
> If the last format string is not the last in the fragment (for example, followed by a space) then a %s is appended and there are two formatters for a single value.  For example,
> 
>    int x = 1;
>    FMT."x: %s {x}";  // extra space
> 
> It is unfortunate that the exception reported (in the case of a mismatch in the number for format strings vs values) is a BootStrapMethodError with a cause of MissingFormatArgument.  That's exposing the implementation and may look like a bug in the FMT.

Will clean up javadoc for FormatProcessor::process.

It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually.

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

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

From jjg at openjdk.org  Wed Nov 23 16:47:22 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 16:47:22 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
 <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
Message-ID: <1chEBBDbhD7PiPdKybnhe3Bq2DyO-GTGaxTU5qtw7C4=.8191c086-d70c-4bc1-b03e-d781b1268f07@github.com>

On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

That was not intentional, and is a result of the scripted edit. I will look to revert those changes and/or change the tooling to ignore those packages.

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

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

From rriggs at openjdk.org  Wed Nov 23 17:30:03 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Nov 2022 17:30:03 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v30]
In-Reply-To: <jjNB6nIhgSsA0xi30tAn3Hm0XxKHvOXydjG7wsdYqms=.75bc8a32-c384-4867-bd07-92f9abd68a1e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <AHyvIcvK9RMEEMIGlfkU3N87JbMKyuGCq12hXXBkNHo=.beb2bc69-a99c-4f54-bbb5-6d0b64c5a8e5@github.com>
 <jjNB6nIhgSsA0xi30tAn3Hm0XxKHvOXydjG7wsdYqms=.75bc8a32-c384-4867-bd07-92f9abd68a1e@github.com>
Message-ID: <WNCff-ybV47pDukR9L9VV6UUApZok60c_Wpjrwl4LPM=.64e69176-ace4-4b57-bc96-030eb9051896@github.com>

On Wed, 23 Nov 2022 16:40:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/FormatProcessor.java line 85:
>> 
>>> 83: 
>>> 84:     /**
>>> 85:      * {@inheritDoc}
>> 
>> The javadoc should describe in more detail what `process` does and the errors than can occur.
>> That will help developers understand the errors that come out of Formatter in the context of FMT.
>> That will help even if that is just to describe how the format string passed to j.u.Formatter is constructed.
>> The javadoc should warn that the fragment should contain only a single format string and it must be at the end of the fragment.
>> For example, if multiple format strings appear in the fragment they are all passed to Formatter.
>> If the last format string is not the last in the fragment (for example, followed by a space) then a %s is appended and there are two formatters for a single value.  For example,
>> 
>>    int x = 1;
>>    FMT."x: %s {x}";  // extra space
>> 
>> It is unfortunate that the exception reported (in the case of a mismatch in the number for format strings vs values) is a BootStrapMethodError with a cause of MissingFormatArgument.  That's exposing the implementation and may look like a bug in the FMT.
>
> Will clean up javadoc for FormatProcessor::process.
> 
> It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually.

Since FormatProcessor is scanning for format strings (in stringTempateFormat), it could check for the wrong number and misplaced format strings and throw.  It would make the exception more specific to the arguments to the FMT.process() and easier for the developer to correct.

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

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

From jjg at openjdk.org  Wed Nov 23 18:57:03 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 18:57:03 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Remove updates from unexported files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/c29092d8..3905ac83

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

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

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

From jlaskey at openjdk.org  Wed Nov 23 19:22:14 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 23 Nov 2022 19:22:14 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v30]
In-Reply-To: <WNCff-ybV47pDukR9L9VV6UUApZok60c_Wpjrwl4LPM=.64e69176-ace4-4b57-bc96-030eb9051896@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <AHyvIcvK9RMEEMIGlfkU3N87JbMKyuGCq12hXXBkNHo=.beb2bc69-a99c-4f54-bbb5-6d0b64c5a8e5@github.com>
 <jjNB6nIhgSsA0xi30tAn3Hm0XxKHvOXydjG7wsdYqms=.75bc8a32-c384-4867-bd07-92f9abd68a1e@github.com>
 <WNCff-ybV47pDukR9L9VV6UUApZok60c_Wpjrwl4LPM=.64e69176-ace4-4b57-bc96-030eb9051896@github.com>
Message-ID: <DsM_dkhUNpq-Zf7GlxpsJfqHCgYpnNcCM_lI5WxuIqs=.fc809023-dcd9-4ebe-b95c-3b6d3603511d@github.com>

On Wed, 23 Nov 2022 17:26:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Will clean up javadoc for FormatProcessor::process.
>> 
>> It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually.
>
> Since FormatProcessor is scanning for format strings (in stringTempateFormat), it could check for the wrong number and misplaced format strings and throw.  It would make the exception more specific to the arguments to the FMT.process() and easier for the developer to correct.

It is doing that now, but I can make the message more informative. The problem still exists that this is always done in the bootstrap method.

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

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

From dfuchs at openjdk.org  Wed Nov 23 19:23:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 19:23:53 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

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

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

From jjg at openjdk.org  Wed Nov 23 22:09:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 22:09:23 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
Message-ID: <CN_yhlxSOuJ_vrZwgtwLXWapiBa9Df2Cab1ySShZvu4=.b3e2212d-2f5d-4cea-a28b-8a02e3b18159@github.com>

On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

Believe me, I tried *very* hard to design and use an inline `{@spec}` tag but such a tag effectively needs a normative external file to indicate the root of a multi-page spec, and the definitive title, since inline tags either do not or are unlikely to contain such information.

The general history of this work is:
* version 1: bimodal tag with no external file -- the content of the summary page was effectively rubbish
* version 2: bimodal tag with an external file -- in discussion with @jddarcy and CSR, we decided that was too much of a non-standard maintenance load
* version 3: new tag, with no external file needed -- as you see here

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

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

From joehw at openjdk.org  Wed Nov 23 23:08:05 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:08:05 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:

> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition

Hi Jon,

I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
points to the fifth edition while @see second.

A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.

[1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

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

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

From joehw at openjdk.org  Wed Nov 23 23:43:57 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:43:57 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <3O_lqMPzsBuGyrQ_snbw0Qv-XY-OaGUly6OBtoRz8hw=.041bf0b3-9dd4-4616-a003-617d28030139@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

Specs for XSLT and XPath (many occurrences) need to point to specific version (e.g. 1.0) rather than the "cover page" (this is an issue in the original javadoc).

src/java.xml/share/classes/javax/xml/transform/OutputKeys.java line 35:

> 33:  *
> 34:  * @spec https://www.w3.org/TR/xslt xslt cover page - W3C
> 35:  * @see <a href="http://www.w3.org/TR/xslt#output">

The pages for XSLT and XPath at W3C are organized differently from the days when this javadoc was created. The "latest version" now points to the "cover page". Could you change the spec to the following? 
      https://www.w3.org/TR/1999/REC-xslt-19991116 XSL Transformations (XSLT) Version 1.0
      
The @spec points to the general spec while @see also a specific section (similar situation as other classes in the package), if we want to keep @see ref here, it would be: 
    https://www.w3.org/TR/1999/REC-xslt-19991116#output

src/java.xml/share/classes/javax/xml/xpath/XPath.java line 104:

> 102:  * @author  Norman Walsh
> 103:  * @author  Jeff Suttor
> 104:  * @see <a href="http://www.w3.org/TR/xpath">XML Path Language (XPath) Version 1.0</a>

Similar situation as XSLT above, the latest version now points to "cover page". For this javadoc then, it needs to be:
    https://www.w3.org/TR/1999/REC-xpath-19991116/ XML Path Language (XPath) Version 1.0
    
Unlike XSLT, the original @see ref also points to the spec generally (not a specific section), we could then drop it to keep just the @spec ref.

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

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

From alanb at openjdk.org  Thu Nov 24 10:56:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 10:56:23 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <W_PDXjCTWZO6xXPHhF-LLKnDxtRgwgI9zdv9Se52Rqo=.0ae98a38-5f76-4839-b579-ab19faf1945b@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.se/share/classes/module-info.java line 39:

> 37:  *
> 38:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 39:  * @spec jni/index.html Java Native Interface Specification

One thing that that bothers me a bit here is that the JNI and JDWP specs will be listed as "External Specifications" in the generated javadoc. This heading is appropriate for RFCs and other standards that we reference but seems misleading for specifications that are part of Java SE. Has this come up already?

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

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

From jlaskey at openjdk.org  Thu Nov 24 13:38:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 24 Nov 2022 13:38:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v31]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <keEVmy8Rwrwxg2U_tzxom4B0ONLiMeEx5cN6BbWGywQ=.84fc8977-ce87-47c2-ae25-55f226fe8215@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:

  FormatProcessor changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/09f1ac08..69efbb48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=29-30

  Stats: 131 lines in 3 files changed: 81 ins; 16 del; 34 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 mernst at openjdk.org  Sun Nov 27 17:53:30 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 27 Nov 2022 17: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: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@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

Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.

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

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

From jpai at openjdk.org  Mon Nov 28 09:02:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 09:02: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: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
Message-ID: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>

On Sun, 27 Nov 2022 17:49:57 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.

I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

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

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

From duke at openjdk.org  Mon Nov 28 15:27:15 2022
From: duke at openjdk.org (duke)
Date: Mon, 28 Nov 2022 15:27:15 GMT
Subject: <i18n dev> Withdrawn: 8289834: Add SBCS and DBCS Only EBCDIC
 charsets
In-Reply-To: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
Message-ID: <34um0oOZCtdh8b-xckxmi96IEO_zSklavBH96B2WmhQ=.e83685bf-8f28-4966-aecc-a8ec0b369bfe@github.com>

On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi <itakiguchi 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

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Nov 28 18:18:42 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 28 Nov 2022 18:18:42 GMT
Subject: <i18n dev> RFR: 8297685: Typo in NullPointerException description
 specified by Locale.lookup
Message-ID: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>

Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563.

Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `.

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

Commit messages:
 - Replace tags with locales in javadoc for locale.lookup

Changes: https://git.openjdk.org/jdk/pull/11394/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11394&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297685
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11394/head:pull/11394

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

From naoto at openjdk.org  Mon Nov 28 18:18:43 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Nov 2022 18:18:43 GMT
Subject: <i18n dev> RFR: 8297685: Typo in NullPointerException
 description specified by Locale.lookup
In-Reply-To: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>
References: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>
Message-ID: <_KpUO_-ffGZT7Zt7h9ZX7OkRTFMEgdfKVtmmamBWZKs=.a48b0986-91e6-4f42-844a-47d1bbc09d7a@github.com>

On Mon, 28 Nov 2022 17:53:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563.
> 
> Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `.

Marked as reviewed by naoto (Reviewer).

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

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

From lancea at openjdk.org  Mon Nov 28 18:26:30 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 28 Nov 2022 18:26:30 GMT
Subject: <i18n dev> RFR: 8297685: Typo in NullPointerException
 description specified by Locale.lookup
In-Reply-To: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>
References: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>
Message-ID: <_yaHUaHxnux0bhwgUrx4p6wg4zFg-Y11tpkooUtoMhM=.bcff4549-f25d-45b2-944b-1026ce3fac12@github.com>

On Mon, 28 Nov 2022 17:53:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563.
> 
> Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `.

Marked as reviewed by lancea (Reviewer).

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

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

From prr at openjdk.org  Mon Nov 28 23:27:55 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Nov 2022 23:27:55 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.desktop/share/classes/java/awt/package-info.java line 58:

> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
> 58:  *                  The Java AWT Native Interface (JAWT)</a>

Why only 1 of these 3 ?

src/java.desktop/share/classes/java/awt/package-info.java line 62:

> 60:  *
> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
> 62:  * @since 1.0

I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
But I also wonder why only the native_interface spec was added and not the other two ?

src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:

> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
> 225:      * @see #TAG_COMPRESSION
> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>

Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?

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

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

From itakiguchi at openjdk.org  Tue Nov 29 01:35:27 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 29 Nov 2022 01:35:27 GMT
Subject: <i18n dev> RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
Message-ID: <H9vlDyydiF_VueVB_XXLS-veYd4czb3xhbJsYO7ej1o=.4e171ea8-c146-4e1e-a859-9c4c5f525395@github.com>

On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi <itakiguchi 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

I'm still working on this one.

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

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

From jpai at openjdk.org  Tue Nov 29 07:01:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 07:01:05 GMT
Subject: <i18n dev> RFR: 8297685: Typo in NullPointerException
 description specified by Locale.lookup
In-Reply-To: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>
References: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>
Message-ID: <KLtaHW6UmwYQbbZMupVQmojQGmHRDeDLN1DRaFEqsEQ=.c047c219-2a19-4901-87ac-09da9f42254f@github.com>

On Mon, 28 Nov 2022 17:53:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563.
> 
> Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `.

Looks good to me.

P.S: There appears to be another PR open for this same change https://github.com/openjdk/jdk/pull/11378

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

Marked as reviewed by jpai (Reviewer).

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

From duke at openjdk.org  Tue Nov 29 18:35:23 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 29 Nov 2022 18:35:23 GMT
Subject: <i18n dev> Integrated: 8297685: Typo in NullPointerException
 description specified by Locale.lookup
In-Reply-To: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>
References: <gGTVDR_-pvpd8zYEy0C9kL1M1UbUd1bLkLVCqigJYYE=.ea550abc-cdb6-4dcf-9d7f-911d65ce32b0@github.com>
Message-ID: <ko6KRCaBMTB1eiJlOQX8YuhzxOw86Iu-bvoI10mXX-Y=.465d7c47-c5ec-4482-908c-13f4cc906568@github.com>

On Mon, 28 Nov 2022 17:53:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563.
> 
> Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `.

This pull request has now been integrated.

Changeset: ae5b1f76
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae5b1f765678a9928696acb7228b197e293171be
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8297685: Typo in NullPointerException description specified by Locale.lookup

Reviewed-by: naoto, lancea, jpai

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

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

From ihse at openjdk.org  Tue Nov 29 19:26:36 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Nov 2022 19:26:36 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: <D-_pSm7C9d1Wdx-g6Tz0PTX_7CgFMitkkGCV907jv_8=.77ff6af8-466b-42ab-a015-73589600dab1@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

Yes bot, I know. I'll need to split this up into multiple steps, but please keep this open for a while more. Thank you.

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

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

From andrew at openjdk.org  Wed Nov 30 18:15:29 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 30 Nov 2022 18:15:29 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g
Message-ID: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>

Update to the latest tzdata, 2022g.

Primary changes:
* `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
* `America/Pangnirtung` becomes a link to `America/Iqaluit`
* `America/Ojinaga` gains DST (CDT)

See bug for the full details.

There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)

Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

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

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

Changes: https://git.openjdk.org/jdk/pull/11438/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297804
  Stats: 217 lines in 21 files changed: 125 ins; 56 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/11438.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11438/head:pull/11438

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