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: 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: 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 alanb at openjdk.org  Tue Nov  1 06:52:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 06:52:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
Message-ID: <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@github.com>

On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race <prr at openjdk.org> wrote:

> You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ?
> 
> Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ?

Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think.

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

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

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: 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: 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: 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: 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: 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 dfuchs at openjdk.org  Tue Nov  1 13:53:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 13:53:37 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
Message-ID: <YyjbpXQ4Nu8hejOV6lg2bwd-Hfk3-9MEAIUuyCKS3cM=.9e689d36-46fd-4f84-8da0-85dd682196bf@github.com>

On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race <prr at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use java.net.URI to parse or construct any URL. ... To construct a URL, using URI::toURL should be preferred.
> 
> You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ?
> 
> Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ?

Possibly yes. Using URI where it was not used before might cause some behavioral changes, that would need to be examined and possibly documented through separate CSRs. This is better handled on a case-by-case basis
for each area affected. The changes as currently proposed will not lead to any behavioral difference.

> 
> And what about Peter Firmstone's comment "We stopped using java.net.URI some years ago as it's obsolete.?"
> 
> I can't reconcile that with the recommendation to use it ..

URI implements RFC 2396 with some deviations, noted in its API documentation, which make it a crossbreed between RFC 2396 and RFC 3986. As Alan noted earlier, changing URI to strictly implement RFC 3986 is not a compatible move: it was attempted in JDK 6 but had to backed out quickly as it caused widespread breakage. But even if it doesn't implement the latest RFC strictly, it's still a much more modern API and implementation than java.net.URL.

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

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

From dfuchs at openjdk.org  Tue Nov  1 13:53:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 13:53:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <GCXHo9bR0jQRKe-qvdgEDkPzvc0zgS6sIlTQ-PiWzmA=.fd82872c-c1c5-4ffa-b602-a4bc60bedc19@github.com>

On Sat, 29 Oct 2022 14:14:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 885:
> 
>> 883: 
>> 884:             @SuppressWarnings("deprecation")
>> 885:             var result = new URL("jrt", host, port, file, null);
> 
> The URL scheme for jrt does not have a port so we should look at that some time.

Noted.

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:00:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:00:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <nB3e9AXOx2rm5qSOhYjm7XRQn4wvLkt2y4VckMIziCY=.95686450-68bc-4d3d-9956-ab722063f00d@github.com>

On Sat, 29 Oct 2022 14:16:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 157:
> 
>> 155:  * The URL constructors are specified to throw
>> 156:  * {@link MalformedURLException} but the actual parsing/validation
>> 157:  * that are performed is implementation dependent. Some parsing/validation
> 
> "the ... are performed" -> "the ... is performed".

done

> src/java.base/share/classes/java/net/URL.java line 852:
> 
>> 850:      * @since 20
>> 851:      */
>> 852:     public static URL of(URI uri, URLStreamHandler streamHandler)
> 
> The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion.

done

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:08:17 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:08:17 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <qCuvc99MQHsNXJh946nVOGlDNWoK-k-iahtS18-I8v4=.ee61f634-b6d1-46c2-9084-2df739c76d9f@github.com>

On Sat, 29 Oct 2022 14:17:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 166:
> 
>> 164:  * The {@code java.net.URL} constructors are deprecated.
>> 165:  * Developers are encouraged to use {@link URI java.net.URI} to parse
>> 166:  * or construct any {@code URL}. In cases where an instance of {@code
> 
> "any URL" -> "a URL" or "all URLs".

done

> src/java.base/share/classes/java/net/URL.java line 168:
> 
>> 166:  * or construct any {@code URL}. In cases where an instance of {@code
>> 167:  * java.net.URL} is needed to open a connection, {@link URI} can be used
>> 168:  * to construct or parse the URL string, possibly calling {@link
> 
> I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString.

I don't believe it would be syntactically correct to put it in all lower case since URL is an acronym.  I could replace it with "URI string" instead but I'm not sure it would be better. What do you think?

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:12:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:12:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>

On Sat, 29 Oct 2022 14:24:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 133:
> 
>> 131:  * specified. The optional fragment is not inherited.
>> 132:  *
>> 133:  * <h2><a id="constructor-deprecation"></a>Constructing instances of {@code URL}</h2>
> 
> Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated?

To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:26:09 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:26:09 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
Message-ID: <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>

On Tue, 1 Nov 2022 14:10:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URL.java line 133:
>> 
>>> 131:  * specified. The optional fragment is not inherited.
>>> 132:  *
>>> 133:  * <h2><a id="constructor-deprecation"></a>Constructing instances of {@code URL}</h2>
>> 
>> Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated?
>
> To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.

Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?

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

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

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: 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 alanb at openjdk.org  Tue Nov  1 14:51:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 14:51:20 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
 <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
Message-ID: <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>

On Tue, 1 Nov 2022 14:22:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.
>
> Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?

Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message.

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

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

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: 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 dfuchs at openjdk.org  Tue Nov  1 16:14:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 16:14:20 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Daniel Fuchs 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 six additional commits since the last revision:

 - Integrated review feedback
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Fix whitespace issues
 - 8294241

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/fd4ca287..f6b8a9f9

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

  Stats: 3893 lines in 203 files changed: 2469 ins; 611 del; 813 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

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

From prr at openjdk.org  Tue Nov  1 16:14:21 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 1 Nov 2022 16:14:21 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <aRKJABG81VEtvU3_sEh-c0yfIQ8SDYp0PFm_TSTRV_M=.2f254387-cd5a-4309-81c0-8a240ef8ecc4@github.com>

On Tue, 1 Nov 2022 16:10:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Marked as reviewed by prr (Reviewer).

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

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

From dfuchs at openjdk.org  Tue Nov  1 16:14:22 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 16:14:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
 <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
 <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>
Message-ID: <2jUuJ4BHyWYygw4wAlZbgMBsxCyVgAOfhNFPl31yKLY=.5c5e0a58-e270-4e95-8cb6-d0c5f7a3bc23@github.com>

On Tue, 1 Nov 2022 14:47:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?
>
> Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message.

Done.

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

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

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: 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: 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: 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: 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: 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 alanb at openjdk.org  Wed Nov  2 12:22:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Nov 2022 12:22:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <Qnv25No1OKTGQ8SRg0TCExRCbZB5h0Izs5vhqAWDTAQ=.66d04bd1-9cb0-4b92-b2ae-a27ee3d8c24d@github.com>

On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Marked as reviewed by alanb (Reviewer).

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

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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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:41 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 19:24:41 GMT
Subject: 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:50 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Nov 2022 19:24:50 GMT
Subject: 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: 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: 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: 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: 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: 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: 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 duke at openjdk.org  Thu Nov  3 07:49:28 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 3 Nov 2022 07:49:28 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>

On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Since?these are?in?the?same compilation?unit as?the?deprecated `URL`?constructors, `@SuppressWarnings("deprecation")` isn?t?needed:

src/java.base/share/classes/java/net/URL.java line 885:

> 883:             @SuppressWarnings("deprecation")
> 884:             var result = new URL("jrt", host, port, file, null);
> 885:             return result;

Suggestion:

            return new URL("jrt", host, port, file, null);

src/java.base/share/classes/java/net/URL.java line 909:

> 907:         @SuppressWarnings("deprecation")
> 908:         var result = new URL((URL)null, uri.toString(), handler);
> 909:         return result;

Suggestion:

        return new URL((URL)null, uri.toString(), handler);

src/java.base/share/classes/java/net/URL.java line 1833:

> 1831:         try {
> 1832:             @SuppressWarnings("deprecation")
> 1833:             var _unused = replacementURL = new URL(urlString);

Suggestion:

            replacementURL = new URL(urlString);

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

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

From dfuchs at openjdk.org  Thu Nov  3 11:20:03 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:03 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/f6b8a9f9..fc899005

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

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

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

From michaelm at openjdk.org  Thu Nov  3 11:20:04 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 3 Nov 2022 11:20:04 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>

On Thu, 3 Nov 2022 10:56:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/java/net/URL.java line 152:

> 150:  * provide any guarantee about its conformance to the URL
> 151:  * syntax specification.
> 152:  * <p>

I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)?

Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical.

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

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

From dfuchs at openjdk.org  Thu Nov  3 11:20:05 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:05 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
 <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>
Message-ID: <f6KQGfu1BOAUMUam_LwZTp88-8NX2-I6d4Ku2d4LJ3U=.e9a5ef53-afa7-4163-bd4b-1260e7ebc2ef@github.com>

On Thu, 3 Nov 2022 10:56:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/java/net/URL.java line 152:
> 
>> 150:  * provide any guarantee about its conformance to the URL
>> 151:  * syntax specification.
>> 152:  * <p>
> 
> I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)?
> 
> Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical.

That would better go in URL::toURI I think - but AFAICS would only apply if you constructed the URL from one of the deprecated constructors. It's not a bad idea - but given that the CSR has been approved I'd rather track that in a follow up PR.

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

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

From dfuchs at openjdk.org  Thu Nov  3 11:20:08 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:08 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
 <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>
Message-ID: <JPqOXDD-OIUnBfjasVY1YXwf6cN-Vknvd4XhDEXJDvI=.7c24b554-eff1-47de-8db2-898439de2338@github.com>

On Thu, 3 Nov 2022 07:42:44 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Daniel Fuchs 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 six additional commits since the last revision:
>> 
>>  - Integrated review feedback
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 885:
> 
>> 883:             @SuppressWarnings("deprecation")
>> 884:             var result = new URL("jrt", host, port, file, null);
>> 885:             return result;
> 
> Suggestion:
> 
>             return new URL("jrt", host, port, file, null);

Ah ! Good point thanks! I have accepted your suggestions.

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

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

From aefimov at openjdk.org  Thu Nov  3 13:05:33 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 3 Nov 2022 13:05:33 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <k_5J1gI_C0W-b_WcMMG6Rf71Bxu-rLiTzonaEiDtXTU=.5a547097-d335-42bc-bb3b-dd970135a666@github.com>

On Thu, 3 Nov 2022 11:20:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

`java.naming` changes looks reasonable to me. Thanks!

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

Marked as reviewed by aefimov (Committer).

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

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: 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: 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: 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: 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: 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: 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: 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 michaelm at openjdk.org  Thu Nov  3 15:10:37 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 3 Nov 2022 15:10:37 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <VIPkTGY5ZJNqBRiHcqesQQOdR3wuw_MR6KIKUm6TGeg=.802cdd63-df58-4c2e-bf83-049e4018021d@github.com>

On Thu, 3 Nov 2022 11:20:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by michaelm (Reviewer).

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

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

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: 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: 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 dfuchs at openjdk.org  Thu Nov  3 15:52:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 15:52:53 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v5]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <BkNpz5wPrxpFJDaE0AzRWyRnG2r8B5qdEgm32zDE3Dw=.32ed243e-d406-4296-86bc-847aaa9d9a06@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Daniel Fuchs 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 10 additional commits since the last revision:

 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Integrated review feedback
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Fix whitespace issues
 - 8294241

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/fc899005..b4a73f40

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

  Stats: 42853 lines in 291 files changed: 10793 ins; 30812 del; 1248 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

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

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: 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 dfuchs at openjdk.org  Thu Nov  3 17:22:28 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 17:22:28 GMT
Subject: Integrated: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <4AGCrDQ4XC3UDTwYPRw8OPCbIFPueKKAGAJVb7ulbmM=.d7bc126d-3230-4d27-8519-ff06233dd8d9@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

This pull request has now been integrated.

Changeset: 4338f527
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4338f527aa81350e3636dcfbcd2eb17ddaad3914
Stats:     853 lines in 82 files changed: 707 ins; 5 del; 141 mod

8294241: Deprecate URL public constructors

Reviewed-by: joehw, prr, alanb, aefimov, michaelm

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

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

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: 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: 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 jlahoda at openjdk.org  Fri Nov  4 08:06:00 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Nov 2022 08:06:00 GMT
Subject: RFR: 8295984: Remove unexpected JShell feature
Message-ID: <Ljac6ps1T03CJKHyuSvPNiTDPpSxRMnh0RthFH8LYtY=.d4f045be-7851-4964-b2b5-2d5f9dbe32c9@github.com>

This patch patches JShell to not have the ability to run URL specified on the command line. Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8296326

Thanks!

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

Commit messages:
 - 8295984: Remove unexpected JShell feature

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

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

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: 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: 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 cstein at openjdk.org  Fri Nov  4 09:50:55 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 4 Nov 2022 09:50:55 GMT
Subject: RFR: 8295984: Remove unexpected JShell feature
In-Reply-To: <Ljac6ps1T03CJKHyuSvPNiTDPpSxRMnh0RthFH8LYtY=.d4f045be-7851-4964-b2b5-2d5f9dbe32c9@github.com>
References: <Ljac6ps1T03CJKHyuSvPNiTDPpSxRMnh0RthFH8LYtY=.d4f045be-7851-4964-b2b5-2d5f9dbe32c9@github.com>
Message-ID: <iZOqRHVqFLQNSMhGSD_5xvCWEG0jyx2DYpjSekTiCpY=.2f8d46cc-e89d-4445-a691-fa1bef9289a4@github.com>

On Fri, 4 Nov 2022 07:57:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch patches JShell to not have the ability to run URL specified on the command line. Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8296326
> 
> Thanks!

LGTM

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

Marked as reviewed by cstein (Committer).

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

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: 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: 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: 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: 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 13:34:20 2022
From: duke at openjdk.org (ExE Boss)
Date: Sun, 6 Nov 2022 13:34:20 GMT
Subject: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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 asotona at openjdk.org  Thu Nov 10 06:33:25 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 10 Nov 2022 06:33:25 GMT
Subject: RFR: 8295814: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected [2] but found [1]" [v2]
In-Reply-To: <MtEnaU7t3HRKKvuvqdnNiy7QsAOU8CHPnrFu6rCdcR8=.0261cb6d-7130-446d-90cd-3559a9131397@github.com>
References: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
 <MtEnaU7t3HRKKvuvqdnNiy7QsAOU8CHPnrFu6rCdcR8=.0261cb6d-7130-446d-90cd-3559a9131397@github.com>
Message-ID: <3LHNwSWv2TxoKmyou4kVV0vd3HjLGAa-vfLBw9zuFAk=.887aef6f-71b5-4fae-b408-940b5a12dedd@github.com>

On Thu, 27 Oct 2022 10:23:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> File completion in CommandCompletionTest::testSet intermittently fails.
>> Also message provided by org.testng.Assert::assertEquals is also not very verbose when comparing collections:
>> "lists don't have the same size expected [2] but found [1]".
>> 
>> Cause of the failure is in the expected side of the assertion (CommandCompletionTest::getRootDirectories), which may conatain duplicates. While the actual side of the assertion is distinct (CommandCompletionTest::computeCompletions).
>> 
>> Proposed patch de-duplicates CommandCompletionTest::getRootDirectories and adds full description of the expected result to the error message for future debugging.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   relaxed tests depending on shared folders content

Please review proposed patch to test minimal size of the expected completion response for problematic test cases, instead of verification of the exact content.

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

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

From asotona at openjdk.org  Thu Nov 10 06:37:30 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 10 Nov 2022 06:37:30 GMT
Subject: RFR: 8294739: jdk/jshell/ToolShiftTabTest.java timed out
In-Reply-To: <kMOXPHvT14VvR6nzGa4VHazSYOAkXv1Nvdw0mxM7WtE=.3544c361-e053-40fc-85fd-32ae83a2997a@github.com>
References: <kMOXPHvT14VvR6nzGa4VHazSYOAkXv1Nvdw0mxM7WtE=.3544c361-e053-40fc-85fd-32ae83a2997a@github.com>
Message-ID: <PsreXS-Ukj64rFLDSn59cjx1haS_aqZAcF2-Bo9eCn8=.dbc466e2-412b-4837-99ec-40cbc5473f1a@github.com>

On Wed, 26 Oct 2022 09:26:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ToolShiftTabTest::testFixImport intermittently timeouts.
> Reason is exhaustive busy waiting loop for completion  to be ready.
> Proposed patch fixes the test loop.
> 
> Please review.
> 
> Thanks,
> Adam

Please review.

Thanks,
Adam

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

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

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: 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: 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 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: 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 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: 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: 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: 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 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: 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 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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 jlahoda at openjdk.org  Tue Nov 15 10:16:11 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Nov 2022 10:16:11 GMT
Subject: RFR: 8294739: jdk/jshell/ToolShiftTabTest.java timed out
In-Reply-To: <kMOXPHvT14VvR6nzGa4VHazSYOAkXv1Nvdw0mxM7WtE=.3544c361-e053-40fc-85fd-32ae83a2997a@github.com>
References: <kMOXPHvT14VvR6nzGa4VHazSYOAkXv1Nvdw0mxM7WtE=.3544c361-e053-40fc-85fd-32ae83a2997a@github.com>
Message-ID: <KrKHWAtsA4xuophbdGiKrtTqDbmr0gIVqwD0XKr75PI=.da077cc8-b1c1-41a2-b7a9-9e547d7b21ad@github.com>

On Wed, 26 Oct 2022 09:26:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ToolShiftTabTest::testFixImport intermittently timeouts.
> Reason is exhaustive busy waiting loop for completion  to be ready.
> Proposed patch fixes the test loop.
> 
> Please review.
> 
> Thanks,
> Adam

Looks OK.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.org  Tue Nov 15 10:18:15 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Nov 2022 10:18:15 GMT
Subject: RFR: 8295814: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected [2] but found [1]" [v2]
In-Reply-To: <MtEnaU7t3HRKKvuvqdnNiy7QsAOU8CHPnrFu6rCdcR8=.0261cb6d-7130-446d-90cd-3559a9131397@github.com>
References: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
 <MtEnaU7t3HRKKvuvqdnNiy7QsAOU8CHPnrFu6rCdcR8=.0261cb6d-7130-446d-90cd-3559a9131397@github.com>
Message-ID: <zZc8_g96fzuQ1NR_Q-YEKUhBiaoMdIG2DIs8wKHsx5k=.02dba373-db6e-46f6-80ba-592444cdbe91@github.com>

On Thu, 27 Oct 2022 10:23:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> File completion in CommandCompletionTest::testSet intermittently fails.
>> Also message provided by org.testng.Assert::assertEquals is also not very verbose when comparing collections:
>> "lists don't have the same size expected [2] but found [1]".
>> 
>> Cause of the failure is in the expected side of the assertion (CommandCompletionTest::getRootDirectories), which may conatain duplicates. While the actual side of the assertion is distinct (CommandCompletionTest::computeCompletions).
>> 
>> Proposed patch de-duplicates CommandCompletionTest::getRootDirectories and adds full description of the expected result to the error message for future debugging.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   relaxed tests depending on shared folders content

Looks OK.

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

Marked as reviewed by jlahoda (Reviewer).

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

From asotona at openjdk.org  Tue Nov 15 12:13:43 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 15 Nov 2022 12:13:43 GMT
Subject: Integrated: 8295814: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected [2] but found [1]"
In-Reply-To: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
References: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
Message-ID: <fZ5onkL6VMWuNWgvSc3Lrduoq2oSZPMRgTHd_nt5KlM=.dfa5db59-8714-4cb3-9c3b-579de87ec8f5@github.com>

On Wed, 26 Oct 2022 10:28:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> File completion in CommandCompletionTest::testSet intermittently fails.
> Also message provided by org.testng.Assert::assertEquals is also not very verbose when comparing collections:
> "lists don't have the same size expected [2] but found [1]".
> 
> Cause of the failure is in the expected side of the assertion (CommandCompletionTest::getRootDirectories), which may conatain duplicates. While the actual side of the assertion is distinct (CommandCompletionTest::computeCompletions).
> 
> Proposed patch de-duplicates CommandCompletionTest::getRootDirectories and adds full description of the expected result to the error message for future debugging.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: a45c9af1
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a45c9af1242d9ad497995f2c1228b6e85dfd79d8
Stats:     46 lines in 2 files changed: 11 ins; 26 del; 9 mod

8295814: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected [2] but found [1]"

Reviewed-by: jlahoda

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

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

From asotona at openjdk.org  Tue Nov 15 12:18:10 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 15 Nov 2022 12:18:10 GMT
Subject: Integrated: 8294739: jdk/jshell/ToolShiftTabTest.java timed out
In-Reply-To: <kMOXPHvT14VvR6nzGa4VHazSYOAkXv1Nvdw0mxM7WtE=.3544c361-e053-40fc-85fd-32ae83a2997a@github.com>
References: <kMOXPHvT14VvR6nzGa4VHazSYOAkXv1Nvdw0mxM7WtE=.3544c361-e053-40fc-85fd-32ae83a2997a@github.com>
Message-ID: <2DE8InJcs20cVbF7cTyjkd3cT8HltxuKu7-AsjmLEHg=.e62c7f29-3b63-4ad0-941f-b198d3a8d8ca@github.com>

On Wed, 26 Oct 2022 09:26:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ToolShiftTabTest::testFixImport intermittently timeouts.
> Reason is exhaustive busy waiting loop for completion  to be ready.
> Proposed patch fixes the test loop.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: c49e4841
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c49e48417d8e58dc34455cb5b503a1ba83a710aa
Stats:     8 lines in 1 file changed: 3 ins; 0 del; 5 mod

8294739: jdk/jshell/ToolShiftTabTest.java timed out

Reviewed-by: jlahoda

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

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

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: 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 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: 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 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: 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 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: 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 sundar at openjdk.org  Wed Nov 16 16:30:14 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 16 Nov 2022 16:30:14 GMT
Subject: RFR: 8295984: Remove unexpected JShell feature
In-Reply-To: <Ljac6ps1T03CJKHyuSvPNiTDPpSxRMnh0RthFH8LYtY=.d4f045be-7851-4964-b2b5-2d5f9dbe32c9@github.com>
References: <Ljac6ps1T03CJKHyuSvPNiTDPpSxRMnh0RthFH8LYtY=.d4f045be-7851-4964-b2b5-2d5f9dbe32c9@github.com>
Message-ID: <lQCE7DCzl4wyx1D3MrDD_XgAAAz0KlG0gGSmGkg1dw0=.c73c00f6-e747-4875-84bd-1493aa947f8b@github.com>

On Fri, 4 Nov 2022 07:57:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch patches JShell to not have the ability to run URL specified on the command line. Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8296326
> 
> Thanks!

LGTM

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

Marked as reviewed by sundar (Reviewer).

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

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: 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: 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: 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 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: 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: 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: 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:37 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 17:56:37 GMT
Subject: 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 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: 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 18:08:24 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 16 Nov 2022 18:08:24 GMT
Subject: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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 jjg at openjdk.org  Thu Nov 17 22:31:43 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 17 Nov 2022 22:31:43 GMT
Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java
Message-ID: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>

Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
(See https://bugs.openjdk.org/browse/JDK-8297165)

In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

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

Commit messages:
 - JDK-8297164: Update troff man pages and CheckManPageOptions.java

Changes: https://git.openjdk.org/jdk/pull/11223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11223&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297164
  Stats: 8944 lines in 29 files changed: 471 ins; 1589 del; 6884 mod
  Patch: https://git.openjdk.org/jdk/pull/11223.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11223/head:pull/11223

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

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: 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 dholmes at openjdk.org  Fri Nov 18 02:35:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Nov 2022 02:35:11 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Hi @jonathan-gibbons ,

I notice that in the new version dash characters are no longer escaped as `-`, do these still display correctly?

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

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

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: 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: 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: 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: 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: 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: 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: 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 jjg at openjdk.org  Fri Nov 18 18:56:31 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 18 Nov 2022 18:56:31 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
 <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>
Message-ID: <l58Z_Qi8-iqqqDhcbhgRgqetaiapUzMdHPPpqMgXzPY=.83952a70-fb4a-43e0-8d1b-4ec22689e398@github.com>

On Fri, 18 Nov 2022 02:31:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi @jonathan-gibbons ,
> 
> I notice that in the new version dash characters are no longer escaped as `-`, do these still display correctly?

Yes, at least in all the files I verified and I have no reason to believe it might be different in any other files.

On a Mac, you can just do `man <path-to-file>` to render the contents of a troff file. That is how I checked the files that I did.

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

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

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: 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: 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 abimpoudis at openjdk.org  Sun Nov 20 12:29:51 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sun, 20 Nov 2022 12:29:51 GMT
Subject: RFR: 8294583: JShell: NPE in switch with non existing record pattern
Message-ID: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>

This fixes a situation where attribution errors are not short circuiting the compilation of an expression, e.g., in case of a declaration missing in the JShell evaluation of a switch expression.

Now there are two options:

1. handle this in `handleSwitch` (specific to switches, and avoid the `NPE` raised according to the JBS description)
2. handle this centrally in the corresponding task that is used in two places: 1) JShell evaluation and 2) `tools.javac.combo`.

I adopted the second option. Any thoughts?

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

Commit messages:
 - 8294583: JShell: NPE in switch with non existing record pattern

Changes: https://git.openjdk.org/jdk/pull/11251/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11251&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294583
  Stats: 53 lines in 2 files changed: 52 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11251.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11251/head:pull/11251

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

From dholmes at openjdk.org  Mon Nov 21 01:35:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Nov 2022 01:35:20 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <RjHY72h2dKDge8MpnS7cKpLDKWBiwNVCBPYmd-uJfjY=.76af7ca7-77db-4d55-b097-d0641701aab8@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Looks okay.

Thanks for doing this before the end-of-release updates!

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

Marked as reviewed by dholmes (Reviewer).

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

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: 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: 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 duke at openjdk.org  Mon Nov 21 14:01:35 2022
From: duke at openjdk.org (Bo Zhang)
Date: Mon, 21 Nov 2022 14:01:35 GMT
Subject: RFR: 8292625: jshell crash on "var a = a"
Message-ID: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>

This commit adds the missing `type` assignment after attributing a variable's initial value. In some cases, this issue causes an NPE.

This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.

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

Commit messages:
 - 8292625: jshell crash on "var a = a"

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

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

From duke at openjdk.org  Mon Nov 21 14:01:35 2022
From: duke at openjdk.org (Bo Zhang)
Date: Mon, 21 Nov 2022 14:01:35 GMT
Subject: RFR: 8292625: jshell crash on "var a = a"
In-Reply-To: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
Message-ID: <M9AuiDzrT7DdCg8Mti7KF7GD7NkW1-UvlzXbYJaDM3o=.7354e112-4b4d-496b-b0f4-aa3223ae98e5@github.com>

On Mon, 21 Nov 2022 13:54:13 GMT, Bo Zhang <duke at openjdk.org> wrote:

> This commit adds the missing `type` assignment after attributing a variable's initial value. In some cases, this issue causes an NPE.
> 
> This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.

@mcimadamore Can you please take a look?

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

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

From jlahoda at openjdk.org  Mon Nov 21 14:08:37 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Nov 2022 14:08:37 GMT
Subject: RFR: 8294583: JShell: NPE in switch with non existing record
 pattern
In-Reply-To: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
References: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
Message-ID: <IlYxn04N5AeaE0EyRTmlfq1qMokucR0bxGergng-iWo=.a801702c-6b0b-47a9-b8c0-d4613a6c9330@github.com>

On Sun, 20 Nov 2022 12:20:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This fixes a situation where attribution errors are not short circuiting the compilation of an expression, e.g., in case of a declaration missing in the JShell evaluation of a switch expression.
> 
> Now there are two options:
> 
> 1. handle this in `handleSwitch` (specific to switches, and avoid the `NPE` raised according to the JBS description)
> 2. handle this centrally in the corresponding task that is used in two places: 1) JShell evaluation and 2) `tools.javac.combo`.
> 
> I adopted the second option. Any thoughts?

I think I'd prefer the former, because we have a) "-XDshould-stop.at=FLOW", which is expected to actually run flow despite errors from Attr; b) quite often handling error by not running flow, the exceptions still happen in some cases (e.g. when we evaluate if a given code can complete normally from Attr), better to ensure Flow can handle the AST, IMO.

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

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

From duke at openjdk.org  Mon Nov 21 14:09:55 2022
From: duke at openjdk.org (Bo Zhang)
Date: Mon, 21 Nov 2022 14:09:55 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v2]
In-Reply-To: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
Message-ID: <7aExdYETNph1ylMuo-LDbuNUKeZQJ13CfdIzPo0JR4Q=.ef3f776d-79e0-4a0f-bdb0-bf6c39ce05fa@github.com>

> This commit adds the missing `type` assignment after attributing a variable's initial value. In some cases, this issue causes an NPE.
> 
> This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.

Bo Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11263/files
  - new: https://git.openjdk.org/jdk/pull/11263/files/dffd32b8..5c58e847

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

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

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

From jlahoda at openjdk.org  Mon Nov 21 14:29:09 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Nov 2022 14:29:09 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v2]
In-Reply-To: <7aExdYETNph1ylMuo-LDbuNUKeZQJ13CfdIzPo0JR4Q=.ef3f776d-79e0-4a0f-bdb0-bf6c39ce05fa@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
 <7aExdYETNph1ylMuo-LDbuNUKeZQJ13CfdIzPo0JR4Q=.ef3f776d-79e0-4a0f-bdb0-bf6c39ce05fa@github.com>
Message-ID: <OunNcKDcEerX-A8j0w-Puh49avgU1zn0Xj_-Z5c1_Hc=.64bb025f-5617-43fc-9a15-5e475846c161@github.com>

On Mon, 21 Nov 2022 14:09:55 GMT, Bo Zhang <duke at openjdk.org> wrote:

>> This commit adds the missing `type` assignment after attributing a variable's initial value. In some cases, this issue causes an NPE.
>> 
>> This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.
>
> Bo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary space

Good catch, but I would personally prefer if `attribExpr` would set the type (as it does under normal circumstances), presumably here?

https://github.com/openjdk/jdk/blob/5c3345404d850cf01d9629b48015f1783a32bfc0/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4651

Also, might be nice to have a (core javac) test that would not rely on JShell, if possible.

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

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

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: 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: 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: 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 abimpoudis at openjdk.org  Mon Nov 21 15:19:39 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Nov 2022 15:19:39 GMT
Subject: RFR: 8294583: JShell: NPE in switch with non existing record
 pattern [v2]
In-Reply-To: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
References: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
Message-ID: <Add1Ov1jsLk6csz69rjrTmG-D9NGEMl6_dYfHmsDPJE=.ad433bdc-82d6-4d56-ac0a-df685fb0a9a6@github.com>

> This fixes a situation where attribution errors are not short circuiting the compilation of an expression, e.g., in case of a declaration missing in the JShell evaluation of a switch expression.
> 
> Now there are two options:
> 
> 1. handle this in `handleSwitch` (specific to switches, and avoid the `NPE` raised according to the JBS description)
> 2. handle this centrally in the corresponding task that is used in two places: 1) JShell evaluation and 2) `tools.javac.combo`.
> 
> I adopted the second option. Any thoughts?

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11251/files
  - new: https://git.openjdk.org/jdk/pull/11251/files/df5e143e..696c03ed

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

  Stats: 6 lines in 2 files changed: 1 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11251.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11251/head:pull/11251

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

From jlahoda at openjdk.org  Mon Nov 21 15:21:33 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Nov 2022 15:21:33 GMT
Subject: RFR: 8294583: JShell: NPE in switch with non existing record
 pattern [v2]
In-Reply-To: <Add1Ov1jsLk6csz69rjrTmG-D9NGEMl6_dYfHmsDPJE=.ad433bdc-82d6-4d56-ac0a-df685fb0a9a6@github.com>
References: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
 <Add1Ov1jsLk6csz69rjrTmG-D9NGEMl6_dYfHmsDPJE=.ad433bdc-82d6-4d56-ac0a-df685fb0a9a6@github.com>
Message-ID: <9SoHORcyJaaPWsrkKlQeTw08Had90aqCRYYql35XFCc=.0fdb31f7-7c14-4ade-896d-e9060bce2c48@github.com>

On Mon, 21 Nov 2022 15:19:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This fixes a situation where attribution errors are not short circuiting the compilation of an expression, e.g., in case of a declaration missing in the JShell evaluation of a switch expression.
>> 
>> Now there are two options:
>> 
>> 1. handle this in `handleSwitch` (specific to switches, and avoid the `NPE` raised according to the JBS description)
>> 2. handle this centrally in the corresponding task that is used in two places: 1) JShell evaluation and 2) `tools.javac.combo`.
>> 
>> I adopted the second option. Any thoughts?
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

Looks fine to me.

test/langtools/jdk/jshell/Test8294583.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.

Nit: copyright years.

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

Marked as reviewed by jlahoda (Reviewer).

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

From abimpoudis at openjdk.org  Mon Nov 21 15:24:41 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Nov 2022 15:24:41 GMT
Subject: RFR: 8294583: JShell: NPE in switch with non existing record
 pattern [v3]
In-Reply-To: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
References: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
Message-ID: <rUTocihatO3GJONym5UUq-fHN5NuAkOQjwNec78e6ks=.4de1e398-7dd8-4a45-9a95-19c32b2f2282@github.com>

> This fixes a situation where attribution errors are not short circuiting the compilation of an expression, e.g., in case of a declaration missing in the JShell evaluation of a switch expression.
> 
> Now there are two options:
> 
> 1. handle this in `handleSwitch` (specific to switches, and avoid the `NPE` raised according to the JBS description)
> 2. handle this centrally in the corresponding task that is used in two places: 1) JShell evaluation and 2) `tools.javac.combo`.
> 
> I adopted the second option. Any thoughts?

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11251/files
  - new: https://git.openjdk.org/jdk/pull/11251/files/696c03ed..6d9d403b

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

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

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

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: 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: 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: 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: 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 jjg at openjdk.org  Mon Nov 21 17:54:15 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 21 Nov 2022 17:54:15 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java [v2]
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Fix merge issue
 - Merge with upstream/master
 - JDK-8297164: Update troff man pages and CheckManPageOptions.java

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

Changes: https://git.openjdk.org/jdk/pull/11223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11223&range=01
  Stats: 8963 lines in 29 files changed: 471 ins; 1587 del; 6905 mod
  Patch: https://git.openjdk.org/jdk/pull/11223.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11223/head:pull/11223

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

From dfuchs at openjdk.org  Mon Nov 21 18:19:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Nov 2022 18:19:23 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java [v2]
In-Reply-To: <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
 <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>
Message-ID: <BfqsAA59PbkyFi7ceXdE3JClChGmOoN7zxbWxPP_pxw=.7948deb7-49d0-4553-8923-69f4daefb1ea@github.com>

On Mon, 21 Nov 2022 17:54:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
>> (See https://bugs.openjdk.org/browse/JDK-8297165)
>> 
>> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Fix merge issue
>  - Merge with upstream/master
>  - JDK-8297164: Update troff man pages and CheckManPageOptions.java

The diffs are a bit difficult to read but I didn't spot anything obviously wrong with jwebserver. I could see that the new compress option was there in jmod man page too. +1.

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

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

From jjg at openjdk.org  Mon Nov 21 22:06:36 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 21 Nov 2022 22:06:36 GMT
Subject: Integrated: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <heN0GBRdomaSVnNUZIi7L1vA_uegGEvn0ZQ1mOD6Mwc=.fb15980e-f807-42bb-976a-f112e0f642e3@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

This pull request has now been integrated.

Changeset: 5a45c251
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a45c25151b1da8e329ea2be21a0e4d2652f8b4a
Stats:     8963 lines in 29 files changed: 471 ins; 1587 del; 6905 mod

8297164: Update troff man pages and CheckManPageOptions.java

Reviewed-by: dholmes

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

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

From duke at openjdk.org  Mon Nov 21 23:03:29 2022
From: duke at openjdk.org (Bo Zhang)
Date: Mon, 21 Nov 2022 23:03:29 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v3]
In-Reply-To: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
Message-ID: <CKep3atbHXI8Asb_UoVefASTLldhmA47f04612mzpN8=.51b7e108-bc80-4096-872d-6ebe742bb241@github.com>

> This commit adds the missing `type` assignment when attributing a variable's initial value. In some cases, this issue causes an NPE.
> 
> This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.

Bo Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Resolve review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11263/files
  - new: https://git.openjdk.org/jdk/pull/11263/files/5c58e847..8bb111b8

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

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

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

From duke at openjdk.org  Mon Nov 21 23:06:50 2022
From: duke at openjdk.org (Bo Zhang)
Date: Mon, 21 Nov 2022 23:06:50 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v2]
In-Reply-To: <OunNcKDcEerX-A8j0w-Puh49avgU1zn0Xj_-Z5c1_Hc=.64bb025f-5617-43fc-9a15-5e475846c161@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
 <7aExdYETNph1ylMuo-LDbuNUKeZQJ13CfdIzPo0JR4Q=.ef3f776d-79e0-4a0f-bdb0-bf6c39ce05fa@github.com>
 <OunNcKDcEerX-A8j0w-Puh49avgU1zn0Xj_-Z5c1_Hc=.64bb025f-5617-43fc-9a15-5e475846c161@github.com>
Message-ID: <JakPcQeUYfEdzQZ7o1lKNBvwRJ3gjQanMvAHFl7vMFA=.e29a02d4-84ee-47d4-965d-8212d10cfd7d@github.com>

On Mon, 21 Nov 2022 14:25:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Bo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary space
>
> Good catch, but I would personally prefer if `attribExpr` would set the type (as it does under normal circumstances), presumably here?
> 
> https://github.com/openjdk/jdk/blob/5c3345404d850cf01d9629b48015f1783a32bfc0/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4651
> 
> Also, might be nice to have a (core javac) test that would not rely on JShell, if possible.

@lahodaj Done moving the assignment. However, this was not a problem with `javac`, probably due to different code path:


# zhb @ zhb in ~/Projects/jdk on git:jdk-8292625 x [7:03:45] C:1
$ cat Test.java
public class Test {
  public static void main() {
    var a = a;
  }
}

# zhb @ zhb in ~/Projects/jdk on git:jdk-8292625 x [7:03:48]
$ /Library/Java/JavaVirtualMachines/temurin-19.jdk/Contents/Home/bin/javac Test.java
Test.java:3: error: cannot infer type for local variable a
    var a = a;
        ^
  (cannot use 'var' on self-referencing variable)
1 error
printing javac parameters to: /Users/zhb/Projects/jdk/javac.20221122_070353.args


That's why I put the test into jshell tests.

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

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

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: 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: 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: 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: 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 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: 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: 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: 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 jlahoda at openjdk.org  Wed Nov 23 14:47:36 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Nov 2022 14:47:36 GMT
Subject: Integrated: 8295984: Remove unexpected JShell feature
In-Reply-To: <Ljac6ps1T03CJKHyuSvPNiTDPpSxRMnh0RthFH8LYtY=.d4f045be-7851-4964-b2b5-2d5f9dbe32c9@github.com>
References: <Ljac6ps1T03CJKHyuSvPNiTDPpSxRMnh0RthFH8LYtY=.d4f045be-7851-4964-b2b5-2d5f9dbe32c9@github.com>
Message-ID: <V_BOAZY6nm4-_GRUSOGm5N8zBwqfZMqOv7bjI5UVNvk=.70bd9e2e-7988-4a4c-a789-5cfc1142d01f@github.com>

On Fri, 4 Nov 2022 07:57:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch patches JShell to not have the ability to run URL specified on the command line. Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8296326
> 
> Thanks!

This pull request has now been integrated.

Changeset: bc59f2a4
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc59f2a4ac3ac02d8333a4f89525bc7c81dc3c9e
Stats:     30 lines in 4 files changed: 22 ins; 0 del; 8 mod

8295984: Remove unexpected JShell feature

Reviewed-by: cstein, sundar

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

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

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: 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: 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: 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: 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: 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 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: 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 jlahoda at openjdk.org  Wed Nov 23 19:12:09 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Nov 2022 19:12:09 GMT
Subject: RFR: 8297525: jdk/jshell/ToolBasicTest.java fails after JDK-8295984
Message-ID: <qXP7_7_QFZ7S19aVbidoLCseverRmC7F1Mqi4OLkajQ=.ea8886a8-af0f-4e05-bff3-e709c77ce442@github.com>

The expected text uses a platform newline, but the actual text seems to always use `'\n'`. Sorry for that.

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

Commit messages:
 - 8297525: jdk/jshell/ToolBasicTest.java fails after JDK-8295984

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

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

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: 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 dcubed at openjdk.org  Wed Nov 23 20:10:30 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 23 Nov 2022 20:10:30 GMT
Subject: RFR: 8297525: jdk/jshell/ToolBasicTest.java fails after
 JDK-8295984
In-Reply-To: <qXP7_7_QFZ7S19aVbidoLCseverRmC7F1Mqi4OLkajQ=.ea8886a8-af0f-4e05-bff3-e709c77ce442@github.com>
References: <qXP7_7_QFZ7S19aVbidoLCseverRmC7F1Mqi4OLkajQ=.ea8886a8-af0f-4e05-bff3-e709c77ce442@github.com>
Message-ID: <wlK6AVSpNPSc9J2PLAk8KO799vWoAAI_lHPFajnyLRA=.a0e8a048-c67c-416d-a5b9-6814ed29eca4@github.com>

On Wed, 23 Nov 2022 19:05:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The expected text uses a platform newline, but the actual text seems to always use `'\n'`. Sorry for that.

I guess my question is whether the bug is in jshell and not the test.

I'm good with the fix as-is since it will solve the Tier2 failures, but
perhaps it's in the wrong place...

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

Marked as reviewed by dcubed (Reviewer).

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

From jlahoda at openjdk.org  Wed Nov 23 20:22:19 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Nov 2022 20:22:19 GMT
Subject: RFR: 8297525: jdk/jshell/ToolBasicTest.java fails after
 JDK-8295984
In-Reply-To: <qXP7_7_QFZ7S19aVbidoLCseverRmC7F1Mqi4OLkajQ=.ea8886a8-af0f-4e05-bff3-e709c77ce442@github.com>
References: <qXP7_7_QFZ7S19aVbidoLCseverRmC7F1Mqi4OLkajQ=.ea8886a8-af0f-4e05-bff3-e709c77ce442@github.com>
Message-ID: <qeSQSPHUXa5friqpF1H-L8-BKfQvX7V7wbzLfJnkiFg=.e3ed2a01-4ee6-4453-b6b6-91bb358a06a9@github.com>

On Wed, 23 Nov 2022 19:05:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The expected text uses a platform newline, but the actual text seems to always use `'\n'`. Sorry for that.

I was somehow convinced the tests are using native line endings, but they are normalizing them here:
https://github.com/openjdk/jdk/blob/6dc4d891c3ad043405c65e0e0eeef28e9e5a2156/test/langtools/jdk/jshell/ReplToolTesting.java#L203

So, I don't think there's a bug in JShell, it is simply the test expecting wrong values.

(And I didn't fully realize the test is not tier1, and so not run on GitHub.)

Sorry for that and thanks for review!

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

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

From jlahoda at openjdk.org  Wed Nov 23 20:25:33 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Nov 2022 20:25:33 GMT
Subject: Integrated: 8297525: jdk/jshell/ToolBasicTest.java fails after
 JDK-8295984
In-Reply-To: <qXP7_7_QFZ7S19aVbidoLCseverRmC7F1Mqi4OLkajQ=.ea8886a8-af0f-4e05-bff3-e709c77ce442@github.com>
References: <qXP7_7_QFZ7S19aVbidoLCseverRmC7F1Mqi4OLkajQ=.ea8886a8-af0f-4e05-bff3-e709c77ce442@github.com>
Message-ID: <zhZyGDQVk5bHUOWpaWVUHkL52GQPoqqisxZKMklYOvo=.1a28ff3e-df22-4114-adca-5fa491ae49ad@github.com>

On Wed, 23 Nov 2022 19:05:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The expected text uses a platform newline, but the actual text seems to always use `'\n'`. Sorry for that.

This pull request has now been integrated.

Changeset: 91cd8a03
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91cd8a03666d5c09c951b439d7d94b79933d97f6
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8297525: jdk/jshell/ToolBasicTest.java fails after JDK-8295984

Reviewed-by: dcubed

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

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

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: 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 abimpoudis at openjdk.org  Fri Nov 25 12:34:30 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 25 Nov 2022 12:34:30 GMT
Subject: Integrated: 8294583: JShell: NPE in switch with non existing record
 pattern
In-Reply-To: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
References: <5Of2Qjc18zFwRk31AMyAOGr6T4lekXksL4f1umXHgMA=.da58bfac-4e93-4f2d-bf22-e5d21c7e1b87@github.com>
Message-ID: <fUTnWnVEklGst3pRX3MWbKDYwrEe4wl809ILEXa77xc=.eb3ca548-f616-4952-a707-df140cb0b2d4@github.com>

On Sun, 20 Nov 2022 12:20:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This fixes a situation where attribution errors are not short circuiting the compilation of an expression, e.g., in case of a declaration missing in the JShell evaluation of a switch expression.
> 
> Now there are two options:
> 
> 1. handle this in `handleSwitch` (specific to switches, and avoid the `NPE` raised according to the JBS description)
> 2. handle this centrally in the corresponding task that is used in two places: 1) JShell evaluation and 2) `tools.javac.combo`.
> 
> I adopted the second option. Any thoughts?

This pull request has now been integrated.

Changeset: 4f655702
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f65570204e2d38415e7761bd81660b081eae882
Stats:     49 lines in 2 files changed: 49 ins; 0 del; 0 mod

8294583: JShell: NPE in switch with non existing record pattern

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.org  Mon Nov 28 09:41:16 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Nov 2022 09:41:16 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v2]
In-Reply-To: <OunNcKDcEerX-A8j0w-Puh49avgU1zn0Xj_-Z5c1_Hc=.64bb025f-5617-43fc-9a15-5e475846c161@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
 <7aExdYETNph1ylMuo-LDbuNUKeZQJ13CfdIzPo0JR4Q=.ef3f776d-79e0-4a0f-bdb0-bf6c39ce05fa@github.com>
 <OunNcKDcEerX-A8j0w-Puh49avgU1zn0Xj_-Z5c1_Hc=.64bb025f-5617-43fc-9a15-5e475846c161@github.com>
Message-ID: <RQRo7xEb9T7lOiS8s0VbKK7ubOprQWYZNcc0uwqkN1g=.0b1f9543-3d56-48cd-8409-56b9d3375913@github.com>

On Mon, 21 Nov 2022 14:25:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Bo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary space
>
> Good catch, but I would personally prefer if `attribExpr` would set the type (as it does under normal circumstances), presumably here?
> 
> https://github.com/openjdk/jdk/blob/5c3345404d850cf01d9629b48015f1783a32bfc0/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4651
> 
> Also, might be nice to have a (core javac) test that would not rely on JShell, if possible.

> @lahodaj Done moving the assignment. However, this was not a problem with `javac`, probably due to different code path:
> 
> ```
> # zhb @ zhb in ~/Projects/jdk on git:jdk-8292625 x [7:03:45] C:1
> $ cat Test.java
> public class Test {
>   public static void main() {
>     var a = a;
>   }
> }
> 
> # zhb @ zhb in ~/Projects/jdk on git:jdk-8292625 x [7:03:48]
> $ /Library/Java/JavaVirtualMachines/temurin-19.jdk/Contents/Home/bin/javac Test.java
> Test.java:3: error: cannot infer type for local variable a
>     var a = a;
>         ^
>   (cannot use 'var' on self-referencing variable)
> 1 error
> printing javac parameters to: /Users/zhb/Projects/jdk/javac.20221122_070353.args
> ```
> 
> That's why I put the test into jshell tests.

Thanks for moving the assignment. For tests, the test in JShell is fine, but there are other ways to the attributes in addition to that, like actually checking the type is assigned in the AST:

diff --git a/test/langtools/tools/javac/attr/AttrRecoveryTest.java b/test/langtools/tools/javac/attr/AttrRecoveryTest.java
index b364cc28001..f5589a8093f 100644
--- a/test/langtools/tools/javac/attr/AttrRecoveryTest.java
+++ b/test/langtools/tools/javac/attr/AttrRecoveryTest.java
@@ -36,6 +36,7 @@
 import com.sun.source.tree.AnnotationTree;
 import com.sun.source.tree.CompilationUnitTree;
 import com.sun.source.tree.ErroneousTree;
+import com.sun.source.tree.VariableTree;
 import com.sun.source.util.TaskEvent;
 import com.sun.source.util.TaskListener;
 import com.sun.source.util.TreePath;
@@ -45,7 +46,9 @@ import java.nio.file.Files;
 import java.nio.file.Path;
 import java.nio.file.Paths;
 import java.util.List;
+import java.util.concurrent.atomic.AtomicInteger;
 import javax.lang.model.element.Element;
+import javax.lang.model.type.TypeMirror;
 
 import toolbox.TestRunner;
 import toolbox.JavacTask;
@@ -162,4 +165,61 @@ public class AttrRecoveryTest extends TestRunner {
             throw new AssertionError();
         }
     }
+
+    @Test
+    public void testVarAssignment2Self(Path base) throws Exception {
+        Path current = base;
+        Path src = current.resolve("src");
+        Path classes = current.resolve("classes");
+        tb.writeJavaFiles(src,
+                          """
+                          public class Test {
+                              void t() {
+                                  var v = v;
+                              }
+                          }
+                          """);
+
+        Files.createDirectories(classes);
+
+        AtomicInteger seenVariables = new AtomicInteger();
+        TreePathScanner<Void, Trees> checkTypes = new TreePathScanner<>() {
+            @Override
+            public Void visitVariable(VariableTree node, Trees trees) {
+                if (node.getName().contentEquals("v")) {
+                    TypeMirror type = trees.getTypeMirror(getCurrentPath());
+                    if (type == null) {
+                        throw new AssertionError("Unexpected null type!");
+                    }
+                    seenVariables.incrementAndGet();
+                }
+                return super.visitVariable(node, trees);
+            }
+        };
+
+        new JavacTask(tb)
+            .options("-XDrawDiagnostics")
+            .outdir(classes)
+            .files(tb.findJavaFiles(src))
+            .callback(t -> {
+                t.addTaskListener(new TaskListener() {
+                    CompilationUnitTree parsed;
+                    @Override
+                    public void finished(TaskEvent e) {
+                        switch (e.getKind()) {
+                            case PARSE -> parsed = e.getCompilationUnit();
+                            case COMPILATION ->
+                                checkTypes.scan(parsed, Trees.instance(t));
+                        }
+                    }
+                });
+            })
+            .run(Task.Expect.FAIL)
+            .writeAll()
+            .getOutputLines(Task.OutputKind.DIRECT);
+
+        if (seenVariables.get() != 1) {
+            throw new AssertionError("Didn't see enough variables: " + seenVariables);
+        }
+    }
 }


I think the advantage of having the test in the javac tests (in addition to the JShell test) is that if someone modifies javac, and only runs javac tests, it would still fail.

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

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

From duke at openjdk.org  Mon Nov 28 12:59:20 2022
From: duke at openjdk.org (Bo Zhang)
Date: Mon, 28 Nov 2022 12:59:20 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v4]
In-Reply-To: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
Message-ID: <KZitFKqna7TwX23uTaxvz1ynky34PKR7V-JHP_u1hyk=.1f6044e2-7ea7-464b-b193-be58df966770@github.com>

> This commit adds the missing `type` assignment when attributing a variable's initial value. In some cases, this issue causes an NPE.
> 
> This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.

Bo Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Add a test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11263/files
  - new: https://git.openjdk.org/jdk/pull/11263/files/8bb111b8..0e1d8034

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

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

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

From duke at openjdk.org  Mon Nov 28 12:59:22 2022
From: duke at openjdk.org (Bo Zhang)
Date: Mon, 28 Nov 2022 12:59:22 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v2]
In-Reply-To: <RQRo7xEb9T7lOiS8s0VbKK7ubOprQWYZNcc0uwqkN1g=.0b1f9543-3d56-48cd-8409-56b9d3375913@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
 <7aExdYETNph1ylMuo-LDbuNUKeZQJ13CfdIzPo0JR4Q=.ef3f776d-79e0-4a0f-bdb0-bf6c39ce05fa@github.com>
 <OunNcKDcEerX-A8j0w-Puh49avgU1zn0Xj_-Z5c1_Hc=.64bb025f-5617-43fc-9a15-5e475846c161@github.com>
 <RQRo7xEb9T7lOiS8s0VbKK7ubOprQWYZNcc0uwqkN1g=.0b1f9543-3d56-48cd-8409-56b9d3375913@github.com>
Message-ID: <BUNguDp4jPo-wwVCmaeO8W_4jOIaxw30E97F-MmrLMQ=.bfd700a2-0b60-4133-9fa4-f596f2fba90d@github.com>

On Mon, 28 Nov 2022 09:37:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Good catch, but I would personally prefer if `attribExpr` would set the type (as it does under normal circumstances), presumably here?
>> 
>> https://github.com/openjdk/jdk/blob/5c3345404d850cf01d9629b48015f1783a32bfc0/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4651
>> 
>> Also, might be nice to have a (core javac) test that would not rely on JShell, if possible.
>
>> @lahodaj Done moving the assignment. However, this was not a problem with `javac`, probably due to different code path:
>> 
>> ```
>> # zhb @ zhb in ~/Projects/jdk on git:jdk-8292625 x [7:03:45] C:1
>> $ cat Test.java
>> public class Test {
>>   public static void main() {
>>     var a = a;
>>   }
>> }
>> 
>> # zhb @ zhb in ~/Projects/jdk on git:jdk-8292625 x [7:03:48]
>> $ /Library/Java/JavaVirtualMachines/temurin-19.jdk/Contents/Home/bin/javac Test.java
>> Test.java:3: error: cannot infer type for local variable a
>>     var a = a;
>>         ^
>>   (cannot use 'var' on self-referencing variable)
>> 1 error
>> printing javac parameters to: /Users/zhb/Projects/jdk/javac.20221122_070353.args
>> ```
>> 
>> That's why I put the test into jshell tests.
> 
> Thanks for moving the assignment. For tests, the test in JShell is fine, but there are other ways to the attributes in addition to that, like actually checking the type is assigned in the AST:
> 
> diff --git a/test/langtools/tools/javac/attr/AttrRecoveryTest.java b/test/langtools/tools/javac/attr/AttrRecoveryTest.java
> index b364cc28001..f5589a8093f 100644
> --- a/test/langtools/tools/javac/attr/AttrRecoveryTest.java
> +++ b/test/langtools/tools/javac/attr/AttrRecoveryTest.java
> @@ -36,6 +36,7 @@
>  import com.sun.source.tree.AnnotationTree;
>  import com.sun.source.tree.CompilationUnitTree;
>  import com.sun.source.tree.ErroneousTree;
> +import com.sun.source.tree.VariableTree;
>  import com.sun.source.util.TaskEvent;
>  import com.sun.source.util.TaskListener;
>  import com.sun.source.util.TreePath;
> @@ -45,7 +46,9 @@ import java.nio.file.Files;
>  import java.nio.file.Path;
>  import java.nio.file.Paths;
>  import java.util.List;
> +import java.util.concurrent.atomic.AtomicInteger;
>  import javax.lang.model.element.Element;
> +import javax.lang.model.type.TypeMirror;
>  
>  import toolbox.TestRunner;
>  import toolbox.JavacTask;
> @@ -162,4 +165,61 @@ public class AttrRecoveryTest extends TestRunner {
>              throw new AssertionError();
>          }
>      }
> +
> +    @Test
> +    public void testVarAssignment2Self(Path base) throws Exception {
> +        Path current = base;
> +        Path src = current.resolve("src");
> +        Path classes = current.resolve("classes");
> +        tb.writeJavaFiles(src,
> +                          """
> +                          public class Test {
> +                              void t() {
> +                                  var v = v;
> +                              }
> +                          }
> +                          """);
> +
> +        Files.createDirectories(classes);
> +
> +        AtomicInteger seenVariables = new AtomicInteger();
> +        TreePathScanner<Void, Trees> checkTypes = new TreePathScanner<>() {
> +            @Override
> +            public Void visitVariable(VariableTree node, Trees trees) {
> +                if (node.getName().contentEquals("v")) {
> +                    TypeMirror type = trees.getTypeMirror(getCurrentPath());
> +                    if (type == null) {
> +                        throw new AssertionError("Unexpected null type!");
> +                    }
> +                    seenVariables.incrementAndGet();
> +                }
> +                return super.visitVariable(node, trees);
> +            }
> +        };
> +
> +        new JavacTask(tb)
> +            .options("-XDrawDiagnostics")
> +            .outdir(classes)
> +            .files(tb.findJavaFiles(src))
> +            .callback(t -> {
> +                t.addTaskListener(new TaskListener() {
> +                    CompilationUnitTree parsed;
> +                    @Override
> +                    public void finished(TaskEvent e) {
> +                        switch (e.getKind()) {
> +                            case PARSE -> parsed = e.getCompilationUnit();
> +                            case COMPILATION ->
> +                                checkTypes.scan(parsed, Trees.instance(t));
> +                        }
> +                    }
> +                });
> +            })
> +            .run(Task.Expect.FAIL)
> +            .writeAll()
> +            .getOutputLines(Task.OutputKind.DIRECT);
> +
> +        if (seenVariables.get() != 1) {
> +            throw new AssertionError("Didn't see enough variables: " + seenVariables);
> +        }
> +    }
>  }
> 
> 
> I think the advantage of having the test in the javac tests (in addition to the JShell test) is that if someone modifies javac, and only runs javac tests, it would still fail.

Thanks for the guidance @lahodaj !

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

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

From jlaskey at openjdk.org  Mon Nov 28 13:11:04 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 28 Nov 2022 13:11:04 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v4]
In-Reply-To: <KZitFKqna7TwX23uTaxvz1ynky34PKR7V-JHP_u1hyk=.1f6044e2-7ea7-464b-b193-be58df966770@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
 <KZitFKqna7TwX23uTaxvz1ynky34PKR7V-JHP_u1hyk=.1f6044e2-7ea7-464b-b193-be58df966770@github.com>
Message-ID: <as-qQ8atiDmB8pf643uIt1nOo9dKf5jTzRCNDtxyx9I=.9edef7c3-6535-4a94-8e22-69e7618b2bc4@github.com>

On Mon, 28 Nov 2022 12:59:20 GMT, Bo Zhang <duke at openjdk.org> wrote:

>> This commit adds the missing `type` assignment when attributing a variable's initial value. In some cases, this issue causes an NPE.
>> 
>> This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.
>
> Bo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test

Marked as reviewed by jlaskey (Reviewer).

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

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

From jlahoda at openjdk.org  Mon Nov 28 14:25:04 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Nov 2022 14:25:04 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v4]
In-Reply-To: <KZitFKqna7TwX23uTaxvz1ynky34PKR7V-JHP_u1hyk=.1f6044e2-7ea7-464b-b193-be58df966770@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
 <KZitFKqna7TwX23uTaxvz1ynky34PKR7V-JHP_u1hyk=.1f6044e2-7ea7-464b-b193-be58df966770@github.com>
Message-ID: <PJorcrxQGdhxLSR0wjDS-COG-ZQIhWYGTt5KyUFvVVM=.fd2871b2-5ec8-40c1-ba42-e5d6f46ebab4@github.com>

On Mon, 28 Nov 2022 12:59:20 GMT, Bo Zhang <duke at openjdk.org> wrote:

>> This commit adds the missing `type` assignment when attributing a variable's initial value. In some cases, this issue causes an NPE.
>> 
>> This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.
>
> Bo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test

Looks good to me!

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

Marked as reviewed by jlahoda (Reviewer).

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

From duke at openjdk.org  Tue Nov 29 01:15:12 2022
From: duke at openjdk.org (Bo Zhang)
Date: Tue, 29 Nov 2022 01:15:12 GMT
Subject: RFR: 8292625: jshell crash on "var a = a" [v2]
In-Reply-To: <RQRo7xEb9T7lOiS8s0VbKK7ubOprQWYZNcc0uwqkN1g=.0b1f9543-3d56-48cd-8409-56b9d3375913@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
 <7aExdYETNph1ylMuo-LDbuNUKeZQJ13CfdIzPo0JR4Q=.ef3f776d-79e0-4a0f-bdb0-bf6c39ce05fa@github.com>
 <OunNcKDcEerX-A8j0w-Puh49avgU1zn0Xj_-Z5c1_Hc=.64bb025f-5617-43fc-9a15-5e475846c161@github.com>
 <RQRo7xEb9T7lOiS8s0VbKK7ubOprQWYZNcc0uwqkN1g=.0b1f9543-3d56-48cd-8409-56b9d3375913@github.com>
Message-ID: <LFATX8D8dCeZAjhMya6dyA76V5z3-kAc8AOdnVHoCIQ=.97540df3-4152-400e-9b31-8db7b4c7ac48@github.com>

On Mon, 28 Nov 2022 09:37:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Good catch, but I would personally prefer if `attribExpr` would set the type (as it does under normal circumstances), presumably here?
>> 
>> https://github.com/openjdk/jdk/blob/5c3345404d850cf01d9629b48015f1783a32bfc0/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4651
>> 
>> Also, might be nice to have a (core javac) test that would not rely on JShell, if possible.
>
>> @lahodaj Done moving the assignment. However, this was not a problem with `javac`, probably due to different code path:
>> 
>> ```
>> # zhb @ zhb in ~/Projects/jdk on git:jdk-8292625 x [7:03:45] C:1
>> $ cat Test.java
>> public class Test {
>>   public static void main() {
>>     var a = a;
>>   }
>> }
>> 
>> # zhb @ zhb in ~/Projects/jdk on git:jdk-8292625 x [7:03:48]
>> $ /Library/Java/JavaVirtualMachines/temurin-19.jdk/Contents/Home/bin/javac Test.java
>> Test.java:3: error: cannot infer type for local variable a
>>     var a = a;
>>         ^
>>   (cannot use 'var' on self-referencing variable)
>> 1 error
>> printing javac parameters to: /Users/zhb/Projects/jdk/javac.20221122_070353.args
>> ```
>> 
>> That's why I put the test into jshell tests.
> 
> Thanks for moving the assignment. For tests, the test in JShell is fine, but there are other ways to the attributes in addition to that, like actually checking the type is assigned in the AST:
> 
> diff --git a/test/langtools/tools/javac/attr/AttrRecoveryTest.java b/test/langtools/tools/javac/attr/AttrRecoveryTest.java
> index b364cc28001..f5589a8093f 100644
> --- a/test/langtools/tools/javac/attr/AttrRecoveryTest.java
> +++ b/test/langtools/tools/javac/attr/AttrRecoveryTest.java
> @@ -36,6 +36,7 @@
>  import com.sun.source.tree.AnnotationTree;
>  import com.sun.source.tree.CompilationUnitTree;
>  import com.sun.source.tree.ErroneousTree;
> +import com.sun.source.tree.VariableTree;
>  import com.sun.source.util.TaskEvent;
>  import com.sun.source.util.TaskListener;
>  import com.sun.source.util.TreePath;
> @@ -45,7 +46,9 @@ import java.nio.file.Files;
>  import java.nio.file.Path;
>  import java.nio.file.Paths;
>  import java.util.List;
> +import java.util.concurrent.atomic.AtomicInteger;
>  import javax.lang.model.element.Element;
> +import javax.lang.model.type.TypeMirror;
>  
>  import toolbox.TestRunner;
>  import toolbox.JavacTask;
> @@ -162,4 +165,61 @@ public class AttrRecoveryTest extends TestRunner {
>              throw new AssertionError();
>          }
>      }
> +
> +    @Test
> +    public void testVarAssignment2Self(Path base) throws Exception {
> +        Path current = base;
> +        Path src = current.resolve("src");
> +        Path classes = current.resolve("classes");
> +        tb.writeJavaFiles(src,
> +                          """
> +                          public class Test {
> +                              void t() {
> +                                  var v = v;
> +                              }
> +                          }
> +                          """);
> +
> +        Files.createDirectories(classes);
> +
> +        AtomicInteger seenVariables = new AtomicInteger();
> +        TreePathScanner<Void, Trees> checkTypes = new TreePathScanner<>() {
> +            @Override
> +            public Void visitVariable(VariableTree node, Trees trees) {
> +                if (node.getName().contentEquals("v")) {
> +                    TypeMirror type = trees.getTypeMirror(getCurrentPath());
> +                    if (type == null) {
> +                        throw new AssertionError("Unexpected null type!");
> +                    }
> +                    seenVariables.incrementAndGet();
> +                }
> +                return super.visitVariable(node, trees);
> +            }
> +        };
> +
> +        new JavacTask(tb)
> +            .options("-XDrawDiagnostics")
> +            .outdir(classes)
> +            .files(tb.findJavaFiles(src))
> +            .callback(t -> {
> +                t.addTaskListener(new TaskListener() {
> +                    CompilationUnitTree parsed;
> +                    @Override
> +                    public void finished(TaskEvent e) {
> +                        switch (e.getKind()) {
> +                            case PARSE -> parsed = e.getCompilationUnit();
> +                            case COMPILATION ->
> +                                checkTypes.scan(parsed, Trees.instance(t));
> +                        }
> +                    }
> +                });
> +            })
> +            .run(Task.Expect.FAIL)
> +            .writeAll()
> +            .getOutputLines(Task.OutputKind.DIRECT);
> +
> +        if (seenVariables.get() != 1) {
> +            throw new AssertionError("Didn't see enough variables: " + seenVariables);
> +        }
> +    }
>  }
> 
> 
> I think the advantage of having the test in the javac tests (in addition to the JShell test) is that if someone modifies javac, and only runs javac tests, it would still fail.

Thanks @lahodaj . Can you please sponsor this one?

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

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

From duke at openjdk.org  Tue Nov 29 14:00:58 2022
From: duke at openjdk.org (Bo Zhang)
Date: Tue, 29 Nov 2022 14:00:58 GMT
Subject: Integrated: 8292625: jshell crash on "var a = a"
In-Reply-To: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
References: <N3hacmGF7_dkEu78pmpw2puqZ8treOeQaomQtJRv1TQ=.d6328180-da8f-46fe-9da4-c0b053030a98@github.com>
Message-ID: <Fv_V1juTRuISbS4jLHbrBD279ZUhhE8A1QYl8VvudFs=.3c5531bc-9547-48c9-9491-2d8ba44f33da@github.com>

On Mon, 21 Nov 2022 13:54:13 GMT, Bo Zhang <duke at openjdk.org> wrote:

> This commit adds the missing `type` assignment when attributing a variable's initial value. In some cases, this issue causes an NPE.
> 
> This issue has existed for a long time, but the NPE was swallowed until https://github.com/openjdk/jdk/commit/433394203dce55db95caefcb57bac9ec114ebc47 stopped swallowing such exceptions.

This pull request has now been integrated.

Changeset: 33587ffd
Author:    Bo Zhang <zhangbodut at gmail.com>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33587ffd35c568c1ef034f064e6f3f06fe9943c3
Stats:     73 lines in 3 files changed: 71 ins; 0 del; 2 mod

8292625: jshell crash on "var a = a"

Reviewed-by: jlaskey, jlahoda

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

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

From vromero at openjdk.org  Tue Nov 29 18:46:17 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 29 Nov 2022 18:46:17 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <GflccGWNfUMEyQHni5dFInGvdaJwiDoKDH_Rn6glf40=.209dd62b-541d-40a9-8e40-073858b5537f@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

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: 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 abimpoudis at openjdk.org  Tue Nov 29 19:37:19 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 29 Nov 2022 19:37:19 GMT
Subject: Integrated: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <qsfhn64DdHNKqfSe5bNqRo02Fe7Gapu9089u9p1-WAs=.e120347a-014a-42fb-a191-47655d7a15f3@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

This pull request has now been integrated.

Changeset: 7af6b4b5
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7af6b4b54cc2ead4f5dbd6bfa7fd343b84c1d8b5
Stats:     51 lines in 2 files changed: 50 ins; 0 del; 1 mod

8296012: jshell crashes on mismatched record pattern

Reviewed-by: vromero

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

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

From shade at openjdk.org  Wed Nov 30 08:49:32 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Nov 2022 08:49:32 GMT
Subject: RFR: 8297821: jdk/jshell/Test8294583.java fails on some platforms
Message-ID: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>

[JDK-8294583](https://bugs.openjdk.org/browse/JDK-8294583) added a new test that does `--enable-preview` to access new language constructs. Unfortunately, this test also enables Loom, which on some platforms like x86_32 uses the 1:1 fallback emulation, which does not support JVMTI. JShell apparently uses JDI -> JDWP -> JVMTI to work, and thus the test fails.

More logs in the bug.

Additional testing:
 - [x] Linux x86_64 fastdebug, test still passes
 - [x] Linux x86_32 fastdebug, test is now skipped

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/11428/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11428&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297821
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11428.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11428/head:pull/11428

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

From alanb at openjdk.org  Wed Nov 30 09:07:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 09:07:18 GMT
Subject: RFR: 8297821: jdk/jshell/Test8294583.java fails on some platforms
In-Reply-To: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>
References: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>
Message-ID: <1_MyGCIT4j1rt9NCSmGaPAs0ITZ1COOVOcre9PyNGBM=.ca741a84-9e19-433c-81c5-06321dea1cb5@github.com>

On Wed, 30 Nov 2022 08:39:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8294583](https://bugs.openjdk.org/browse/JDK-8294583) added a new test that does `--enable-preview` to access new language constructs. Unfortunately, this test also enables Loom, which on some platforms like x86_32 uses the 1:1 fallback emulation, which does not support JVMTI. JShell apparently uses JDI -> JDWP -> JVMTI to work, and thus the test fails.
> 
> More logs in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, test still passes
>  - [x] Linux x86_32 fastdebug, test is now skipped

This looks okay, you can close JDK-8297790 as it was tracking the same issue.

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

Marked as reviewed by alanb (Reviewer).

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

From jlahoda at openjdk.org  Wed Nov 30 09:51:11 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Nov 2022 09:51:11 GMT
Subject: RFR: 8297821: jdk/jshell/Test8294583.java fails on some platforms
In-Reply-To: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>
References: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>
Message-ID: <nrvHsYyesGZktHIESo7yIPF4hyEmAG7hXI7gybuvlh4=.614cf408-d400-4ce3-96e9-8e95584ff09e@github.com>

On Wed, 30 Nov 2022 08:39:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8294583](https://bugs.openjdk.org/browse/JDK-8294583) added a new test that does `--enable-preview` to access new language constructs. Unfortunately, this test also enables Loom, which on some platforms like x86_32 uses the 1:1 fallback emulation, which does not support JVMTI. JShell apparently uses JDI -> JDWP -> JVMTI to work, and thus the test fails.
> 
> More logs in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, test still passes
>  - [x] Linux x86_32 fastdebug, test is now skipped

Seems OK. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

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

From shade at openjdk.org  Wed Nov 30 09:51:12 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Nov 2022 09:51:12 GMT
Subject: RFR: 8297821: jdk/jshell/Test8294583.java fails on some platforms
In-Reply-To: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>
References: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>
Message-ID: <BlHIKihLnSLRh_BeuFLhD37hyUtTm-H-h52h3bzLjwU=.076c7040-980e-4616-a36e-ec86f1c6a475@github.com>

On Wed, 30 Nov 2022 08:39:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8294583](https://bugs.openjdk.org/browse/JDK-8294583) added a new test that does `--enable-preview` to access new language constructs. Unfortunately, this test also enables Loom, which on some platforms like x86_32 uses the 1:1 fallback emulation, which does not support JVMTI. JShell apparently uses JDI -> JDWP -> JVMTI to work, and thus the test fails.
> 
> More logs in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, test still passes
>  - [x] Linux x86_32 fastdebug, test is now skipped

Trivial, right? I would like to integrate now to make GHAs cleaner.

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

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

From naoto at openjdk.org  Wed Nov 30 17:03:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Nov 2022 17:03:57 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments
Message-ID: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>

This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

Commit messages:
 - Minor fixup
 - GetPropertyAction.privilegedGetProperty
 - Changed to use SharedSecrets
 - Password.readPassword() fix
 - Always returns Console, even without TTY attached
 - Comments refresh, clean-up
 - Removed charset from factory, added new jdk.console property
 - Revived the provider i/f
 - Replacing SPI with proxy delegate
 - javadoc
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ae5b1f76...96a46843

Changes: https://git.openjdk.org/jdk/pull/11421/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295803
  Stats: 387 lines in 10 files changed: 373 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From jlaskey at openjdk.org  Wed Nov 30 17:17:09 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 30 Nov 2022 17:17:09 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <SUWtCtsUcioHCAW1JuIZI1zrvQmv5yFmsbsOSEo5B3k=.59acf778-f4f3-4c15-9dde-5cd486c88eae@github.com>

On Tue, 29 Nov 2022 19:38:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

Looks good otherwise. Add tests.

src/java.base/share/classes/java/io/Console.java line 617:

> 615: 
> 616:             public Charset charset() {
> 617:                 return cons.charset();

What happens when cons is null?

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

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

From naoto at openjdk.org  Wed Nov 30 18:49:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Nov 2022 18:49:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments
In-Reply-To: <SUWtCtsUcioHCAW1JuIZI1zrvQmv5yFmsbsOSEo5B3k=.59acf778-f4f3-4c15-9dde-5cd486c88eae@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <SUWtCtsUcioHCAW1JuIZI1zrvQmv5yFmsbsOSEo5B3k=.59acf778-f4f3-4c15-9dde-5cd486c88eae@github.com>
Message-ID: <7WZIOj2VKO3XArhieDZXxG_YQgQCHtjyNRuRtAbfxHs=.490ebf81-101f-4a91-8b87-f1c82f07e5f1@github.com>

On Wed, 30 Nov 2022 17:07:35 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> src/java.base/share/classes/java/io/Console.java line 617:
> 
>> 615: 
>> 616:             public Charset charset() {
>> 617:                 return cons.charset();
> 
> What happens when cons is null?

Turned out that `JavaIOAccess.charset()` is not used anywhere. Will remove this method. Will also add a test.

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

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

From naoto at openjdk.org  Wed Nov 30 20:44:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Nov 2022 20:44:30 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Adds a test
 - Removed JavaIOAccess.charset() which is no longer needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/96a46843..3d2b01f6

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

  Stats: 70 lines in 4 files changed: 64 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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