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 darcy at openjdk.org  Tue Nov  1 02:27:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 1 Nov 2022 02:27:32 GMT
Subject: RFR: 8294461: wrong effectively final determination by javac [v2]
In-Reply-To: <LaIQIkFUwyHdgt-TH0TSPf2dmtZc-TeB0yXCf0xwf20=.caaecb78-4f28-4aed-9b6c-75438c3d3996@github.com>
References: <egFxyVqD2GYc5iyZWKpmSEfRn1y3i4MnahYLQk91Y34=.e99d43fc-7afe-4096-a91f-e59c67659e29@github.com>
 <dr8Kj1I3xZf9MvKmMJ-xDGRrInr-fnjZVHixy02YVmc=.4db885e0-398a-45a1-8964-7309d937c1f9@github.com>
 <LaIQIkFUwyHdgt-TH0TSPf2dmtZc-TeB0yXCf0xwf20=.caaecb78-4f28-4aed-9b6c-75438c3d3996@github.com>
Message-ID: <gYa841BYbdH0XDxQhZY6Z0oM9zwYQK8KaU_U5ajJce8=.c2906500-5055-4fcc-a6d2-68fea850c709@github.com>

On Mon, 31 Oct 2022 19:00:32 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> There shouldn't be any spec change implied by this change. From my understanding, the compiler was not following the spec, which says that the variable `i` in the example is not effectively final. This change makes the compiler follow the spec and generate a "local variables referenced from a lambda expression must be final or effectively final" error.
> 
> Regarding release notes, I'll let someone else who has more familiarity with the release process comment on that.

Adding some additional context, there CSR reviews both specification changes and behavioral changes considered to have sufficiently high compatibility impact.

This change renders code that previously (if erroneously) compiled into a compilation error, which is a source compatibility concern. (Changing code that compiles into code that doesn't compile is considered a more serious change than the reverse.)

Offhand, I don't know how often such coding patterns may appear in practice; we should some internal tooling which can help gauge that. A modification that may be suggested is only doing the updated check for source level 20 and higher.

HTH

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

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

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 abimpoudis at openjdk.org  Tue Nov  1 08:18:22 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 1 Nov 2022 08:18:22 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v5]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <XYzqFg0AYoly-FZ-MpuHPkpFRe3eyWxKZ91zHDyp_mg=.f7177bcd-5108-4fb7-9698-a0bbe0aa7402@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

Aggelos Biboudis 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 ten additional commits since the last revision:

 - Simplify getDeclarationKind
 - Adjustments to make for-patterns and JDK-8294942 work together.
 - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns
 - Address Review
 - Fix applicability bug
 - Store element type calculation result in JCEnhancedForLoop
 - API cleanup.
 - Adding @since, adding PreviewFeature, restoring API method.
 - 8294943: Implement record patterns in enhanced for

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/892fddf3..3e07a53d

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

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

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

From mcimadamore at openjdk.org  Tue Nov  1 10:31:19 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 10:31:19 GMT
Subject: RFR: 8232933: Javac inferred type does not conform to equality
 constraint
In-Reply-To: <2euRx3nxZrGa-iDmuGUJCo9e6rOxFXYBhdhCI7PQjeo=.4fc91bac-8072-43c4-8bab-72ef38467df8@github.com>
References: <2euRx3nxZrGa-iDmuGUJCo9e6rOxFXYBhdhCI7PQjeo=.4fc91bac-8072-43c4-8bab-72ef38467df8@github.com>
Message-ID: <Ojes2rap6FE4GC_FW-Ds50KvO7QBTD0J8M8v8NntEgY=.604723e7-2ae4-44e6-b463-3461b4cb787d@github.com>

On Fri, 28 Oct 2022 02:56:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> When dealing with nested invocations it could be that the inference context of a nested invocation is propagated to the inference context of the outer invocation. There are occasions when the propagated inference context can be minimized if some of its inference variables are deemed redundant. This is an optimization that is done in order to speed up the type inference algo which can take a while if the number of variables to be reduced is large. Of course by removing some variables from an inference context we have an inherent risk of cutting too much and not being able to produce the same results compared to not minimizing it. My understanding is that this bug shows one of those cases in which an inference context has been reduced too much.
> 
> The proposed solution is not to minimize an inference context if at least one of its inference variables is a capture type. The reason is because when capture types are present, some bounds are wildcards which could be captured again generating new capture types etc., this could make impossible to prove that some constraints hold for an inference context, thus making the compiler wrongly reject correct code.
> 
> TIA

The fix seems ok, if perhaps a bit too aggressive. Probably the problem comes from the fact that we should never treat captured inference variables as "regular" inference variables - so the minimization algorithm should treat them as black boxes and try not to do much with them. Of course bailing out if any capture is spotted is also an ok approach. It would be interesting to understand if this patch significantly alter the performance of the compiler in more common use cases.

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

Marked as reviewed by mcimadamore (Reviewer).

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

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 12:40:48 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 12:40:48 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview)
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <Htv9U5teYGyWLX1UCGT-tBDid8XzEKXm9R6_kb3jtBY=.47bf6046-65df-4de1-a2aa-900160d1eecc@github.com>

On Fri, 21 Oct 2022 11:56:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 678:

> 676: 
> 677:         //step 2:
> 678:         Set<Symbol> patternTypeSuperTypes = new HashSet<>();

Can you use `Infer::getParameterizedSupers` for this?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 714:

> 712:             } else {
> 713:                 List<Type> upperBounds = undet.getBounds(InferenceBound.UPPER);
> 714:                 Type bound = upperBounds.isEmpty() ? syms.objectType : types.glb(upperBounds);

I'm not sure this is 100% correct. E.g. what if an under variable has an upper bound that refers to itself - e.g. `T <: Foo<T>`. In this case we need to step - first create the new tvars, then replace new tvars in the bound of the old ones. We do this in `Infer::instantiateAsUninferredVars` - perhaps some code from there should be borrowed?

test/langtools/tools/javac/patterns/InferenceUnitTest.java line 164:

> 162:     }
> 163: 
> 164:     private void checkAsSub(String base, String test, String expected) {

maybe change the name of this function, since Types::asSub is no longer used

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

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

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 duke at openjdk.org  Tue Nov  1 14:02:36 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 1 Nov 2022 14:02:36 GMT
Subject: RFR: 8294461: wrong effectively final determination by javac [v2]
In-Reply-To: <dr8Kj1I3xZf9MvKmMJ-xDGRrInr-fnjZVHixy02YVmc=.4db885e0-398a-45a1-8964-7309d937c1f9@github.com>
References: <egFxyVqD2GYc5iyZWKpmSEfRn1y3i4MnahYLQk91Y34=.e99d43fc-7afe-4096-a91f-e59c67659e29@github.com>
 <dr8Kj1I3xZf9MvKmMJ-xDGRrInr-fnjZVHixy02YVmc=.4db885e0-398a-45a1-8964-7309d937c1f9@github.com>
Message-ID: <_9DKSTD4TrYw8Rd1kuBI43pMDKrjvVXY2AH3TunrlVw=.d1c94662-ac03-40af-a8a6-6ffff0260027@github.com>

On Wed, 26 Oct 2022 19:45:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug involves DA/DU analysis and the concept of "effectively final".
>> 
>> Here's the test case, which the compiler currently but incorrectly accepts:
>> 
>>     for (int i = 0; i < 10; i++) {
>>         Runnable r = () -> System.out.println(i);   // variable i is NOT effectively final
>>         break;                                      // even though "i++" is never reached
>>     }
>> 
>> 
>> For the purposes of "effectively final", it doesn't matter whether an assignment statement that makes a variable no longer effectively final is actually reachable or not. In cases like the `i++` above, a statement can be actually unreachable yet not "unreachable" according to the JLS, and so it does not generate an "unreachable statement" compiler error (which would otherwise hide this bug).
>> 
>> JLS ?4.12.4 states:
>> 
>>> A local variable declared by a statement and whose declarator has an initializer ... is effectively final if all of the following are true:
>>> ...
>>> ? It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15).
>> 
>> So clearly `i` is not effectively final.
>> 
>> However, the way we calculate effective finality does not involve actually looking for increment/decrement operators. Instead, it's determined during DA/DU analysis: non-final variables have an `EFFECTIVELY_FINAL` flag which is initialized to `true` and then cleared if/when we encounter contrary evidence - e.g., an assignment when not DU.
>> 
>> For simplicity, the DA/DU analysis works like this:
>> * Variables with initializers are treated like variables without initializers followed by an assignment
>> * Increment/decrement operators are treated as a normal read followed by a normal assignment.
>> 
>> These are reasonable. However, it means this clause of JLS ?4.12.4 effectively applies:
>> 
>>> A local variable declared by a statement and whose declarator lacks an initializer is effectively final if all of the following are true:
>>> ...
>>> ? Whenever it occurs as the left hand side in an assignment expression, it is definitely unassigned and not definitely assigned before the assignment...
>> 
>> The bug with the current code is that when we see an assignment to a variable with the `EFFECTIVELY_FINAL` flag still set, we clear the flag if the variable is not DU, but we are _not_ clearing the flag if the variable is DA, as required above. This happens with the `i++` statement because, by virtue of it being actually unreachable, `i` is both DA and DU before that statement.
>> 
>> This patch corrects that omission.
>
> Archie L. Cobbs 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8294461
>  - A for loop variable is not effectively final even if the loop never increments.

Thanks for the clarifications, now I understand better the rationale.

Seems this example might be a good one to add to the spec in a non-normative/informational blurb, to demonstrate (a) how "JLS unreachable" doesn't always equal "flow analysis unreachable", and/or (b) how "effectively final" can fail because of statements that are "flow analysis unreachable".

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

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

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 weijun at openjdk.org  Tue Nov  1 14:27:25 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 1 Nov 2022 14:27:25 GMT
Subject: RFR: 8296167:
 test/langtools/tools/jdeps/jdkinternals/ShowReplacement.java failing after
 JDK-8296072
Message-ID: <7ISuHIn0Hmcot_xfuCazJ2YEsEnxJxr0iJEXEtHSARY=.afe3cc30-00a9-4f35-8e3d-17e22a058aae@github.com>

The argument of `DerEncoder::derEncode` changed.

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

Commit messages:
 - the fix

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

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

From alanb at openjdk.org  Tue Nov  1 14:42:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 14:42:36 GMT
Subject: RFR: 8296167:
 test/langtools/tools/jdeps/jdkinternals/ShowReplacement.java failing after
 JDK-8296072
In-Reply-To: <7ISuHIn0Hmcot_xfuCazJ2YEsEnxJxr0iJEXEtHSARY=.afe3cc30-00a9-4f35-8e3d-17e22a058aae@github.com>
References: <7ISuHIn0Hmcot_xfuCazJ2YEsEnxJxr0iJEXEtHSARY=.afe3cc30-00a9-4f35-8e3d-17e22a058aae@github.com>
Message-ID: <gYXzgmeA81FIH1QVSebvdT1uJfWmBKy9Y3_RIm8Z7pA=.3d058ce4-5624-432b-9de9-1710008549a2@github.com>

On Tue, 1 Nov 2022 14:18:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The argument of `DerEncoder::derEncode` changed.

Marked as reviewed by alanb (Reviewer).

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

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

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 joe.darcy at oracle.com  Tue Nov  1 16:36:35 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 1 Nov 2022 09:36:35 -0700
Subject: CSR review request for start-of-JDK-21 langtools changes
Message-ID: <186e9820-75f9-9f76-62d5-f0ac0f3fa961@oracle.com>

Hello,

Please review these two CSRs associated with the upcoming start of JDK 21:

 ??? JDK-8296180: Add source 21 and target 21 to javac
 ??? https://bugs.openjdk.org/browse/JDK-8296180

 ??? JDK-8296179: Add SourceVersion.RELEASE_21
 ??? https://bugs.openjdk.org/browse/JDK-8296179

The changes area analogous to similar changes made at the start of 
earlier releases.

-Joe


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 vromero at openjdk.org  Tue Nov  1 19:15:06 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 1 Nov 2022 19:15:06 GMT
Subject: RFR: 8232933: Javac inferred type does not conform to equality
 constraint
In-Reply-To: <Ojes2rap6FE4GC_FW-Ds50KvO7QBTD0J8M8v8NntEgY=.604723e7-2ae4-44e6-b463-3461b4cb787d@github.com>
References: <2euRx3nxZrGa-iDmuGUJCo9e6rOxFXYBhdhCI7PQjeo=.4fc91bac-8072-43c4-8bab-72ef38467df8@github.com>
 <Ojes2rap6FE4GC_FW-Ds50KvO7QBTD0J8M8v8NntEgY=.604723e7-2ae4-44e6-b463-3461b4cb787d@github.com>
Message-ID: <E06pCYVvYLf-kPc0zoDRU0uaU1360K-_NkUJRyH4BzQ=.485ff991-fc13-436a-b475-f3436aa5a475@github.com>

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

> The fix seems ok, if perhaps a bit too aggressive. Probably the problem comes from the fact that we should never treat captured inference variables as "regular" inference variables - so the minimization algorithm should treat them as black boxes and try not to do much with them. Of course bailing out if any capture is spotted is also an ok approach. It would be interesting to understand if this patch significantly alter the performance of the compiler in more common use cases.

Thanks for the review, some comments, I'm not sure if treating captured types as a black box could help. I assume you mean: if there are captured types just add them to the minimal set. But at least in this particular case this doesn't help. Here we have the following situation:

- there is an inference variable `A`, using same variable name as in the test case, who's undetVar has an equal bound linking it to the captured type
- so even if we determine that the captured type should be included in the minimal set, `A` won't ever be considered as it is not a bound of the captured type but the other way around

so we are back to square 1. We could define a more complex heuristic here to fit this case kind of saying OK if there are captured types, add them to the minimal set, along with any other variable equal to it. But I'm not sure if this will just fix this issue but not a similar one down the road. This is why I went for the all or nothing solution. Also, I think we are facing here a correctness issue so evaluating if the performance is hit or not, IMO is secondary if the correctness issue is unsolved.

PS. I mean correctness of the type inference algo

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

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

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 joehw at openjdk.org  Wed Nov  2 18:19:17 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 2 Nov 2022 18:19:17 GMT
Subject: RFR: JDK-8288232: Address typos in jar man page
In-Reply-To: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com>
References: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com>
Message-ID: <yk1rlV3--1lkhJLgKYK493LzNbMZcfKvLFkIYxOnPAk=.62062c2f-2b8d-4c33-bf61-a288adbed51d@github.com>

On Wed, 2 Nov 2022 14:04:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi
> 
> Please review this update to the jar man page which removes the "=" for the non GNU style options
> 
> Best
> Lance

Marked as reviewed by joehw (Reviewer).

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

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

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 duke at openjdk.org  Wed Nov  2 19:13:59 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 2 Nov 2022 19:13:59 GMT
Subject: RFR: 8193904: Uninitialized final field access and qualified this
Message-ID: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>

If a class `MyClass` has a blank final field `foo` that has not yet been assigned, the compiler prevents you from accessing it via the expressions `foo` or `this.foo`. However, it does not prevent you from accessing it via the expression `MyClass.this.foo`.

Here's a simple example:

class QualifiedThis {
    final int foo;
    QualifiedThis() {
        System.err.println(QualifiedThis.this.foo);   // should get an error here
        this.foo = 42;
    }
}


This patch fixes that omission.

I couldn't find an existing method that answers the question "Is this AST tree a reference to the current instance of the class I'm now compiling?" so I wrote a new one `TreeInfo.isThisReference()`.

The question itself is a little tricky. For example, `this` alone always is, but `Foo.this` is if the class being compiled is `Foo` or any supertype of `Foo`, *except* when `Foo` is an outer class containing the class being compiled, when it instead refers to that outer instance.

On the other hand, `Foo.super` (which, unlike `Foo.this`, can only be used to invoke a method), when `Foo` is a type and not a variable, refers to the current 'this' instance when the class being compiled is `Foo` or any supertype of `Foo`, period.

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

Commit messages:
 - Disallow early access to final fields via qualified 'this'.

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

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

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: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 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 forax at univ-mlv.fr  Wed Nov  2 19:28:38 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 2 Nov 2022 20:28:38 +0100 (CET)
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
Message-ID: <321410319.38475751.1667417318889.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Archie L. Cobbs" <duke at openjdk.org>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Wednesday, November 2, 2022 8:13:59 PM
> Subject: RFR: 8193904: Uninitialized final field access and qualified this

> If a class `MyClass` has a blank final field `foo` that has not yet been
> assigned, the compiler prevents you from accessing it via the expressions `foo`
> or `this.foo`. However, it does not prevent you from accessing it via the
> expression `MyClass.this.foo`.
> 
> Here's a simple example:
> 
> class QualifiedThis {
>    final int foo;
>    QualifiedThis() {
>        System.err.println(QualifiedThis.this.foo);   // should get an error here
>        this.foo = 42;
>    }
> }
> 
> 
> This patch fixes that omission.
> 
> I couldn't find an existing method that answers the question "Is this AST tree a
> reference to the current instance of the class I'm now compiling?" so I wrote a
> new one `TreeInfo.isThisReference()`.
> 
> The question itself is a little tricky. For example, `this` alone always is, but
> `Foo.this` is if the class being compiled is `Foo` or any supertype of `Foo`,
> *except* when `Foo` is an outer class containing the class being compiled, when
> it instead refers to that outer instance.

yes, i've always seen the qualification of this by the current class as a weird unnecessary generalization
(John in CC if there is a real reason/use case for it).

> 
> On the other hand, `Foo.super` (which, unlike `Foo.this`, can only be used to
> invoke a method), when `Foo` is a type and not a variable, refers to the
> current 'this' instance when the class being compiled is `Foo` or any supertype
> of `Foo`, period.

yes.

R?mi


> 
> -------------
> 
> Commit messages:
> - Disallow early access to final fields via qualified 'this'.
> 
> Changes: https://git.openjdk.org/jdk/pull/10956/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10956&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8193904
>  Stats: 73 lines in 5 files changed: 70 ins; 0 del; 3 mod
>  Patch: https://git.openjdk.org/jdk/pull/10956.diff
>  Fetch: git fetch https://git.openjdk.org/jdk pull/10956/head:pull/10956
> 
> PR: https://git.openjdk.org/jdk/pull/10956

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 alex.buckley at oracle.com  Wed Nov  2 19:46:06 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 2 Nov 2022 12:46:06 -0700
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
Message-ID: <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>

JLS ch.16 is specific that only `foo` and `this.foo` cause an error. See 
the definition of "access" in the opening paragraphs of the chapter.

I seem to recall some (recent?) discussion about whether other 
qualifications of foo should count as "access", but can't find it now.

Alex

On 11/2/2022 12:13 PM, Archie L. Cobbs wrote:
> If a class `MyClass` has a blank final field `foo` that has not yet been assigned, the compiler prevents you from accessing it via the expressions `foo` or `this.foo`. However, it does not prevent you from accessing it via the expression `MyClass.this.foo`.
> 
> Here's a simple example:
> 
> class QualifiedThis {
>      final int foo;
>      QualifiedThis() {
>          System.err.println(QualifiedThis.this.foo);   // should get an error here
>          this.foo = 42;
>      }
> }
> 
> 
> This patch fixes that omission.
> 
> I couldn't find an existing method that answers the question "Is this AST tree a reference to the current instance of the class I'm now compiling?" so I wrote a new one `TreeInfo.isThisReference()`.
> 
> The question itself is a little tricky. For example, `this` alone always is, but `Foo.this` is if the class being compiled is `Foo` or any supertype of `Foo`, *except* when `Foo` is an outer class containing the class being compiled, when it instead refers to that outer instance.
> 
> On the other hand, `Foo.super` (which, unlike `Foo.this`, can only be used to invoke a method), when `Foo` is a type and not a variable, refers to the current 'this' instance when the class being compiled is `Foo` or any supertype of `Foo`, period.
> 
> -------------
> 
> Commit messages:
>   - Disallow early access to final fields via qualified 'this'.
> 
> Changes: https://git.openjdk.org/jdk/pull/10956/files
>   Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10956&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8193904
>    Stats: 73 lines in 5 files changed: 70 ins; 0 del; 3 mod
>    Patch: https://git.openjdk.org/jdk/pull/10956.diff
>    Fetch: git fetch https://git.openjdk.org/jdk pull/10956/head:pull/10956
> 
> PR: https://git.openjdk.org/jdk/pull/10956

From naoto at openjdk.org  Wed Nov  2 20:07:25 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Nov 2022 20:07:25 GMT
Subject: RFR: JDK-8288232: Address typos in jar man page
In-Reply-To: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com>
References: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com>
Message-ID: <fE0LJ1s3dREfUlyuZW9_TwZBxZVi6grRIeufVxrdO9A=.5a69c7f8-bf74-40e5-987f-dbdb276b51ec@github.com>

On Wed, 2 Nov 2022 14:04:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi
> 
> Please review this update to the jar man page which removes the "=" for the non GNU style options
> 
> Best
> Lance

Marked as reviewed by naoto (Reviewer).

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

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

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 archie.cobbs at gmail.com  Wed Nov  2 20:18:16 2022
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 2 Nov 2022 15:18:16 -0500
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
Message-ID: <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>

On Wed, Nov 2, 2022 at 2:47 PM Alex Buckley <alex.buckley at oracle.com> wrote:

> JLS ch.16 is specific that only `foo` and `this.foo` cause an error. See
> the definition of "access" in the opening paragraphs of the chapter.
>

Thanks for pointing that out, which I forgot to do. The JLS language is:

An access to its value consists of the simple name of the variable (or, for
a field, the simple name of the field qualified by this) occurring anywhere
in an expression except as the left-hand operand of the simple assignment
operator =

In theory one could argue that MyClass.this.foo is also an example of "the
simple name of the field qualified by this" - just look at the latter part,
no?

Regardless, it looks like there needs to be a spec change... right? I'm
assuming we'd rather do that than continue to allow the current behavior.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221102/cc6edeaa/attachment.htm>

From bpb at openjdk.org  Wed Nov  2 21:04:39 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Nov 2022 21:04:39 GMT
Subject: RFR: JDK-8288232: Address typos in jar man page
In-Reply-To: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com>
References: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com>
Message-ID: <S7XINp8470B156U7KKlX9y2_erBIhs2R7wmvk9FqsH0=.1cd9e1e2-b72c-4853-a731-ffcc57c3655c@github.com>

On Wed, 2 Nov 2022 14:04:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi
> 
> Please review this update to the jar man page which removes the "=" for the non GNU style options
> 
> Best
> Lance

Marked as reviewed by bpb (Reviewer).

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

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

From alex.buckley at oracle.com  Wed Nov  2 21:19:21 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 2 Nov 2022 14:19:21 -0700
Subject: [External] : Re: RFR: 8193904: Uninitialized final field access
 and qualified this
In-Reply-To: <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
Message-ID: <8afdb3b2-102b-27d1-f427-98e5f199354b@oracle.com>

DU/DA analysis is about whether names have bindings. `x.foo` and `new 
C().foo` and `m().foo` are expressions, not names, so we don't attempt 
the analysis on them. As Jan points out [1], access via expressions is 
hard to track. `this.foo` is an expression, but a very easy one, so we 
treat it like the name `foo` and do the analysis. `A.B.C.this.foo` is an 
expression with a qualified-this subexpression and now you need a bunch 
of analysis to figure out whether it means the same as the name `foo`.

Alex

[1] 
https://bugs.openjdk.org/browse/JDK-8289777?focusedCommentId=14516785&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14516785


On 11/2/2022 1:18 PM, Archie Cobbs wrote:
> On Wed, Nov 2, 2022 at 2:47 PM Alex Buckley <alex.buckley at oracle.com 
> <mailto:alex.buckley at oracle.com>> wrote:
> 
>     JLS ch.16 is specific that only `foo` and `this.foo` cause an error.
>     See
>     the definition of "access" in the opening paragraphs of the chapter.
> 
> 
> Thanks for pointing that out, which I forgot to do. The JLS language is:
> 
> An access to its value consists of the simple name of the variable (or, 
> for a field, the simple name of the field qualified by |this|) occurring 
> anywhere in an expression except as the left-hand operand of the simple 
> assignment operator |=| ||
> 
> In theory one could argue that MyClass.this.foo is also an example of 
> "the simple name of the field qualified by |this" - just look at the 
> latter part, no?
> |
> |
> |
> Regardless, it looks like there needs to be a spec change... right? I'm 
> assuming we'd rather do that than continue to allow the current behavior.
> 
> Thanks,
> -Archie
> 
> -- 
> Archie L. Cobbs

From archie.cobbs at gmail.com  Wed Nov  2 21:28:58 2022
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 2 Nov 2022 16:28:58 -0500
Subject: [External] : Re: RFR: 8193904: Uninitialized final field access
 and qualified this
In-Reply-To: <8afdb3b2-102b-27d1-f427-98e5f199354b@oracle.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
 <8afdb3b2-102b-27d1-f427-98e5f199354b@oracle.com>
Message-ID: <CANSoFxuAV_f5XXr_RAC=bPxEgLcSxFFsDJOJPu2_CrvMSLudyA@mail.gmail.com>

On Wed, Nov 2, 2022 at 4:19 PM Alex Buckley <alex.buckley at oracle.com> wrote:

> DU/DA analysis is about whether names have bindings. `x.foo` and `new
> C().foo` and `m().foo` are expressions, not names, so we don't attempt
> the analysis on them. As Jan points out [1], access via expressions is
> hard to track. `this.foo` is an expression, but a very easy one, so we
> treat it like the name `foo` and do the analysis. `A.B.C.this.foo` is an
> expression with a qualified-this subexpression and now you need a bunch
> of analysis to figure out whether it means the same as the name `foo`.
>

Gotcha. And so my patch is therefore purporting to do "a bunch of
analysis"... which of course it may very well be doing incorrectly...

If so I'd be interested to know that. Do you mind taking a look at
TreeInfo.isThisReference() to see if it looks correct?

Of course because "this" is special we don't need to do a full blown
expression analysis... e.g., you can't ever say "myMethod().this" in Java.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221102/e12e758a/attachment-0001.htm>

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 vromero at openjdk.org  Thu Nov  3 02:47:00 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Nov 2022 02:47:00 GMT
Subject: RFR: 8294020: improve errors for record declarations
Message-ID: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>

Although the reporter originally complained about the error message for records with no header, I think the issue is deeper. We intentionally didn't follow the same path for parsing record declarations as we do for, for example, classes. This is mainly because `class` is a keyword but `record` is a contextual keyword. So when we find `record` we are not sure if it is an identifier or a record declaration. Although I think that given a context where the compiler expects a type declaration, we can be more aggressive than before and if we find `record` + `identifier` consider it a record declaration. The current implementation of `JavacParser::isRecordStart` is trying to be too clever but it is actually leaving several cases uncovered. So the proposed simpler version should be more stable and make record related errors more similar to those for other class declarations. Test `RecordDeclarationSyntaxTest.java` has been added just to have a golden file that stores the error position.

TIA

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

Commit messages:
 - 8294020: improve errors for record declarations

Changes: https://git.openjdk.org/jdk/pull/10963/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294020
  Stats: 45 lines in 6 files changed: 15 ins; 13 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10963.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10963/head:pull/10963

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

From jpai at openjdk.org  Thu Nov  3 06:21:25 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Nov 2022 06:21:25 GMT
Subject: RFR: 8294020: improve errors for record declarations
In-Reply-To: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
References: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
Message-ID: <A0_ftRICID4NpTlKdjWm5A63SCov5LismSnoKvwh1Eo=.76a98120-015d-46d3-af55-59865dcf5d30@github.com>

On Thu, 3 Nov 2022 02:39:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Although the reporter originally complained about the error message for records with no header, I think the issue is deeper. We intentionally didn't follow the same path for parsing record declarations as we do for, for example, classes. This is mainly because `class` is a keyword but `record` is a contextual keyword. So when we find `record` we are not sure if it is an identifier or a record declaration. Although I think that given a context where the compiler expects a type declaration, we can be more aggressive than before and if we find `record` + `identifier` consider it a record declaration. The current implementation of `JavacParser::isRecordStart` is trying to be too clever but it is actually leaving several cases uncovered. So the proposed simpler version should be more stable and make record related errors more similar to those for other class declarations. Test `RecordDeclarationSyntaxTest.java` has been added just to have a golden file that stores the error position.
> 
> TIA

Hello Vicente, I built this PR locally and compiled the same previous code that was reporting that odd error message:

public record Record {

}


With the change in this PR, the error message is much more understandable:


javac /tmp/Record.java

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

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

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 forax at openjdk.org  Thu Nov  3 07:52:52 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 3 Nov 2022 07:52:52 GMT
Subject: RFR: 8294020: improve errors for record declarations
In-Reply-To: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
References: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
Message-ID: <hq40-F56rPZU7P2dOKiT1u_FQ0xwiEI2oeHYtAZrCEQ=.503ad0be-2171-4fa3-a2bd-b8447c9f0c02@github.com>

On Thu, 3 Nov 2022 02:39:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Although the reporter originally complained about the error message for records with no header, I think the issue is deeper. We intentionally didn't follow the same path for parsing record declarations as we do for, for example, classes. This is mainly because `class` is a keyword but `record` is a contextual keyword. So when we find `record` we are not sure if it is an identifier or a record declaration. Although I think that given a context where the compiler expects a type declaration, we can be more aggressive than before and if we find `record` + `identifier` consider it a record declaration. The current implementation of `JavacParser::isRecordStart` is trying to be too clever but it is actually leaving several cases uncovered. So the proposed simpler version should be more stable and make record related errors more similar to those for other class declarations. Test `RecordDeclarationSyntaxTest.java` has been added just to have a golden file that stores the error position.
> 
> TIA

There is also the dual problem, students are writing *classes* with parenthesis after the name and the error message is not obvious too

FooNotARecord.java:1: error: '{' expected
public class FooNotARecord(String s) {
                          ^
1 error

I believe in both cases, the error message should mention that a record requires parenthesis (the word record should be in the error message).

By example here is the error message reported by IntelliJ when a class is declared with parenthesis
"record header declared for non record".

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

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

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 vromero at openjdk.org  Thu Nov  3 11:50:33 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Nov 2022 11:50:33 GMT
Subject: RFR: 8294020: improve errors for record declarations
In-Reply-To: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
References: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
Message-ID: <UBzyyx0mw8qvfrUvLSTyW-ouoTeVBwMZxLD12yNEaGI=.d1f77c9e-f3e8-4429-8965-64ba92cd14f8@github.com>

On Thu, 3 Nov 2022 02:39:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Although the reporter originally complained about the error message for records with no header, I think the issue is deeper. We intentionally didn't follow the same path for parsing record declarations as we do for, for example, classes. This is mainly because `class` is a keyword but `record` is a contextual keyword. So when we find `record` we are not sure if it is an identifier or a record declaration. Although I think that given a context where the compiler expects a type declaration, we can be more aggressive than before and if we find `record` + `identifier` consider it a record declaration. The current implementation of `JavacParser::isRecordStart` is trying to be too clever but it is actually leaving several cases uncovered. So the proposed simpler version should be more stable and make record related errors more similar to those for other class declarations. Test `RecordDeclarationSyntaxTest.java` has been added just to have a golden file that stores the error position.
> 
> TIA

> Hello Vicente, I built this PR locally and compiled the same previous code that was reporting that odd error message:
> 
> ```
> public record Record {
> 
> }
> ```
> 
> With the change in this PR, the error message is much more understandable:
> 
> ```
> javac /tmp/Record.java 
> /tmp/Record.java:1: error: '(' expected
> public record Record {
>                     ^
> /tmp/Record.java:1: error: illegal start of type
> public record Record {
>                      ^
> 2 errors
> ```
> 
> Thank you.

well this is a syntax error, detected by the parser, which doesn't have all the information to know what a user is trying to do so it just says: hey I was expecting something and I can't find it in the input you gave me. What this fix is doing is trying to make the treatment for records the same as that for classes. The compiler points to the right position and shows what it is expecting. If we go down the road to trying to propose what the right thing should be then we will have a lot more complains from users and it will be a never ending loop. Plus as I was saying parser is the one generating the error message, it shouldn't assume that the user is defining a record or not. I don't think that over complicating the parser is a good approach plus we will need to do the same for enums, other classes etc.

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

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

From jpai at openjdk.org  Thu Nov  3 11:50:36 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Nov 2022 11:50:36 GMT
Subject: RFR: 8294020: improve errors for record declarations
In-Reply-To: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
References: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
Message-ID: <jQF9dn3Ntp9CE9ep-ltF0TEkJNClybCbLE1paYHy13U=.2beb9d64-1cf4-4425-af6d-af4ee9b2fff3@github.com>

On Thu, 3 Nov 2022 02:39:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Although the reporter originally complained about the error message for records with no header, I think the issue is deeper. We intentionally didn't follow the same path for parsing record declarations as we do for, for example, classes. This is mainly because `class` is a keyword but `record` is a contextual keyword. So when we find `record` we are not sure if it is an identifier or a record declaration. Although I think that given a context where the compiler expects a type declaration, we can be more aggressive than before and if we find `record` + `identifier` consider it a record declaration. The current implementation of `JavacParser::isRecordStart` is trying to be too clever but it is actually leaving several cases uncovered. So the proposed simpler version should be more stable and make record related errors more similar to those for other class declarations. Test `RecordDeclarationSyntaxTest.java` has been added just to have a golden file that stores the error position.
> 
> TIA

I wasn't complaining :) I am just happily stating that your change in this PR makes the error message more understandable than what was before.

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

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

From vromero at openjdk.org  Thu Nov  3 12:12:01 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Nov 2022 12:12:01 GMT
Subject: Integrated: 8232933: Javac inferred type does not conform to equality
 constraint
In-Reply-To: <2euRx3nxZrGa-iDmuGUJCo9e6rOxFXYBhdhCI7PQjeo=.4fc91bac-8072-43c4-8bab-72ef38467df8@github.com>
References: <2euRx3nxZrGa-iDmuGUJCo9e6rOxFXYBhdhCI7PQjeo=.4fc91bac-8072-43c4-8bab-72ef38467df8@github.com>
Message-ID: <abobgLHGZkxrFFBH3KRM18xK5-wq3chbfn0ogPO2rsQ=.50b805db-16cd-400e-8bdc-c31890f16ac8@github.com>

On Fri, 28 Oct 2022 02:56:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> When dealing with nested invocations it could be that the inference context of a nested invocation is propagated to the inference context of the outer invocation. There are occasions when the propagated inference context can be minimized if some of its inference variables are deemed redundant. This is an optimization that is done in order to speed up the type inference algo which can take a while if the number of variables to be reduced is large. Of course by removing some variables from an inference context we have an inherent risk of cutting too much and not being able to produce the same results compared to not minimizing it. My understanding is that this bug shows one of those cases in which an inference context has been reduced too much.
> 
> The proposed solution is not to minimize an inference context if at least one of its inference variables is a capture type. The reason is because when capture types are present, some bounds are wildcards which could be captured again generating new capture types etc., this could make impossible to prove that some constraints hold for an inference context, thus making the compiler wrongly reject correct code.
> 
> TIA

This pull request has now been integrated.

Changeset: 7a85441a
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a85441a85b2472215ca7bc66e636dff06d9ebf3
Stats:     60 lines in 2 files changed: 60 ins; 0 del; 0 mod

8232933: Javac inferred type does not conform to equality constraint

Reviewed-by: mcimadamore

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

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

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 vromero at openjdk.org  Thu Nov  3 14:57:01 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Nov 2022 14:57:01 GMT
Subject: RFR: 8294020: improve errors for record declarations
In-Reply-To: <jQF9dn3Ntp9CE9ep-ltF0TEkJNClybCbLE1paYHy13U=.2beb9d64-1cf4-4425-af6d-af4ee9b2fff3@github.com>
References: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
 <jQF9dn3Ntp9CE9ep-ltF0TEkJNClybCbLE1paYHy13U=.2beb9d64-1cf4-4425-af6d-af4ee9b2fff3@github.com>
Message-ID: <v7qMl6csqhdYNqDDNcCfJf9b5Oyw2q7QRPmYItt0kFo=.83f2ff7a-3e62-44c4-b540-248b37da56a4@github.com>

On Thu, 3 Nov 2022 11:14:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I wasn't complaining :) I am just happily stating that your change in this PR makes the error message more understandable than what was before.

hehe, right I think I was pre-coffee sorry, thanks for your feedback

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

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

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 lancea at openjdk.org  Thu Nov  3 17:09:38 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 3 Nov 2022 17:09:38 GMT
Subject: Integrated: JDK-8288232: Address typos in jar man page
In-Reply-To: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com>
References: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com>
Message-ID: <NRWnuN3FuCTMm0t9jO9OIcrPY_BMqWz02ak-EEbElA0=.854da7e7-1213-456c-ac01-b39947c5b175@github.com>

On Wed, 2 Nov 2022 14:04:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi
> 
> Please review this update to the jar man page which removes the "=" for the non GNU style options
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: 68209adf
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68209adfa788b3cdf86c75f74857dd28c74c3cc2
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8288232: Address typos in jar man page

Reviewed-by: joehw, naoto, bpb

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

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

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 darcy at openjdk.org  Fri Nov  4 05:55:07 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Nov 2022 05:55:07 GMT
Subject: RFR: JDK-8296287: Improve documentation for Types.directSupertypes()
Message-ID: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>

Please review the PR and CSR (https://bugs.openjdk.org/browse/JDK-8296354) to add text to explicitly specify the behavior of Types.directSupertypes on java.lang.Object.

(This text could be added as informative text as it is implied by the existing specification, but I think it was reasonable to add the text as a normative statement instead.)

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

Commit messages:
 - JDK-8296287: Improve documentation for Types.directSupertypes()

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

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

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 jlahoda at openjdk.org  Fri Nov  4 09:08:31 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Nov 2022 09:08:31 GMT
Subject: RFR: JDK-8296287: Improve documentation for
 Types.directSupertypes()
In-Reply-To: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
References: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
Message-ID: <Qr99wdtx7pRa6SOMNJGgoP1X6W3tDqYxKdgo9VaFSnA=.e9e15836-48a6-406f-81b3-25e373295c42@github.com>

On Fri, 4 Nov 2022 05:46:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the PR and CSR (https://bugs.openjdk.org/browse/JDK-8296354) to add text to explicitly specify the behavior of Types.directSupertypes on java.lang.Object.
> 
> (This text could be added as informative text as it is implied by the existing specification, but I think it was reasonable to add the text as a normative statement instead.)

Looks good to me.

test/langtools/tools/javac/processing/model/util/types/TestDirectSupertypeObject.java line 48:

> 46:         if (!roundEnv.processingOver()) {
> 47:             TypeMirror objectType  = requireNonNull(eltUtils.getTypeElement("java.lang.Object")).asType();
> 48:             var ojectSupertypes = typeUtils.directSupertypes(objectType);

Nit: `objectSupertypes` -> `objectSupertypes`.

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

Marked as reviewed by jlahoda (Reviewer).

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

From prappo at openjdk.org  Fri Nov  4 10:15:39 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Nov 2022 10:15:39 GMT
Subject: RFR: JDK-8296287: Improve documentation for
 Types.directSupertypes()
In-Reply-To: <Qr99wdtx7pRa6SOMNJGgoP1X6W3tDqYxKdgo9VaFSnA=.e9e15836-48a6-406f-81b3-25e373295c42@github.com>
References: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
 <Qr99wdtx7pRa6SOMNJGgoP1X6W3tDqYxKdgo9VaFSnA=.e9e15836-48a6-406f-81b3-25e373295c42@github.com>
Message-ID: <_qXs7vywrjEPOb50pYQ2j5hAy--eihdefMMJZrK6lXs=.0732cd06-ae03-4df6-bf76-9b87d688d861@github.com>

On Fri, 4 Nov 2022 09:06:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Please review the PR and CSR (https://bugs.openjdk.org/browse/JDK-8296354) to add text to explicitly specify the behavior of Types.directSupertypes on java.lang.Object.
>> 
>> (This text could be added as informative text as it is implied by the existing specification, but I think it was reasonable to add the text as a normative statement instead.)
>
> test/langtools/tools/javac/processing/model/util/types/TestDirectSupertypeObject.java line 48:
> 
>> 46:         if (!roundEnv.processingOver()) {
>> 47:             TypeMirror objectType  = requireNonNull(eltUtils.getTypeElement("java.lang.Object")).asType();
>> 48:             var ojectSupertypes = typeUtils.directSupertypes(objectType);
> 
> Nit: `objectSupertypes` -> `objectSupertypes`.

_ojectSupertypes_

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

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

From prappo at openjdk.org  Fri Nov  4 11:21:04 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Nov 2022 11:21:04 GMT
Subject: RFR: JDK-8296287: Improve documentation for
 Types.directSupertypes()
In-Reply-To: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
References: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
Message-ID: <t2quKoZ46Mc3kIwKnpu7Vv_-3RHmN-6LyZgQ-fsZL6w=.ecac5f2c-d805-4afa-9df9-e571e0e20de8@github.com>

On Fri, 4 Nov 2022 05:46:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the PR and CSR (https://bugs.openjdk.org/browse/JDK-8296354) to add text to explicitly specify the behavior of Types.directSupertypes on java.lang.Object.
> 
> (This text could be added as informative text as it is implied by the existing specification, but I think it was reasonable to add the text as a normative statement instead.)

test/langtools/tools/javac/processing/model/util/types/TestDirectSupertypeObject.java line 27:

> 25:  * @test
> 26:  * @bug 8296287
> 27:  * @summary Test Types methods on module and package TypeMirrors

I don't think I understand the summary. Specifically, how are modules and packages pertinent to this test? (I'm not an expert in compiler area.)

test/langtools/tools/javac/processing/model/util/types/TestDirectSupertypeObject.java line 47:

> 45:                            RoundEnvironment roundEnv) {
> 46:         if (!roundEnv.processingOver()) {
> 47:             TypeMirror objectType  = requireNonNull(eltUtils.getTypeElement("java.lang.Object")).asType();

Redundant whitespace before =

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

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

From jlaskey at openjdk.org  Fri Nov  4 12:43:09 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 4 Nov 2022 12:43:09 GMT
Subject: RFR: JDK-8296322 javac: use methods to manage parser mode flags
Message-ID: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>

Manage parser mode flags using methods for easy of reading and maintenance.

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

Commit messages:
 - JDK-8296322 javac: use methods to manage parser mode flags

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

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

From jlahoda at openjdk.org  Fri Nov  4 14:13:12 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Nov 2022 14:13:12 GMT
Subject: RFR: 8296390: Incremental build failed with a NPE
Message-ID: <ELodOjBLAO1exPcb_tDxfi_3Mrgaoc_m_cLgBVIZULQ=.ff3b5258-e368-4d1f-98e2-7fbd5f2ce319@github.com>

In [Enter](https://github.com/openjdk/jdk/blob/22347e46f7e66a864ea987fa084c44792cae2e6a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java#L617), we finish verification that imports in files are valid. But, if the module graph is not finished yet (modules are not initialized), we defer checking imports in module-infos until the modules are setup.

What can happen is that `java.base`', if load lazily, may not be completed as part of module system initialization, and can trigger imports check in other module prematurely.

The proposal is to explicitly complete `java.base` while setting up the compile-time module system. Other (named) modules are normally completed around the same time while [building all modules](https://github.com/openjdk/jdk/blob/22347e46f7e66a864ea987fa084c44792cae2e6a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1414).

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

Commit messages:
 - 8296390: Incremental build failed with a NPE

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

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

From hannesw at openjdk.org  Fri Nov  4 15:00:42 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Nov 2022 15:00:42 GMT
Subject: Integrated: JDK-8200337: Generalize see and link tags for user-defined
 anchors
In-Reply-To: <ZKiIuLCvf1-4YoR6_qb2HEblSz9T45jDz_Jm_cyqPzE=.e5958099-340f-43c3-9666-b0aaea485d9f@github.com>
References: <ZKiIuLCvf1-4YoR6_qb2HEblSz9T45jDz_Jm_cyqPzE=.e5958099-340f-43c3-9666-b0aaea485d9f@github.com>
Message-ID: <T7Em_gUUV4qMGu3GfIWxv5V0m7ZscqClCH0xYQYmCtY=.925ab62b-0d27-4e48-96eb-7c197825995f@github.com>

On Thu, 22 Sep 2022 16:51:56 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation).
> 
> The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered.
> 
> The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable.
>  
> Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain.
> 
> One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label.

This pull request has now been integrated.

Changeset: 5622b095
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5622b0956581ed5057f708ee77cb648705ea7e94
Stats:     586 lines in 17 files changed: 521 ins; 15 del; 50 mod

8200337: Generalize see and link tags for user-defined anchors

Reviewed-by: jjg

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

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

From darcy at openjdk.org  Fri Nov  4 16:16:06 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Nov 2022 16:16:06 GMT
Subject: RFR: JDK-8296287: Improve documentation for
 Types.directSupertypes()
In-Reply-To: <t2quKoZ46Mc3kIwKnpu7Vv_-3RHmN-6LyZgQ-fsZL6w=.ecac5f2c-d805-4afa-9df9-e571e0e20de8@github.com>
References: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
 <t2quKoZ46Mc3kIwKnpu7Vv_-3RHmN-6LyZgQ-fsZL6w=.ecac5f2c-d805-4afa-9df9-e571e0e20de8@github.com>
Message-ID: <cqs2BxByKnY-WoqjImUqPrORPOwFfCmXVh4xSCBnGDc=.4494d52e-ade5-4680-81e5-bffc3a4a5840@github.com>

On Fri, 4 Nov 2022 11:17:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review the PR and CSR (https://bugs.openjdk.org/browse/JDK-8296354) to add text to explicitly specify the behavior of Types.directSupertypes on java.lang.Object.
>> 
>> (This text could be added as informative text as it is implied by the existing specification, but I think it was reasonable to add the text as a normative statement instead.)
>
> test/langtools/tools/javac/processing/model/util/types/TestDirectSupertypeObject.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8296287
>> 27:  * @summary Test Types methods on module and package TypeMirrors
> 
> I don't think I understand the summary. Specifically, how are modules and packages pertinent to this test? (I'm not an expert in compiler area.)

Ah, that was a left over from copying the other test in that directory; will correct to an accurate summary.

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

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

From darcy at openjdk.org  Fri Nov  4 16:16:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Nov 2022 16:16:10 GMT
Subject: RFR: JDK-8296287: Improve documentation for
 Types.directSupertypes()
In-Reply-To: <_qXs7vywrjEPOb50pYQ2j5hAy--eihdefMMJZrK6lXs=.0732cd06-ae03-4df6-bf76-9b87d688d861@github.com>
References: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
 <Qr99wdtx7pRa6SOMNJGgoP1X6W3tDqYxKdgo9VaFSnA=.e9e15836-48a6-406f-81b3-25e373295c42@github.com>
 <_qXs7vywrjEPOb50pYQ2j5hAy--eihdefMMJZrK6lXs=.0732cd06-ae03-4df6-bf76-9b87d688d861@github.com>
Message-ID: <BoZdL72SatCr4tv9uRrziXlwV3Myf9PLA9NiKaCi9SM=.7957310b-38c6-474f-9bb8-24178ef1ef62@github.com>

On Fri, 4 Nov 2022 10:13:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/tools/javac/processing/model/util/types/TestDirectSupertypeObject.java line 48:
>> 
>>> 46:         if (!roundEnv.processingOver()) {
>>> 47:             TypeMirror objectType  = requireNonNull(eltUtils.getTypeElement("java.lang.Object")).asType();
>>> 48:             var ojectSupertypes = typeUtils.directSupertypes(objectType);
>> 
>> Nit: `objectSupertypes` -> `objectSupertypes`.
>
> _ojectSupertypes_

Thanks; will fix before pushing.

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

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

From darcy at openjdk.org  Fri Nov  4 16:22:54 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Nov 2022 16:22:54 GMT
Subject: RFR: JDK-8296287: Improve documentation for
 Types.directSupertypes() [v2]
In-Reply-To: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
References: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
Message-ID: <sWaNm1hppjojdNdB5ucKzgnRH178HEZ6N2znlifdw7k=.64a435b6-c2b4-43f8-a62c-9ff8abaa9a9b@github.com>

> Please review the PR and CSR (https://bugs.openjdk.org/browse/JDK-8296354) to add text to explicitly specify the behavior of Types.directSupertypes on java.lang.Object.
> 
> (This text could be added as informative text as it is implied by the existing specification, but I think it was reasonable to add the text as a normative statement instead.)

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10977/files
  - new: https://git.openjdk.org/jdk/pull/10977/files/e216112e..26ac86b8

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

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

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

From prappo at openjdk.org  Fri Nov  4 16:22:54 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Nov 2022 16:22:54 GMT
Subject: RFR: JDK-8296287: Improve documentation for
 Types.directSupertypes() [v2]
In-Reply-To: <sWaNm1hppjojdNdB5ucKzgnRH178HEZ6N2znlifdw7k=.64a435b6-c2b4-43f8-a62c-9ff8abaa9a9b@github.com>
References: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
 <sWaNm1hppjojdNdB5ucKzgnRH178HEZ6N2znlifdw7k=.64a435b6-c2b4-43f8-a62c-9ff8abaa9a9b@github.com>
Message-ID: <7x_SK5ZtNYnu0Spz3lQVACC6Eum-gl-IixXTQZmheEE=.c56fd6ec-7c38-4c85-98e2-d8d0797d604f@github.com>

On Fri, 4 Nov 2022 16:19:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review the PR and CSR (https://bugs.openjdk.org/browse/JDK-8296354) to add text to explicitly specify the behavior of Types.directSupertypes on java.lang.Object.
>> 
>> (This text could be added as informative text as it is implied by the existing specification, but I think it was reasonable to add the text as a normative statement instead.)
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Looks good.

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

Marked as reviewed by prappo (Reviewer).

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

From darcy at openjdk.org  Fri Nov  4 16:27:37 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Nov 2022 16:27:37 GMT
Subject: Integrated: JDK-8296287: Improve documentation for
 Types.directSupertypes()
In-Reply-To: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
References: <TyoaswR8Ycnm8pCH5osiOFS9E2wXSNOGHi_zBhG1MJc=.61a4f0ad-049c-4045-a80b-5024592f21a2@github.com>
Message-ID: <w7biRi8TQTTxlywhjwFsw61cCLjVx0ESwHmFD4fQzUM=.8d757755-fb52-4190-afdd-0dfdb36222c3@github.com>

On Fri, 4 Nov 2022 05:46:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the PR and CSR (https://bugs.openjdk.org/browse/JDK-8296354) to add text to explicitly specify the behavior of Types.directSupertypes on java.lang.Object.
> 
> (This text could be added as informative text as it is implied by the existing specification, but I think it was reasonable to add the text as a normative statement instead.)

This pull request has now been integrated.

Changeset: 97c5a64d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97c5a64d5cef6da43691a8396d4013145aa04f66
Stats:     59 lines in 2 files changed: 59 ins; 0 del; 0 mod

8296287: Improve documentation for Types.directSupertypes()

Reviewed-by: jlahoda, prappo

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

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

From duke at openjdk.org  Fri Nov  4 16:38:33 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 4 Nov 2022 16:38:33 GMT
Subject: RFR: 8163229: test test/tools/javac/CaptureInSubtype.java has a main
 method that is never executed Export
Message-ID: <43_ndNUnEtQisakxCPVIqZGvizAmLUd2cKQ60X_3HRs=.05235cae-336f-4cb4-9e2a-88c4ba5753b8@github.com>

This PR deals with some housekeeping relating to compiler unit tests.

JDK-8163229 points out that there are several tests that have a `public static void main(String[])` method, but because the test expects to fail during compilation, the test is never actually run, and so these `main` methods are just clutter that can be removed.

However, there are also some tests where the test is never run, but the `main()` method generates one or more of the expected compilation errors. Obviously we need to keep those, but they don't need to be declared as `public static void main(String[])` which is misleading. So instead we rename these methods to `meth()`, and also we remove the `String[]` parameter when it's not needed by the test.

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

Commit messages:
 - Rename or remove "main()" methods in tests that never actually run.

Changes: https://git.openjdk.org/jdk/pull/10992/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10992&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8163229
  Stats: 187 lines in 127 files changed: 0 ins; 68 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/10992.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10992/head:pull/10992

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

From jjg at openjdk.org  Fri Nov  4 21:56:17 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 4 Nov 2022 21:56:17 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
Message-ID: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>

Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.

For bonus, I've added a target for the German version of the output.

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

Commit messages:
 - JDK-8296137: diags-examples.xml is broken

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

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

From iris at openjdk.org  Fri Nov  4 22:21:29 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 4 Nov 2022 22:21:29 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
Message-ID: <cV4D9NvxIkHuwzPIUjxQodjxt4B1HFtV8AuUBysqk5M=.5795376e-e949-4a95-9a50-84ae3975a0fe@github.com>

On Fri, 4 Nov 2022 21:50:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.
> 
> For bonus, I've added a target for the German version of the output.

Marked as reviewed by iris (Reviewer).

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

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

From vromero at openjdk.org  Fri Nov  4 22:30:30 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Nov 2022 22:30:30 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
Message-ID: <_xycNWnz6SYSwF3z46hlstyVJjV7jlytrBD_JajDtAQ=.60315a94-7c73-42f8-9a89-be6e3b653e76@github.com>

On Fri, 4 Nov 2022 21:50:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.
> 
> For bonus, I've added a target for the German version of the output.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

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 vromero at openjdk.org  Sun Nov  6 18:05:34 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 6 Nov 2022 18:05:34 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v4]
In-Reply-To: <x_D9WO40s5Qp-u61pajcLO5hsm8gcRtDuCf00Qni7vg=.8dbcd29b-0579-4aad-bd50-0e07f4bde04b@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <x_D9WO40s5Qp-u61pajcLO5hsm8gcRtDuCf00Qni7vg=.8dbcd29b-0579-4aad-bd50-0e07f4bde04b@github.com>
Message-ID: <bF4xBF2SkVG6rELlYAzx1bxT20Dgl2Z9CG2a1toU0fU=.60e2ac1a-bdbd-45cc-bc48-643e7ce05d61@github.com>

On Mon, 31 Oct 2022 14:55:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
>> 
>> 
>> record Complex(double real, double img) {}
>> 
>> List<Complex> list = ...;
>> 
>> for (Complex(var real, var img) : list) {
>>     // can use ?real? and ?img? directly
>> }
>> 
>> 
>> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
>> 
>> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
>> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
>> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
>> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
>> - The enhanced for, supports record patterns for both arrays and reference types.
>> 
>> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
>> 
>> For more information on the changes please see:
>> 
>> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
>> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
>> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
>> 
>> Looking forward for your review.
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Adjustments to make for-patterns and JDK-8294942 work together.
>  - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns
>  - Fixing test.
>  - Cleanup.
>  - Some more cleanup.
>  - Various cleanup and adjustments to specification updates.
>  - 8294942: Compiler implementation for Record Patterns (Second Preview)
>  - Address Review
>  - Fix applicability bug
>  - Store element type calculation result in JCEnhancedForLoop
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d8e3092a...892fddf3

src/jdk.compiler/share/classes/com/sun/source/tree/EnhancedForLoopTree.java line 65:

> 63:     /**
> 64:      * Returns the control variable for the loop.
> 65:      * @return the control variable, or {@code null} if this enhanced for uses a pattern

other references to enhanced for have been coded as: "enhanced" {@code for} in the javadoc

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

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

From vromero at openjdk.org  Sun Nov  6 21:40:21 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 6 Nov 2022 21:40:21 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v5]
In-Reply-To: <XYzqFg0AYoly-FZ-MpuHPkpFRe3eyWxKZ91zHDyp_mg=.f7177bcd-5108-4fb7-9698-a0bbe0aa7402@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <XYzqFg0AYoly-FZ-MpuHPkpFRe3eyWxKZ91zHDyp_mg=.f7177bcd-5108-4fb7-9698-a0bbe0aa7402@github.com>
Message-ID: <NHiMyU1uxlXFVRM4uyuSako68XMQQzkVFh97Wh9ya4Q=.00a3f461-efe7-42d2-9ceb-6e0b09a2321b@github.com>

On Tue, 1 Nov 2022 08:18:22 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
>> 
>> 
>> record Complex(double real, double img) {}
>> 
>> List<Complex> list = ...;
>> 
>> for (Complex(var real, var img) : list) {
>>     // can use ?real? and ?img? directly
>> }
>> 
>> 
>> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
>> 
>> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
>> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
>> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
>> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
>> - The enhanced for, supports record patterns for both arrays and reference types.
>> 
>> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
>> 
>> For more information on the changes please see:
>> 
>> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
>> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
>> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
>> 
>> Looking forward for your review.
>
> Aggelos Biboudis 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 ten additional commits since the last revision:
> 
>  - Simplify getDeclarationKind
>  - Adjustments to make for-patterns and JDK-8294942 work together.
>  - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns
>  - Address Review
>  - Fix applicability bug
>  - Store element type calculation result in JCEnhancedForLoop
>  - API cleanup.
>  - Adding @since, adding PreviewFeature, restoring API method.
>  - 8294943: Implement record patterns in enhanced for

src/jdk.compiler/share/classes/com/sun/source/tree/EnhancedForLoopTree.java line 94:

> 92:      * @since 20
> 93:      */
> 94:     @PreviewFeature(feature=PreviewFeature.Feature.RECORD_PATTERNS, reflective=true)

same issue mentioned above with the javadoc comment

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1560:

> 1558:                 attribStat(tree.body, loopEnv);
> 1559:             }
> 1560:             else if (tree.varOrRecordPattern instanceof JCRecordPattern jcRecordPattern) {

nit: suggestion, consider moving this line up kind of:

        } else if (...

also I wonder about the need for the `if` here as I think that the there is only one option here right?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 1216:

> 1214:         public JCExpression expr;
> 1215:         public JCStatement body;
> 1216:         public Type elementType;

is this new field strictly necessary? usually we try not to add new fields to ASTs unless we don't have any other option as they will imply more memory consumption.

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

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

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 jlahoda at openjdk.org  Mon Nov  7 08:49:35 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Nov 2022 08:49:35 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v2]
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <X25KIAASVSchrhf4tkpv4AT4kWqt1UGBCRWMbLEoIls=.deb5603e-e243-4dc5-a27d-54780a342558@github.com>

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Better tests for inference with recursive bounds, and related fixes.
 - Adding a kind to InstanceOfTree, as suggested.
 - Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10814/files
  - new: https://git.openjdk.org/jdk/pull/10814/files/6f1c30d8..77c34fcf

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

  Stats: 165 lines in 4 files changed: 66 ins; 14 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/10814.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10814/head:pull/10814

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

From mcimadamore at openjdk.org  Mon Nov  7 09:08:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 09:08:22 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v2]
In-Reply-To: <X25KIAASVSchrhf4tkpv4AT4kWqt1UGBCRWMbLEoIls=.deb5603e-e243-4dc5-a27d-54780a342558@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <X25KIAASVSchrhf4tkpv4AT4kWqt1UGBCRWMbLEoIls=.deb5603e-e243-4dc5-a27d-54780a342558@github.com>
Message-ID: <sljvfvyQWFvehgm5WIVRTt-FLLTC9vrridxmaK_fNks=.7faa4122-15f3-4904-ba28-7bac6eb12028@github.com>

On Mon, 7 Nov 2022 08:49:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
>> 
>>  - removal of named record patterns
>>  - (preview) type inference for type test and record patterns
>>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>>  - fixing exhaustiveness of certain switches
>> 
>> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
>> 
>> For more information on the changes please see:
>>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
>> 
>> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
>> 
>> Any feedback is welcome.
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Better tests for inference with recursive bounds, and related fixes.
>  - Adding a kind to InstanceOfTree, as suggested.
>  - Reflecting review feedback.

Looks good - left some minor comments

src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java line 97:

> 95: 
> 96:     /**
> 97:      * Returns the type of this instanceof expression.

Suggestion:

     * Returns the kind of this instanceof expression.

src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java line 99:

> 97:      * Returns the type of this instanceof expression.
> 98:      *
> 99:      * @return the type of this instanceof expression

Suggestion:

     * @return the kind of this instanceof expression

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 717:

> 715:             } else {
> 716:                 List<Type> upperBounds = undet.getBounds(InferenceBound.UPPER);
> 717:                 Type bound;

Maybe we should call this `upper`, for uniformity

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

Marked as reviewed by mcimadamore (Reviewer).

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

From abimpoudis at openjdk.org  Mon Nov  7 09:42:37 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 7 Nov 2022 09:42:37 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v5]
In-Reply-To: <NHiMyU1uxlXFVRM4uyuSako68XMQQzkVFh97Wh9ya4Q=.00a3f461-efe7-42d2-9ceb-6e0b09a2321b@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <XYzqFg0AYoly-FZ-MpuHPkpFRe3eyWxKZ91zHDyp_mg=.f7177bcd-5108-4fb7-9698-a0bbe0aa7402@github.com>
 <NHiMyU1uxlXFVRM4uyuSako68XMQQzkVFh97Wh9ya4Q=.00a3f461-efe7-42d2-9ceb-6e0b09a2321b@github.com>
Message-ID: <4fm3jAccvG8MPKVQFzefRUWttHQV2jcft9vkWNsZ05o=.b95defb4-3f30-4360-9718-ef7f1969fecb@github.com>

On Sun, 6 Nov 2022 19:26:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis 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 ten additional commits since the last revision:
>> 
>>  - Simplify getDeclarationKind
>>  - Adjustments to make for-patterns and JDK-8294942 work together.
>>  - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns
>>  - Address Review
>>  - Fix applicability bug
>>  - Store element type calculation result in JCEnhancedForLoop
>>  - API cleanup.
>>  - Adding @since, adding PreviewFeature, restoring API method.
>>  - 8294943: Implement record patterns in enhanced for
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 1216:
> 
>> 1214:         public JCExpression expr;
>> 1215:         public JCStatement body;
>> 1216:         public Type elementType;
> 
> is this new field strictly necessary? usually we try not to add new fields to ASTs unless we don't have any other option as they will imply more memory consumption.

We would need to discover again the type of the element in `AliveAnalyzer` when we need to do the exhaustivity check. This avoids an extra refactoring to extract code that discovers this type from attribution. If there is another way to persist the type between phases, I am open to remove it.

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

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

From jlahoda at openjdk.org  Mon Nov  7 09:52:29 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Nov 2022 09:52:29 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v5]
In-Reply-To: <4fm3jAccvG8MPKVQFzefRUWttHQV2jcft9vkWNsZ05o=.b95defb4-3f30-4360-9718-ef7f1969fecb@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <XYzqFg0AYoly-FZ-MpuHPkpFRe3eyWxKZ91zHDyp_mg=.f7177bcd-5108-4fb7-9698-a0bbe0aa7402@github.com>
 <NHiMyU1uxlXFVRM4uyuSako68XMQQzkVFh97Wh9ya4Q=.00a3f461-efe7-42d2-9ceb-6e0b09a2321b@github.com>
 <4fm3jAccvG8MPKVQFzefRUWttHQV2jcft9vkWNsZ05o=.b95defb4-3f30-4360-9718-ef7f1969fecb@github.com>
Message-ID: <XOxA9h0MZ3LJ4J3QbI5LHwvl_ZDfBfjL5huqeQyFqf0=.efbdf06a-e969-44f8-af63-034324fc2645@github.com>

On Mon, 7 Nov 2022 09:38:50 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 1216:
>> 
>>> 1214:         public JCExpression expr;
>>> 1215:         public JCStatement body;
>>> 1216:         public Type elementType;
>> 
>> is this new field strictly necessary? usually we try not to add new fields to ASTs unless we don't have any other option as they will imply more memory consumption.
>
> We would need to discover again the type of the element in `AliveAnalyzer` when we need to do the exhaustivity check. This avoids an extra refactoring to extract code that discovers this type from attribution. If there is another way to persist the type between phases, I am open to remove it.

Adding a field here seemed like a reasonable compromise to me. It will make `JCEnhancedForLoop` bigger, but presumably, there won't be that many instances of this class. I'd be more concerned if we were adding a new field to all `JCTree`s, `Symbol`s or `Type`s.

Alternatives would include re-computing the element type in `Flow`, which also feels a bit wasteful, or doing exhaustiveness checks in `Attr`, which is tricky, because exhaustiveness is mostly handled in `Flow`.

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

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

From abimpoudis at openjdk.org  Mon Nov  7 09:56:45 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 7 Nov 2022 09:56:45 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v6]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <ildOTAhtkxaaFuunFgvvoiL9-t6R36AvvGqWKJxXL6c=.6a6a37a6-7f55-45aa-8392-1b3a2b8dc154@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

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/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/3e07a53d..a65bf7a2

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

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

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

From jlahoda at openjdk.org  Mon Nov  7 10:48:50 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Nov 2022 10:48:50 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v3]
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <Iq0UMDQEFTP7MORp8-64IlD7nMIVzwUrge11giig_wQ=.df8dea88-b345-41bc-b7c9-1bb08dbf1962@github.com>

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Reflecting review comment.
 - Apply suggestions from code review
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10814/files
  - new: https://git.openjdk.org/jdk/pull/10814/files/77c34fcf..c8f29c4e

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

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

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

From mcimadamore at openjdk.org  Mon Nov  7 12:21:04 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 12:21:04 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v6]
In-Reply-To: <ildOTAhtkxaaFuunFgvvoiL9-t6R36AvvGqWKJxXL6c=.6a6a37a6-7f55-45aa-8392-1b3a2b8dc154@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <ildOTAhtkxaaFuunFgvvoiL9-t6R36AvvGqWKJxXL6c=.6a6a37a6-7f55-45aa-8392-1b3a2b8dc154@github.com>
Message-ID: <GPCkQX7eSspEeTW9QCdxfDVdrETxmlomgDn6bh4RC6o=.4fdd1005-8923-4317-9fa6-1741c8f32147@github.com>

On Mon, 7 Nov 2022 09:56:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
>> 
>> 
>> record Complex(double real, double img) {}
>> 
>> List<Complex> list = ...;
>> 
>> for (Complex(var real, var img) : list) {
>>     // can use ?real? and ?img? directly
>> }
>> 
>> 
>> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
>> 
>> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
>> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
>> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
>> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
>> - The enhanced for, supports record patterns for both arrays and reference types.
>> 
>> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
>> 
>> For more information on the changes please see:
>> 
>> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
>> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
>> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
>> 
>> Looking forward for your review.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

Looks good - only doubt is on translation strategy - but that could also be improved upon with separate PR.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 736:

> 734:                  * <pre>{@code
> 735:                  *     for (<type-of-coll-item> N$temp : coll) {
> 736:                  *     switch (N$temp) {

This is obviously a correct translation (I like that it delegates to what we already know how to do). I wonder if it would be better to use a pattern with `if/instanceof` (as the switch machinery is a tad expensive, and has an invokedynamic, which in this case could be avoided, I think?).

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.org  Mon Nov  7 12:21:06 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 12:21:06 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v5]
In-Reply-To: <XOxA9h0MZ3LJ4J3QbI5LHwvl_ZDfBfjL5huqeQyFqf0=.efbdf06a-e969-44f8-af63-034324fc2645@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <XYzqFg0AYoly-FZ-MpuHPkpFRe3eyWxKZ91zHDyp_mg=.f7177bcd-5108-4fb7-9698-a0bbe0aa7402@github.com>
 <NHiMyU1uxlXFVRM4uyuSako68XMQQzkVFh97Wh9ya4Q=.00a3f461-efe7-42d2-9ceb-6e0b09a2321b@github.com>
 <4fm3jAccvG8MPKVQFzefRUWttHQV2jcft9vkWNsZ05o=.b95defb4-3f30-4360-9718-ef7f1969fecb@github.com>
 <XOxA9h0MZ3LJ4J3QbI5LHwvl_ZDfBfjL5huqeQyFqf0=.efbdf06a-e969-44f8-af63-034324fc2645@github.com>
Message-ID: <KSWbRXIjN2CT9yB8D0lZB6GnD39R-b12eI42Yc0jlv8=.58714648-4101-489e-9026-d4dae642af59@github.com>

On Mon, 7 Nov 2022 09:49:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> We would need to discover again the type of the element in `AliveAnalyzer` when we need to do the exhaustivity check. This avoids an extra refactoring to extract code that discovers this type from attribution. If there is another way to persist the type between phases, I am open to remove it.
>
> Adding a field here seemed like a reasonable compromise to me. It will make `JCEnhancedForLoop` bigger, but presumably, there won't be that many instances of this class. I'd be more concerned if we were adding a new field to all `JCTree`s, `Symbol`s or `Type`s.
> 
> Alternatives would include re-computing the element type in `Flow`, which also feels a bit wasteful, or doing exhaustiveness checks in `Attr`, which is tricky, because exhaustiveness is mostly handled in `Flow`.

We also capture fields like these in other cases; e.g. varargs method calls have their `elementType` set, and functional expressions (like lambdas) have their target type set in the same way. So I think this is good.

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

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

From ihse at openjdk.org  Mon Nov  7 12:25:18 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 12:25:18 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
Message-ID: <9kacXthJ9DQm7GiGAgh3wvGLQTlGa6K82CYH2dGxfQw=.a5e0de72-dafb-4f18-a891-e439db88b41b@github.com>

On Fri, 4 Nov 2022 21:50:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.
> 
> For bonus, I've added a target for the German version of the output.

Looks good. Thanks for fixing, and sorry for breaking. :-( At some point, we should go through the files in `make/langtools` and check if they all are still needed, and so that we document how to test them, in case of future refactorings.

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

Marked as reviewed by ihse (Reviewer).

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

From jlahoda at openjdk.org  Mon Nov  7 12:43:40 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Nov 2022 12:43:40 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v6]
In-Reply-To: <GPCkQX7eSspEeTW9QCdxfDVdrETxmlomgDn6bh4RC6o=.4fdd1005-8923-4317-9fa6-1741c8f32147@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <ildOTAhtkxaaFuunFgvvoiL9-t6R36AvvGqWKJxXL6c=.6a6a37a6-7f55-45aa-8392-1b3a2b8dc154@github.com>
 <GPCkQX7eSspEeTW9QCdxfDVdrETxmlomgDn6bh4RC6o=.4fdd1005-8923-4317-9fa6-1741c8f32147@github.com>
Message-ID: <6ECtigOrmKpg1jJfrq3wl-u3T_kgCxwN3HLumkK_Lhc=.e2527701-e1c8-4719-b73e-107d1b041ede@github.com>

On Mon, 24 Oct 2022 19:03:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 736:
> 
>> 734:                  * <pre>{@code
>> 735:                  *     for (<type-of-coll-item> N$temp : coll) {
>> 736:                  *     switch (N$temp) {
> 
> This is obviously a correct translation (I like that it delegates to what we already know how to do). I wonder if it would be better to use a pattern with `if/instanceof` (as the switch machinery is a tad expensive, and has an invokedynamic, which in this case could be avoided, I think?).

I was thinking of that, but (to me) it seemed better to handle that on the switch level, to avoid the indy for all switches with a single/few arms.

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

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

From jlahoda at openjdk.org  Mon Nov  7 15:07:22 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Nov 2022 15:07:22 GMT
Subject: RFR: 8294020: improve errors for record declarations
In-Reply-To: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
References: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
Message-ID: <634APxI4Eibhi0lzgRUu2DzylAHyBKXllM_tEu8ZmGk=.759a2702-3824-44ae-8b69-be4d451bc522@github.com>

On Thu, 3 Nov 2022 02:39:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Although the reporter originally referred to the error message for records with no header, I think the issue is deeper. We intentionally didn't follow the same path for parsing record declarations as we do for, for example, classes. This is mainly because `class` is a keyword but `record` is a contextual keyword. So when we find `record` we are not sure if it is an identifier or a record declaration. Although I think that given a context where the compiler expects a type declaration, we can be more aggressive than before and if we find `record` + `identifier` consider it a record declaration. The current implementation of `JavacParser::isRecordStart` is trying to be too clever but it is actually leaving several cases uncovered. So the proposed simpler version should be more stable and make record related errors more similar to those for other class declarations. Test `RecordDeclarationSyntaxTest.java` has been added just to have a golden file that stores the error position.
> 
> TIA

Looks OK.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jjg at openjdk.org  Mon Nov  7 15:59:36 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 7 Nov 2022 15:59:36 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <9kacXthJ9DQm7GiGAgh3wvGLQTlGa6K82CYH2dGxfQw=.a5e0de72-dafb-4f18-a891-e439db88b41b@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
 <9kacXthJ9DQm7GiGAgh3wvGLQTlGa6K82CYH2dGxfQw=.a5e0de72-dafb-4f18-a891-e439db88b41b@github.com>
Message-ID: <kOoey77Nqyn6-T6Imf_6UsgrOCFcWvm69alGsY1EvpM=.b1106100-4143-47f8-9d2a-227c2b7d0073@github.com>

On Mon, 7 Nov 2022 12:23:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Looks good. Thanks for fixing, and sorry for breaking. :-( At some point, we should go through the files in `make/langtools` and check if they all are still needed, and so that we document how to test them, in case of future refactorings.

Yeah, ideally we should execute code like this more of the time, perhaps figuring out how to run it in some sort of test.

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

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

From jjg at openjdk.org  Mon Nov  7 16:01:41 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 7 Nov 2022 16:01:41 GMT
Subject: Integrated: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
Message-ID: <SFcQbOVrWsCVkbcTwg8smLy9vSNZyUAHzeY2MFm1Enc=.e4546db7-e929-46a0-96c3-ca9ecdcfc3bd@github.com>

On Fri, 4 Nov 2022 21:50:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.
> 
> For bonus, I've added a target for the German version of the output.

This pull request has now been integrated.

Changeset: f8b2574e
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8b2574ebc32fa0e62dbaa0f2447757ff83c320f
Stats:     12 lines in 2 files changed: 6 ins; 0 del; 6 mod

8296137: diags-examples.xml is broken

Reviewed-by: iris, vromero, ihse

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

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

From duke at openjdk.org  Mon Nov  7 16:22:18 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 7 Nov 2022 16:22:18 GMT
Subject: RFR: 8043251: Bogus javac error: required: no arguments,
 found: no arguments
Message-ID: <ttyl1QzWEJGynqGR_A3okSQE1raIc9Z_k964MzAx1Fw=.30f27c1a-ed84-4876-88b2-9bc58f2ad3f4@github.com>

We have an error message `compiler.err.cant.apply.symbol` for cases where a method invocation doesn't resolve. It shows the "required" parameters and the "found" parameters, plus a further description of the problem.

This message being used inappropriately when the problem is actually due to explicitly passed method type parameters instead of regular method parameters.

For example, if you do this:

Function<String, String> f = Function.<String, String>identity();

the error reported is this:

error: method identity in interface Function<T,R> cannot be applied to given types;
    Function<String, String> f = Function.<String, String>identity();
                                         ^
  required: no arguments
  found:    no arguments
  reason: wrong number of type arguments; required 1
  where T,R are type-variables:
    T extends Object declared in interface Function
    R extends Object declared in interface Function

The real error here is `wrong number of type arguments; required 1`, but the `compiler.err.cant.apply.symbol` error message that assumes the problem is with the regular parameters, which it displays. The result is the appearance of the useless and confusing `required` and `found` lines.

This patch creates an alternate version of that error message (`compiler.err.cant.apply.symbol.noargs`) that omits the `required` and `found` lines, and makes the compiler use this alternate message when the error is due to type parameters (specifically, when the underlying error is "wrong number of type arguments" or "explicit type argument X does not conform to declared bound(s)").

This improves the error for example above to this:

error: method identity in interface Function<T,R> cannot be applied to given types;
    Function<String, String> f = Function.<String, String>identity();
                                         ^
  reason: wrong number of type arguments; required 1
  where T,R are type-variables:
    T extends Object declared in interface Function
    R extends Object declared in interface Function
1 error

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

Commit messages:
 - Fix confusing error message regarding wrong number of type parameters.

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

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

From mcimadamore at openjdk.org  Mon Nov  7 16:28:33 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 16:28:33 GMT
Subject: RFR: JDK-8296322 javac: use methods to manage parser mode flags
In-Reply-To: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>
References: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>
Message-ID: <YecF8QQTlk3h1JiBgxYtswKw-M3ZZx66jJNHnlCI818=.0cd6e58b-bb2f-401b-b513-6df1303a8c6a@github.com>

On Fri, 4 Nov 2022 12:33:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Manage parser mode flags using methods for easy of reading and maintenance.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From vromero at openjdk.org  Mon Nov  7 18:09:37 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Nov 2022 18:09:37 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v5]
In-Reply-To: <KSWbRXIjN2CT9yB8D0lZB6GnD39R-b12eI42Yc0jlv8=.58714648-4101-489e-9026-d4dae642af59@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <XYzqFg0AYoly-FZ-MpuHPkpFRe3eyWxKZ91zHDyp_mg=.f7177bcd-5108-4fb7-9698-a0bbe0aa7402@github.com>
 <NHiMyU1uxlXFVRM4uyuSako68XMQQzkVFh97Wh9ya4Q=.00a3f461-efe7-42d2-9ceb-6e0b09a2321b@github.com>
 <4fm3jAccvG8MPKVQFzefRUWttHQV2jcft9vkWNsZ05o=.b95defb4-3f30-4360-9718-ef7f1969fecb@github.com>
 <XOxA9h0MZ3LJ4J3QbI5LHwvl_ZDfBfjL5huqeQyFqf0=.efbdf06a-e969-44f8-af63-034324fc2645@github.com>
 <KSWbRXIjN2CT9yB8D0lZB6GnD39R-b12eI42Yc0jlv8=.58714648-4101-489e-9026-d4dae642af59@github.com>
Message-ID: <L9PAsGFEpK9ak_Bcr5yxvh_1cQAK3YLslSuKiSaZufA=.d817fb60-556f-4528-a406-bbb36ac4f9b7@github.com>

On Mon, 7 Nov 2022 12:17:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adding a field here seemed like a reasonable compromise to me. It will make `JCEnhancedForLoop` bigger, but presumably, there won't be that many instances of this class. I'd be more concerned if we were adding a new field to all `JCTree`s, `Symbol`s or `Type`s.
>> 
>> Alternatives would include re-computing the element type in `Flow`, which also feels a bit wasteful, or doing exhaustiveness checks in `Attr`, which is tricky, because exhaustiveness is mostly handled in `Flow`.
>
> We also capture fields like these in other cases; e.g. varargs method calls have their `elementType` set, and functional expressions (like lambdas) have their target type set in the same way. So I think this is good.

ok sounds good to me

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

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

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 vromero at openjdk.org  Mon Nov  7 20:16:31 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Nov 2022 20:16:31 GMT
Subject: RFR: 8294020: improve errors for record declarations
In-Reply-To: <634APxI4Eibhi0lzgRUu2DzylAHyBKXllM_tEu8ZmGk=.759a2702-3824-44ae-8b69-be4d451bc522@github.com>
References: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
 <634APxI4Eibhi0lzgRUu2DzylAHyBKXllM_tEu8ZmGk=.759a2702-3824-44ae-8b69-be4d451bc522@github.com>
Message-ID: <lIF_UIZuZ6s5H4k6_JS0AScE7TX_nP7ohCPZi3qDHmg=.a2800fc9-e252-4d55-9dc5-941ef9399a1f@github.com>

On Mon, 7 Nov 2022 15:05:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Although the reporter originally referred to the error message for records with no header, I think the issue is deeper. We intentionally didn't follow the same path for parsing record declarations as we do for, for example, classes. This is mainly because `class` is a keyword but `record` is a contextual keyword. So when we find `record` we are not sure if it is an identifier or a record declaration. Although I think that given a context where the compiler expects a type declaration, we can be more aggressive than before and if we find `record` + `identifier` consider it a record declaration. The current implementation of `JavacParser::isRecordStart` is trying to be too clever but it is actually leaving several cases uncovered. So the proposed simpler version should be more stable and make record related errors more similar to those for other class declarations. Test `RecordDeclarationSyntaxTest.java` has been added just to have a golden file that stores the error position.
>> 
>> TIA
>
> Looks OK.

@lahodaj thanks for the review

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

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

From vromero at openjdk.org  Mon Nov  7 20:18:39 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Nov 2022 20:18:39 GMT
Subject: Integrated: 8294020: improve errors for record declarations
In-Reply-To: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
References: <ebTillSiRUNt4H-KQKVbxzLSLS9QINKaIhX89iEmZa4=.b038971a-c590-457a-9e73-6b71b62d613b@github.com>
Message-ID: <0_05VQ0k56XmVB6MURuu95Dq1FooFUiTOL1j3TiGdK4=.8ae1a09b-effe-49d1-99cc-e375332ef37c@github.com>

On Thu, 3 Nov 2022 02:39:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Although the reporter originally referred to the error message for records with no header, I think the issue is deeper. We intentionally didn't follow the same path for parsing record declarations as we do for, for example, classes. This is mainly because `class` is a keyword but `record` is a contextual keyword. So when we find `record` we are not sure if it is an identifier or a record declaration. Although I think that given a context where the compiler expects a type declaration, we can be more aggressive than before and if we find `record` + `identifier` consider it a record declaration. The current implementation of `JavacParser::isRecordStart` is trying to be too clever but it is actually leaving several cases uncovered. So the proposed simpler version should be more stable and make record related errors more similar to those for other class declarations. Test `RecordDeclarationSyntaxTest.java` has been added just to have a golden file that stores the error position.
> 
> TIA

This pull request has now been integrated.

Changeset: 60db5f2b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60db5f2ba271176292374b21c343cfc3167df562
Stats:     45 lines in 6 files changed: 15 ins; 13 del; 17 mod

8294020: improve errors for record declarations

Reviewed-by: jlahoda

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

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

From sadayapalam at openjdk.org  Tue Nov  8 06:44:50 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Tue, 8 Nov 2022 06:44:50 GMT
Subject: RFR: 8059632: Method reference compilation uses incorrect
 qualifying type [v3]
In-Reply-To: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
References: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
Message-ID: <cML-Orfdo-aI_INKC_GxwDpBg7vc9aHZyfkbaG0goVw=.bf000493-ebcf-447d-91ca-54366f857494@github.com>

> Align with JLS 13.1 (the qualifying class or interface of the method invocation) by
>     referring to the type of the receiver rather than the type of the declaring 
>     class/interface in the bootstrap attribute

Srikanth Adayapalam 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 five additional commits since the last revision:

 - Merge branch 'master' into JDK-8059632
 - Merge branch 'master' into JDK-8059632
 - Merge branch 'master' into JDK-8059632
 - Fix whitespace problem
 - 8059632: Method reference compilation uses incorrect qualifying type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10809/files
  - new: https://git.openjdk.org/jdk/pull/10809/files/b44fe30e..99853563

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

  Stats: 53522 lines in 729 files changed: 17617 ins; 32743 del; 3162 mod
  Patch: https://git.openjdk.org/jdk/pull/10809.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10809/head:pull/10809

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

From sadayapalam at openjdk.org  Tue Nov  8 07:02:36 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Tue, 8 Nov 2022 07:02:36 GMT
Subject: RFR: 8059632: Method reference compilation uses incorrect
 qualifying type [v4]
In-Reply-To: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
References: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
Message-ID: <nHiau40ereo_hJhBJ2Y5vdYiY1MFTJ3T6Pm3iBM1rkg=.b177e743-1618-49c5-8769-3ed71c6ccbae@github.com>

> Align with JLS 13.1 (the qualifying class or interface of the method invocation) by
>     referring to the type of the receiver rather than the type of the declaring 
>     class/interface in the bootstrap attribute

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate review feedback from Andrey Turbanov (Thanks!)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10809/files
  - new: https://git.openjdk.org/jdk/pull/10809/files/99853563..11f6c08e

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

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

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

From vromero at openjdk.org  Tue Nov  8 19:01:27 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Nov 2022 19:01:27 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v6]
In-Reply-To: <ildOTAhtkxaaFuunFgvvoiL9-t6R36AvvGqWKJxXL6c=.6a6a37a6-7f55-45aa-8392-1b3a2b8dc154@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <ildOTAhtkxaaFuunFgvvoiL9-t6R36AvvGqWKJxXL6c=.6a6a37a6-7f55-45aa-8392-1b3a2b8dc154@github.com>
Message-ID: <d30UFL_y9JYK4Wm6HmS9SnD7MIWdKVipLP51eEUlg-k=.6addf652-69cb-4271-be94-cec58a8f592a@github.com>

On Mon, 7 Nov 2022 09:56:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
>> 
>> 
>> record Complex(double real, double img) {}
>> 
>> List<Complex> list = ...;
>> 
>> for (Complex(var real, var img) : list) {
>>     // can use ?real? and ?img? directly
>> }
>> 
>> 
>> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
>> 
>> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
>> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
>> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
>> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
>> - The enhanced for, supports record patterns for both arrays and reference types.
>> 
>> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
>> 
>> For more information on the changes please see:
>> 
>> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
>> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
>> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
>> 
>> Looking forward for your review.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

src/jdk.compiler/share/classes/com/sun/source/tree/EnhancedForLoopTree.java line 65:

> 63:     /**
> 64:      * Returns the control variable for the loop.
> 65:      * @return the control variable, or {@code null} if this "enhanced" {@code for} uses a pattern

nit: this javadoc line is probably too long, usually we try to respect the 80 columns max width. Not sure why but I have myself got this comment in the past

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

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

From vromero at openjdk.org  Tue Nov  8 19:54:16 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Nov 2022 19:54:16 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v6]
In-Reply-To: <ildOTAhtkxaaFuunFgvvoiL9-t6R36AvvGqWKJxXL6c=.6a6a37a6-7f55-45aa-8392-1b3a2b8dc154@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <ildOTAhtkxaaFuunFgvvoiL9-t6R36AvvGqWKJxXL6c=.6a6a37a6-7f55-45aa-8392-1b3a2b8dc154@github.com>
Message-ID: <m0iPGBqIR1PXhuRj-R_DSuqYrFH8yJLqXYdYeunJzSk=.a0f6a3a7-f134-4e42-9292-d88c9f69698a@github.com>

On Mon, 7 Nov 2022 09:56:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
>> 
>> 
>> record Complex(double real, double img) {}
>> 
>> List<Complex> list = ...;
>> 
>> for (Complex(var real, var img) : list) {
>>     // can use ?real? and ?img? directly
>> }
>> 
>> 
>> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
>> 
>> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
>> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
>> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
>> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
>> - The enhanced for, supports record patterns for both arrays and reference types.
>> 
>> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
>> 
>> For more information on the changes please see:
>> 
>> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
>> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
>> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
>> 
>> Looking forward for your review.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

Marked as reviewed by vromero (Reviewer).

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

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

From weijun at openjdk.org  Tue Nov  8 22:48:56 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Nov 2022 22:48:56 GMT
Subject: RFR: 8296612: CertAttrSet is useless
Message-ID: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>

- All `CertAttrSet` child classes now implement `DerEncoder`
- `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate methods are removed
- `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need to implement it
- `X509CertImpl::encode(OutputStream out)` removed, used nowhere

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/11048/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11048&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296612
  Stats: 207 lines in 52 files changed: 4 ins; 134 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/11048.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11048/head:pull/11048

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

From vromero at openjdk.org  Wed Nov  9 06:19:55 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Nov 2022 06:19:55 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v3]
In-Reply-To: <Iq0UMDQEFTP7MORp8-64IlD7nMIVzwUrge11giig_wQ=.df8dea88-b345-41bc-b7c9-1bb08dbf1962@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <Iq0UMDQEFTP7MORp8-64IlD7nMIVzwUrge11giig_wQ=.df8dea88-b345-41bc-b7c9-1bb08dbf1962@github.com>
Message-ID: <dtDK9h174oAYC2izgUeGdoyWzlza2dqpL84cvWqETKA=.3641affe-c1b0-41c7-8ef1-4a9a4f190d2c@github.com>

On Mon, 7 Nov 2022 10:48:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
>> 
>>  - removal of named record patterns
>>  - (preview) type inference for type test and record patterns
>>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>>  - fixing exhaustiveness of certain switches
>> 
>> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
>> 
>> For more information on the changes please see:
>>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
>> 
>> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
>> 
>> Any feedback is welcome.
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reflecting review comment.
>  - Apply suggestions from code review
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 677:

> 675:         Type exprType = c.asUndetVar(expressionTypeCaptured);
> 676: 
> 677:         capturedWildcards.forEach(s -> ((UndetVar) c.asUndetVar(s)).setNormal());

could be a minor issue but still: it doesn't feel correct to set an UndetVar created from a captured type as normal. I think that we should either create a TypeVar with the info from the CapturedType and then create a `normal` UndetVar with that TypeVar or we should create another category inside `enum Kind`:


enum Kind {
    NORMAL,
    CAPTURED,
    THROWS;
}

`MODIFIABLE_CAPTURED` dunno, just my opinion

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 681:

> 679:         try {
> 680:             //step 2:
> 681:             if (commonSuperWithDiffParameterization(patternType, exprType)) {

I think this is not correct according to the spec. The spec says:

If T' is a parameterization of a generic class G, and there exists a supertype of R<?1, ..., ?n> that is also a parameterization of G, let R' be that supertype...

the current code could look for any common supertype even if that common supertype is not G but a super type of G that is also common to R. More than that the current code will look for all common parameterized supertypes and create bonds etc. I think the right thing to do here according to the spec is:

           if (!types.isSameType(types.asSuper(patternType, exprType.tsym), exprType)) {
                return null;
            }

unless I'm missing something here

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 689:

> 687:             doIncorporation(c, types.noWarnings);
> 688: 
> 689:             while (c.solveBasic(varsToSolve, EnumSet.of(InferenceStep.EQ)).nonEmpty()) {

if `varsToSolve` is equal to the number of variables in the inference context this step is a no-op and I think this should be always the case, so I think that the real resolution is happening below when `instantiatePatternVars` is invoked, unless I'm missing something this while loop could be safely removed

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

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

From shade at openjdk.org  Wed Nov  9 10:07:07 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Nov 2022 10:07:07 GMT
Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class files
 in current directory
Message-ID: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>

$ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
...

$ ls
Apan.class
``` 

Additional testing:
 - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers

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

Commit messages:
 - Fix indenting
 - Fix

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

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

From jlahoda at openjdk.org  Wed Nov  9 15:52:55 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Nov 2022 15:52:55 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v4]
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Not looking for common supertype, not solving in a loop.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10814/files
  - new: https://git.openjdk.org/jdk/pull/10814/files/c8f29c4e..5996914b

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

  Stats: 14 lines in 2 files changed: 5 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10814.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10814/head:pull/10814

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

From vromero at openjdk.org  Wed Nov  9 16:26:44 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Nov 2022 16:26:44 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v4]
In-Reply-To: <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
Message-ID: <fWBx7YOvtaSvHMzD1YRZAWrYH2AmGezR5lb0dsC7BJQ=.43b5eec8-895d-4494-8716-1d35ff047a95@github.com>

On Wed, 9 Nov 2022 15:52:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
>> 
>>  - removal of named record patterns
>>  - (preview) type inference for type test and record patterns
>>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>>  - fixing exhaustiveness of certain switches
>> 
>> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
>> 
>> For more information on the changes please see:
>>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
>> 
>> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
>> 
>> Any feedback is welcome.
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not looking for common supertype, not solving in a loop.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 657:

> 655:         }
> 656:     }
> 657: 

nit: before we push this I think some javadoc, not to formal, should be added explaining what this method is doing etc, now we remember but later on we could forget some details, also a reference to the section of the spec will be very helpful

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

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

From vromero at openjdk.org  Wed Nov  9 18:12:41 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Nov 2022 18:12:41 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v4]
In-Reply-To: <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
Message-ID: <wZLFJ5Gv9SzpGxwT6NBDt9WSrQ3MgaOJkYPEln4qsJk=.9c75503c-4b3d-4b79-9bd0-3b97714d3d2a@github.com>

On Wed, 9 Nov 2022 15:52:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
>> 
>>  - removal of named record patterns
>>  - (preview) type inference for type test and record patterns
>>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>>  - fixing exhaustiveness of certain switches
>> 
>> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
>> 
>> For more information on the changes please see:
>>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
>> 
>> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
>> 
>> Any feedback is welcome.
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not looking for common supertype, not solving in a loop.

side I extracted this example from the spec:


import java.util.function.*;

record Mapper<T>(T in, T out) implements UnaryOperator<T> {
    public T apply(T arg) { return in.equals(arg) ? out : null; }
}


class Test {
    void test(Function<? super String, ? extends CharSequence> f) {
        if (f instanceof Mapper(var in, var out)) {
            boolean shorter = out.length() < in.length();
        }
    }
}


it is not accepted by the current code, we should either modify the spec or go deeper and see if there is something missing in the current implementation

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

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

From vromero at openjdk.org  Wed Nov  9 19:50:31 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Nov 2022 19:50:31 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v4]
In-Reply-To: <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
Message-ID: <GIAdDbJ8VGLKtiyAcjJfQG6NzoNdHq26EV5ZNJ7-qIU=.40c3f8e3-f439-4be7-ac8b-9930bbc6acfa@github.com>

On Wed, 9 Nov 2022 15:52:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
>> 
>>  - removal of named record patterns
>>  - (preview) type inference for type test and record patterns
>>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>>  - fixing exhaustiveness of certain switches
>> 
>> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
>> 
>> For more information on the changes please see:
>>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
>> 
>> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
>> 
>> Any feedback is welcome.
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not looking for common supertype, not solving in a loop.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 659:

> 657: 
> 658:     public Type instantiatePatternType(Type expressionType, TypeSymbol patternTypeSymbol) {
> 659:         if (expressionType.tsym == patternTypeSymbol)

not sure we are dealing with cases when expressionType is a type variable or an intersection type, are there tests covering those cases, sorry if I'm missing something here

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

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

From vromero at openjdk.org  Wed Nov  9 20:30:30 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Nov 2022 20:30:30 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v4]
In-Reply-To: <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
Message-ID: <GX4Fkiw2a512A1ol1S4hIK3agBP2fjgm5XgghAZ0QbI=.bb7107d6-6f34-454b-98c8-d0893d58b023@github.com>

On Wed, 9 Nov 2022 15:52:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
>> 
>>  - removal of named record patterns
>>  - (preview) type inference for type test and record patterns
>>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>>  - fixing exhaustiveness of certain switches
>> 
>> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
>> 
>> For more information on the changes please see:
>>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
>> 
>> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
>> 
>> Any feedback is welcome.
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not looking for common supertype, not solving in a loop.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 709:

> 707: 
> 708:         //step 1 - create fresh tvars
> 709:         for (Type t : vars) {

I'm not sure about this so just a question: shouldn't we run this loop until no more undetVars need to be instantiated? we could also limit until a maximum number of steps in case we find cases that doesn't converge to a solution

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi Jon,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From jlaskey at openjdk.org  Thu Nov 10 15:09:14 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 10 Nov 2022 15:09:14 GMT
Subject: 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 abimpoudis at openjdk.org  Thu Nov 10 15:48:38 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 10 Nov 2022 15:48:38 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v7]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <LE-E5TA8am2PZS51FRi3xeRmfLCOY2GDRYNfPSN6UOM=.46f06fb3-7578-49d1-ac26-2ec4a5dbdb01@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

Aggelos Biboudis has updated the pull request incrementally with three additional commits since the last revision:

 - Merge pull request #1 from lahodaj/for-patterns
   
   Fixing record patterns with primitive components in enhanced for
 - Cleanup
 - Fixing pattern/non-pattern disambiguation in presence of primitive-typed patterns.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/a65bf7a2..ff0d086c

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

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

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

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

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

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

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

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

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

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

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

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

did you changed 420 files ?

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

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

From forax at openjdk.org  Thu Nov 10 16:47:00 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 10 Nov 2022 16:47:00 GMT
Subject: 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 jonathan.gibbons at oracle.com  Thu Nov 10 19:19:28 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 11:19:28 -0800
Subject: Error examples page
In-Reply-To: <d13c8ca2-9602-8656-33fa-2eabcae9611a@oracle.com>
References: <CA+NR86hzKmTDQQm93jU+g-KmE-f9h807AnzqPAFPnY9UJEV+Vw@mail.gmail.com>
 <d13c8ca2-9602-8656-33fa-2eabcae9611a@oracle.com>
Message-ID: <71606e79-2d79-68e8-deb5-d2e79066392c@oracle.com>

As a followup, the code to generate diags-examples.html needed some TLC, 
and was fixed in JDK-8296137 <https://bugs.openjdk.org/browse/JDK-8296137>.

The command to generate the report is effectively this:

JAVA_HOME=$JDK $ANT \
 ??? -Dlangtools.jdk.home=$JDK \
 ??? -f make/langtools/diags-examples.xml

where:

  * the current directory is the root of the OpenJDK repo
  * ANT refers to a recent executable for Ant,
  * JDK refers to a build of JDK in the same repo containing the
    examples directory

The report will be written to build/langtools/diags-examples/

-- Jon

On 10/3/22 1:22 PM, Jonathan Gibbons wrote:
>
> It's generated by the code in open/test/langtools/tools/javac/diags/.
>
> There are various classes there, like RunExamples.java, 
> CheckExamples.java etc. You are probably looking for RunExamples.java; 
> there are comments in the code on how to use it.
>
> -- Jon
>
> On 10/3/22 7:31 AM, Ethan McCue wrote:
>> Hey all,
>>
>> My group stumbled upon this page with a bunch of error examples in a 
>> nice presentable format.
>>
>> https://cr.openjdk.java.net/~jjg/diags-examples.html 
>> <https://cr.openjdk.java.net/~jjg/diags-examples.html>
>>
>> My suspicion is that this was generated by something in the codebase 
>> - if so does anyone know the command of the top of their head?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221110/764bf811/attachment-0001.htm>

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

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

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

+1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> did you changed 420 files ?

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

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

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

From ethan at mccue.dev  Thu Nov 10 22:21:42 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Thu, 10 Nov 2022 17:21:42 -0500
Subject: [External] : Re: Error examples page
In-Reply-To: <CA+NR86gf=zrhzKrvTtGggcPKkojqS3QqC0qEjPgzCa2mqogrfg@mail.gmail.com>
References: <CA+NR86hzKmTDQQm93jU+g-KmE-f9h807AnzqPAFPnY9UJEV+Vw@mail.gmail.com>
 <d13c8ca2-9602-8656-33fa-2eabcae9611a@oracle.com>
 <71606e79-2d79-68e8-deb5-d2e79066392c@oracle.com>
 <CA+NR86gD81zb0ssocFgtbdAO3NtGz=T_eMngwT42ZBsqhudAwQ@mail.gmail.com>
 <86f1c26f-1756-4d8e-ae08-d2bbf4edea8a@oracle.com>
 <CA+NR86gf=zrhzKrvTtGggcPKkojqS3QqC0qEjPgzCa2mqogrfg@mail.gmail.com>
Message-ID: <CA+NR86huXFfVZiPQM-6Q=44ezDQxPQqyq8cetGDV+ddSKhKpsw@mail.gmail.com>

I think for the JLS justification in particular - that is something which
fits within the "info" part of our model but also isn't
particularly interesting for the target audience of "people who trigger
compiler errors."

 A motivating example I sent to Vicente (almost 9 months ago! God I'm
unproductive) was the contrast between the information conveyed in this
message

    import java.util.List;

    enum Ex {
        A,
        B
    }

    public class MyClass {
        public static void main(String args[]) {
            var ex = B;
        }
    }



    /MyClass.java:10: error: cannot find symbol
            var ex = B;
                     ^
      symbol:   variable B
      location: class MyClass

As compared to that emitted by rustc

    enum Ex {
        A,
        B
    }

    pub fn main() {
        let ex = A;
    }

    error[E0425]: cannot find value `A` in this scope
     --> src/main.rs:7:14
      |
    7 |     let ex = A;
      |              ^ not found in this scope
      |
    help: consider importing this unit variant
      |
    1 | use crate::Ex::A;
      |

    For more information about this error, try `rustc --explain E0425`.

Which could look like (ignoring the finer details of the ascii art)

    error[E0123]: cannot find symbol `A` in this scope
     --> src/Main.java:9:18
      |
    9 |     var ex = B;
      |              ^ not found in this scope
      |
    help: consider importing this enum variant
      |
    1 | import static Ex.B;
      |

    For more information about this error, try `javac --explain E0123`.

Where it is not enough to just "make a better message." There are
structural deficiencies which preclude giving this sort of feedback.

The *desire* to give a hint on how to fix something or extra context on why
something is an error is what I think the true monster hiding under the bed
of JDK-6397027 was. Language kinda has to be irregular in order to contain
multiple of these semantic elements - y'know?

(sorry if this isn't the most complete justification)

---

My strategy for making progress has been to recruit the help of some
students for whom working out a prototype is their senior design project.
It's slow going, but we're all learning.

On Thu, Nov 10, 2022, 4:40 PM Ethan McCue <ethan at mccue.dev> wrote:

> Pithy instant response: it's not too big for mainstream rustc
>
>
> On Thu, Nov 10, 2022, 4:31 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>>
>> Our current brain scratcher is how to represent suggestions on how to fix
>> code that actually "makes the correction for them"
>>
>> So like
>>
>>     int assert;
>>
>> How to model some code that can be later formatted as a suggestion to
>> rename the "assert" variable to "assert_"
>>
>>
>>
>> While it sounds fun, it also sounds "too big" for mainstream javac.
>> That suggests there could be a plugin mechanism to add more info to
>> diagnostics.  Maybe.
>>
>> -- Jon
>>
>>
>>
>> On 11/10/22 11:42 AM, Ethan McCue wrote:
>>
>> Thanks - we have been tracking the PR. It will be helpful for us to track
>> our progress.
>>
>> ---
>>
>> To springboard into something different but related:
>>
>> We have been working on modeling how to add kinds of information to
>> JCDiagnostics that are semantically different from a message as produced by
>> DiagnosticInfo.
>>
>> In the current hypothesis there are two new categories of information we
>> are calling "help" and "info".
>>
>> "help" contains some suggestions on how to rectify a given sort of error.
>> In the simplest form this is a codification of the "try using
>> --enable-preview" type messages which exist somewhat ad-hoc throughout the
>> codebase.
>>
>> Our current brain scratcher is how to represent suggestions on how to fix
>> code that actually "makes the correction for them"
>>
>> So like
>>
>>     int assert;
>>
>> How to model some code that can be later formatted as a suggestion to
>> rename the "assert" variable to "assert_"
>>
>>
>>
>>
>>
>> On Thu, Nov 10, 2022, 2:25 PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> As a followup, the code to generate diags-examples.html needed some TLC,
>>> and was fixed in JDK-8296137
>>> <https://bugs.openjdk.org/browse/JDK-8296137>.
>>>
>>> The command to generate the report is effectively this:
>>>
>>> JAVA_HOME=$JDK $ANT \
>>>     -Dlangtools.jdk.home=$JDK \
>>>     -f make/langtools/diags-examples.xml
>>>
>>> where:
>>>
>>>    - the current directory is the root of the OpenJDK repo
>>>    - ANT refers to a recent executable for Ant,
>>>    - JDK refers to a build of JDK in the same repo containing the
>>>    examples directory
>>>
>>> The report will be written to build/langtools/diags-examples/
>>> -- Jon
>>>
>>> On 10/3/22 1:22 PM, Jonathan Gibbons wrote:
>>>
>>> It's generated by the code in open/test/langtools/tools/javac/diags/.
>>>
>>> There are various classes there, like RunExamples.java,
>>> CheckExamples.java etc. You are probably looking for RunExamples.java;
>>> there are comments in the code on how to use it.
>>>
>>> -- Jon
>>> On 10/3/22 7:31 AM, Ethan McCue wrote:
>>>
>>> Hey all,
>>>
>>> My group stumbled upon this page with a bunch of error examples in a
>>> nice presentable format.
>>>
>>> https://cr.openjdk.java.net/~jjg/diags-examples.html
>>>
>>> My suspicion is that this was generated by something in the codebase -
>>> if so does anyone know the command of the top of their head?
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221110/43e495d0/attachment-0001.htm>

From jonathan.gibbons at oracle.com  Thu Nov 10 22:36:04 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 14:36:04 -0800
Subject: [External] : Re: Error examples page
In-Reply-To: <CA+NR86huXFfVZiPQM-6Q=44ezDQxPQqyq8cetGDV+ddSKhKpsw@mail.gmail.com>
References: <CA+NR86hzKmTDQQm93jU+g-KmE-f9h807AnzqPAFPnY9UJEV+Vw@mail.gmail.com>
 <d13c8ca2-9602-8656-33fa-2eabcae9611a@oracle.com>
 <71606e79-2d79-68e8-deb5-d2e79066392c@oracle.com>
 <CA+NR86gD81zb0ssocFgtbdAO3NtGz=T_eMngwT42ZBsqhudAwQ@mail.gmail.com>
 <86f1c26f-1756-4d8e-ae08-d2bbf4edea8a@oracle.com>
 <CA+NR86gf=zrhzKrvTtGggcPKkojqS3QqC0qEjPgzCa2mqogrfg@mail.gmail.com>
 <CA+NR86huXFfVZiPQM-6Q=44ezDQxPQqyq8cetGDV+ddSKhKpsw@mail.gmail.com>
Message-ID: <bbeec72f-04e1-709c-cb4e-e173f5b15f06@oracle.com>

Thanks for all the extra info.

Yes, the desire for JLS references was primarily for some of the more 
obscure messages about generic types, and bounds checking, etc.

Giving advice about how to fix code is definitely a challenge. Bad or 
incorrect advice is arguably worse than no advice at all. Generally, the 
policy for javac over the past few years has been to provide more 
specific details about what is wrong, and the general context of the 
error, but stopping short of suggesting changes.? IDEs have arguably 
more context to do it better, providing GUI support for "suggestions" on 
how to change the code.

-- Jon

On 11/10/22 2:21 PM, Ethan McCue wrote:
> I think for the JLS justification in particular - that is something 
> which fits within the "info" part of our model but also isn't 
> particularly?interesting for the target audience of "people who 
> trigger compiler errors."
>
> ?A motivating example I sent to Vicente (almost 9 months ago! God I'm 
> unproductive) was the contrast between the information conveyed in 
> this message
>
> ? ? import java.util.List;
>
> ? ? enum Ex {
> ? ? ? ? A,
> ? ? ? ? B
> ? ? }
>
> ? ? public class MyClass {
> ? ? ? ? public static void main(String args[]) {
> ? ? ? ? ? ? var ex = B;
> ? ? ? ? }
> ? ? }
>
>
>
> ? ? /MyClass.java:10: error: cannot find symbol
> ? ? ? ? ? ? var ex = B;
> ? ? ? ? ? ? ? ? ? ? ?^
> ? ? ? symbol: ? variable B
> ? ? ? location: class MyClass
>
> As compared to that emitted by rustc
>
> ? ? enum Ex {
> ? ? ? ? A,
> ? ? ? ? B
> ? ? }
>
> ? ? pub fn main() {
> ? ? ? ? let ex = A;
> ? ? }
>
> ? ? error[E0425]: cannot find value `A` in this scope
> ? ? ?--> src/main.rs:7:14
> ? ? ? |
> ? ? 7 | ? ? let ex = A;
> ? ? ? | ? ? ? ? ? ? ?^ not found in this scope
> ? ? ? |
> ? ? help: consider importing this unit variant
> ? ? ? |
> ? ? 1 | use crate::Ex::A;
> ? ? ? |
>
> ? ? For more information about this error, try `rustc --explain E0425`.
>
> Which could look like (ignoring the finer details of the ascii art)
>
> ? ? error[E0123]: cannot find symbol `A` in this scope
> ? ? ?--> src/Main.java:9:18
> ? ? ? |
> ? ? 9 | ? ? var ex = B;
> ? ? ? | ? ? ? ? ? ? ?^ not found in this scope
> ? ? ? |
> ? ? help: consider importing this enum variant
> ? ? ? |
> ? ? 1 | import static Ex.B;
> ? ? ? |
>
> ? ? For more information about this error, try `javac --explain E0123`.
>
> Where it is not enough to just "make a better message." There are 
> structural deficiencies which preclude giving this sort of feedback.
>
> The *desire* to give a hint on how to fix something or extra context 
> on why something is an error is what I think the true monster hiding 
> under the bed of JDK-6397027 was. Language kinda has to be irregular 
> in order to contain multiple of these semantic elements - y'know?
>
> (sorry if this isn't the most complete justification)
>
> ---
>
> My strategy for making progress has been to recruit the help of some 
> students for whom working out a prototype is their senior design 
> project. It's slow going, but we're all learning.
>
> On Thu, Nov 10, 2022, 4:40 PM Ethan McCue <ethan at mccue.dev> wrote:
>
>     Pithy instant response: it's not too big for mainstream rustc
>
>
>     On Thu, Nov 10, 2022, 4:31 PM Jonathan Gibbons
>     <jonathan.gibbons at oracle.com> wrote:
>
>>
>>         Our current brain scratcher is how to represent suggestions
>>         on how to fix code that actually "makes the correction for them"
>>
>>         So like
>>
>>         ? ? int assert;
>>
>>         How to model some code that can be later formatted as a
>>         suggestion to rename the "assert" variable to "assert_"
>>
>>
>>
>         While it sounds fun, it also sounds "too big" for mainstream
>         javac.?? That suggests there could be a plugin mechanism to
>         add more info to diagnostics.? Maybe.
>
>         -- Jon
>
>
>
>         On 11/10/22 11:42 AM, Ethan McCue wrote:
>>         Thanks - we have been tracking the PR. It will be helpful for
>>         us to track our progress.
>>
>>         ---
>>
>>         To springboard into something different but related:
>>
>>         We have been working on modeling how to add kinds of
>>         information to JCDiagnostics that are semantically different
>>         from a message as produced by DiagnosticInfo.
>>
>>         In the current hypothesis there are two new categories of
>>         information we are calling "help" and "info".
>>
>>         "help" contains some suggestions on how to rectify a given
>>         sort of error. In the simplest form this is a codification of
>>         the "try using --enable-preview" type messages which exist
>>         somewhat ad-hoc throughout the codebase.
>>
>>         Our current brain scratcher is how to represent suggestions
>>         on how to fix code that actually "makes the correction for them"
>>
>>         So like
>>
>>         ? ? int assert;
>>
>>         How to model some code that can be later formatted as a
>>         suggestion to rename the "assert" variable to "assert_"
>>
>>
>>
>>
>>
>>         On Thu, Nov 10, 2022, 2:25 PM Jonathan Gibbons
>>         <jonathan.gibbons at oracle.com> wrote:
>>
>>             As a followup, the code to generate diags-examples.html
>>             needed some TLC, and was fixed in JDK-8296137
>>             <https://bugs.openjdk.org/browse/JDK-8296137>.
>>
>>             The command to generate the report is effectively this:
>>
>>             JAVA_HOME=$JDK $ANT \
>>             ??? -Dlangtools.jdk.home=$JDK \
>>             ??? -f make/langtools/diags-examples.xml
>>
>>             where:
>>
>>               * the current directory is the root of the OpenJDK repo
>>               * ANT refers to a recent executable for Ant,
>>               * JDK refers to a build of JDK in the same repo
>>                 containing the examples directory
>>
>>             The report will be written to build/langtools/diags-examples/
>>
>>             -- Jon
>>
>>             On 10/3/22 1:22 PM, Jonathan Gibbons wrote:
>>>
>>>             It's generated by the code in
>>>             open/test/langtools/tools/javac/diags/.
>>>
>>>             There are various classes there, like RunExamples.java,
>>>             CheckExamples.java etc. You are probably looking for
>>>             RunExamples.java; there are comments in the code on how
>>>             to use it.
>>>
>>>             -- Jon
>>>
>>>             On 10/3/22 7:31 AM, Ethan McCue wrote:
>>>>             Hey all,
>>>>
>>>>             My group stumbled upon this page with a bunch of error
>>>>             examples in a nice presentable format.
>>>>
>>>>             https://cr.openjdk.java.net/~jjg/diags-examples.html
>>>>
>>>>             My suspicion is that this was generated by something in
>>>>             the codebase - if so does anyone know the command of
>>>>             the top of their head?
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221110/eaa37e9a/attachment-0001.htm>

From kevinw at openjdk.org  Thu Nov 10 22:53:34 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 10 Nov 2022 22:53:34 GMT
Subject: RFR: 8296390: Incremental build failed with a NPE
In-Reply-To: <ELodOjBLAO1exPcb_tDxfi_3Mrgaoc_m_cLgBVIZULQ=.ff3b5258-e368-4d1f-98e2-7fbd5f2ce319@github.com>
References: <ELodOjBLAO1exPcb_tDxfi_3Mrgaoc_m_cLgBVIZULQ=.ff3b5258-e368-4d1f-98e2-7fbd5f2ce319@github.com>
Message-ID: <7Xw2j5d3i9j7t1UqpgnYkPIUjLWQ1I5P1fc-4jMP9So=.81825fc4-f43d-43fd-810c-2846474c5836@github.com>

On Fri, 4 Nov 2022 14:05:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> In [Enter](https://github.com/openjdk/jdk/blob/22347e46f7e66a864ea987fa084c44792cae2e6a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java#L617), we finish verification that imports in files are valid. But, if the module graph is not finished yet (modules are not initialized), we defer checking imports in module-infos until the modules are setup.
> 
> What can happen is that `java.base`', if load lazily, may not be completed as part of module system initialization, and can trigger imports check in other module prematurely.
> 
> The proposal is to explicitly complete `java.base` while setting up the compile-time module system. Other (named) modules are normally completed around the same time while [building all modules](https://github.com/openjdk/jdk/blob/22347e46f7e66a864ea987fa084c44792cae2e6a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1414).

Not a review exactly, but I'm hitting this problem, and the one-line change does fix it.  Incremental builds work again.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

See above comment for Connection.java.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi Jon,

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

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

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

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

Line 52 should be removed

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

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

Line 448 should be removed

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

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

Line 44 should be removed

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

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

Line 43 should be removed

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

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

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

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

Changes requested by lancea (Reviewer).

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

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

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

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

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

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

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

From jlahoda at openjdk.org  Fri Nov 11 14:03:43 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 11 Nov 2022 14:03:43 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v4]
In-Reply-To: <GX4Fkiw2a512A1ol1S4hIK3agBP2fjgm5XgghAZ0QbI=.bb7107d6-6f34-454b-98c8-d0893d58b023@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
 <GX4Fkiw2a512A1ol1S4hIK3agBP2fjgm5XgghAZ0QbI=.bb7107d6-6f34-454b-98c8-d0893d58b023@github.com>
Message-ID: <jAWDXwLG-cYYmnLpk1S-jT8dcdEowS-AI5zbbRC829w=.0f314fb6-9f76-419f-aad7-f8e860537e7a@github.com>

On Wed, 9 Nov 2022 20:28:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Not looking for common supertype, not solving in a loop.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 709:
> 
>> 707: 
>> 708:         //step 1 - create fresh tvars
>> 709:         for (Type t : vars) {
> 
> I'm not sure about this so just a question: shouldn't we run this loop until no more undetVars need to be instantiated? we could also limit until a maximum number of steps in case we find cases that doesn't converge to a solution

In my understanding, we are not creating new undet vars here, and we instantiate them all in this loop, and fix their bounds if needed in the next step, so this should resolve all the vars.

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

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

From abimpoudis at openjdk.org  Fri Nov 11 15:42:03 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 11 Nov 2022 15:42:03 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v8]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <HUKeKqJ2OkULqOXHIhNrn8OfsUB0uva2S_ahFXMD9A8=.3f20d024-d804-451e-9a69-9a3a167f2698@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

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

  Fix parsing error in presence of nested patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/ff0d086c..6e57e550

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

  Stats: 37 lines in 2 files changed: 35 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

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

From mcimadamore at openjdk.org  Fri Nov 11 16:31:55 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Nov 2022 16:31:55 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v8]
In-Reply-To: <HUKeKqJ2OkULqOXHIhNrn8OfsUB0uva2S_ahFXMD9A8=.3f20d024-d804-451e-9a69-9a3a167f2698@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <HUKeKqJ2OkULqOXHIhNrn8OfsUB0uva2S_ahFXMD9A8=.3f20d024-d804-451e-9a69-9a3a167f2698@github.com>
Message-ID: <YcDgXa-Nt-GOlS5wY7OUknM3d28CBRb1Rp5Lu4rLsyI=.18bbb95a-27b2-48a2-b889-a714ef99b85a@github.com>

On Fri, 11 Nov 2022 15:42:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
>> 
>> 
>> record Complex(double real, double img) {}
>> 
>> List<Complex> list = ...;
>> 
>> for (Complex(var real, var img) : list) {
>>     // can use ?real? and ?img? directly
>> }
>> 
>> 
>> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
>> 
>> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
>> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
>> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
>> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
>> - The enhanced for, supports record patterns for both arrays and reference types.
>> 
>> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
>> 
>> For more information on the changes please see:
>> 
>> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
>> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
>> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
>> 
>> Looking forward for your review.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix parsing error in presence of nested patterns

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

> 2985:         boolean inType = false;
> 2986:         boolean inSelectionAndParenthesis = false;
> 2987:         boolean sequentialIdentifiers = false;

In general the changes look good - but please make sure that we don't get confused by lambda expressions. E.g. a lambda can be like `(type name)`, so you have two identifiers between parens. Or, even `(int x)`, so `int x` between parens - which I think will trick this code into thinking you have a record?

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

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

From abimpoudis at openjdk.org  Fri Nov 11 17:38:31 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 11 Nov 2022 17:38:31 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v8]
In-Reply-To: <YcDgXa-Nt-GOlS5wY7OUknM3d28CBRb1Rp5Lu4rLsyI=.18bbb95a-27b2-48a2-b889-a714ef99b85a@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <HUKeKqJ2OkULqOXHIhNrn8OfsUB0uva2S_ahFXMD9A8=.3f20d024-d804-451e-9a69-9a3a167f2698@github.com>
 <YcDgXa-Nt-GOlS5wY7OUknM3d28CBRb1Rp5Lu4rLsyI=.18bbb95a-27b2-48a2-b889-a714ef99b85a@github.com>
Message-ID: <lRhY7609TG1JgrEZ-Pb-k_TmidAKkchHojohuE4lmBQ=.7dcd23ae-8619-44ff-8b5c-d43d308019b9@github.com>

On Fri, 11 Nov 2022 16:29:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix parsing error in presence of nested patterns
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2987:
> 
>> 2985:         boolean inType = false;
>> 2986:         boolean inSelectionAndParenthesis = false;
>> 2987:         boolean sequentialIdentifiers = false;
> 
> In general the changes look good - but please make sure that we don't get confused by lambda expressions. E.g. a lambda can be like `(type name)`, so you have two identifiers between parens. Or, even `(int x)`, so `int x` between parens - which I think will trick this code into thinking you have a record?

This qualifies as a test case to add and a new bug to fix :D 
Good catch.


static <T> void method2(Function<Integer, Integer> f) {}
int i = 42;
for (method2((Integer a) -> 42); i == 0;) { i++; }

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

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

From mcimadamore at openjdk.org  Fri Nov 11 18:06:32 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Nov 2022 18:06:32 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v8]
In-Reply-To: <lRhY7609TG1JgrEZ-Pb-k_TmidAKkchHojohuE4lmBQ=.7dcd23ae-8619-44ff-8b5c-d43d308019b9@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <HUKeKqJ2OkULqOXHIhNrn8OfsUB0uva2S_ahFXMD9A8=.3f20d024-d804-451e-9a69-9a3a167f2698@github.com>
 <YcDgXa-Nt-GOlS5wY7OUknM3d28CBRb1Rp5Lu4rLsyI=.18bbb95a-27b2-48a2-b889-a714ef99b85a@github.com>
 <lRhY7609TG1JgrEZ-Pb-k_TmidAKkchHojohuE4lmBQ=.7dcd23ae-8619-44ff-8b5c-d43d308019b9@github.com>
Message-ID: <khuVXO6wKOVJD0X6KxZpE-SYFDlRSN1FFnm1Gw3ZlbE=.5432fa15-6917-4029-9e29-5292a8cc3bd9@github.com>

On Fri, 11 Nov 2022 17:34:37 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2987:
>> 
>>> 2985:         boolean inType = false;
>>> 2986:         boolean inSelectionAndParenthesis = false;
>>> 2987:         boolean sequentialIdentifiers = false;
>> 
>> In general the changes look good - but please make sure that we don't get confused by lambda expressions. E.g. a lambda can be like `(type name)`, so you have two identifiers between parens. Or, even `(int x)`, so `int x` between parens - which I think will trick this code into thinking you have a record?
>
> This qualifies as a test case to add and a new bug to fix :D 
> Good catch.
> 
> 
> static <T> void method2(Function<Integer, Integer> f) {}
> int i = 42;
> for (method2((Integer a) -> 42); i == 0;) { i++; }

Note also that a generic type might end with `>` - so `>` followed by an IDENT could also be a sign or a record (same as IDENT IDENT).

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

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

From duke at openjdk.org  Fri Nov 11 21:49:31 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 11 Nov 2022 21:49:31 GMT
Subject: RFR: 8296846: Minor cleanup of some dead code in Flow.java
Message-ID: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>

This patch removes two bits of dead code that I ran across.

The only interesting bit is the second patch, which removes this check:

                /*  Ignore synthetic methods, except for translated lambda methods.
                 */
                if ((tree.sym.flags() & (SYNTHETIC | LAMBDA_METHOD)) == SYNTHETIC) {
                    return;
                }

because it's always preceded by this more general check:

             /*  MemberEnter can generate synthetic methods ignore them
              */
             if ((tree.sym.flags() & SYNTHETIC) != 0) {
                 return;
             }

and so can never match.

So the patch preserves the existing behavior, but the bit being removed there begs the question: was there some scenario where `tree.sym.flags()` could have both `SYNTHETIC` and `LAMBDA_METHOD` that we were supposed to be handling?

As it turns out, the `LAMBDA_METHOD` flag is only ever set by `LambdaToMethod`, but that class runs after this code (during flow analysis). So if there ever was any such scenario, it can no longer happen anyway.

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

Commit messages:
 - 8296846: Minor cleanup of some dead code in Flow.java

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

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

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 abimpoudis at openjdk.org  Sat Nov 12 14:45:21 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 12 Nov 2022 14:45:21 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v9]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <Jffp7WpOPHWGuBEmascfGjZRuf73XgmeAyH9yf7RPH8=.e3459219-223f-4cdf-817d-994994ae4678@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

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

  Fix parsing error in presence of lambdas

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/6e57e550..68955d56

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

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

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

From abimpoudis at openjdk.org  Sat Nov 12 14:45:21 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 12 Nov 2022 14:45:21 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v8]
In-Reply-To: <khuVXO6wKOVJD0X6KxZpE-SYFDlRSN1FFnm1Gw3ZlbE=.5432fa15-6917-4029-9e29-5292a8cc3bd9@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <HUKeKqJ2OkULqOXHIhNrn8OfsUB0uva2S_ahFXMD9A8=.3f20d024-d804-451e-9a69-9a3a167f2698@github.com>
 <YcDgXa-Nt-GOlS5wY7OUknM3d28CBRb1Rp5Lu4rLsyI=.18bbb95a-27b2-48a2-b889-a714ef99b85a@github.com>
 <lRhY7609TG1JgrEZ-Pb-k_TmidAKkchHojohuE4lmBQ=.7dcd23ae-8619-44ff-8b5c-d43d308019b9@github.com>
 <khuVXO6wKOVJD0X6KxZpE-SYFDlRSN1FFnm1Gw3ZlbE=.5432fa15-6917-4029-9e29-5292a8cc3bd9@github.com>
Message-ID: <dKYpFvlBrQUdRwxmVBSWnnSZ94xkA5fcbKcYk2uglvk=.5ea73fcb-a32f-45be-bbe6-f4fb37e95790@github.com>

On Fri, 11 Nov 2022 18:04:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This qualifies as a test case to add and a new bug to fix :D 
>> Good catch.
>> 
>> 
>> static <T> void method2(Function<Integer, Integer> f) {}
>> int i = 42;
>> for (method2((Integer a) -> 42); i == 0;) { i++; }
>
> Note also that a generic type might end with `>` - so `>` followed by an IDENT could also be a sign or a record (same as IDENT IDENT).

PR updated!

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

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

From abimpoudis at openjdk.org  Sat Nov 12 15:31:34 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 12 Nov 2022 15:31:34 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v10]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <kuk8GGMj1PI4pZNMxtQM3J74uIrm1mMceNY5ACTWlRg=.ccf602b4-70ee-4c8d-8166-e4cb02267a78@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

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

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/68955d56..05965c26

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

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

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

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 vromero at openjdk.org  Mon Nov 14 16:19:12 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 14 Nov 2022 16:19:12 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v4]
In-Reply-To: <jAWDXwLG-cYYmnLpk1S-jT8dcdEowS-AI5zbbRC829w=.0f314fb6-9f76-419f-aad7-f8e860537e7a@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
 <GX4Fkiw2a512A1ol1S4hIK3agBP2fjgm5XgghAZ0QbI=.bb7107d6-6f34-454b-98c8-d0893d58b023@github.com>
 <jAWDXwLG-cYYmnLpk1S-jT8dcdEowS-AI5zbbRC829w=.0f314fb6-9f76-419f-aad7-f8e860537e7a@github.com>
Message-ID: <e1BdDoYQ-llUBfDjPmAS_i75X2YXzVCMo-FtGwnKsuI=.6c6f5f51-90e0-4f9c-8549-0d1bedda3766@github.com>

On Fri, 11 Nov 2022 14:01:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 709:
>> 
>>> 707: 
>>> 708:         //step 1 - create fresh tvars
>>> 709:         for (Type t : vars) {
>> 
>> I'm not sure about this so just a question: shouldn't we run this loop until no more undetVars need to be instantiated? we could also limit until a maximum number of steps in case we find cases that doesn't converge to a solution
>
> In my understanding, we are not creating new undet vars here, and we instantiate them all in this loop, and fix their bounds if needed in the next step, so this should resolve all the vars.

ok, yes I guess we should be fine and if we find any issue in the future we can always go back and react then

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

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

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 vromero at openjdk.org  Mon Nov 14 18:33:05 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 14 Nov 2022 18:33:05 GMT
Subject: RFR: 8296171: Compiler incorrectly rejects code with variadic method
 references
Message-ID: <aUU86kwXah5s-vGc5-4aTdK1iIUm1diZoyCQXtIF10g=.867e0f45-57a3-4011-8de9-148c748b51db@github.com>

Please review this PR that is syncing javac with the spec. Javac is rejecting this code:


import java.util.function.*;
interface Intf {
    Object apply(String... args);
}
                
public class Test {
    public static Object foo(Object o) { return "bar"; }
    public final Object foo(Object... o) { return "foo"; }
                
    public void test() {
        Intf f = this::foo;
    }
}


javac indicates that the method reference is invalid when according to the spec the second `foo` method should be selected by the compiler. The related section of the spec can be found at section `15.13.1 Compile-Time Declaration of a Method Reference`: 


  ? For all other forms of method reference expression, one search for a most
  specific applicable method is performed. The search is as specified in
  ?15.12.2.2 through ?15.12.2.5, with the clarifications below.
  The method reference is treated as if it were an invocation with argument
  expressions of types P 1 , ..., P n ; the type arguments, if any, are given by the
  method reference expression.
  If the search results in an error as specified in ?15.12.2.2 through ?15.12.2.5,
  or if the most specific applicable method is static , there is no compile-time
  declaration.
  Otherwise, the compile-time declaration is the most specific applicable
  method.



Actually the method search is correct but later on javac is seeing that both methods are applicable and given that they have different staticness, it is making wrong assumptions down the road.

TIA

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

Commit messages:
 - removing whitespace
 - 8296171: Compiler incorrectly rejects code with variadic method references

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

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

From mcimadamore at openjdk.org  Mon Nov 14 18:33:07 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 14 Nov 2022 18:33:07 GMT
Subject: RFR: 8296171: Compiler incorrectly rejects code with variadic
 method references
In-Reply-To: <aUU86kwXah5s-vGc5-4aTdK1iIUm1diZoyCQXtIF10g=.867e0f45-57a3-4011-8de9-148c748b51db@github.com>
References: <aUU86kwXah5s-vGc5-4aTdK1iIUm1diZoyCQXtIF10g=.867e0f45-57a3-4011-8de9-148c748b51db@github.com>
Message-ID: <MJJQJcFpalFN4j9F9Pcny3YNsLPYissgVKfxRkkLV8o=.2148ba33-1be7-4759-a2c5-a793e21976df@github.com>

On Thu, 10 Nov 2022 22:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR that is syncing javac with the spec. Javac is rejecting this code:
> 
> 
> import java.util.function.*;
> interface Intf {
>     Object apply(String... args);
> }
>                 
> public class Test {
>     public static Object foo(Object o) { return "bar"; }
>     public final Object foo(Object... o) { return "foo"; }
>                 
>     public void test() {
>         Intf f = this::foo;
>     }
> }
> 
> 
> javac indicates that the method reference is invalid when according to the spec the second `foo` method should be selected by the compiler. The related section of the spec can be found at section `15.13.1 Compile-Time Declaration of a Method Reference`: 
> 
> 
>   ? For all other forms of method reference expression, one search for a most
>   specific applicable method is performed. The search is as specified in
>   ?15.12.2.2 through ?15.12.2.5, with the clarifications below.
>   The method reference is treated as if it were an invocation with argument
>   expressions of types P 1 , ..., P n ; the type arguments, if any, are given by the
>   method reference expression.
>   If the search results in an error as specified in ?15.12.2.2 through ?15.12.2.5,
>   or if the most specific applicable method is static , there is no compile-time
>   declaration.
>   Otherwise, the compile-time declaration is the most specific applicable
>   method.
> 
> 
> 
> Actually the method search is correct but later on javac is seeing that both methods are applicable and given that they have different staticness, it is making wrong assumptions down the road.
> 
> TIA

Looks good - watch out for whitespaces

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3114:

> 3112:         Symbol boundSym = lookupMethod(boundEnv, env.tree.pos(),
> 3113:                 site.tsym, boundSearchResolveContext, boundLookupHelper);
> 3114:         boolean isStaticSelector = TreeInfo.isStaticSelector(referenceTree.expr, names);

This is a good minimal fix I believe.
Moving forward (e.g. maybe in a separate PR) I wonder if it would be useful to make this code less general. E.g. the method reference lookup code comes from a time where we always did two lookups - but the JL:S has later been rectified, so that now we only do two lookups for unbound method references (e.g. those with static qualifier). I think that the current code is not the best in terms of achieving good JLS parity w/ a good readability, because it's trying to do too much. But of course that's an issue that was there before your fix.

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

Marked as reviewed by mcimadamore (Reviewer).

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

From vromero at openjdk.org  Mon Nov 14 18:33:09 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 14 Nov 2022 18:33:09 GMT
Subject: RFR: 8296171: Compiler incorrectly rejects code with variadic
 method references
In-Reply-To: <MJJQJcFpalFN4j9F9Pcny3YNsLPYissgVKfxRkkLV8o=.2148ba33-1be7-4759-a2c5-a793e21976df@github.com>
References: <aUU86kwXah5s-vGc5-4aTdK1iIUm1diZoyCQXtIF10g=.867e0f45-57a3-4011-8de9-148c748b51db@github.com>
 <MJJQJcFpalFN4j9F9Pcny3YNsLPYissgVKfxRkkLV8o=.2148ba33-1be7-4759-a2c5-a793e21976df@github.com>
Message-ID: <JrQpkbAhA2vIzMwN-pT9PCuPZV1cHt2lt3Kh-IuvZos=.76724bcd-8bd7-457d-bf17-998e2d8328b1@github.com>

On Mon, 14 Nov 2022 16:42:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Please review this PR that is syncing javac with the spec. Javac is rejecting this code:
>> 
>> 
>> import java.util.function.*;
>> interface Intf {
>>     Object apply(String... args);
>> }
>>                 
>> public class Test {
>>     public static Object foo(Object o) { return "bar"; }
>>     public final Object foo(Object... o) { return "foo"; }
>>                 
>>     public void test() {
>>         Intf f = this::foo;
>>     }
>> }
>> 
>> 
>> javac indicates that the method reference is invalid when according to the spec the second `foo` method should be selected by the compiler. The related section of the spec can be found at section `15.13.1 Compile-Time Declaration of a Method Reference`: 
>> 
>> 
>>   ? For all other forms of method reference expression, one search for a most
>>   specific applicable method is performed. The search is as specified in
>>   ?15.12.2.2 through ?15.12.2.5, with the clarifications below.
>>   The method reference is treated as if it were an invocation with argument
>>   expressions of types P 1 , ..., P n ; the type arguments, if any, are given by the
>>   method reference expression.
>>   If the search results in an error as specified in ?15.12.2.2 through ?15.12.2.5,
>>   or if the most specific applicable method is static , there is no compile-time
>>   declaration.
>>   Otherwise, the compile-time declaration is the most specific applicable
>>   method.
>> 
>> 
>> 
>> Actually the method search is correct but later on javac is seeing that both methods are applicable and given that they have different staticness, it is making wrong assumptions down the road.
>> 
>> TIA
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3114:
> 
>> 3112:         Symbol boundSym = lookupMethod(boundEnv, env.tree.pos(),
>> 3113:                 site.tsym, boundSearchResolveContext, boundLookupHelper);
>> 3114:         boolean isStaticSelector = TreeInfo.isStaticSelector(referenceTree.expr, names);
> 
> This is a good minimal fix I believe.
> Moving forward (e.g. maybe in a separate PR) I wonder if it would be useful to make this code less general. E.g. the method reference lookup code comes from a time where we always did two lookups - but the JL:S has later been rectified, so that now we only do two lookups for unbound method references (e.g. those with static qualifier). I think that the current code is not the best in terms of achieving good JLS parity w/ a good readability, because it's trying to do too much. But of course that's an issue that was there before your fix.

thanks for the review. Yes I agree that a follow up issue should be filed to track this [1]

[1] https://bugs.openjdk.org/browse/JDK-8296948

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

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

From vromero at openjdk.org  Mon Nov 14 18:34:55 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 14 Nov 2022 18:34:55 GMT
Subject: Integrated: 8296171: Compiler incorrectly rejects code with variadic
 method references
In-Reply-To: <aUU86kwXah5s-vGc5-4aTdK1iIUm1diZoyCQXtIF10g=.867e0f45-57a3-4011-8de9-148c748b51db@github.com>
References: <aUU86kwXah5s-vGc5-4aTdK1iIUm1diZoyCQXtIF10g=.867e0f45-57a3-4011-8de9-148c748b51db@github.com>
Message-ID: <GFSdo5Bws9U952yGdI4oR_E2YGuCTcUM_SJXD07XQCQ=.e62e9517-8702-477f-821b-18894a326d42@github.com>

On Thu, 10 Nov 2022 22:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR that is syncing javac with the spec. Javac is rejecting this code:
> 
> 
> import java.util.function.*;
> interface Intf {
>     Object apply(String... args);
> }
>                 
> public class Test {
>     public static Object foo(Object o) { return "bar"; }
>     public final Object foo(Object... o) { return "foo"; }
>                 
>     public void test() {
>         Intf f = this::foo;
>     }
> }
> 
> 
> javac indicates that the method reference is invalid when according to the spec the second `foo` method should be selected by the compiler. The related section of the spec can be found at section `15.13.1 Compile-Time Declaration of a Method Reference`: 
> 
> 
>   ? For all other forms of method reference expression, one search for a most
>   specific applicable method is performed. The search is as specified in
>   ?15.12.2.2 through ?15.12.2.5, with the clarifications below.
>   The method reference is treated as if it were an invocation with argument
>   expressions of types P 1 , ..., P n ; the type arguments, if any, are given by the
>   method reference expression.
>   If the search results in an error as specified in ?15.12.2.2 through ?15.12.2.5,
>   or if the most specific applicable method is static , there is no compile-time
>   declaration.
>   Otherwise, the compile-time declaration is the most specific applicable
>   method.
> 
> 
> 
> Actually the method search is correct but later on javac is seeing that both methods are applicable and given that they have different staticness, it is making wrong assumptions down the road.
> 
> TIA

This pull request has now been integrated.

Changeset: 3eb789af
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3eb789af74231d37796a5670ffab935cabbf3b09
Stats:     36 lines in 2 files changed: 21 ins; 0 del; 15 mod

8296171: Compiler incorrectly rejects code with variadic method references

Reviewed-by: mcimadamore

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

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

From darcy at openjdk.org  Mon Nov 14 22:11:39 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 14 Nov 2022 22:11:39 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
Message-ID: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>

Update langtools tests to use JTreg's @enablePreview tag, where appropriate.

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

Commit messages:
 - JDK-8296968: Update langtools tests to use @enablePreview

Changes: https://git.openjdk.org/jdk/pull/11149/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11149&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296968
  Stats: 133 lines in 32 files changed: 15 ins; 6 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/11149.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11149/head:pull/11149

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

From duke at openjdk.org  Tue Nov 15 02:01:15 2022
From: duke at openjdk.org (Bo Zhang)
Date: Tue, 15 Nov 2022 02:01:15 GMT
Subject: RFR: 8296329: Only compare major versions in jar validator
Message-ID: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>

As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison.

This PR fixes it by only comparing major versions.

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

Commit messages:
 - 8296329: Only compare major versions in jar validator

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

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

From sundar at openjdk.org  Tue Nov 15 03:23:05 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 15 Nov 2022 03:23:05 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
In-Reply-To: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
Message-ID: <8q-gqgYAdtSt977m6UM77oyhhYbsYHUKOfOfWzK4E2Q=.e7e97922-3e7a-4fff-80ab-4b194765d7ff@github.com>

On Mon, 14 Nov 2022 22:02:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update langtools tests to use JTreg's @enablePreview tag, where appropriate.

LGTM

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

Marked as reviewed by sundar (Reviewer).

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

From jlaskey at openjdk.org  Tue Nov 15 07:03:03 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 15 Nov 2022 07:03:03 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
In-Reply-To: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
Message-ID: <QP7jKvqZdH6RR-1AqrhszfYbIdub2r5AFU2Htxw_W34=.fd83543f-a042-4019-ba6e-50b879daa28c@github.com>

On Mon, 14 Nov 2022 22:02:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update langtools tests to use JTreg's @enablePreview tag, where appropriate.

Just as a note: when using @enablePreview it is unnecessary to use @run main/othervm ... . That is the @run statement can be dropped.

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

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

From alanb at openjdk.org  Tue Nov 15 12:06:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Nov 2022 12:06:55 GMT
Subject: RFR: 8296329: jar validator doesn't account for minor class file
 version
In-Reply-To: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
Message-ID: <Du2jKJDf7mjsiIhcPWuumYMfofXsu6da8RBf1mQjxO4=.a1219207-6b19-4a09-b127-bd549653151c@github.com>

On Tue, 15 Nov 2022 01:52:14 GMT, Bo Zhang <duke at openjdk.org> wrote:

> As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison.
> 
> This PR fixes it by only comparing major versions.

See also JDK-8296119.  I don't know how common it will be for someone to publish a MR JAR containing classes compiled to use preview features. It would be a bit inconvenient for users as they would need to know to run with --enable-preview on some releases. This shouldn't impact the API compatibility checking that the jar tool does so dropping the minor version and just checking the major version might be okay.

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

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

From jlahoda at openjdk.org  Tue Nov 15 12:36:36 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Nov 2022 12:36:36 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v5]
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <8oUJ1SQebxYajLLG_OzC7VXQyOr18a7A5CD57CEP0D8=.68f9b00b-03a6-483a-ba77-97c5f7071a70@github.com>

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback - proper handling of type vars and intersection types.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10814/files
  - new: https://git.openjdk.org/jdk/pull/10814/files/5996914b..5afc6023

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

  Stats: 57 lines in 3 files changed: 43 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10814.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10814/head:pull/10814

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

From shade at openjdk.org  Tue Nov 15 13:53:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Nov 2022 13:53:23 GMT
Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class
 files in current directory [v2]
In-Reply-To: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
References: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
Message-ID: <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>

> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
> ...
> 
> $ ls
> Apan.class
> ``` 
> 
> Additional testing:
>  - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers

Aleksey Shipilev 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 three additional commits since the last revision:

 - Merge branch 'master' into JDK-8296645-javac-bench-class-files
 - Fix indenting
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11055/files
  - new: https://git.openjdk.org/jdk/pull/11055/files/d272fc6b..f472ba6e

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

  Stats: 10394 lines in 442 files changed: 4082 ins; 4461 del; 1851 mod
  Patch: https://git.openjdk.org/jdk/pull/11055.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11055/head:pull/11055

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

From shade at openjdk.org  Tue Nov 15 13:53:26 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Nov 2022 13:53:26 GMT
Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class
 files in current directory
In-Reply-To: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
References: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
Message-ID: <8WuqzHxbGXq8Jmd9dyI37CQhE20UoqScAjzNp84aIS8=.aa412fa7-f92a-4665-b945-3d6422d95a14@github.com>

On Wed, 9 Nov 2022 09:00:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
> ...
> 
> $ ls
> Apan.class
> ``` 
> 
> Additional testing:
>  - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers

Any takers? :)

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

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

From jvernee at openjdk.org  Tue Nov 15 14:21:03 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 15 Nov 2022 14:21:03 GMT
Subject: RFR: 8296329: jar validator doesn't account for minor class file
 version
In-Reply-To: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
Message-ID: <cH0t7_mc9GeIehwWIIgUK2hwL5TTU9q2IdHLxGK5auw=.6a603751-a308-40d5-92bf-0131b273ba5d@github.com>

On Tue, 15 Nov 2022 01:52:14 GMT, Bo Zhang <duke at openjdk.org> wrote:

> As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison.
> 
> This PR fixes it by only comparing major versions.

Please assign the JBS ticket to yourself as well.

test/jdk/tools/jar/multiRelease/VersionValidatorTest.java line 107:

> 105:                 { "19", "20", "", true },
> 106:                 { "20", "19", "", false },
> 107:         };

My concern with this is that this will need to be updated after each release. Looks like there are also ways to directly alter the minor version of a class file, and I recommend doing that instead. See: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/PreviewVersion.java#L51

Also, there's one more negative case missing where the base version uses 20 + preview features, and the other version is 19.

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

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

From jlahoda at openjdk.org  Tue Nov 15 14:22:03 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Nov 2022 14:22:03 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v4]
In-Reply-To: <GIAdDbJ8VGLKtiyAcjJfQG6NzoNdHq26EV5ZNJ7-qIU=.40c3f8e3-f439-4be7-ac8b-9930bbc6acfa@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <kEz4op7CaptreMhq1mWWSK55fx1AQy_3_t1EBSxVlSg=.7cd0e221-7692-4fac-b746-cc1790422715@github.com>
 <GIAdDbJ8VGLKtiyAcjJfQG6NzoNdHq26EV5ZNJ7-qIU=.40c3f8e3-f439-4be7-ac8b-9930bbc6acfa@github.com>
Message-ID: <D8MipppfjHDXGLReWV4egakDilb0MnB7YkAw2Pb9VqY=.4ffe5a82-17ca-4ab9-a5ab-c86cb0a4be9d@github.com>

On Wed, 9 Nov 2022 19:48:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Not looking for common supertype, not solving in a loop.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 659:
> 
>> 657: 
>> 658:     public Type instantiatePatternType(Type expressionType, TypeSymbol patternTypeSymbol) {
>> 659:         if (expressionType.tsym == patternTypeSymbol)
> 
> not sure we are dealing with cases where expressionType is a type variable or an intersection type, are there tests covering these cases, sorry if I'm missing something here

Good catch, thanks! Should be fixed in [5afc602](https://github.com/openjdk/jdk/pull/10814/commits/5afc60236005d5ea77984f2baeca7e928334ce3a). Thanks!

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

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

From vromero at openjdk.org  Tue Nov 15 15:59:09 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 15 Nov 2022 15:59:09 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v5]
In-Reply-To: <8oUJ1SQebxYajLLG_OzC7VXQyOr18a7A5CD57CEP0D8=.68f9b00b-03a6-483a-ba77-97c5f7071a70@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <8oUJ1SQebxYajLLG_OzC7VXQyOr18a7A5CD57CEP0D8=.68f9b00b-03a6-483a-ba77-97c5f7071a70@github.com>
Message-ID: <JHBCWRSHhG6roDYEsqEy8HSUpE08ooMlq8e91IpVlPo=.b08d10a5-537b-4447-8c83-787a57d8a9ee@github.com>

On Tue, 15 Nov 2022 12:36:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
>> 
>>  - removal of named record patterns
>>  - (preview) type inference for type test and record patterns
>>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>>  - fixing exhaustiveness of certain switches
>> 
>> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
>> 
>> For more information on the changes please see:
>>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
>> 
>> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
>> 
>> Any feedback is welcome.
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - proper handling of type vars and intersection types.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 697:

> 695:                 }
> 696:                 case TYPEVAR -> {
> 697:                     todo = todo.prepend(((TypeVar) current).getUpperBound());

here you probably want to skip all possible upper bounds that happen to be type vars using Types::skipTypeVars

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

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

From vromero at openjdk.org  Tue Nov 15 16:26:13 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 15 Nov 2022 16:26:13 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v5]
In-Reply-To: <8oUJ1SQebxYajLLG_OzC7VXQyOr18a7A5CD57CEP0D8=.68f9b00b-03a6-483a-ba77-97c5f7071a70@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
 <8oUJ1SQebxYajLLG_OzC7VXQyOr18a7A5CD57CEP0D8=.68f9b00b-03a6-483a-ba77-97c5f7071a70@github.com>
Message-ID: <325j_d_QI4IBay5IIFKTEzK8ToQzRm50NeK96hO-JwQ=.c8f971bb-72d3-4044-a37e-1dfb233801ef@github.com>

On Tue, 15 Nov 2022 12:36:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
>> 
>>  - removal of named record patterns
>>  - (preview) type inference for type test and record patterns
>>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>>  - fixing exhaustiveness of certain switches
>> 
>> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
>> 
>> For more information on the changes please see:
>>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
>> 
>> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
>> 
>> Any feedback is welcome.
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - proper handling of type vars and intersection types.

I just added a nit comment. Really nice job, very complex patch, lots of details and moving parts, very vertical also with mostly all phases affected adding to the complexity, lots of fun to reviewed it too. Well done!

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

Marked as reviewed by vromero (Reviewer).

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

From jlahoda at openjdk.org  Tue Nov 15 16:48:54 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Nov 2022 16:48:54 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v6]
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <tCnNoYxQcBGCP-h4zgNaYEm-ORgcOJiIoi34e-gVxNo=.4cd01b8e-43d8-4d1e-9e2c-215ed60d6c4f@github.com>

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Using skipTypeVars as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10814/files
  - new: https://git.openjdk.org/jdk/pull/10814/files/5afc6023..e7196a02

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

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

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

From abimpoudis at openjdk.org  Tue Nov 15 18:26:45 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 15 Nov 2022 18:26:45 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v11]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <icH-DP2jNXkinBlK6dyOygfLRytJwnXYS1qzOz-I7Z0=.a0b1de7e-f3f0-48cd-8d18-04235b743703@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Improve error message on non-exhaustive enhanced for
 - Merge branch 'JDK-8294942' into for-patterns
   
   # Conflicts:
   #	test/langtools/tools/javac/patterns/GenericRecordDeconstructionPattern.java
 - Cleanup
 - Fix parsing error in presence of lambdas
 - Fix parsing error in presence of nested patterns
 - Merge pull request #1 from lahodaj/for-patterns
   
   Fixing record patterns with primitive components in enhanced for
 - Cleanup
 - Fixing pattern/non-pattern disambiguation in presence of primitive-typed patterns.
 - Address review
 - Simplify getDeclarationKind
 - ... and 8 more: https://git.openjdk.org/jdk/compare/5afc6023...42f0cecb

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

Changes: https://git.openjdk.org/jdk/pull/10798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=10
  Stats: 744 lines in 26 files changed: 674 ins; 7 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

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

From abimpoudis at openjdk.org  Tue Nov 15 18:29:21 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 15 Nov 2022 18:29:21 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v12]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <cujlivWpcv5zpHfT8dODIyD0Fg79XKcDB2JxF1Ghags=.7c9f256a-3d32-495f-a43c-e26b2c78d541@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'JDK-8294942' into for-patterns
 - Improve error message on non-exhaustive enhanced for
 - Merge branch 'JDK-8294942' into for-patterns
   
   # Conflicts:
   #	test/langtools/tools/javac/patterns/GenericRecordDeconstructionPattern.java
 - Cleanup
 - Fix parsing error in presence of lambdas
 - Fix parsing error in presence of nested patterns
 - Merge pull request #1 from lahodaj/for-patterns
   
   Fixing record patterns with primitive components in enhanced for
 - Cleanup
 - Fixing pattern/non-pattern disambiguation in presence of primitive-typed patterns.
 - Address review
 - ... and 9 more: https://git.openjdk.org/jdk/compare/e7196a02...f37e8eaa

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

Changes: https://git.openjdk.org/jdk/pull/10798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=11
  Stats: 744 lines in 26 files changed: 674 ins; 7 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

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

From darcy at openjdk.org  Tue Nov 15 20:14:41 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 15 Nov 2022 20:14:41 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
 [v2]
In-Reply-To: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
Message-ID: <I87W2bVhRTCDf_tqLBx2zvgXNF4oQvJ829zLYiA_08I=.bdb9d666-b234-425e-8c57-a30ef7edd74f@github.com>

> Update langtools tests to use JTreg's @enablePreview tag, where appropriate.

Joe Darcy 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:

 - Update copyrights.
 - Remove unnecessary run tags.
 - Merge branch 'master' into JDK-8296968
 - JDK-8296968: Update langtools tests to use @enablePreview

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11149/files
  - new: https://git.openjdk.org/jdk/pull/11149/files/9fa41e15..b4748553

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

  Stats: 2484 lines in 67 files changed: 1416 ins; 695 del; 373 mod
  Patch: https://git.openjdk.org/jdk/pull/11149.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11149/head:pull/11149

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

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 jjg at openjdk.org  Tue Nov 15 20:54:06 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 15 Nov 2022 20:54:06 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
 [v2]
In-Reply-To: <I87W2bVhRTCDf_tqLBx2zvgXNF4oQvJ829zLYiA_08I=.bdb9d666-b234-425e-8c57-a30ef7edd74f@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
 <I87W2bVhRTCDf_tqLBx2zvgXNF4oQvJ829zLYiA_08I=.bdb9d666-b234-425e-8c57-a30ef7edd74f@github.com>
Message-ID: <6FIv1P5qCKiPV_O_kD3C7S6IBrz80Hx3k1kp0HbdSBk=.42c057d4-12dc-487a-94d8-f692b4080040@github.com>

On Tue, 15 Nov 2022 20:14:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update langtools tests to use JTreg's @enablePreview tag, where appropriate.
>
> Joe Darcy 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:
> 
>  - Update copyrights.
>  - Remove unnecessary run tags.
>  - Merge branch 'master' into JDK-8296968
>  - JDK-8296968: Update langtools tests to use @enablePreview

In various places `/othervm` has been left in place, but not clear why.

In one place, whitespace was fixed, but `@enablePreview` was not added

test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java line 32:

> 30:  * @build toolbox.JavapTask
> 31:  * @enablePreview
> 32:  * @run main/othervm Patterns

do we still need `/othervm` ?

test/langtools/tools/javac/patterns/EnumTypeChanges.java line 31:

> 29:  * @compile EnumTypeChanges.java
> 30:  * @compile EnumTypeChanges2.java
> 31:  * @run main/othervm EnumTypeChanges

Do we need `/othervm` ?

test/langtools/tools/javac/patterns/PatternErrorRecovery.java line 5:

> 3:  * @bug 8268320
> 4:  * @summary Verify user-friendly errors are reported for ill-formed pattern.
> 5:  * @compile/fail/ref=PatternErrorRecovery.out -XDrawDiagnostics -XDshould-stop.at=FLOW --enable-preview -source ${jdk.version} PatternErrorRecovery.java

why no `@enablePreview` for this test?

test/langtools/tools/javac/patterns/SealedTypeChanges.java line 31:

> 29:  * @compile SealedTypeChanges.java
> 30:  * @compile SealedTypeChanges2.java
> 31:  * @run main/othervm SealedTypeChanges

`/othervm` ?

test/langtools/tools/javac/patterns/SimpleAndGuardPattern.java line 28:

> 26:  * @enablePreview
> 27:  * @compile -doe SimpleAndGuardPattern.java
> 28:  * @run main/othervm SimpleAndGuardPattern

`/othervm` ?

test/langtools/tools/javac/patterns/SwitchErrors.out line 58:

> 56: - compiler.note.preview.filename: SwitchErrors.java, DEFAULT
> 57: - compiler.note.preview.recompile
> 58: 55 errors

Interesting glyph for no trailing newline; I've not seen that before

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

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

From jlahoda at openjdk.org  Tue Nov 15 20:57:54 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Nov 2022 20:57:54 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
 [v2]
In-Reply-To: <I87W2bVhRTCDf_tqLBx2zvgXNF4oQvJ829zLYiA_08I=.bdb9d666-b234-425e-8c57-a30ef7edd74f@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
 <I87W2bVhRTCDf_tqLBx2zvgXNF4oQvJ829zLYiA_08I=.bdb9d666-b234-425e-8c57-a30ef7edd74f@github.com>
Message-ID: <xs1-TPlxPOmHY5RrUmJGm1AxwXWiqMHr4KLdIbyVuh4=.3bb833d1-f1b6-4a73-b3db-5e1d709e2450@github.com>

On Tue, 15 Nov 2022 20:14:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update langtools tests to use JTreg's @enablePreview tag, where appropriate.
>
> Joe Darcy 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:
> 
>  - Update copyrights.
>  - Remove unnecessary run tags.
>  - Merge branch 'master' into JDK-8296968
>  - JDK-8296968: Update langtools tests to use @enablePreview

test/langtools/tools/javac/patterns/NestedPrimitiveDeconstructionPattern.java line 1:

> 1: 

Nit - maybe add the empty line behind or before the `@test` comment, just to be sure header checkers are not confused?

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

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

From darcy at openjdk.org  Tue Nov 15 23:10:02 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 15 Nov 2022 23:10:02 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
 [v2]
In-Reply-To: <6FIv1P5qCKiPV_O_kD3C7S6IBrz80Hx3k1kp0HbdSBk=.42c057d4-12dc-487a-94d8-f692b4080040@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
 <I87W2bVhRTCDf_tqLBx2zvgXNF4oQvJ829zLYiA_08I=.bdb9d666-b234-425e-8c57-a30ef7edd74f@github.com>
 <6FIv1P5qCKiPV_O_kD3C7S6IBrz80Hx3k1kp0HbdSBk=.42c057d4-12dc-487a-94d8-f692b4080040@github.com>
Message-ID: <o_r-mnYEfuAJWTt5stOlzWIyrpzmMF14qV2FrhZRhk4=.ed7cdc95-0442-4e08-8110-23f7f8478dc6@github.com>

On Tue, 15 Nov 2022 20:43:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy 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:
>> 
>>  - Update copyrights.
>>  - Remove unnecessary run tags.
>>  - Merge branch 'master' into JDK-8296968
>>  - JDK-8296968: Update langtools tests to use @enablePreview
>
> test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java line 32:
> 
>> 30:  * @build toolbox.JavapTask
>> 31:  * @enablePreview
>> 32:  * @run main/othervm Patterns
> 
> do we still need `/othervm` ?

I suppose it isn't strictly required; I assume the @enablePreview functionality handles this if needed. I'll go through and remove the /othervm options and make sure the tests still pass, etc.

> test/langtools/tools/javac/patterns/PatternErrorRecovery.java line 5:
> 
>> 3:  * @bug 8268320
>> 4:  * @summary Verify user-friendly errors are reported for ill-formed pattern.
>> 5:  * @compile/fail/ref=PatternErrorRecovery.out -XDrawDiagnostics -XDshould-stop.at=FLOW --enable-preview -source ${jdk.version} PatternErrorRecovery.java
> 
> why no `@enablePreview` for this test?

The test has multiple @compile directives, one of which does not use --enable-preview. (I didn't check closely to see if enablePreview could be toggled on/off for different sets of directives.)

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

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

From darcy at openjdk.org  Tue Nov 15 23:10:02 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 15 Nov 2022 23:10:02 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
 [v2]
In-Reply-To: <xs1-TPlxPOmHY5RrUmJGm1AxwXWiqMHr4KLdIbyVuh4=.3bb833d1-f1b6-4a73-b3db-5e1d709e2450@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
 <I87W2bVhRTCDf_tqLBx2zvgXNF4oQvJ829zLYiA_08I=.bdb9d666-b234-425e-8c57-a30ef7edd74f@github.com>
 <xs1-TPlxPOmHY5RrUmJGm1AxwXWiqMHr4KLdIbyVuh4=.3bb833d1-f1b6-4a73-b3db-5e1d709e2450@github.com>
Message-ID: <nSJY8KgMCF6HrIGwFWx0Bzk2zZVv5HhRe98gm3LH4oo=.055926c8-ed9d-472b-b853-2585279e7389@github.com>

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

>> Joe Darcy 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:
>> 
>>  - Update copyrights.
>>  - Remove unnecessary run tags.
>>  - Merge branch 'master' into JDK-8296968
>>  - JDK-8296968: Update langtools tests to use @enablePreview
>
> test/langtools/tools/javac/patterns/NestedPrimitiveDeconstructionPattern.java line 1:
> 
>> 1: 
> 
> Nit - maybe add the empty line behind or before the `@test` comment, just to be sure header checkers are not confused?

Okay -- must have accidentally added a blank line.

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

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

From darcy at openjdk.org  Tue Nov 15 23:17:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 15 Nov 2022 23:17:14 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
 [v3]
In-Reply-To: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
Message-ID: <yQR_FGPiNELTPYk3_VKOl0NZwVPbUVXXDw_J-cwX_Wk=.46c0faac-fc1e-4ddd-86c3-1893e9c2efcb@github.com>

> Update langtools tests to use JTreg's @enablePreview tag, where appropriate.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Implement review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11149/files
  - new: https://git.openjdk.org/jdk/pull/11149/files/b4748553..faac4542

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

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

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

From duke at openjdk.org  Wed Nov 16 00:44:50 2022
From: duke at openjdk.org (Bo Zhang)
Date: Wed, 16 Nov 2022 00:44:50 GMT
Subject: RFR: 8296329: jar validator doesn't account for minor class file
 version [v2]
In-Reply-To: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
Message-ID: <S0SX7RmT9RYqI6e7obS952K7LXHvFWFo9KymHpPua-Q=.cc6fa603-651d-4eed-b243-b2d569514094@github.com>

> As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison.
> 
> This PR fixes it by only comparing major versions.

Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8296329: Only compare major versions in jar validator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11153/files
  - new: https://git.openjdk.org/jdk/pull/11153/files/93ec7fb8..b293cbfe

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

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

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

From duke at openjdk.org  Wed Nov 16 00:44:53 2022
From: duke at openjdk.org (Bo Zhang)
Date: Wed, 16 Nov 2022 00:44:53 GMT
Subject: RFR: 8296329: jar validator doesn't account for minor class file
 version [v2]
In-Reply-To: <cH0t7_mc9GeIehwWIIgUK2hwL5TTU9q2IdHLxGK5auw=.6a603751-a308-40d5-92bf-0131b273ba5d@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
 <cH0t7_mc9GeIehwWIIgUK2hwL5TTU9q2IdHLxGK5auw=.6a603751-a308-40d5-92bf-0131b273ba5d@github.com>
Message-ID: <VDnZevJP492oQtMpJ6DBpRsqRAKSv32y7Po0dhKSplU=.23aaa249-42a9-4e8d-b895-cb1123f77e58@github.com>

On Tue, 15 Nov 2022 02:14:46 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8296329: Only compare major versions in jar validator
>
> test/jdk/tools/jar/multiRelease/VersionValidatorTest.java line 116:
> 
> 
> My concern with this is that this will need to be updated after each release. Looks like there are also ways to directly alter the minor version of a class file, and I recommend doing that instead. See: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/PreviewVersion.java#L51
> 
> Also, there's one more negative case missing where the base version uses 20 + preview features, and the other version is 19.

Thanks @JornVernee . I have updated the test, PTAL!

> Please assign the JBS ticket to yourself as well.

Sorry, I don't have permission to update JBS ticket.

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

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

From james.laskey at oracle.com  Wed Nov 16 12:49:27 2022
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 16 Nov 2022 12:49:27 +0000
Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
Message-ID: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>

May I get a final  (PR) review of JDK-8285932 Implementation of JEP-430 String Templates (Preview) from core-libs and compiler.

PR: https://github.com/openjdk/jdk/pull/10889


JBS: https://bugs.openjdk.org/browse/JDK-8285932
CSR: https://bugs.openjdk.org/browse/JDK-8286021
JEP: https://openjdk.org/jeps/430 https://bugs.openjdk.org/browse/JDK-8273943
SPEC: https://bugs.openjdk.org/browse/JDK-8296302

Thank you.

Cheers,

? Jim


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221116/86e44874/attachment.htm>

From jvernee at openjdk.org  Wed Nov 16 13:25:05 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 16 Nov 2022 13:25:05 GMT
Subject: RFR: 8296329: jar validator doesn't account for minor class file
 version [v2]
In-Reply-To: <S0SX7RmT9RYqI6e7obS952K7LXHvFWFo9KymHpPua-Q=.cc6fa603-651d-4eed-b243-b2d569514094@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
 <S0SX7RmT9RYqI6e7obS952K7LXHvFWFo9KymHpPua-Q=.cc6fa603-651d-4eed-b243-b2d569514094@github.com>
Message-ID: <anh3NKU6QnjZjt6-6Vbml0twjcCnMnOFUyE3Ygf7-5M=.cc31cf47-e2ef-4427-b83b-2c2674acc62b@github.com>

On Wed, 16 Nov 2022 00:44:50 GMT, Bo Zhang <duke at openjdk.org> wrote:

>> As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison.
>> 
>> This PR fixes it by only comparing major versions.
>
> Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8296329: Only compare major versions in jar validator

This looks good to me. Thanks for fixing.

I'm running a test job for tier 1-4 as well

Marked as reviewed by jvernee (Reviewer).

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

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

From ihse at openjdk.org  Wed Nov 16 13:31:09 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 13:31:09 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
Message-ID: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>

The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.

Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.

This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

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

Commit messages:
 - Update copyright year for javac server files
 - One more sjavac reference in test
 - Remove last references to sjavac
 - Move compilation of javac server to interim langtools
 - Update package in compilation as well
 - Remove or rename remaining references to sjavac
 - Change package name to javacserver
 - Clean up Options
 - Move javac server to buildtools
 - Cut last ties to javac internals...
 - ... and 4 more: https://git.openjdk.org/jdk/compare/d0fae43e...2124c86b

Changes: https://git.openjdk.org/jdk/pull/11185/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11185&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297041
  Stats: 12695 lines in 118 files changed: 1058 ins; 11574 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/11185.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11185/head:pull/11185

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

From ihse at openjdk.org  Wed Nov 16 13:35:04 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 13:35:04 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <JUaz8z0HCWb7nesWL6TwnlvTHjgxjoTTAvkbf-HxF6A=.181317f5-8b0b-4f6e-9fd9-e31da5d4b7c8@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Some more detailed explanations of the changes I've made in this patch.

* I have stripped down the original sjavac code to retain only the "javac server" part, and associated machinery. In some cases it can probably be possible to cut out even more baggage, but I had to draw the line somewhere.
* The remaining sjavac code has moved to `make/langtools/tools`, together with the other langtools buildtools.
* All sjavac jtreg tests in langtools has been removed.
* A few non-sjavac-related tests (for AppCDS) references sjavac. My interpretation is that these classes were just picked arbitrarily as a good representation, so I have modified these tests to pick other, arbitrary classes. (I'd like to have some input from AppCDS folks that I did this correctly)
* I have verified that it is still possible to build with, and without, the javac server, and that there has been no build performance regressions.
* The original implementation used a class internal to the `jdk.compiler` module to actually kick off the javac compilation. This was no longer an option when moving out of the module, but fortunately there is actually an exported class that does the same, `com.sun.tools.javac.Main`. This is however deprecated, and I realize it is not ideal to introduce a dependency to a deprecated class (but see below).

On a longer term, the current javac server tool is under scrutiny, and it will probably be rewritten into a more general "portal" to run other langtools binaries such as javadoc. It will also be transformed into using the ToolProvider API, which will solve the problem of calling the deprecated method. @sormuras is working on this.

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

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

From cstein at openjdk.org  Wed Nov 16 13:52:59 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 16 Nov 2022 13:52:59 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <8lxHo8-YXCouOHXWzh4_dzhNRsXXCztN1QETwKe7hlQ=.83d75077-4b11-4d0e-acdc-f2784fd2d634@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

LGTM

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

Marked as reviewed by cstein (Committer).

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

From erikj at openjdk.org  Wed Nov 16 14:10:04 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 16 Nov 2022 14:10:04 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Would it be worth keeping the relevant tests around in a separate test root for buildtools, given that this buildtool is rather big and complex? Or is the replacement so imminent that it's not worth the effort?

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

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

From cstein at openjdk.org  Wed Nov 16 14:14:59 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 16 Nov 2022 14:14:59 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
 <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>
Message-ID: <SAaDNvVSjC3bQD5vvTnY68j93lCkvUZjKJ6dNYyGTrg=.b12dcc25-ca84-4ea1-b7ca-7a26edb6f8a0@github.com>

On Wed, 16 Nov 2022 14:06:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Or is the replacement so imminent that it's not worth the effort?

This. I aim to replace `javacserver` with a well-tested `javatoolportal` buildtool in the coming months. An almost working POC is already available - but forcing it to go live with the JDK 20 train would not be good and replacing a minimal `javacserver` buildtool is an easier/lighter task.

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

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

From erikj at openjdk.org  Wed Nov 16 14:31:19 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 16 Nov 2022 14:31:19 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <aCNu8qcj9_G8Zkmrezs-CaLlGP5gdZIsHJ52wXm17Kk=.98e3dc97-bf03-41a6-a832-4cb85ae27f74@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Marked as reviewed by erikj (Reviewer).

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

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

From jlahoda at openjdk.org  Wed Nov 16 15:19:23 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Nov 2022 15:19:23 GMT
Subject: RFR: 8297118: Change IncompatibleClassChangeError to MatchException
 for exhaustive switch statements and switch expressions
Message-ID: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>

As per recent update of the JEP 433 specification, javac should use MatchException instead of IncompatbileClassChangeError to flag switches over enum values that were exhaustive at compile time, but no longer are exhaustive at runtime. This patch implements that change.

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

Depends on: https://git.openjdk.org/jdk/pull/10814

Commit messages:
 - Using pattern switch instead of record patterns as the feature key to determine whether MatchException should be used instead of ICCE.
 - 8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions

Changes: https://git.openjdk.org/jdk/pull/11189/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11189&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297118
  Stats: 226 lines in 4 files changed: 220 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11189.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11189/head:pull/11189

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

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 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 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 ihse at openjdk.org  Wed Nov 16 16:44:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 16:44:16 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
 <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>
Message-ID: <jSIXSNB5jlpKJ0OxG2lIf_G3O1Q0jJWbWCEVpXDWEK0=.f56d3507-e50a-47f3-aa45-138e60583284@github.com>

On Wed, 16 Nov 2022 14:06:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
>> 
>> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
>> 
>> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.
>
> Would it be worth keeping the relevant tests around in a separate test root for buildtools, given that this buildtool is rather big and complex? Or is the replacement so imminent that it's not worth the effort?

@erikj79 I'd also like to add that, at this point, the buildtool is not very complex. Right now it just listens to a port, and kicks off a javac compilation for each incoming call. It looks more complex since we've come here the long way around from a more complicated tool, and I did not spend too much time simplifying the code.

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

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

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 jjg at openjdk.org  Wed Nov 16 17:56:13 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 16 Nov 2022 17:56:13 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <l1ScWjGMeDMWfHzGC9AmHkiRtYBMbQEbz_oKFdk9vAQ=.e63fa7c0-4a12-4e01-ae30-51304fcfa465@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

make/langtools/tools/javacserver/comp/SjavacImpl.java line 36:

> 34: import java.io.PrintWriter;
> 35: import java.io.StringWriter;
> 36: import java.util.stream.Stream;

This is a build tool, so you get to set the guidelines, but generally, this is an unusual order for imports

make/langtools/tools/javacserver/comp/SjavacImpl.java line 47:

> 45:  *  deletion without notice.</b>
> 46:  */
> 47: public class SjavacImpl implements Sjavac {

... so it looks like there are still some vestiges of `Sjavac` ...

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

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

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 jjg at openjdk.org  Wed Nov 16 18:02:18 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 16 Nov 2022 18:02:18 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <wF99SFlLAleWm5XZgGEtGGZ1Pkq0AV3EcZjeqTX4V1w=.e9a198a8-ce53-4eb2-ae24-03f9f0a3e46a@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Nice cleanup.

test/langtools/ProblemList.txt line 69:

> 67: tools/sjavac/IgnoreSymbolFile.java                                              8158002    generic-all    Requires investigation
> 68: tools/sjavac/ClasspathDependencies.java                                         8158002    generic-all    Requires investigation
> 69: 

I presume these issues, 8152055, 8158002, are still open?    They should either be closed or assigned to the build team.

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

Marked as reviewed by jjg (Reviewer).

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

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: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: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 ihse at openjdk.org  Wed Nov 16 18:47:05 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 18:47:05 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <l1ScWjGMeDMWfHzGC9AmHkiRtYBMbQEbz_oKFdk9vAQ=.e63fa7c0-4a12-4e01-ae30-51304fcfa465@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
 <l1ScWjGMeDMWfHzGC9AmHkiRtYBMbQEbz_oKFdk9vAQ=.e63fa7c0-4a12-4e01-ae30-51304fcfa465@github.com>
Message-ID: <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com>

On Wed, 16 Nov 2022 17:51:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
>> 
>> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
>> 
>> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.
>
> make/langtools/tools/javacserver/comp/SjavacImpl.java line 36:
> 
>> 34: import java.io.PrintWriter;
>> 35: import java.io.StringWriter;
>> 36: import java.util.stream.Stream;
> 
> This is a build tool, so you get to set the guidelines, but generally, this is an unusual order for imports

Haha! Calling this "unusual" is the most diplomatic expression I've heard today. :-) This is just bonkers. I used a combination of "organize imports" on IntelliJ (without setting up specific rules for the project) and a brute search-and-replace. I'll fix.

> make/langtools/tools/javacserver/comp/SjavacImpl.java line 47:
> 
>> 45:  *  deletion without notice.</b>
>> 46:  */
>> 47: public class SjavacImpl implements Sjavac {
> 
> ... so it looks like there are still some vestiges of `Sjavac` ...

Yes, I did not bother renaming the files and classes in the actual javacserver implementation. I'm hoping Christian will clean this up later on anyway. I just tried to prune out the lion's share of what's not needed anymore.

> test/langtools/ProblemList.txt line 69:
> 
>> 67: tools/sjavac/IgnoreSymbolFile.java                                              8158002    generic-all    Requires investigation
>> 68: tools/sjavac/ClasspathDependencies.java                                         8158002    generic-all    Requires investigation
>> 69: 
> 
> I presume these issues, 8152055, 8158002, are still open?    They should either be closed or assigned to the build team.

No, I've closed them already, with a reference to this issue.

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

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

From ihse at openjdk.org  Wed Nov 16 18:47:06 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 18:47:06 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
 <l1ScWjGMeDMWfHzGC9AmHkiRtYBMbQEbz_oKFdk9vAQ=.e63fa7c0-4a12-4e01-ae30-51304fcfa465@github.com>
 <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com>
Message-ID: <481wI-t55703G09LJRP45YUrPga7pe8M_diFquKb_c4=.31d3ceda-d828-42ee-a8d2-1bd3f160dc65@github.com>

On Wed, 16 Nov 2022 18:42:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/langtools/ProblemList.txt line 69:
>> 
>>> 67: tools/sjavac/IgnoreSymbolFile.java                                              8158002    generic-all    Requires investigation
>>> 68: tools/sjavac/ClasspathDependencies.java                                         8158002    generic-all    Requires investigation
>>> 69: 
>> 
>> I presume these issues, 8152055, 8158002, are still open?    They should either be closed or assigned to the build team.
>
> No, I've closed them already, with a reference to this issue.

To be clear: they referred to the test code that is removed as part of this PR, so closing them is the only reasonable thing to do.

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

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

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 alex.buckley at oracle.com  Wed Nov 16 19:10:20 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 16 Nov 2022 11:10:20 -0800
Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>
References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>
Message-ID: <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>

Below, a revised description for `StringTemplate`.


// High-level opener.

`StringTemplate` is the run-time representation of a string template or 
text block template in a template expression.

[Sidebar. The JEP says "An instance of StringTemplate represents the 
string template or text block template that appears either as the 
template in a template expression, or as a standalone literal." -- the 
'standalone literal' clause should be deleted.]

// Basic concepts. No need to spell out details like immutability or 
return types here; leave them for the method specs.

In the source code of a Java program, a string template or text block 
template contains an interleaved succession of _fragment literals_ and 
_embedded expressions_. The `fragments()` method returns the fragment 
literals, and the `values()` method returns the results of evaluating 
the embedded expressions. `StringTemplate` does not provide access to 
the source code of the embedded expressions themselves; it is not a 
compile-time representation of a string template or text block template.

// Usage

`StringTemplate` is primarily used in conjunction with a template 
processor to produce a string or other useful value. Evaluation of a 
template expression first produces an instance of `StringTemplate`, 
representing the template of the template expression, and then passes 
the instance to the template processor given by the template expression.

For example, the following code contains a template expression that uses 
the template processor `RAW`, which simply yields the `StringTemplate` 
passed to it:

int x = 10;
int y = 20;
StringTemplate st = RAW."\{x} + \{y} = \{x + y}";
List<String> fragments = st.fragments();
List<Object> values    = st.values();

`fragments` will be equivalent to `List.of(" + ", " = ")` and `values` 
will be the equivalent of `List.of(10, 20, 30)`.

The following code contains a template expression with the same template 
but a different template processor:

int x = 10;
int y = 20;
String s = STR."\{x} + \{y} = \{x + y}";

When the template expression is evaluated, an instance of 
`StringTemplate` is produced that returns the same lists from 
`fragments()` and `values()` as shown above. The `STR` template 
processor uses these lists to yield an interpolated string. `s` will be 
equivalent to `"10 + 20 = 30"`.

The `interpolate()` method provides a direct way to perform string 
interpolation of a `StringTemplate`. Template processors can use the 
following code pattern:

List<String> fragments = st.fragments();
List<Object> values    = st.values();
... check or manipulate the fragments and/or values ...
String result = StringTemplate.interpolate(fragments, values);

The `process(ValidatingProcessor)` method provides an alternative to 
using string template expressions.  [Sidebar. The example line of code 
which follows, is using a template expression. I'm not sure what was 
meant here.]

String result = RAW."\{x} + \{y} = \{x + y}".process(STR);

The factory methods `of(String)` and `of(List, List)` can be used to 
construct a `StringTemplate`.

@implNote: Implementations of `StringTemplate` must minimally implement 
the methods fragments() and values(). Instances of `StringTemplate` are 
considered immutable. To preserve the semantics of string templates and 
text block templates, the list returned by `fragments()` must be one 
element larger than the list returned by `values()`.

@jls 15.8.6


Alex

On 11/16/2022 4:49 AM, Jim Laskey wrote:
> May I get a final ?(PR) review of?JDK-8285932 Implementation of JEP-430 
> String Templates (Preview) from core-libs and compiler.
> 
> PR: https://github.com/openjdk/jdk/pull/10889 
> <https://github.com/openjdk/jdk/pull/10889>
> 
> 
> JBS: https://bugs.openjdk.org/browse/JDK-8285932 
> <https://bugs.openjdk.org/browse/JDK-8285932>
> CSR: https://bugs.openjdk.org/browse/JDK-8286021 
> <https://bugs.openjdk.org/browse/JDK-8286021>
> JEP: https://openjdk.org/jeps/430 <https://openjdk.org/jeps/430> 
> https://bugs.openjdk.org/browse/JDK-8273943 
> <https://bugs.openjdk.org/browse/JDK-8273943>
> SPEC: https://bugs.openjdk.org/browse/JDK-8296302 
> <https://bugs.openjdk.org/browse/JDK-8296302>
> 
> Thank you.
> 
> Cheers,
> 
> ? Jim
> 
> 

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 vromero at openjdk.org  Wed Nov 16 19:43:02 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Nov 2022 19:43:02 GMT
Subject: RFR: 8297118: Change IncompatibleClassChangeError to
 MatchException for exhaustive switch statements and switch expressions
In-Reply-To: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
References: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
Message-ID: <abaa6lMtHmISCF1b0kt1c_sAVUpmXBjhvWL4RGdD23s=.b6a6dcb0-c212-4153-8eaf-4e8624402a5c@github.com>

On Wed, 16 Nov 2022 15:11:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As per recent update of the JEP 433 specification, javac should use MatchException instead of IncompatbileClassChangeError to flag switches over enum values that were exhaustive at compile time, but no longer are exhaustive at runtime. This patch implements that change.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From james.laskey at oracle.com  Wed Nov 16 20:06:58 2022
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 16 Nov 2022 20:06:58 +0000
Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>
References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>
 <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>
Message-ID: <F211D4E7-0F26-4BBE-B108-C9A827B6337F@oracle.com>

CSR and available docs have been changed to reflect these changes.

https://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html

Cheers,

? Jim


On Nov 16, 2022, at 3:10 PM, Alex Buckley <alex.buckley at oracle.com<mailto:alex.buckley at oracle.com>> wrote:

Below, a revised description for `StringTemplate`.


// High-level opener.

`StringTemplate` is the run-time representation of a string template or text block template in a template expression.

[Sidebar. The JEP says "An instance of StringTemplate represents the string template or text block template that appears either as the template in a template expression, or as a standalone literal." -- the 'standalone literal' clause should be deleted.]

// Basic concepts. No need to spell out details like immutability or return types here; leave them for the method specs.

In the source code of a Java program, a string template or text block template contains an interleaved succession of _fragment literals_ and _embedded expressions_. The `fragments()` method returns the fragment literals, and the `values()` method returns the results of evaluating the embedded expressions. `StringTemplate` does not provide access to the source code of the embedded expressions themselves; it is not a compile-time representation of a string template or text block template.

// Usage

`StringTemplate` is primarily used in conjunction with a template processor to produce a string or other useful value. Evaluation of a template expression first produces an instance of `StringTemplate`, representing the template of the template expression, and then passes the instance to the template processor given by the template expression.

For example, the following code contains a template expression that uses the template processor `RAW`, which simply yields the `StringTemplate` passed to it:

int x = 10;
int y = 20;
StringTemplate st = RAW."\{x} + \{y} = \{x + y}";
List<String> fragments = st.fragments();
List<Object> values    = st.values();

`fragments` will be equivalent to `List.of(" + ", " = ")` and `values` will be the equivalent of `List.of(10, 20, 30)`.

The following code contains a template expression with the same template but a different template processor:

int x = 10;
int y = 20;
String s = STR."\{x} + \{y} = \{x + y}";

When the template expression is evaluated, an instance of `StringTemplate` is produced that returns the same lists from `fragments()` and `values()` as shown above. The `STR` template processor uses these lists to yield an interpolated string. `s` will be equivalent to `"10 + 20 = 30"`.

The `interpolate()` method provides a direct way to perform string interpolation of a `StringTemplate`. Template processors can use the following code pattern:

List<String> fragments = st.fragments();
List<Object> values    = st.values();
... check or manipulate the fragments and/or values ...
String result = StringTemplate.interpolate(fragments, values);

The `process(ValidatingProcessor)` method provides an alternative to using string template expressions.  [Sidebar. The example line of code which follows, is using a template expression. I'm not sure what was meant here.]

String result = RAW."\{x} + \{y} = \{x + y}".process(STR);

The factory methods `of(String)` and `of(List, List)` can be used to construct a `StringTemplate`.

@implNote: Implementations of `StringTemplate` must minimally implement the methods fragments() and values(). Instances of `StringTemplate` are considered immutable. To preserve the semantics of string templates and text block templates, the list returned by `fragments()` must be one element larger than the list returned by `values()`.

@jls 15.8.6


Alex

On 11/16/2022 4:49 AM, Jim Laskey wrote:
May I get a final  (PR) review of JDK-8285932 Implementation of JEP-430 String Templates (Preview) from core-libs and compiler.
PR: https://github.com/openjdk/jdk/pull/10889 <https://github.com/openjdk/jdk/pull/10889>
JBS: https://bugs.openjdk.org/browse/JDK-8285932 <https://bugs.openjdk.org/browse/JDK-8285932>
CSR: https://bugs.openjdk.org/browse/JDK-8286021 <https://bugs.openjdk.org/browse/JDK-8286021>
JEP: https://openjdk.org/jeps/430 <https://openjdk.org/jeps/430> https://bugs.openjdk.org/browse/JDK-8273943 <https://bugs.openjdk.org/browse/JDK-8273943>
SPEC: https://bugs.openjdk.org/browse/JDK-8296302 <https://bugs.openjdk.org/browse/JDK-8296302>
Thank you.
Cheers,
? Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221116/ce91ad4c/attachment-0001.htm>

From vromero at openjdk.org  Wed Nov 16 20:07:42 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Nov 2022 20:07:42 GMT
Subject: RFR: 8296846: Minor cleanup of some dead code in Flow.java
In-Reply-To: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>
References: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>
Message-ID: <PmLexH2dg_iBEv8xDgSasniFFfbyfYcZDv2yyjzb52I=.e7441052-7836-4173-b931-edbd322174ef@github.com>

On Fri, 11 Nov 2022 21:40:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This patch removes two bits of dead code that I ran across.
> 
> The only interesting bit is the second patch, which removes this check:
> 
>                 /*  Ignore synthetic methods, except for translated lambda methods.
>                  */
>                 if ((tree.sym.flags() & (SYNTHETIC | LAMBDA_METHOD)) == SYNTHETIC) {
>                     return;
>                 }
> 
> because it's always preceded by this more general check:
> 
>              /*  MemberEnter can generate synthetic methods ignore them
>               */
>              if ((tree.sym.flags() & SYNTHETIC) != 0) {
>                  return;
>              }
> 
> and so can never match.
> 
> So the patch preserves the existing behavior, but the bit being removed there begs the question: was there some scenario where `tree.sym.flags()` could have both `SYNTHETIC` and `LAMBDA_METHOD` that we were supposed to be handling?
> 
> As it turns out, the `LAMBDA_METHOD` flag is only ever set by `LambdaToMethod`, but that class runs after this code (during flow analysis). So if there ever was any such scenario, it can no longer happen anyway.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

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 duke at openjdk.org  Wed Nov 16 20:27:04 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 16 Nov 2022 20:27:04 GMT
Subject: RFR: 8296846: Minor cleanup of some dead code in Flow.java
In-Reply-To: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>
References: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>
Message-ID: <_6D5-Lx0bsrvnzKv5RBQinHb5IK4ZsUiNTlvjbwYWYc=.66e2e41c-9106-4e78-9d27-56a3df238154@github.com>

On Fri, 11 Nov 2022 21:40:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This patch removes two bits of dead code that I ran across.
> 
> The only interesting bit is the second patch, which removes this check:
> 
>                 /*  Ignore synthetic methods, except for translated lambda methods.
>                  */
>                 if ((tree.sym.flags() & (SYNTHETIC | LAMBDA_METHOD)) == SYNTHETIC) {
>                     return;
>                 }
> 
> because it's always preceded by this more general check:
> 
>              /*  MemberEnter can generate synthetic methods ignore them
>               */
>              if ((tree.sym.flags() & SYNTHETIC) != 0) {
>                  return;
>              }
> 
> and so can never match.
> 
> So the patch preserves the existing behavior, but the bit being removed there begs the question: was there some scenario where `tree.sym.flags()` could have both `SYNTHETIC` and `LAMBDA_METHOD` that we were supposed to be handling?
> 
> As it turns out, the `LAMBDA_METHOD` flag is only ever set by `LambdaToMethod`, but that class runs after this code (during flow analysis). So if there ever was any such scenario, it can no longer happen anyway.

Thanks for the review.

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

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

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 duke at openjdk.org  Wed Nov 16 21:33:21 2022
From: duke at openjdk.org (duke)
Date: Wed, 16 Nov 2022 21:33:21 GMT
Subject: Withdrawn: 8292275: javac does not emit SYNTHETIC and MANDATED flags
 for parameters by default
In-Reply-To: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
Message-ID: <4ecJ3NyfeX_H1avBjdtDSd1lu8myTu50dYi_e4561n4=.004f07d4-7214-45dc-b2f6-4f2674ae2d78@github.com>

On Fri, 12 Aug 2022 19:54:59 GMT, Hannes Greule <duke at openjdk.org> wrote:

> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
> Parameter names are *not* emitted unless the `-parameter` flag is set.
> 
> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
> 
> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
> I also had to update some tests as they got a new constant pool entry.
> 
> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
> Please let me know if you want tests for specific appearances of synthetic parameters.

This pull request has been closed without being integrated.

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

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

From alex.buckley at oracle.com  Wed Nov 16 21:41:28 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 16 Nov 2022 13:41:28 -0800
Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <F211D4E7-0F26-4BBE-B108-C9A827B6337F@oracle.com>
References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>
 <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>
 <F211D4E7-0F26-4BBE-B108-C9A827B6337F@oracle.com>
Message-ID: <06693be8-6ae0-34c1-8fb3-b02b472dc030@oracle.com>

The first line says StringTemplates, should say StringTemplate.

The paragraph about the `process(ValidatingProcessor)` method is 
confusing -- it's not an alternative to using template expressions if 
the example needs to show a template expression before invoking 
`process`. I think you mean to say something about supporting deferred 
evaluation of a template expression, in conjunction with the RAW processor?

The implNote: "Libraries may produce StringTemplate instances as long as 
they conform to the requirements of this interface." -- there's no need 
to say this if the requirements (e.g. for immutability) are spelled out 
in the normative specs (keep reading).

The immutability of lists returned from `fragments()` and `values()` is 
mentioned both in the user-level spec ("Returns this StringTemplate's 
immutable list ...") and in the implementer-level spec ("The list 
returned is immutable."). That's a recipe for confusion. Better to drop 
the @implNote and commit to immutability as core to the method's result:

---
Returns a list of the fragment literals for this StringTemplate.

The fragment literals are the character sequences preceding each of the 
embedded expressions in source code, plus the character sequence 
following the last embedded expression. Such character sequences may be 
zero-length if an embedded expression appears at the beginning or end of 
a template, or if two embedded expressions are directly adjacent in a 
template.

The list is immutable.  [I'm not sure why this is important, but OK.]
---

The spec of the `interpolate` method has a stray dot and an example 
which calls `interpolation()`. Please rename `string` to `result`. Say: 
@return A string denoting the interpolation of this `StringTemplate`'s 
fragments and values.

Alex

On 11/16/2022 12:06 PM, Jim Laskey wrote:
> CSR and available docs have been changed to reflect these changes.
> 
> https://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html <https://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html>
> 
> Cheers,
> 
> ? Jim
> 
> 
>> On Nov 16, 2022, at 3:10 PM, Alex Buckley <alex.buckley at oracle.com 
>> <mailto:alex.buckley at oracle.com>> wrote:
>>
>> Below, a revised description for `StringTemplate`.
>>
>>
>> // High-level opener.
>>
>> `StringTemplate` is the run-time representation of a string template 
>> or text block template in a template expression.
>>
>> [Sidebar. The JEP says "An instance of StringTemplate represents the 
>> string template or text block template that appears either as the 
>> template in a template expression, or as a standalone literal." -- the 
>> 'standalone literal' clause should be deleted.]
>>
>> // Basic concepts. No need to spell out details like immutability or 
>> return types here; leave them for the method specs.
>>
>> In the source code of a Java program, a string template or text block 
>> template contains an interleaved succession of _fragment literals_ and 
>> _embedded expressions_. The `fragments()` method returns the fragment 
>> literals, and the `values()` method returns the results of evaluating 
>> the embedded expressions. `StringTemplate` does not provide access to 
>> the source code of the embedded expressions themselves; it is not a 
>> compile-time representation of a string template or text block template.
>>
>> // Usage
>>
>> `StringTemplate` is primarily used in conjunction with a template 
>> processor to produce a string or other useful value. Evaluation of a 
>> template expression first produces an instance of `StringTemplate`, 
>> representing the template of the template expression, and then passes 
>> the instance to the template processor given by the template expression.
>>
>> For example, the following code contains a template expression that 
>> uses the template processor `RAW`, which simply yields the 
>> `StringTemplate` passed to it:
>>
>> int x = 10;
>> int y = 20;
>> StringTemplate st = RAW."\{x} + \{y} = \{x + y}";
>> List<String> fragments = st.fragments();
>> List<Object> values ???= st.values();
>>
>> `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` 
>> will be the equivalent of `List.of(10, 20, 30)`.
>>
>> The following code contains a template expression with the same 
>> template but a different template processor:
>>
>> int x = 10;
>> int y = 20;
>> String s = STR."\{x} + \{y} = \{x + y}";
>>
>> When the template expression is evaluated, an instance of 
>> `StringTemplate` is produced that returns the same lists from 
>> `fragments()` and `values()` as shown above. The `STR` template 
>> processor uses these lists to yield an interpolated string. `s` will 
>> be equivalent to `"10 + 20 = 30"`.
>>
>> The `interpolate()` method provides a direct way to perform string 
>> interpolation of a `StringTemplate`. Template processors can use the 
>> following code pattern:
>>
>> List<String> fragments = st.fragments();
>> List<Object> values ???= st.values();
>> ... check or manipulate the fragments and/or values ...
>> String result = StringTemplate.interpolate(fragments, values);
>>
>> The `process(ValidatingProcessor)` method provides an alternative to 
>> using string template expressions. ?[Sidebar. The example line of code 
>> which follows, is using a template expression. I'm not sure what was 
>> meant here.]
>>
>> String result = RAW."\{x} + \{y} = \{x + y}".process(STR);
>>
>> The factory methods `of(String)` and `of(List, List)` can be used to 
>> construct a `StringTemplate`.
>>
>> @implNote: Implementations of `StringTemplate` must minimally 
>> implement the methods fragments() and values(). Instances of 
>> `StringTemplate` are considered immutable. To preserve the semantics 
>> of string templates and text block templates, the list returned by 
>> `fragments()` must be one element larger than the list returned by 
>> `values()`.
>>
>> @jls 15.8.6
>>
>>
>> Alex
>>
>> On 11/16/2022 4:49 AM, Jim Laskey wrote:
>>> May I get a final ?(PR) review of?JDK-8285932 Implementation of 
>>> JEP-430 String Templates (Preview) from core-libs and compiler.
>>> PR: https://github.com/openjdk/jdk/pull/10889 
>>> <https://github.com/openjdk/jdk/pull/10889> 
>>> <https://github.com/openjdk/jdk/pull/10889 
>>> <https://github.com/openjdk/jdk/pull/10889>>
>>> JBS: https://bugs.openjdk.org/browse/JDK-8285932 
>>> <https://bugs.openjdk.org/browse/JDK-8285932> 
>>> <https://bugs.openjdk.org/browse/JDK-8285932 
>>> <https://bugs.openjdk.org/browse/JDK-8285932>>
>>> CSR: https://bugs.openjdk.org/browse/JDK-8286021 
>>> <https://bugs.openjdk.org/browse/JDK-8286021> 
>>> <https://bugs.openjdk.org/browse/JDK-8286021 
>>> <https://bugs.openjdk.org/browse/JDK-8286021>>
>>> JEP: https://openjdk.org/jeps/430 <https://openjdk.org/jeps/430> 
>>> <https://openjdk.org/jeps/430 <https://openjdk.org/jeps/430>> 
>>> https://bugs.openjdk.org/browse/JDK-8273943 
>>> <https://bugs.openjdk.org/browse/JDK-8273943> 
>>> <https://bugs.openjdk.org/browse/JDK-8273943 
>>> <https://bugs.openjdk.org/browse/JDK-8273943>>
>>> SPEC: https://bugs.openjdk.org/browse/JDK-8296302 
>>> <https://bugs.openjdk.org/browse/JDK-8296302> 
>>> <https://bugs.openjdk.org/browse/JDK-8296302 
>>> <https://bugs.openjdk.org/browse/JDK-8296302>>
>>> Thank you.
>>> Cheers,
>>> ? Jim
> 

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 jjg at openjdk.org  Wed Nov 16 22:57:30 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 16 Nov 2022 22:57:30 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
 [v3]
In-Reply-To: <yQR_FGPiNELTPYk3_VKOl0NZwVPbUVXXDw_J-cwX_Wk=.46c0faac-fc1e-4ddd-86c3-1893e9c2efcb@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
 <yQR_FGPiNELTPYk3_VKOl0NZwVPbUVXXDw_J-cwX_Wk=.46c0faac-fc1e-4ddd-86c3-1893e9c2efcb@github.com>
Message-ID: <qGQ5CYVnfJZsCVtj7YNvRnWrn4W6xd2wzkDTuzlKsv4=.eaa09daf-86d5-40f4-886b-40c2cee2abe4@github.com>

On Tue, 15 Nov 2022 23:17:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update langtools tests to use JTreg's @enablePreview tag, where appropriate.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

Nice cleanup

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

Marked as reviewed by jjg (Reviewer).

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

From jjg at openjdk.org  Wed Nov 16 22:57:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 16 Nov 2022 22:57:32 GMT
Subject: RFR: JDK-8296968: Update langtools tests to use @enablePreview
 [v2]
In-Reply-To: <o_r-mnYEfuAJWTt5stOlzWIyrpzmMF14qV2FrhZRhk4=.ed7cdc95-0442-4e08-8110-23f7f8478dc6@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
 <I87W2bVhRTCDf_tqLBx2zvgXNF4oQvJ829zLYiA_08I=.bdb9d666-b234-425e-8c57-a30ef7edd74f@github.com>
 <6FIv1P5qCKiPV_O_kD3C7S6IBrz80Hx3k1kp0HbdSBk=.42c057d4-12dc-487a-94d8-f692b4080040@github.com>
 <o_r-mnYEfuAJWTt5stOlzWIyrpzmMF14qV2FrhZRhk4=.ed7cdc95-0442-4e08-8110-23f7f8478dc6@github.com>
Message-ID: <M2HqZUlTFSFM4bTz3wwyJv4qzQtk7dd5zyT8rchWGXQ=.a0f664d6-0659-4690-a134-042ac3d0840f@github.com>

On Tue, 15 Nov 2022 23:05:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/PatternErrorRecovery.java line 5:
>> 
>>> 3:  * @bug 8268320
>>> 4:  * @summary Verify user-friendly errors are reported for ill-formed pattern.
>>> 5:  * @compile/fail/ref=PatternErrorRecovery.out -XDrawDiagnostics -XDshould-stop.at=FLOW --enable-preview -source ${jdk.version} PatternErrorRecovery.java
>> 
>> why no `@enablePreview` for this test?
>
> The test has multiple @compile directives, one of which does not use --enable-preview. (I didn't check closely to see if enablePreview could be toggled on/off for different sets of directives.)

You can't toggle. Thanks for the note.

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

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

From john.r.rose at oracle.com  Wed Nov 16 23:41:16 2022
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 16 Nov 2022 15:41:16 -0800
Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>
References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>
 <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>
Message-ID: <DE8DAED1-F786-4427-8552-91F662170F52@oracle.com>

On 16 Nov 2022, at 11:10, Alex Buckley wrote:

> ?
> For example, the following code contains a template expression that 
> uses the template processor `RAW`, which simply yields the 
> `StringTemplate` passed to it:
>
> int x = 10;
> int y = 20;
> StringTemplate st = RAW."\{x} + \{y} = \{x + y}";
> List<String> fragments = st.fragments();
> List<Object> values    = st.values();
>
> `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` 
> will be the equivalent of `List.of(10, 20, 30)`.
> ?
> To preserve the semantics of string templates and text block 
> templates, the list returned by `fragments()` must be one element 
> larger than the list returned by `values()`.

And yet, in the example given above, the list of fragments `List.of(" + 
", " = ")` is one element *smaller* than the list of values `List.of(10, 
20, 30)`.  The example is wrong.  It?s worth a note in the doc that if 
an interpolated expression begins and/or ends the template, there will 
be a zero length fragment at the beginning or end of the fragments list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221116/1e466640/attachment-0001.htm>

From alex.buckley at oracle.com  Wed Nov 16 23:59:15 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 16 Nov 2022 15:59:15 -0800
Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <DE8DAED1-F786-4427-8552-91F662170F52@oracle.com>
References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>
 <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>
 <DE8DAED1-F786-4427-8552-91F662170F52@oracle.com>
Message-ID: <c47ce71a-91df-fb05-e253-8b8d7659e95b@oracle.com>

On 11/16/2022 3:41 PM, John Rose wrote:
> And yet, in the example given above, the list of fragments |List.of(" + 
> ", " = ")| is one element /smaller/ than the list of values |List.of(10, 
> 20, 30)|. The example is wrong. It?s worth a note in the doc that if an 
> interpolated expression begins and/or ends the template, there will be a 
> zero length fragment at the beginning or end of the fragments list.

Jim already caught and fixed the list examples in the latest javadoc, 
which says:

---
fragments will be equivalent to List.of("", " + ", " = ", "") and values 
will be the equivalent of List.of(10, 20, 30).
---

I agree that the javadoc should flag the existence of zero-length 
fragments; my later mail offered text for `fragments()` and `values()` 
which did so; that offering should be treated as merely the first draft 
of how to explain the reification of a source-code template.

Alex

From darcy at openjdk.org  Thu Nov 17 00:54:25 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Nov 2022 00:54:25 GMT
Subject: Integrated: JDK-8296968: Update langtools tests to use @enablePreview
In-Reply-To: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
References: <oQNTh43lxbrxYSro5mvB7paAEtMitMQV35_-jSmhFRA=.a3aeeed6-db9e-44e0-a80c-885b511559cc@github.com>
Message-ID: <AsABeVaKrb5uKyzqGlQ-gE59gKDxjCDEC1g6wqBuup8=.b6f663ed-aabf-45bd-bca0-f2ce3b81c492@github.com>

On Mon, 14 Nov 2022 22:02:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update langtools tests to use JTreg's @enablePreview tag, where appropriate.

This pull request has now been integrated.

Changeset: e2269fd2
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e2269fd2ca64347fcfa2275d7dd530428afa75f2
Stats:     133 lines in 32 files changed: 13 ins; 20 del; 100 mod

8296968: Update langtools tests to use @enablePreview

Reviewed-by: sundar, jjg

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

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

From darcy at openjdk.org  Thu Nov 17 00:57:57 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Nov 2022 00:57:57 GMT
Subject: RFR: 8297118: Change IncompatibleClassChangeError to
 MatchException for exhaustive switch statements and switch expressions
In-Reply-To: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
References: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
Message-ID: <vNBgPvclInCijqyqg1YBmcER2vj_wWsl2TaMdSVtbBI=.71d4417d-d76f-411f-88c5-10729d20fe36@github.com>

On Wed, 16 Nov 2022 15:11:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As per recent update of the JEP 433 specification, javac should use MatchException instead of IncompatbileClassChangeError to flag switches over enum values that were exhaustive at compile time, but no longer are exhaustive at runtime. This patch implements that change.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 131:

> 129:             options.getBoolean("optimizeOuterThis", false);
> 130:         disableProtectedAccessors = options.isSet("disableProtectedAccessors");
> 131:         Source source = Source.instance(context);

Does this merit addition of a feature-enum constant in the usual way?

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

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

From jwaters at openjdk.org  Thu Nov 17 04:59:23 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 04:59:23 GMT
Subject: RFR: 8296846: Minor cleanup of some dead code in Flow.java
In-Reply-To: <_6D5-Lx0bsrvnzKv5RBQinHb5IK4ZsUiNTlvjbwYWYc=.66e2e41c-9106-4e78-9d27-56a3df238154@github.com>
References: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>
 <_6D5-Lx0bsrvnzKv5RBQinHb5IK4ZsUiNTlvjbwYWYc=.66e2e41c-9106-4e78-9d27-56a3df238154@github.com>
Message-ID: <8GVJHO2YPHRifGmykvwc-bEN62yV_ZN22LVyXNQrf00=.2056050c-f869-46b6-9d9a-8a1c7f1c043e@github.com>

On Wed, 16 Nov 2022 20:24:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch removes two bits of dead code that I ran across.
>> 
>> The only interesting bit is the second patch, which removes this check:
>> 
>>                 /*  Ignore synthetic methods, except for translated lambda methods.
>>                  */
>>                 if ((tree.sym.flags() & (SYNTHETIC | LAMBDA_METHOD)) == SYNTHETIC) {
>>                     return;
>>                 }
>> 
>> because it's always preceded by this more general check:
>> 
>>              /*  MemberEnter can generate synthetic methods ignore them
>>               */
>>              if ((tree.sym.flags() & SYNTHETIC) != 0) {
>>                  return;
>>              }
>> 
>> and so can never match.
>> 
>> So the patch preserves the existing behavior, but the bit being removed there begs the question: was there some scenario where `tree.sym.flags()` could have both `SYNTHETIC` and `LAMBDA_METHOD` that we were supposed to be handling?
>> 
>> As it turns out, the `LAMBDA_METHOD` flag is only ever set by `LambdaToMethod`, but that class runs after this code (during flow analysis). So if there ever was any such scenario, it can no longer happen anyway.
>
> Thanks for the review.

Guess my committer status promotion hasn't been fully registered with the integration system yet, sorry @archiecobbs

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

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

From ihse at openjdk.org  Thu Nov 17 09:21:53 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Nov 2022 09:21:53 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac [v2]
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <S69lflCZsor47KYO4-j5W7L1bC8wxHCqSsgV9oUxIiI=.921650ac-a4fa-46be-846d-483323511ad2@github.com>

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

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

 - Fix weird imports
 - Update comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11185/files
  - new: https://git.openjdk.org/jdk/pull/11185/files/2124c86b..8ff38b78

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

  Stats: 77 lines in 15 files changed: 45 ins; 30 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11185.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11185/head:pull/11185

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

From ihse at openjdk.org  Thu Nov 17 09:23:35 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Nov 2022 09:23:35 GMT
Subject: Integrated: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <QWQArKF8QOhyEqhqmMxOp4Wu6BAldOHpEffOPzqYYuo=.cc2559f2-87f2-4aa4-99a8-6313aad6c66a@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

This pull request has now been integrated.

Changeset: 4527dc67
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4527dc67be6d238dcecd98c2aa05cbf0b8077e59
Stats:     12695 lines in 118 files changed: 1060 ins; 11561 del; 74 mod

8297041: Remove the last remnants of sjavac

Reviewed-by: cstein, erikj, jjg

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

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

From vromero at openjdk.org  Thu Nov 17 11:00:21 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Nov 2022 11:00:21 GMT
Subject: RFR: 8296846: Minor cleanup of some dead code in Flow.java
In-Reply-To: <_6D5-Lx0bsrvnzKv5RBQinHb5IK4ZsUiNTlvjbwYWYc=.66e2e41c-9106-4e78-9d27-56a3df238154@github.com>
References: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>
 <_6D5-Lx0bsrvnzKv5RBQinHb5IK4ZsUiNTlvjbwYWYc=.66e2e41c-9106-4e78-9d27-56a3df238154@github.com>
Message-ID: <IG-ejxDELrOHWyeCb-f3kg89CgfNRoOUnup3beuS4es=.80d504a4-39ca-4ad1-be16-f1f2bb5d6528@github.com>

On Wed, 16 Nov 2022 20:24:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch removes two bits of dead code that I ran across.
>> 
>> The only interesting bit is the second patch, which removes this check:
>> 
>>                 /*  Ignore synthetic methods, except for translated lambda methods.
>>                  */
>>                 if ((tree.sym.flags() & (SYNTHETIC | LAMBDA_METHOD)) == SYNTHETIC) {
>>                     return;
>>                 }
>> 
>> because it's always preceded by this more general check:
>> 
>>              /*  MemberEnter can generate synthetic methods ignore them
>>               */
>>              if ((tree.sym.flags() & SYNTHETIC) != 0) {
>>                  return;
>>              }
>> 
>> and so can never match.
>> 
>> So the patch preserves the existing behavior, but the bit being removed there begs the question: was there some scenario where `tree.sym.flags()` could have both `SYNTHETIC` and `LAMBDA_METHOD` that we were supposed to be handling?
>> 
>> As it turns out, the `LAMBDA_METHOD` flag is only ever set by `LambdaToMethod`, but that class runs after this code (during flow analysis). So if there ever was any such scenario, it can no longer happen anyway.
>
> Thanks for the review.

Hi, @archiecobbs this test: test/jdk/javax/swing/JFileChooser/8046391/bug8046391.java is failing with your patch on Windows. I will rerun the tests just to double check

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

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

From james.laskey at oracle.com  Thu Nov 17 12:56:24 2022
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 17 Nov 2022 12:56:24 +0000
Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <06693be8-6ae0-34c1-8fb3-b02b472dc030@oracle.com>
References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>
 <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>
 <F211D4E7-0F26-4BBE-B108-C9A827B6337F@oracle.com>
 <06693be8-6ae0-34c1-8fb3-b02b472dc030@oracle.com>
Message-ID: <5984E564-B175-45D9-A4A2-9AB52AF8E610@oracle.com>

Updating.

> On Nov 16, 2022, at 5:41 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> The first line says StringTemplates, should say StringTemplate.
> 
> The paragraph about the `process(ValidatingProcessor)` method is confusing -- it's not an alternative to using template expressions if the example needs to show a template expression before invoking `process`. I think you mean to say something about supporting deferred evaluation of a template expression, in conjunction with the RAW processor?
> 
> The implNote: "Libraries may produce StringTemplate instances as long as they conform to the requirements of this interface." -- there's no need to say this if the requirements (e.g. for immutability) are spelled out in the normative specs (keep reading).
> 
> The immutability of lists returned from `fragments()` and `values()` is mentioned both in the user-level spec ("Returns this StringTemplate's immutable list ...") and in the implementer-level spec ("The list returned is immutable."). That's a recipe for confusion. Better to drop the @implNote and commit to immutability as core to the method's result:
> 
> ---
> Returns a list of the fragment literals for this StringTemplate.
> 
> The fragment literals are the character sequences preceding each of the embedded expressions in source code, plus the character sequence following the last embedded expression. Such character sequences may be zero-length if an embedded expression appears at the beginning or end of a template, or if two embedded expressions are directly adjacent in a template.
> 
> The list is immutable.  [I'm not sure why this is important, but OK.]
> ---
> 
> The spec of the `interpolate` method has a stray dot and an example which calls `interpolation()`. Please rename `string` to `result`. Say: @return A string denoting the interpolation of this `StringTemplate`'s fragments and values.
> 
> Alex
> 
> On 11/16/2022 12:06 PM, Jim Laskey wrote:
>> CSR and available docs have been changed to reflect these changes.
>> https://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html <https://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html>
>> Cheers,
>> ? Jim
>>> On Nov 16, 2022, at 3:10 PM, Alex Buckley <alex.buckley at oracle.com <mailto:alex.buckley at oracle.com>> wrote:
>>> 
>>> Below, a revised description for `StringTemplate`.
>>> 
>>> 
>>> // High-level opener.
>>> 
>>> `StringTemplate` is the run-time representation of a string template or text block template in a template expression.
>>> 
>>> [Sidebar. The JEP says "An instance of StringTemplate represents the string template or text block template that appears either as the template in a template expression, or as a standalone literal." -- the 'standalone literal' clause should be deleted.]
>>> 
>>> // Basic concepts. No need to spell out details like immutability or return types here; leave them for the method specs.
>>> 
>>> In the source code of a Java program, a string template or text block template contains an interleaved succession of _fragment literals_ and _embedded expressions_. The `fragments()` method returns the fragment literals, and the `values()` method returns the results of evaluating the embedded expressions. `StringTemplate` does not provide access to the source code of the embedded expressions themselves; it is not a compile-time representation of a string template or text block template.
>>> 
>>> // Usage
>>> 
>>> `StringTemplate` is primarily used in conjunction with a template processor to produce a string or other useful value. Evaluation of a template expression first produces an instance of `StringTemplate`, representing the template of the template expression, and then passes the instance to the template processor given by the template expression.
>>> 
>>> For example, the following code contains a template expression that uses the template processor `RAW`, which simply yields the `StringTemplate` passed to it:
>>> 
>>> int x = 10;
>>> int y = 20;
>>> StringTemplate st = RAW."\{x} + \{y} = \{x + y}";
>>> List<String> fragments = st.fragments();
>>> List<Object> values    = st.values();
>>> 
>>> `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` will be the equivalent of `List.of(10, 20, 30)`.
>>> 
>>> The following code contains a template expression with the same template but a different template processor:
>>> 
>>> int x = 10;
>>> int y = 20;
>>> String s = STR."\{x} + \{y} = \{x + y}";
>>> 
>>> When the template expression is evaluated, an instance of `StringTemplate` is produced that returns the same lists from `fragments()` and `values()` as shown above. The `STR` template processor uses these lists to yield an interpolated string. `s` will be equivalent to `"10 + 20 = 30"`.
>>> 
>>> The `interpolate()` method provides a direct way to perform string interpolation of a `StringTemplate`. Template processors can use the following code pattern:
>>> 
>>> List<String> fragments = st.fragments();
>>> List<Object> values    = st.values();
>>> ... check or manipulate the fragments and/or values ...
>>> String result = StringTemplate.interpolate(fragments, values);
>>> 
>>> The `process(ValidatingProcessor)` method provides an alternative to using string template expressions.  [Sidebar. The example line of code which follows, is using a template expression. I'm not sure what was meant here.]
>>> 
>>> String result = RAW."\{x} + \{y} = \{x + y}".process(STR);
>>> 
>>> The factory methods `of(String)` and `of(List, List)` can be used to construct a `StringTemplate`.
>>> 
>>> @implNote: Implementations of `StringTemplate` must minimally implement the methods fragments() and values(). Instances of `StringTemplate` are considered immutable. To preserve the semantics of string templates and text block templates, the list returned by `fragments()` must be one element larger than the list returned by `values()`.
>>> 
>>> @jls 15.8.6
>>> 
>>> 
>>> Alex
>>> 
>>> On 11/16/2022 4:49 AM, Jim Laskey wrote:
>>>> May I get a final  (PR) review of JDK-8285932 Implementation of JEP-430 String Templates (Preview) from core-libs and compiler.
>>>> PR: https://github.com/openjdk/jdk/pull/10889 <https://github.com/openjdk/jdk/pull/10889> <https://github.com/openjdk/jdk/pull/10889 <https://github.com/openjdk/jdk/pull/10889>>
>>>> JBS: https://bugs.openjdk.org/browse/JDK-8285932 <https://bugs.openjdk.org/browse/JDK-8285932> <https://bugs.openjdk.org/browse/JDK-8285932 <https://bugs.openjdk.org/browse/JDK-8285932>>
>>>> CSR: https://bugs.openjdk.org/browse/JDK-8286021 <https://bugs.openjdk.org/browse/JDK-8286021> <https://bugs.openjdk.org/browse/JDK-8286021 <https://bugs.openjdk.org/browse/JDK-8286021>>
>>>> JEP: https://openjdk.org/jeps/430 <https://openjdk.org/jeps/430> <https://openjdk.org/jeps/430 <https://openjdk.org/jeps/430>> https://bugs.openjdk.org/browse/JDK-8273943 <https://bugs.openjdk.org/browse/JDK-8273943> <https://bugs.openjdk.org/browse/JDK-8273943 <https://bugs.openjdk.org/browse/JDK-8273943>>
>>>> SPEC: https://bugs.openjdk.org/browse/JDK-8296302 <https://bugs.openjdk.org/browse/JDK-8296302> <https://bugs.openjdk.org/browse/JDK-8296302 <https://bugs.openjdk.org/browse/JDK-8296302>>
>>>> Thank you.
>>>> Cheers,
>>>> ? Jim


From james.laskey at oracle.com  Thu Nov 17 12:57:17 2022
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 17 Nov 2022 12:57:17 +0000
Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <DE8DAED1-F786-4427-8552-91F662170F52@oracle.com>
References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com>
 <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com>
 <DE8DAED1-F786-4427-8552-91F662170F52@oracle.com>
Message-ID: <2670B559-05D1-49B5-AAA0-166CE7A4190C@oracle.com>

I corrected before inserting.

On Nov 16, 2022, at 7:41 PM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote:


On 16 Nov 2022, at 11:10, Alex Buckley wrote:

?
For example, the following code contains a template expression that uses the template processor `RAW`, which simply yields the `StringTemplate` passed to it:

int x = 10;
int y = 20;
StringTemplate st = RAW."\{x} + \{y} = \{x + y}";
List<String> fragments = st.fragments();
List<Object> values = st.values();

`fragments` will be equivalent to `List.of(" + ", " = ")` and `values` will be the equivalent of `List.of(10, 20, 30)`.
?
To preserve the semantics of string templates and text block templates, the list returned by `fragments()` must be one element larger than the list returned by `values()`.

And yet, in the example given above, the list of fragments List.of(" + ", " = ") is one element smaller than the list of values List.of(10, 20, 30). The example is wrong. It?s worth a note in the doc that if an interpolated expression begins and/or ends the template, there will be a zero length fragment at the beginning or end of the fragments list.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221117/60bff773/attachment.htm>

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 jlahoda at openjdk.org  Thu Nov 17 13:43:26 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 17 Nov 2022 13:43:26 GMT
Subject: RFR: 8297118: Change IncompatibleClassChangeError to
 MatchException for exhaustive switch statements and switch expressions
In-Reply-To: <vNBgPvclInCijqyqg1YBmcER2vj_wWsl2TaMdSVtbBI=.71d4417d-d76f-411f-88c5-10729d20fe36@github.com>
References: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
 <vNBgPvclInCijqyqg1YBmcER2vj_wWsl2TaMdSVtbBI=.71d4417d-d76f-411f-88c5-10729d20fe36@github.com>
Message-ID: <r2wnlcQ7df0dTijVzbnFqDxwocNHvS4olPS9q4-OlEE=.6c21b722-cd6e-41d2-a045-00b2f3c0b5a9@github.com>

On Thu, 17 Nov 2022 00:54:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> As per recent update of the JEP 433 specification, javac should use MatchException instead of IncompatbileClassChangeError to flag switches over enum values that were exhaustive at compile time, but no longer are exhaustive at runtime. This patch implements that change.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 131:
> 
>> 129:             options.getBoolean("optimizeOuterThis", false);
>> 130:         disableProtectedAccessors = options.isSet("disableProtectedAccessors");
>> 131:         Source source = Source.instance(context);
> 
> Does this merit addition of a feature-enum constant in the usual way?

I was thinking of this, but opted to reuse the existing feature constant, as this is not a separate user-selectable feature, but rather part of the patterns in switch feature. Also, each feature enum constant must a diagnostic set, and as it would never be part of any diagnostic, it would be impossible to test.

It is possible to have a separate constant if desired, though.

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

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

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 vromero at openjdk.org  Thu Nov 17 15:41:23 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Nov 2022 15:41:23 GMT
Subject: RFR: 8297118: Change IncompatibleClassChangeError to
 MatchException for exhaustive switch statements and switch expressions
In-Reply-To: <r2wnlcQ7df0dTijVzbnFqDxwocNHvS4olPS9q4-OlEE=.6c21b722-cd6e-41d2-a045-00b2f3c0b5a9@github.com>
References: <8ML1Ug8-AR0-D-c3rUlYUxQpqVllyP-BecJZvvkXX9w=.f41891ec-b5dc-418f-9234-7e36d291632a@github.com>
 <vNBgPvclInCijqyqg1YBmcER2vj_wWsl2TaMdSVtbBI=.71d4417d-d76f-411f-88c5-10729d20fe36@github.com>
 <r2wnlcQ7df0dTijVzbnFqDxwocNHvS4olPS9q4-OlEE=.6c21b722-cd6e-41d2-a045-00b2f3c0b5a9@github.com>
Message-ID: <V3A5ObTGsDjdwmAiXJpwsT-vlBHcbRBO4VMm8mxEuis=.2cf7302b-7041-4c2b-9de2-c9a4e14eedb4@github.com>

On Thu, 17 Nov 2022 13:40:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 131:
>> 
>>> 129:             options.getBoolean("optimizeOuterThis", false);
>>> 130:         disableProtectedAccessors = options.isSet("disableProtectedAccessors");
>>> 131:         Source source = Source.instance(context);
>> 
>> Does this merit addition of a feature-enum constant in the usual way?
>
> I was thinking of this, but opted to reuse the existing feature constant, as this is not a separate user-selectable feature, but rather part of the patterns in switch feature. Also, each feature enum constant must a diagnostic set, and as it would never be part of any diagnostic, it would be impossible to test.
> 
> It is possible to have a separate constant if desired, though.

I'm OK with the current approach

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

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

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 duke at openjdk.org  Thu Nov 17 19:10:54 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:10:54 GMT
Subject: RFR: 8193904: Uninitialized final field access and qualified this
 [v2]
In-Reply-To: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
Message-ID: <2p11BvHQ9v3hUxKasK-izVlTleuJkdxSLIJ7HVu0sH4=.857f50c9-6eea-4239-aa6f-1c300aa0b497@github.com>

> If a class `MyClass` has a blank final field `foo` that has not yet been assigned, the compiler prevents you from accessing it via the expressions `foo` or `this.foo`. However, it does not prevent you from accessing it via the expression `MyClass.this.foo`.
> 
> Here's a simple example:
> 
> class QualifiedThis {
>     final int foo;
>     QualifiedThis() {
>         System.err.println(QualifiedThis.this.foo);   // should get an error here
>         this.foo = 42;
>     }
> }
> 
> 
> This patch fixes that omission.
> 
> I couldn't find an existing method that answers the question "Is this AST tree a reference to the current instance of the class I'm now compiling?" so I wrote a new one `TreeInfo.isThisReference()`.
> 
> The question itself is a little tricky. For example, `this` alone always is, but `Foo.this` is if the class being compiled is `Foo` or any supertype of `Foo`, *except* when `Foo` is an outer class containing the class being compiled, when it instead refers to that outer instance.
> 
> On the other hand, `Foo.super` (which, unlike `Foo.this`, can only be used to invoke a method), when `Foo` is a type and not a variable, refers to the current 'this' instance when the class being compiled is `Foo` or any supertype of `Foo`, period.

Archie L. Cobbs 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 three additional commits since the last revision:

 - Replace any remaining uses of TreeInfo.isThisQualifier().
   
   Bug 8193904 describes how "A.this.foo" is not detected as an early reference to
   the uninitialized final variable "foo". There is also a flip-side to this bug,
   which is that "A.this.foo = ..." is not accepted as a valid assignment to the
   uninitialized final variable "foo". This commit fixes that part of the bug.
   
   Also do some minor refactoring for clarity.
 - Merge branch 'master' into JDK-8193904
 - Disallow early access to final fields via qualified 'this'.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10956/files
  - new: https://git.openjdk.org/jdk/pull/10956/files/7dfff1a4..bbb800a9

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

  Stats: 89224 lines in 1450 files changed: 30188 ins; 52786 del; 6250 mod
  Patch: https://git.openjdk.org/jdk/pull/10956.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10956/head:pull/10956

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

From duke at openjdk.org  Thu Nov 17 19:10:59 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:10:59 GMT
Subject: RFR: 8043251: Bogus javac error: required: no arguments,
 found: no arguments [v2]
In-Reply-To: <ttyl1QzWEJGynqGR_A3okSQE1raIc9Z_k964MzAx1Fw=.30f27c1a-ed84-4876-88b2-9bc58f2ad3f4@github.com>
References: <ttyl1QzWEJGynqGR_A3okSQE1raIc9Z_k964MzAx1Fw=.30f27c1a-ed84-4876-88b2-9bc58f2ad3f4@github.com>
Message-ID: <bloQnoxGgoYjCi756qXF-04sPgs2CRoQzm9ol1a0Hk8=.514795a1-776d-44ca-a94c-3559090796b2@github.com>

> We have an error message `compiler.err.cant.apply.symbol` for cases where a method invocation doesn't resolve. It shows the "required" parameters and the "found" parameters, plus a further description of the problem.
> 
> This message being used inappropriately when the problem is actually due to explicitly passed method type parameters instead of regular method parameters.
> 
> For example, if you do this:
> 
> Function<String, String> f = Function.<String, String>identity();
> 
> the error reported is this:
> 
> error: method identity in interface Function<T,R> cannot be applied to given types;
>     Function<String, String> f = Function.<String, String>identity();
>                                          ^
>   required: no arguments
>   found:    no arguments
>   reason: wrong number of type arguments; required 1
>   where T,R are type-variables:
>     T extends Object declared in interface Function
>     R extends Object declared in interface Function
> 
> The real error here is `wrong number of type arguments; required 1`, but the `compiler.err.cant.apply.symbol` error message that assumes the problem is with the regular parameters, which it displays. The result is the appearance of the useless and confusing `required` and `found` lines.
> 
> This patch creates an alternate version of that error message (`compiler.err.cant.apply.symbol.noargs`) that omits the `required` and `found` lines, and makes the compiler use this alternate message when the error is due to type parameters (specifically, when the underlying error is "wrong number of type arguments" or "explicit type argument X does not conform to declared bound(s)").
> 
> This improves the error for example above to this:
> 
> error: method identity in interface Function<T,R> cannot be applied to given types;
>     Function<String, String> f = Function.<String, String>identity();
>                                          ^
>   reason: wrong number of type arguments; required 1
>   where T,R are type-variables:
>     T extends Object declared in interface Function
>     R extends Object declared in interface Function
> 1 error

Archie L. Cobbs 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8043251
 - Fix confusing error message regarding wrong number of type parameters.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10799/files
  - new: https://git.openjdk.org/jdk/pull/10799/files/d497ed13..2615d24b

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

  Stats: 232655 lines in 2313 files changed: 113387 ins; 82545 del; 36723 mod
  Patch: https://git.openjdk.org/jdk/pull/10799.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10799/head:pull/10799

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

From duke at openjdk.org  Thu Nov 17 19:11:03 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:11:03 GMT
Subject: RFR: 8184444: The compiler error
 "variable not initialized in the default constructor" is not apt in case of
 static final variables [v2]
In-Reply-To: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
References: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
Message-ID: <kma982o4buot6_vVMO59n-62-sE3D0e67XnESp3IOX0=.f41647e2-fade-4dfc-9569-8be876d07e7a@github.com>

> This bug causes this class:
> 
> class StaticFinalInit {
>     static final int foo;
> }
> 
> to fail to compile as it should but with a confusing error message:
> 
> StaticFinalInit.java:2: error: variable foo not initialized in the default constructor
>     static final int foo;
>                      ^
> 
> In another variant, if there is a non-default constructor:
> 
> class StaticFinalInit {
>     static final int foo;
>     StaticFinalInit() { }
> }
> 
> the compiler gives the right error message but shows the wrong source code location:
> 
> StaticFinalInit.java:3: error: variable foo might not have been initialized
>     StaticFinalInit() { }
>                         ^
> 
> This behavior is a side-effect of the roundabout way we currently check for definite assignment of static final fields.
> 
> When recursing into a class definition in `Flow.AssignAnalyzer`, we first initialize DA/DU analysis for static fields, and then recurse on the static initializers to pick up static field assignments. However, we don't then check for definite assignment of static final fields. Instead, we proceed with the analysis, and then later, whenever we visit an initial constructor (i.e., one that invokes `super()` instead of `this()`), we check for definite assignment of both static final and instance final fields.
> 
> This works because every class has at least one initial constructor, so static fields will always get checked at least once. Of course, it also results in doing some redundant work (if there are multiple initial constructors) and it generates the wrong error message and/or source code position.
> 
> This patch adds a check for definite assignment of static final fields (with the appropriate error message) after we recurse on the static initializers, and it filters out static fields from the checks being done in initial constructors. It also updates a couple of existing unit tests that were expecting the wrong source code position.
> 
> The two examples above now both generate this error message:
> 
> StaticFinalInit.java:2: error: variable foo might not have been initialized
>     static final int foo;
>                      ^

Archie L. Cobbs 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8184444
 - Fix confusing error message for uninitialized static final fields.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10896/files
  - new: https://git.openjdk.org/jdk/pull/10896/files/b50dc40a..1e6594d2

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

  Stats: 89121 lines in 1445 files changed: 30128 ins; 52755 del; 6238 mod
  Patch: https://git.openjdk.org/jdk/pull/10896.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10896/head:pull/10896

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

From duke at openjdk.org  Thu Nov 17 19:11:06 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:11:06 GMT
Subject: RFR: 8200610: Compiling fails with
 java.nio.file.ReadOnlyFileSystemException [v2]
In-Reply-To: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
References: <SHA0wdbS8kB3JkH13ni--c2_Ph0b3lt7LxddzhYOncU=.60122a51-b50d-4dcf-8766-93d2592e014e@github.com>
Message-ID: <FgpEG0__pgxvRdyuB8HnjGXSgNNzAcLsvM3LKcyf9_M=.2457f9a8-21e9-45f2-937e-dd1d504190f9@github.com>

> In `JavaCompiler`, when trying to write a class file, if an `IOException`s is thrown, instead of crashing, we report a normal error" `error while writing [file]: ...`.
> 
> However there are some I/O errors that can generate `RuntimeException`s not caught by this logic. So instead these errors cause a compiler crash.
> 
> An example is given in JDK-8200610, where the compiler tries to write into a ZIP file system and a `java.nio.file.ReadOnlyFileSystemException` is thrown.
> 
> This patch adds that exception and a couple of others which (in my estimation) could reasonably be expected to be thrown in various obscure cases involving alternative file systems: `FileSystemNotFoundException` and `InvalidPathException`.
> 
> Any suggestions on what the most appropriate list of exception types to include here are appreciated.

Archie L. Cobbs 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8200610
 - Catch and report some java.nio.file.* exceptions along with IOException.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10818/files
  - new: https://git.openjdk.org/jdk/pull/10818/files/8114d08e..ecdd8b55

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

  Stats: 232655 lines in 2313 files changed: 113387 ins; 82545 del; 36723 mod
  Patch: https://git.openjdk.org/jdk/pull/10818.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10818/head:pull/10818

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

From duke at openjdk.org  Thu Nov 17 19:11:11 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:11:11 GMT
Subject: RFR: 8064931: tools/javac/scope/DupUnsharedTest.java needs to be
 updated to add the bug id [v2]
In-Reply-To: <ZsHhpuB7WpP8v5heIy3W4y-s3ixm7dLP6Ums5U2zGb4=.b35f60e9-a2f9-49e4-bd0a-7c7a350a0f83@github.com>
References: <ZsHhpuB7WpP8v5heIy3W4y-s3ixm7dLP6Ums5U2zGb4=.b35f60e9-a2f9-49e4-bd0a-7c7a350a0f83@github.com>
Message-ID: <kB7ovPJy_u4EWw-fhievBgaLJxExs0RF3HFnhUj-6cc=.df238445-e15c-4067-a10f-52bdd210cde2@github.com>

> 8064931: tools/javac/scope/DupUnsharedTest.java needs to be updated to add the bug id

Archie L. Cobbs 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8064931
 - Add missing @bug tag to unit test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10777/files
  - new: https://git.openjdk.org/jdk/pull/10777/files/9fd23703..46d87b73

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

  Stats: 233587 lines in 2373 files changed: 114137 ins; 82571 del; 36879 mod
  Patch: https://git.openjdk.org/jdk/pull/10777.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10777/head:pull/10777

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

From duke at openjdk.org  Thu Nov 17 19:11:14 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:11:14 GMT
Subject: RFR: 8155259: Suspicious buffer allocation in
 com.sun.tools.javac.file.BaseFileManager [v2]
In-Reply-To: <a0jq1KJR3VGCmm-vEnlUcHw_CYNlHmJNJd6tlgceEUs=.07787b9f-b04f-4d33-9b46-f0c0420b8398@github.com>
References: <a0jq1KJR3VGCmm-vEnlUcHw_CYNlHmJNJd6tlgceEUs=.07787b9f-b04f-4d33-9b46-f0c0420b8398@github.com>
Message-ID: <h8eLLAo5jXsAwKc6-jCNpva3lEu3yCsWMMEDkQ32EXE=.7ed16262-b40c-48bb-8693-f93d4517f574@github.com>

> JDK-8155259 notes that in `BaseFileManager` this code:
> 
> ByteBuffer.allocate(capacity + capacity>>1)
> 
> is actually equivalent (assuming no overflow) to:
> 
> ByteBuffer.allocate(capacity)
> 
> because in Java the `+` operator has higher precedence than the `>>` operator.
> 
> In the bug it is suggested that this be changed to reflect the presumed original intent to over-allocate by 50%, i.e.:
> 
> ByteBuffer.allocate(capacity + (capacity>>1))
> 
> however, this patch is more conservative in that it leaves the existing behavior alone and instead just simplifies it to:
> 
> ByteBuffer.allocate(capacity)
> 
> allowing us to at least resolve JDK-8155259.

Archie L. Cobbs 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8155259
 - 8155259: Suspicious buffer allocation in com.sun.tools.javac.file.BaseFileManager

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10803/files
  - new: https://git.openjdk.org/jdk/pull/10803/files/b3f88603..4dfeba3b

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

  Stats: 232655 lines in 2313 files changed: 113387 ins; 82545 del; 36723 mod
  Patch: https://git.openjdk.org/jdk/pull/10803.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10803/head:pull/10803

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

From duke at openjdk.org  Thu Nov 17 19:11:18 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:11:18 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v3]
In-Reply-To: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
Message-ID: <X0oiPC_N0W-ipAJksCkgeAbL_mSdqvjNOKkRoK-PkK0=.9045fbe9-8739-4ce5-8a9d-effc122db075@github.com>

> This patch is both a minor optimization and a fix for JDK-7176515.
> 
> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
> 
> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
> 
> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
> 
> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
> 
> This results in two improvements:
> * It avoids building the lookup table for switches on self
> * It fixes JDK-7176515 as stated
> 
> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
> 
> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
> 
> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.

Archie L. Cobbs 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 three additional commits since the last revision:

 - Merge branch 'master' into JDK-7176515
 - Give test a better name and don't rely on assertions being enabled.
 - Skip enum switch lookup tables when compiling the enum switch class.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10797/files
  - new: https://git.openjdk.org/jdk/pull/10797/files/8cd5b49c..b5da18df

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

  Stats: 232655 lines in 2313 files changed: 113387 ins; 82545 del; 36723 mod
  Patch: https://git.openjdk.org/jdk/pull/10797.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10797/head:pull/10797

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

From duke at openjdk.org  Thu Nov 17 19:11:29 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:11:29 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v11]
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <foofblsc7TB2dP5Jj0aU7wG08KvFSqujXJj0Rr-bkR8=.a9d7ba1b-3f71-4b56-8e34-029fb1e97e1b@github.com>

> (Description revised)
> 
> JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime:
> 
>>  _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._
> 
> This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body.

Archie L. Cobbs 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 ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8043179
 - Update failed test output line numbers after removing @author tags.
 - Remove @author tags from tests.
 - Add a unit test verifying a change in reported error for final variables.
   
   Before this change, compiling this class:
   
       class LambdaMutateFinalVar {
           LambdaMutateFinalVar() {
               final String x;
               Runnable r1 = () -> x = "not ok";
               x = "ok";
           }
       }
   
   would report this error:
   
     local variables referenced from a lambda expression must be final or effectively final
   
   That error is not really appropriate; after all, the variable IS final. The
   real problem is that it can't be assigned from within the lambda because it
   can't be assumed to be DU.
   
   After this change, this error is reported instead:
   
     variable x might already have been assigned
 - Fix previously incorrect logic and update unit tests.
 - Fix @author in test to match github username per instructions.
 - Move unit test into a more appropriate subdirectory.
 - Use /nodynamiccopyright/ for "golden file" test per instructions.
 - 8043179: Lambda expression can mutate final field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10381/files
  - new: https://git.openjdk.org/jdk/pull/10381/files/0081d190..1e38c30f

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

  Stats: 243197 lines in 3049 files changed: 117420 ins; 86685 del; 39092 mod
  Patch: https://git.openjdk.org/jdk/pull/10381.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381

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

From duke at openjdk.org  Thu Nov 17 19:11:25 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:11:25 GMT
Subject: RFR: 8219810: javac throws NullPointerException [v2]
In-Reply-To: <PNAXdaGgA5nNPEm4fb-jWSoTuZHtAqfSvtaiCyZ5vzM=.cfb759ae-f8d9-4fe8-8c19-35251b3a586e@github.com>
References: <PNAXdaGgA5nNPEm4fb-jWSoTuZHtAqfSvtaiCyZ5vzM=.cfb759ae-f8d9-4fe8-8c19-35251b3a586e@github.com>
Message-ID: <7zparHfFb_VqJAO3dUHq-zx85G6i79FBEogM_ncd4qg=.2d27b84d-3ec9-4e17-b13c-4f2743ce230d@github.com>

> JVMS 4.5 states:
> 
>> Each field of a class may have at most one of its ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set (JLS ?8.3.1), and must not have both its ACC_FINAL and ACC_VOLATILE flags set (JLS ?8.3.1.4).
> 
> and JVMS 4.6 states:
> 
>> Each method of a class may have at most one of its ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set (JLS ?8.4.3). 
> 
> However, when reading class files these illegal combinations are not actually checked, and this can lead to compiler crashes as in the bug example.
> 
> This patch adds checks for these illegal combinations.

Archie L. Cobbs 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 three additional commits since the last revision:

 - Merge branch 'master' into JDK-8219810
 - Also disallow field access flags from having both FINAL and VOLATILE.
 - Detect invalid access flag combinations for fields and methods in classfiles.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10826/files
  - new: https://git.openjdk.org/jdk/pull/10826/files/5d7fa500..b2667d90

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

  Stats: 218112 lines in 2202 files changed: 101760 ins; 81071 del; 35281 mod
  Patch: https://git.openjdk.org/jdk/pull/10826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10826/head:pull/10826

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

From duke at openjdk.org  Thu Nov 17 19:15:31 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 17 Nov 2022 19:15:31 GMT
Subject: RFR: 8163229: test test/tools/javac/CaptureInSubtype.java has a
 main method that is never executed Export [v2]
In-Reply-To: <43_ndNUnEtQisakxCPVIqZGvizAmLUd2cKQ60X_3HRs=.05235cae-336f-4cb4-9e2a-88c4ba5753b8@github.com>
References: <43_ndNUnEtQisakxCPVIqZGvizAmLUd2cKQ60X_3HRs=.05235cae-336f-4cb4-9e2a-88c4ba5753b8@github.com>
Message-ID: <hBaHZlw-nfe5Ll2uf8-ETAmBhUudkFEMbC9dQS0eEro=.e20d5242-6c96-4c36-9271-ecf9e7efb5fa@github.com>

> This PR deals with some housekeeping relating to compiler unit tests.
> 
> JDK-8163229 points out that there are several tests that have a `public static void main(String[])` method, but because the test expects to fail during compilation, the test is never actually run, and so these `main` methods are just clutter that can be removed.
> 
> However, there are also some tests where the test is never run, but the `main()` method generates one or more of the expected compilation errors. Obviously we need to keep those, but they don't need to be declared as `public static void main(String[])` which is misleading. So instead we rename these methods to `meth()`, and also we remove the `String[]` parameter when it's not needed by the test.

Archie L. Cobbs 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8163229
 - Rename or remove "main()" methods in tests that never actually run.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10992/files
  - new: https://git.openjdk.org/jdk/pull/10992/files/0dd3380c..ee28175a

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

  Stats: 36592 lines in 956 files changed: 13797 ins; 18971 del; 3824 mod
  Patch: https://git.openjdk.org/jdk/pull/10992.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10992/head:pull/10992

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

From vromero at openjdk.org  Thu Nov 17 20:48:32 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Nov 2022 20:48:32 GMT
Subject: RFR: 8295447: NullPointerException with invalid pattern matching
 construct in constructor call
In-Reply-To: <mlgMQGuS8W7aqLo81LOV3WOXRO-w3q4kjRSt33HU4C0=.4762ab98-a5b8-48a7-93e2-ad1543a9d213@github.com>
References: <mlgMQGuS8W7aqLo81LOV3WOXRO-w3q4kjRSt33HU4C0=.4762ab98-a5b8-48a7-93e2-ad1543a9d213@github.com>
Message-ID: <WYO85qobBqn2AsQ_MweUePJxHKdCz-vct7AyNf7pdMg=.7e6873fe-7bf2-4472-9567-796af185c4b1@github.com>

On Thu, 20 Oct 2022 11:30:41 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In the examples below:
> 
> 
> int i = (o instanceof Bar(int x))? 0 : 1;
> meth(i);
> 
> 
> 
> meth((o instanceof Bar(int x))? 0 : 1);
> 
> 
> the error `DeconstructionPatternOnlyRecords` was reported only on the first case but the compiler was still crashing in both occasions. `NoType` was passed and `checkCastablePattern` was letting an erroneous type to pass through the subtyping checks. The proposed fix addresses that in `checkCastablePattern`.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

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 jjg at openjdk.org  Fri Nov 18 00:03:42 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 18 Nov 2022 00:03:42 GMT
Subject: RFR: JDK-8245246: Deprecate -profile option in javac
Message-ID: <m-wmDE50V70Cq2k84rsHbLrpGm2lkWIRQVVbX-jWWzU=.5a0cc95b-f682-4977-ab8a-4d07e056e115@github.com>

Please review a trivial update for javac, to note that the `-profile` option is deprecated and may be removed.

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

Commit messages:
 - JDK-8245246: Deprecate -profile option in javac

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

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

From darcy at openjdk.org  Fri Nov 18 01:28:18 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 18 Nov 2022 01:28:18 GMT
Subject: RFR: JDK-8245246: Deprecate -profile option in javac
In-Reply-To: <m-wmDE50V70Cq2k84rsHbLrpGm2lkWIRQVVbX-jWWzU=.5a0cc95b-f682-4977-ab8a-4d07e056e115@github.com>
References: <m-wmDE50V70Cq2k84rsHbLrpGm2lkWIRQVVbX-jWWzU=.5a0cc95b-f682-4977-ab8a-4d07e056e115@github.com>
Message-ID: <rJh4mmKTztp76rOJYHFD0RPJk0sEAKeWh_K7mzXui0Q=.2e324022-9daf-44a2-914b-28d67273afb4@github.com>

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

> Please review a trivial update for javac, to note that the `-profile` option is deprecated and may be removed.

Marked as reviewed by darcy (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 129:

> 127:     <release>
> 128: javac.opt.arg.release=\
> 129:     <release>

I assume this is just an incidental cleanup.

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

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

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 jjg at openjdk.org  Fri Nov 18 03:06:20 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 18 Nov 2022 03:06:20 GMT
Subject: RFR: JDK-8245246: Deprecate -profile option in javac
In-Reply-To: <rJh4mmKTztp76rOJYHFD0RPJk0sEAKeWh_K7mzXui0Q=.2e324022-9daf-44a2-914b-28d67273afb4@github.com>
References: <m-wmDE50V70Cq2k84rsHbLrpGm2lkWIRQVVbX-jWWzU=.5a0cc95b-f682-4977-ab8a-4d07e056e115@github.com>
 <rJh4mmKTztp76rOJYHFD0RPJk0sEAKeWh_K7mzXui0Q=.2e324022-9daf-44a2-914b-28d67273afb4@github.com>
Message-ID: <w7bUImtUujkoMOoS_RA8fkwPVTeWxE-9awIonTISY0I=.4aea3114-fedd-4b9c-b7d1-ee49f00e7ad9@github.com>

On Fri, 18 Nov 2022 01:26:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review a trivial update for javac, to note that the `-profile` option is deprecated and may be removed.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 129:
> 
>> 127:     <release>
>> 128: javac.opt.arg.release=\
>> 129:     <release>
> 
> I assume this is just an incidental cleanup.

Yes, note it was a duplicated resource, that was flagged by the IDE.

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

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

From duke at openjdk.org  Fri Nov 18 04:29:17 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 18 Nov 2022 04:29:17 GMT
Subject: Integrated: 8296846: Minor cleanup of some dead code in Flow.java
In-Reply-To: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>
References: <Z1Jcs8gCr_gbSiagBiXRp850N_qm2nlyz9088JZLx5U=.d7aaf349-e911-43fe-a338-ca72d651db72@github.com>
Message-ID: <ycXEqfWYqVBB8uGL1gwm65IjwPI7ITzJNoT9lk_rNZI=.284c8231-fd69-41fc-ab29-abc66f898429@github.com>

On Fri, 11 Nov 2022 21:40:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This patch removes two bits of dead code that I ran across.
> 
> The only interesting bit is the second patch, which removes this check:
> 
>                 /*  Ignore synthetic methods, except for translated lambda methods.
>                  */
>                 if ((tree.sym.flags() & (SYNTHETIC | LAMBDA_METHOD)) == SYNTHETIC) {
>                     return;
>                 }
> 
> because it's always preceded by this more general check:
> 
>              /*  MemberEnter can generate synthetic methods ignore them
>               */
>              if ((tree.sym.flags() & SYNTHETIC) != 0) {
>                  return;
>              }
> 
> and so can never match.
> 
> So the patch preserves the existing behavior, but the bit being removed there begs the question: was there some scenario where `tree.sym.flags()` could have both `SYNTHETIC` and `LAMBDA_METHOD` that we were supposed to be handling?
> 
> As it turns out, the `LAMBDA_METHOD` flag is only ever set by `LambdaToMethod`, but that class runs after this code (during flow analysis). So if there ever was any such scenario, it can no longer happen anyway.

This pull request has now been integrated.

Changeset: 2f063b86
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f063b86fba785bce03f9f9b3092046be188b84c
Stats:     13 lines in 1 file changed: 0 ins; 13 del; 0 mod

8296846: Minor cleanup of some dead code in Flow.java

Reviewed-by: vromero

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

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

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 archie.cobbs at gmail.com  Fri Nov 18 15:49:44 2022
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 18 Nov 2022 09:49:44 -0600
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
Message-ID: <CANSoFxuXWStZv+2oBFo3WO5mvFava6+9ESxS3RUk-PjHp2koEw@mail.gmail.com>

On Wed, Nov 2, 2022 at 3:18 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Wed, Nov 2, 2022 at 2:47 PM Alex Buckley <alex.buckley at oracle.com>
> wrote:
>
>> JLS ch.16 is specific that only `foo` and `this.foo` cause an error. See
>> the definition of "access" in the opening paragraphs of the chapter.
>>
>
> Thanks for pointing that out, which I forgot to do. The JLS language is:
>
> An access to its value consists of the simple name of the variable (or,
> for a field, the simple name of the field qualified by this) occurring
> anywhere in an expression except as the left-hand operand of the simple
> assignment operator =
>
> In theory one could argue that MyClass.this.foo is also an example of
> "the simple name of the field qualified by this" - just look at the
> latter part, no?
>
> Regardless, it looks like there needs to be a spec change... right? I'm
> assuming we'd rather do that than continue to allow the current behavior.
>

Any further thoughts on this one?

It seems to me that regardless of what you think the right answer is, the
current situation could use some improvement.

Here's how the compiler currently behaves:

// This class compiles without error
public class Example1 {
    final int foo;
    public Example1() {
        System.err.println(Example1.this.foo);  // no error generated here
        this.foo = 42;
    }
}

// This class fails to compile
public class Example2 {
    private final int foo;
    public Example2() {
        Example2.this.foo = 42; // "cannot assign a value to final variable
foo"
    }
}

My thoughts...

   - If the compiler is not following the spec, then we need to fix the
   compiler
   - If the compiler is following the spec, then shouldn't the spec be
   corrected so that it treats Foo.this and this the same way?

In another email Alex said:

> DU/DA analysis is about whether names have bindings. `x.foo` and `new
>
C().foo` and `m().foo` are expressions, not names, so we don't attempt
> the analysis on them. As Jan points out [1], access via expressions is
> hard to track. `this.foo` is an expression, but a very easy one, so we
> treat it like the name `foo` and do the analysis. `A.B.C.this.foo` is an
> expression with a qualified-this subexpression and now you need a bunch
> of analysis to figure out whether it means the same as the name `foo`.


I don't see that you "need a bunch of analysis". The required analysis is
already being done, for example, when handling expressions that could refer
to outer 'this' instances. We're not talking about arbitrarily complex
expressions. The only two options are 'this' or 'this' qualified by a type
name.

Apologies if I'm missing something, just trying to understand what the
issue is here.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221118/7e9ede4c/attachment-0001.htm>

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 jjg at openjdk.org  Fri Nov 18 23:47:24 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 18 Nov 2022 23:47:24 GMT
Subject: Integrated: JDK-8245246: Deprecate -profile option in javac
In-Reply-To: <m-wmDE50V70Cq2k84rsHbLrpGm2lkWIRQVVbX-jWWzU=.5a0cc95b-f682-4977-ab8a-4d07e056e115@github.com>
References: <m-wmDE50V70Cq2k84rsHbLrpGm2lkWIRQVVbX-jWWzU=.5a0cc95b-f682-4977-ab8a-4d07e056e115@github.com>
Message-ID: <nMYwwGw8gpdibOIBdpxyEyxgi-XJvc30jtoQ-dfg6Ts=.c50caf9a-4189-4cd2-a712-14a2cbcf330d@github.com>

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

> Please review a trivial update for javac, to note that the `-profile` option is deprecated and may be removed.

This pull request has now been integrated.

Changeset: dcb83754
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dcb83754ceeb771b64c32d5b721b313032068732
Stats:     4 lines in 1 file changed: 1 ins; 2 del; 1 mod

8245246: Deprecate -profile option in javac

Reviewed-by: darcy

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

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

From sadayapalam at openjdk.org  Sat Nov 19 04:04:18 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Sat, 19 Nov 2022 04:04:18 GMT
Subject: RFR: 8059632: Method reference compilation uses incorrect
 qualifying type [v5]
In-Reply-To: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
References: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
Message-ID: <w2t5iK3-3IWLou43mb9XdaIBPiNqx8wkZThzC_xU4gM=.2716fafb-7a87-4833-9d12-46b90a652580@github.com>

> Align with JLS 13.1 (the qualifying class or interface of the method invocation) by
>     referring to the type of the receiver rather than the type of the declaring 
>     class/interface in the bootstrap attribute

Srikanth Adayapalam 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 seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8059632
 - Incorporate review feedback from Andrey Turbanov (Thanks!)
 - Merge branch 'master' into JDK-8059632
 - Merge branch 'master' into JDK-8059632
 - Merge branch 'master' into JDK-8059632
 - Fix whitespace problem
 - 8059632: Method reference compilation uses incorrect qualifying type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10809/files
  - new: https://git.openjdk.org/jdk/pull/10809/files/11f6c08e..2a54bee9

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

  Stats: 37020 lines in 931 files changed: 14165 ins; 18903 del; 3952 mod
  Patch: https://git.openjdk.org/jdk/pull/10809.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10809/head:pull/10809

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

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 sadayapalam at openjdk.org  Mon Nov 21 03:02:33 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Mon, 21 Nov 2022 03:02:33 GMT
Subject: RFR: 8059632: Method reference compilation uses incorrect
 qualifying type [v6]
In-Reply-To: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
References: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
Message-ID: <Mvt4xFeYBcPxSk-OYXzKmYksYS88kzjDOoi02OFPTdw=.f1d08fbf-3fdf-46a9-89a2-36e51a5e7d72@github.com>

> Align with JLS 13.1 (the qualifying class or interface of the method invocation) by
>     referring to the type of the receiver rather than the type of the declaring 
>     class/interface in the bootstrap attribute

Srikanth Adayapalam 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 eight additional commits since the last revision:

 - Merge branch 'master' into JDK-8059632
 - Merge branch 'master' into JDK-8059632
 - Incorporate review feedback from Andrey Turbanov (Thanks!)
 - Merge branch 'master' into JDK-8059632
 - Merge branch 'master' into JDK-8059632
 - Merge branch 'master' into JDK-8059632
 - Fix whitespace problem
 - 8059632: Method reference compilation uses incorrect qualifying type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10809/files
  - new: https://git.openjdk.org/jdk/pull/10809/files/2a54bee9..19b75d2d

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

  Stats: 557 lines in 24 files changed: 332 ins; 92 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/10809.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10809/head:pull/10809

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

From sadayapalam at openjdk.org  Mon Nov 21 03:05:50 2022
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Mon, 21 Nov 2022 03:05:50 GMT
Subject: Integrated: 8059632: Method reference compilation uses incorrect
 qualifying type
In-Reply-To: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
References: <JQQxkgZAHlteHLfIjKTXvrmntDaLeTQAedhyW-yLC1o=.e5f7189e-ac70-4d42-8a32-4de340e31fa0@github.com>
Message-ID: <YjDy_CEDcUSD2a8x_E2mKjLi-8hfBM2PxbGXP8_9wa4=.2e8d2157-dfb4-44a9-b644-6d89797e915e@github.com>

On Fri, 21 Oct 2022 09:31:11 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Align with JLS 13.1 (the qualifying class or interface of the method invocation) by
>     referring to the type of the receiver rather than the type of the declaring 
>     class/interface in the bootstrap attribute

This pull request has now been integrated.

Changeset: 544e3172
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/544e31722528d12fae0eb19271f85886680801a6
Stats:     376 lines in 6 files changed: 325 ins; 47 del; 4 mod

8059632: Method reference compilation uses incorrect qualifying type

Reviewed-by: mcimadamore

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

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

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"
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 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 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: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 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 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 cstein at openjdk.org  Mon Nov 21 20:26:37 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 21 Nov 2022 20:26:37 GMT
Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a
 reusable module for other JDK tools
Message-ID: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>

This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules:
- `jdk.jartool`
- `jdk.jlink`
- `jdk.jpackage`

Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21)  the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module.

- [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule".
- [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule".
- [x] Remove `CommandLine.java` from `jdk.jartool` module
- [x] Remove `CommandLine.java` from `jdk.jlink` module
- [x] Remove `CommandLine.java` from `jdk.jpackage` module
- [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ...

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

Commit messages:
 - 8236919: Delete superseded `CommandLine` classes
 - 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools

Changes: https://git.openjdk.org/jdk/pull/11272/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11272&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8236919
  Stats: 514 lines in 10 files changed: 35 ins; 472 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11272.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11272/head:pull/11272

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

From jjg at openjdk.org  Mon Nov 21 22:02:01 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 21 Nov 2022 22:02:01 GMT
Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a
 reusable module for other JDK tools
In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
Message-ID: <qyq43jLpSP-HRnffhZrY_-0b6AI_V4tlKUTPLLtQTRE=.8dc9316c-ad16-4a77-a316-148b345cdfa5@github.com>

On Mon, 21 Nov 2022 15:40:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules:
> - `jdk.jartool`
> - `jdk.jlink`
> - `jdk.jpackage`
> 
> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21)  the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module.
> 
> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule".
> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule".
> - [x] Remove `CommandLine.java` from `jdk.jartool` module
> - [x] Remove `CommandLine.java` from `jdk.jlink` module
> - [x] Remove `CommandLine.java` from `jdk.jpackage` module
> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ...

I guess git is "confused" by not realizing that the "new" `CommandLine.java` is just a clone of the existing `javac` version. (It is, isn't it ... apart from the package rename?)

src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java line 51:

> 49:  *  If you write code that depends on this, you do so at your own risk.
> 50:  *  This code and its internal interfaces are subject to change or
> 51:  *  deletion without notice.</b>

Maybe we can drop this part of the comment

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

Marked as reviewed by jjg (Reviewer).

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

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 dholmes at openjdk.org  Tue Nov 22 06:41:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Nov 2022 06:41:24 GMT
Subject: RFR: JDK-8245246: Deprecate -profile option in javac
In-Reply-To: <m-wmDE50V70Cq2k84rsHbLrpGm2lkWIRQVVbX-jWWzU=.5a0cc95b-f682-4977-ab8a-4d07e056e115@github.com>
References: <m-wmDE50V70Cq2k84rsHbLrpGm2lkWIRQVVbX-jWWzU=.5a0cc95b-f682-4977-ab8a-4d07e056e115@github.com>
Message-ID: <dUF6GikjyCy3jFcwdYRTLB5JRXVc4DJJVb1a0y64Y4k=.b4597f22-453b-4e28-b8c8-98c8f2dc68f5@github.com>

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

> Please review a trivial update for javac, to note that the `-profile` option is deprecated and may be removed.

@jonathan-gibbons  why wasn't the updated javac.1 file integrated?

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

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

From abimpoudis at openjdk.org  Tue Nov 22 15:03:49 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 22 Nov 2022 15:03:49 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v13]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <3HPrCXhOK-SKNjO4Fqh_qyIYusPJKADGNgs2x2n2j3g=.4ac5c88d-5258-4c7f-81fa-e170c23a5426@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

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

  Fix selector type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/f37e8eaa..73ca672b

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

  Stats: 97 lines in 2 files changed: 45 ins; 33 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

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

From cstein at openjdk.org  Tue Nov 22 15:50:20 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 22 Nov 2022 15:50:20 GMT
Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a
 reusable module for other JDK tools
In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
Message-ID: <T4DadmqB2x7Q2mmKmJu3dw4gKKd-e7h7LSur64l18jI=.64de9ead-c360-4ae5-8392-069f4fae02f1@github.com>

On Mon, 21 Nov 2022 15:40:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules:
> - `jdk.jartool`
> - `jdk.jlink`
> - `jdk.jpackage`
> 
> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21)  the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module.
> 
> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule".
> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule".
> - [x] Remove `CommandLine.java` from `jdk.jartool` module
> - [x] Remove `CommandLine.java` from `jdk.jlink` module
> - [x] Remove `CommandLine.java` from `jdk.jpackage` module
> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ...

Yes. I copied `CommandLine` class from module `jdk.compiler`. In addition to update of the copyright year and the name of the package, I also added small API changes that other tools developed in their copies of the class. Find a diff attached below:


diff --git a/open/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java b/open/src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java
index ec6f711f9b..9e4b0c6fe2 100644
--- a/open/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java
+++ b/open/src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1999, 2022, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -23,17 +23,25 @@
  * questions.
  */
 
-package com.sun.tools.javac.main;
+package jdk.internal.opt;
 
 import java.io.IOException;
+import java.io.InputStream;
+import java.io.InputStreamReader;
 import java.io.Reader;
 import java.nio.charset.Charset;
 import java.nio.file.Files;
 import java.nio.file.Paths;
 import java.util.ArrayList;
-import java.util.Arrays;
 import java.util.List;
 
+/*
+ * This file was originally a copy of CommandLine.java in
+ * com.sun.tools.javac.main -- and it will be the last.
+ *
+ * Find details at https://bugs.openjdk.org/browse/JDK-8236919
+ */
+
 /**
  * Various utility methods for processing Java tool command line arguments.
  *
@@ -42,7 +50,16 @@ import java.util.List;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
-public class CommandLine {
+public final class CommandLine {
+    /**
+     * Convenient wrapper for the {@code List}-based parse method.
+     *
+     * @see #parse(List)
+     */
+    public static String[] parse(String... args) throws IOException {
+        return parse(List.of(args)).toArray(String[]::new);
+    }
+
     /**
      * Process Win32-style command files for the specified command line
      * arguments and return the resulting arguments. A command file argument
@@ -91,7 +108,7 @@ public class CommandLine {
      * @param args the arguments that may contain @files
      * @return the arguments, with environment variable's content and expansion of @files
      * @throws IOException if there is a problem reading any of the @files
-     * @throws com.sun.tools.javac.main.CommandLine.UnmatchedQuote
+     * @throws CommandLine.UnmatchedQuote
      */
     public static List<String> parse(String envVariable, List<String> args)
             throws IOException, UnmatchedQuote {
@@ -104,8 +121,18 @@ public class CommandLine {
         return newArgs;
     }
 
+    public static void loadCmdFile(InputStream in, List<String> args) throws IOException {
+        Reader reader = new InputStreamReader(in);
+        loadCmdFileAndCloseReader(reader, args);
+    }
+
     private static void loadCmdFile(String name, List<String> args) throws IOException {
-        try (Reader r = Files.newBufferedReader(Paths.get(name), Charset.defaultCharset())) {
+        Reader reader = Files.newBufferedReader(Paths.get(name), Charset.defaultCharset());
+        loadCmdFileAndCloseReader(reader, args);
+    }
+
+    private static void loadCmdFileAndCloseReader(Reader r, List<String> args) throws IOException {
+        try (r) {
             Tokenizer t = new Tokenizer(r);
             String s;
             while ((s = t.nextToken()) != null) {

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

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

From cstein at openjdk.org  Tue Nov 22 15:57:57 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 22 Nov 2022 15:57:57 GMT
Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a
 reusable module for other JDK tools [v2]
In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
Message-ID: <i-ffNGmO1YuADS5Cri_IrghTAwtsNMtOpQ-lRBFHzQw=.74bac34c-6775-4550-9ad7-642879667376@github.com>

> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules:
> - `jdk.jartool`
> - `jdk.jlink`
> - `jdk.jpackage`
> 
> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21)  the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module.
> 
> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule".
> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule".
> - [x] Remove `CommandLine.java` from `jdk.jartool` module
> - [x] Remove `CommandLine.java` from `jdk.jlink` module
> - [x] Remove `CommandLine.java` from `jdk.jpackage` module
> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ...

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Remove superseded comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11272/files
  - new: https://git.openjdk.org/jdk/pull/11272/files/ebdcbde7..7854e14c

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

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

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

From jjg at openjdk.org  Tue Nov 22 17:19:28 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 22 Nov 2022 17:19:28 GMT
Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a
 reusable module for other JDK tools [v2]
In-Reply-To: <i-ffNGmO1YuADS5Cri_IrghTAwtsNMtOpQ-lRBFHzQw=.74bac34c-6775-4550-9ad7-642879667376@github.com>
References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
 <i-ffNGmO1YuADS5Cri_IrghTAwtsNMtOpQ-lRBFHzQw=.74bac34c-6775-4550-9ad7-642879667376@github.com>
Message-ID: <0WBh1OHEuCdBwQ4dXLlip2J6bhh-X7LZu-Jm0JenJlY=.e77a0a31-7427-42fd-9667-7dad4c0d64b8@github.com>

On Tue, 22 Nov 2022 15:57:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules:
>> - `jdk.jartool`
>> - `jdk.jlink`
>> - `jdk.jpackage`
>> 
>> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21)  the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module.
>> 
>> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule".
>> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule".
>> - [x] Remove `CommandLine.java` from `jdk.jartool` module
>> - [x] Remove `CommandLine.java` from `jdk.jlink` module
>> - [x] Remove `CommandLine.java` from `jdk.jpackage` module
>> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ...
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove superseded comment

Marked as reviewed by jjg (Reviewer).

src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java line 49:

> 47:  *
> 48:  *  <p><b>This is NOT part of any supported API.
> 49:  *  If you write code that depends on this, you do so at your own risk.</b>

I think this entire paragraph can be removed. It is "just" the "scary warning" meant to warn people about using not-really-public classes in javac, before we had a module system for the encapsulation.

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

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

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 ihse at openjdk.org  Tue Nov 22 20:03:09 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:03:09 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool
Message-ID: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>

Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.

This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

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

Commit messages:
 - 8297444: Refactor the javacserver build tool

Changes: https://git.openjdk.org/jdk/pull/11298/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297444
  Stats: 3440 lines in 35 files changed: 1198 ins; 2212 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/11298.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11298/head:pull/11298

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

From ihse at openjdk.org  Tue Nov 22 20:05:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:05:38 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <n5JTP5PQ6sRa4aIyfffbdemmhwtQRnZ8fkvneOEz0kU=.32d3d85b-4073-4fe1-bdb5-b11e3f9130e1@github.com>

On Tue, 22 Nov 2022 19:54:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

I realize this PR can be a bit of a challenge to review. I'll explain the changes I have done.

The "actual" changes I have made is to how the javacserver tool is called from the makefiles, and how the client starts the server. 

The client now takes a `--conf=<conf file>` argument, instead of `--server:conf=<conf file>`. This argument has to be the first argument; the rest of the argument line is passed on to javac in the server. This allowed me to remove all the complex option processing stuff. Also, the client cannot any longer be called in "stand-alone" mode where no server is used (basically a complex version of plain `javac`).

Secondly, the server is now started with a separate main method in the Server class. This means the entry point need not determine if it is being called as a client or a server, simplifying further. The server takes exactly one argument, the path of the port file. That means the last of the option processing could go.

Third, the configuration file has changed slightly. Instead of a `servercmd` there is now a `javacmd`, which tells the client how to start java (suitable path to the java executable, and proper flags) when launching the server. The actual class used to launch the server is known by the client and does not have to be provided by the makefile. This change made new configuration files incompatible with old files; it turned out make had a bit of a problem of recognizing the file needed to be updated, so I chose a slightly different name for the configuration file, to avoid strange recompilation errors when this patch gets integrated.

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

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

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 ihse at openjdk.org  Tue Nov 22 20:12:42 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:12:42 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <Bvs88hx9hk3mMxpuzqqh5PPCDw-D4Rz82h4kRBnGajA=.d5deeb8a-6c23-4b67-a43f-3f75317418ae@github.com>

On Tue, 22 Nov 2022 19:54:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

The remaining changes are "pure" refactorings. I have moved code around, and reworked the abstraction layers. Basically, I put everything pertaining to the client in a long sequence (calling the client is basically a trivial sequence of events), and similarly for the server. Code that were shared between both were put in the `shared` or `util` packages (the latter for more auxiliary classes, the former for more central). Everything else were mercilessly removed.

I then abstracted out what seemed like reasonable parts from the long sequences in Client and Server, in the process mostly recreating the thread pool and idle detection classes of the former structure (so git will present them as renames).

I've been extra careful not to change any behavior regarding the portfile locking and synchronization, or the actual protocol exchanged by the server and client (with one exception: the exit code from javac is now returned as an integer, and not as a string representing the `Result` enum.) I believe there are a number of places where races can be introduced, and I intend to come back later and try to patch this. But I deemed it essential that I do not change any behavior in that regard in this patch, otherwise it would be hopeless to know if a potential future regression was caused by a mistake in my refactoring, or that any changed behavior was faulty.

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

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

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 ihse at openjdk.org  Tue Nov 22 20:59:02 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:59:02 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
Message-ID: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>

In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.

After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

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

Depends on: https://git.openjdk.org/jdk/pull/11298

Commit messages:
 - 8297455: Use the official ToolProvider API to call javac

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

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

From ihse at openjdk.org  Tue Nov 22 20:59:03 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:59:03 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <unr9CfY_t_qUacibGc3W3K40tugWoymjsI8r4hT1C-0=.a5e8c5ac-e0ff-49ca-81d9-f4e1a88be1ba@github.com>

On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Note that this PR is dependent on JDK-8297444 (PR: https://github.com/openjdk/jdk/pull/11298)

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

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

From jjg at openjdk.org  Tue Nov 22 22:04:57 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 22 Nov 2022 22:04:57 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>

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

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Prefix RFC titles with `RFC NNNN:`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/30ce235f..c29092d8

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

  Stats: 325 lines in 165 files changed: 4 ins; 4 del; 317 mod
  Patch: https://git.openjdk.org/jdk/pull/11073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073

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

From weijun at openjdk.org  Tue Nov 22 22:37:32 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 22:37:32 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw IOExceptions
Message-ID: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>

This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:

- Remove unnecessary `throws IOException` in code and spec
- Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
- More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
- Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
- Some unused methods removed

The only actual changes (still trivial) are:
- Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
- In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/11302/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11302&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297065
  Stats: 1139 lines in 109 files changed: 58 ins; 426 del; 655 mod
  Patch: https://git.openjdk.org/jdk/pull/11302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11302/head:pull/11302

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

From erikj at openjdk.org  Tue Nov 22 23:17:25 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 22 Nov 2022 23:17:25 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <TgMb35D7NBQlloSqy1x-jGTfukkD1bAdXC4TZIw5uEs=.9075cea9-951a-4ff7-86a8-2273e8151b65@github.com>

On Tue, 22 Nov 2022 19:54:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

Only some minor comments. Looks good to me overall. The proof is in the building.

Have you tried more than just full builds on all platforms? Things like incremental builds, some forced failure conditions etc?

make/langtools/tools/javacserver/client/Client.java line 140:

> 138: 
> 139:     /*
> 140:      * Fork a server process process and wait for server to come around

Suggestion:

     * Fork a server process and wait for server to come around

make/langtools/tools/javacserver/client/Client.java line 148:

> 146:         cmd.addAll(Arrays.asList(conf.javaCommand().split(" ")));
> 147:         // javacserver.server.Server is the server main class
> 148:         cmd.add("javacserver.server.Server");

Did you consider referencing the class name using `Server.class.getName()`?

make/langtools/tools/javacserver/server/Server.java line 200:

> 198: 
> 199:                 // Set up logging for this thread. Stream back logging messages to
> 200:                 // client on the format format "level:msg".

Suggestion:

                // client on the format "level:msg".

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

Marked as reviewed by erikj (Reviewer).

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

From erikj at openjdk.org  Tue Nov 22 23:20:06 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 22 Nov 2022 23:20:06 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <udbl8J8U6WPQZEJXIzYehxr5YNQ81iFJicrrTLEOZ78=.48d644af-224c-4cc0-9be0-79e79d79d112@github.com>

On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Marked as reviewed by erikj (Reviewer).

Just to make sure, will this find the interim javac before the bootjdk javac? How is this enforced?

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

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

From ihse at openjdk.org  Tue Nov 22 23:40:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 23:40:30 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

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

 - Fix typo #2
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Fix typo
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11298/files
  - new: https://git.openjdk.org/jdk/pull/11298/files/3dd8af2a..2a0e0975

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

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

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

From ihse at openjdk.org  Tue Nov 22 23:40:31 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 23:40:31 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <TgMb35D7NBQlloSqy1x-jGTfukkD1bAdXC4TZIw5uEs=.9075cea9-951a-4ff7-86a8-2273e8151b65@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <TgMb35D7NBQlloSqy1x-jGTfukkD1bAdXC4TZIw5uEs=.9075cea9-951a-4ff7-86a8-2273e8151b65@github.com>
Message-ID: <g5TrBpGApGYMd3fNc2w3eeA1b7J4axMFT8l_bAIMW2M=.7caef6aa-26bc-472b-834c-a99def22cf06@github.com>

On Tue, 22 Nov 2022 23:15:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Things like incremental builds, some forced failure conditions etc?

I tested simple incremental builds but I should probably make a bit more advanced versions where I modify different files to trigger more real-life like scenarios, including compilation errors. Good point.

> make/langtools/tools/javacserver/client/Client.java line 148:
> 
>> 146:         cmd.addAll(Arrays.asList(conf.javaCommand().split(" ")));
>> 147:         // javacserver.server.Server is the server main class
>> 148:         cmd.add("javacserver.server.Server");
> 
> Did you consider referencing the class name using `Server.class.getName()`?

No, can't say I have. Do you think there is anything to gain by doing that? (Apart from possibly getting this right automatically if the class is renamed by IDE tools) (I'm not sure it would be a win in readability)

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

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

From ihse at openjdk.org  Tue Nov 22 23:48:49 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 23:48:49 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <xLMfuwSf852VdOtQVXrUtiWlmear1MjKiFUYp4ofSFY=.409b6ba5-7c1f-4717-8c61-86fb07bfdaa7@github.com>

On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Well, I assume so. If this does not work properly, the problem will most likely be already in JDK-8297444; this patch is just choosing a different path to end up in the same class, as far as I can understand.

The thing that makes (or should make) us chose the interim javac is the `$(INTERIM_LANGTOOLS_ARGS)` which is passed to java when launching the server. (This is since these flags are passed in the config file to the client as `javacmd`). 

I'll add some test output code to the interim compiler to verify that it is actually executed, both in JDK-8297444 and in this PR.

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

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

From erikj at openjdk.org  Tue Nov 22 23:55:19 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 22 Nov 2022 23:55:19 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <g5TrBpGApGYMd3fNc2w3eeA1b7J4axMFT8l_bAIMW2M=.7caef6aa-26bc-472b-834c-a99def22cf06@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <TgMb35D7NBQlloSqy1x-jGTfukkD1bAdXC4TZIw5uEs=.9075cea9-951a-4ff7-86a8-2273e8151b65@github.com>
 <g5TrBpGApGYMd3fNc2w3eeA1b7J4axMFT8l_bAIMW2M=.7caef6aa-26bc-472b-834c-a99def22cf06@github.com>
Message-ID: <MAtvRVWPv0Wvo6bTB-QfFhgb0NXa70shx8rAIlnweq4=.2b3918dc-8a7d-4e01-b8a9-5b521e8f817c@github.com>

On Tue, 22 Nov 2022 23:32:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/langtools/tools/javacserver/client/Client.java line 148:
>> 
>>> 146:         cmd.addAll(Arrays.asList(conf.javaCommand().split(" ")));
>>> 147:         // javacserver.server.Server is the server main class
>>> 148:         cmd.add("javacserver.server.Server");
>> 
>> Did you consider referencing the class name using `Server.class.getName()`?
>
> No, can't say I have. Do you think there is anything to gain by doing that? (Apart from possibly getting this right automatically if the class is renamed by IDE tools) (I'm not sure it would be a win in readability)

I like to reference class names that way so that it's typed instead of just a string. If the class changes name, you get a compilation error, and the IDE would handle refactoring automatically. Not a strong need in this particular instance, just something I generally tend to do.

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

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

From duke at openjdk.org  Wed Nov 23 02:52:34 2022
From: duke at openjdk.org (Bo Zhang)
Date: Wed, 23 Nov 2022 02:52:34 GMT
Subject: RFR: 8296329: jar validator doesn't account for minor class file
 version [v2]
In-Reply-To: <anh3NKU6QnjZjt6-6Vbml0twjcCnMnOFUyE3Ygf7-5M=.cc31cf47-e2ef-4427-b83b-2c2674acc62b@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
 <S0SX7RmT9RYqI6e7obS952K7LXHvFWFo9KymHpPua-Q=.cc6fa603-651d-4eed-b243-b2d569514094@github.com>
 <anh3NKU6QnjZjt6-6Vbml0twjcCnMnOFUyE3Ygf7-5M=.cc31cf47-e2ef-4427-b83b-2c2674acc62b@github.com>
Message-ID: <ryPvF8xUbwxpkapkSGsWLwORf6O4xo0Zlw5hxKq7j7c=.8e95c8ce-5ddf-45fd-b1a2-c82621d5be53@github.com>

On Wed, 16 Nov 2022 13:23:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8296329: Only compare major versions in jar validator
>
> Marked as reviewed by jvernee (Reviewer).

@JornVernee  can you please sponsor this PR?

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

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

From jvernee at openjdk.org  Wed Nov 23 03:04:33 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 23 Nov 2022 03:04:33 GMT
Subject: RFR: 8296329: jar validator doesn't account for minor class file
 version [v2]
In-Reply-To: <ryPvF8xUbwxpkapkSGsWLwORf6O4xo0Zlw5hxKq7j7c=.8e95c8ce-5ddf-45fd-b1a2-c82621d5be53@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
 <S0SX7RmT9RYqI6e7obS952K7LXHvFWFo9KymHpPua-Q=.cc6fa603-651d-4eed-b243-b2d569514094@github.com>
 <anh3NKU6QnjZjt6-6Vbml0twjcCnMnOFUyE3Ygf7-5M=.cc31cf47-e2ef-4427-b83b-2c2674acc62b@github.com>
 <ryPvF8xUbwxpkapkSGsWLwORf6O4xo0Zlw5hxKq7j7c=.8e95c8ce-5ddf-45fd-b1a2-c82621d5be53@github.com>
Message-ID: <X2kwR-ha_gRPjkndZD-frQOTu0-A1-u7Xjqahp8uXBc=.6246d369-2ab6-4b77-9c22-938196ca0fef@github.com>

On Wed, 23 Nov 2022 02:50:26 GMT, Bo Zhang <duke at openjdk.org> wrote:

>> Marked as reviewed by jvernee (Reviewer).
>
> @JornVernee  can you please sponsor this PR?

@blindpirate Yes. If you `/integrate` it, I can then `/sponsor`.

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

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

From duke at openjdk.org  Wed Nov 23 03:10:44 2022
From: duke at openjdk.org (Bo Zhang)
Date: Wed, 23 Nov 2022 03:10:44 GMT
Subject: RFR: 8296329: jar validator doesn't account for minor class file
 version [v2]
In-Reply-To: <X2kwR-ha_gRPjkndZD-frQOTu0-A1-u7Xjqahp8uXBc=.6246d369-2ab6-4b77-9c22-938196ca0fef@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
 <S0SX7RmT9RYqI6e7obS952K7LXHvFWFo9KymHpPua-Q=.cc6fa603-651d-4eed-b243-b2d569514094@github.com>
 <anh3NKU6QnjZjt6-6Vbml0twjcCnMnOFUyE3Ygf7-5M=.cc31cf47-e2ef-4427-b83b-2c2674acc62b@github.com>
 <ryPvF8xUbwxpkapkSGsWLwORf6O4xo0Zlw5hxKq7j7c=.8e95c8ce-5ddf-45fd-b1a2-c82621d5be53@github.com>
 <X2kwR-ha_gRPjkndZD-frQOTu0-A1-u7Xjqahp8uXBc=.6246d369-2ab6-4b77-9c22-938196ca0fef@github.com>
Message-ID: <3zWUu4_htVwRRuA8ekMWUf8CSB0fVDl5j2-MEHrLqpY=.7987cebe-4b22-4ad4-8130-adbd5404ae93@github.com>

On Wed, 23 Nov 2022 03:01:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @JornVernee  can you please sponsor this PR?
>
> @blindpirate Yes. If you `/integrate` it, I can then `/sponsor`.

Thanks @JornVernee !

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

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

From duke at openjdk.org  Wed Nov 23 03:12:35 2022
From: duke at openjdk.org (Bo Zhang)
Date: Wed, 23 Nov 2022 03:12:35 GMT
Subject: Integrated: 8296329: jar validator doesn't account for minor class
 file version
In-Reply-To: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
References: <TVB6f-5OnJ-lJbn0jZwM77ZrqPY3rMgbpVz9rekjgxA=.5aaff363-1c0b-4d24-845e-6fa371eb2425@github.com>
Message-ID: <DClXsS8JfO65wk_4dNvxG9lH4LseceE5VcOXcxpYf0M=.fd4845b0-8870-4350-8aaa-081e32145884@github.com>

On Tue, 15 Nov 2022 01:52:14 GMT, Bo Zhang <duke at openjdk.org> wrote:

> As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison.
> 
> This PR fixes it by only comparing major versions.

This pull request has now been integrated.

Changeset: faf48e61
Author:    Bo Zhang <zhangbodut at gmail.com>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/faf48e61be4f97f725b053aa351d3c64638546bf
Stats:     127 lines in 3 files changed: 123 ins; 1 del; 3 mod

8296329: jar validator doesn't account for minor class file version

Reviewed-by: jvernee

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

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

From cstein at openjdk.org  Wed Nov 23 09:41:18 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 23 Nov 2022 09:41:18 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>
Message-ID: <6RfobOhE7uu5mMuHP_ea2iwL_IKBbEI0I3WMaNV38VY=.5538da47-c278-4603-8422-9b64fde7da8c@github.com>

On Tue, 22 Nov 2022 23:40:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
>> 
>> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix typo #2
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Fix typo
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by cstein (Committer).

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

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

From dfuchs at openjdk.org  Wed Nov 23 12:47:43 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:47:43 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
Message-ID: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>

On Tue, 22 Nov 2022 22:04:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

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

Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

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

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

From jlaskey at openjdk.org  Wed Nov 23 12:58:04 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 23 Nov 2022 12:58:04 GMT
Subject: 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 jlahoda at openjdk.org  Wed Nov 23 13:25:47 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Nov 2022 13:25:47 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v7]
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <h2iJAiZZ60-WXUx-XNtmpE8tFc0LYV8snjHgFCjKj6I=.e5e4df54-2865-4997-9a08-ac58bd8bb4d5@github.com>

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into JDK-8294942
 - Using skipTypeVars as suggested.
 - Reflecting review feedback - proper handling of type vars and intersection types.
 - Not looking for common supertype, not solving in a loop.
 - Reflecting review comment.
 - Apply suggestions from code review
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Better tests for inference with recursive bounds, and related fixes.
 - Adding a kind to InstanceOfTree, as suggested.
 - Reflecting review feedback.
 - Fixing test.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/373e52c0...5e8e554a

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

Changes: https://git.openjdk.org/jdk/pull/10814/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10814&range=06
  Stats: 1564 lines in 39 files changed: 1176 ins; 278 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/10814.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10814/head:pull/10814

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

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 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 cstein at openjdk.org  Wed Nov 23 15:59:42 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 23 Nov 2022 15:59:42 GMT
Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a
 reusable module for other JDK tools [v3]
In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
Message-ID: <T7QZxCPzluyJvgD23inJkhYALs2Tgt-2tQzDz1rJhc8=.cf466bfe-8276-45de-a637-6962f56566fb@github.com>

> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules:
> - `jdk.jartool`
> - `jdk.jlink`
> - `jdk.jpackage`
> 
> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21)  the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module.
> 
> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule".
> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule".
> - [x] Remove `CommandLine.java` from `jdk.jartool` module
> - [x] Remove `CommandLine.java` from `jdk.jlink` module
> - [x] Remove `CommandLine.java` from `jdk.jpackage` module
> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ...

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Remove entire "scary warning" paragraph

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11272/files
  - new: https://git.openjdk.org/jdk/pull/11272/files/7854e14c..6d2de1ee

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

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

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

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 jjg at openjdk.org  Wed Nov 23 16:47:22 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 16:47:22 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
 <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
Message-ID: <1chEBBDbhD7PiPdKybnhe3Bq2DyO-GTGaxTU5qtw7C4=.8191c086-d70c-4bc1-b03e-d781b1268f07@github.com>

On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

That was not intentional, and is a result of the scripted edit. I will look to revert those changes and/or change the tooling to ignore those packages.

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

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

From rriggs at openjdk.org  Wed Nov 23 17:30:03 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Nov 2022 17:30:03 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v30]
In-Reply-To: <jjNB6nIhgSsA0xi30tAn3Hm0XxKHvOXydjG7wsdYqms=.75bc8a32-c384-4867-bd07-92f9abd68a1e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <AHyvIcvK9RMEEMIGlfkU3N87JbMKyuGCq12hXXBkNHo=.beb2bc69-a99c-4f54-bbb5-6d0b64c5a8e5@github.com>
 <jjNB6nIhgSsA0xi30tAn3Hm0XxKHvOXydjG7wsdYqms=.75bc8a32-c384-4867-bd07-92f9abd68a1e@github.com>
Message-ID: <WNCff-ybV47pDukR9L9VV6UUApZok60c_Wpjrwl4LPM=.64e69176-ace4-4b57-bc96-030eb9051896@github.com>

On Wed, 23 Nov 2022 16:40:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/FormatProcessor.java line 85:
>> 
>>> 83: 
>>> 84:     /**
>>> 85:      * {@inheritDoc}
>> 
>> The javadoc should describe in more detail what `process` does and the errors than can occur.
>> That will help developers understand the errors that come out of Formatter in the context of FMT.
>> That will help even if that is just to describe how the format string passed to j.u.Formatter is constructed.
>> The javadoc should warn that the fragment should contain only a single format string and it must be at the end of the fragment.
>> For example, if multiple format strings appear in the fragment they are all passed to Formatter.
>> If the last format string is not the last in the fragment (for example, followed by a space) then a %s is appended and there are two formatters for a single value.  For example,
>> 
>>    int x = 1;
>>    FMT."x: %s {x}";  // extra space
>> 
>> It is unfortunate that the exception reported (in the case of a mismatch in the number for format strings vs values) is a BootStrapMethodError with a cause of MissingFormatArgument.  That's exposing the implementation and may look like a bug in the FMT.
>
> Will clean up javadoc for FormatProcessor::process.
> 
> It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually.

Since FormatProcessor is scanning for format strings (in stringTempateFormat), it could check for the wrong number and misplaced format strings and throw.  It would make the exception more specific to the arguments to the FMT.process() and easier for the developer to correct.

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

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

From jjg at openjdk.org  Wed Nov 23 18:57:03 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 18:57:03 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>

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

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Remove updates from unexported files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/c29092d8..3905ac83

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

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

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

From jlaskey at openjdk.org  Wed Nov 23 19:22:14 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 23 Nov 2022 19:22:14 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v30]
In-Reply-To: <WNCff-ybV47pDukR9L9VV6UUApZok60c_Wpjrwl4LPM=.64e69176-ace4-4b57-bc96-030eb9051896@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <AHyvIcvK9RMEEMIGlfkU3N87JbMKyuGCq12hXXBkNHo=.beb2bc69-a99c-4f54-bbb5-6d0b64c5a8e5@github.com>
 <jjNB6nIhgSsA0xi30tAn3Hm0XxKHvOXydjG7wsdYqms=.75bc8a32-c384-4867-bd07-92f9abd68a1e@github.com>
 <WNCff-ybV47pDukR9L9VV6UUApZok60c_Wpjrwl4LPM=.64e69176-ace4-4b57-bc96-030eb9051896@github.com>
Message-ID: <DsM_dkhUNpq-Zf7GlxpsJfqHCgYpnNcCM_lI5WxuIqs=.fc809023-dcd9-4ebe-b95c-3b6d3603511d@github.com>

On Wed, 23 Nov 2022 17:26:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Will clean up javadoc for FormatProcessor::process.
>> 
>> It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually.
>
> Since FormatProcessor is scanning for format strings (in stringTempateFormat), it could check for the wrong number and misplaced format strings and throw.  It would make the exception more specific to the arguments to the FMT.process() and easier for the developer to correct.

It is doing that now, but I can make the message more informative. The problem still exists that this is always done in the bootstrap method.

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

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

From dfuchs at openjdk.org  Wed Nov 23 19:23:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 19:23:53 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

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

The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

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

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

From jjg at openjdk.org  Wed Nov 23 22:09:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 22:09:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
Message-ID: <CN_yhlxSOuJ_vrZwgtwLXWapiBa9Df2Cab1ySShZvu4=.b3e2212d-2f5d-4cea-a28b-8a02e3b18159@github.com>

On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

Believe me, I tried *very* hard to design and use an inline `{@spec}` tag but such a tag effectively needs a normative external file to indicate the root of a multi-page spec, and the definitive title, since inline tags either do not or are unlikely to contain such information.

The general history of this work is:
* version 1: bimodal tag with no external file -- the content of the summary page was effectively rubbish
* version 2: bimodal tag with an external file -- in discussion with @jddarcy and CSR, we decided that was too much of a non-standard maintenance load
* version 3: new tag, with no external file needed -- as you see here

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

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

From joehw at openjdk.org  Wed Nov 23 23:08:05 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:08:05 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

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

src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:

> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition

Hi Jon,

I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
points to the fifth edition while @see second.

A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.

[1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

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

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

From joehw at openjdk.org  Wed Nov 23 23:43:57 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:43:57 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <3O_lqMPzsBuGyrQ_snbw0Qv-XY-OaGUly6OBtoRz8hw=.041bf0b3-9dd4-4616-a003-617d28030139@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

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

Specs for XSLT and XPath (many occurrences) need to point to specific version (e.g. 1.0) rather than the "cover page" (this is an issue in the original javadoc).

src/java.xml/share/classes/javax/xml/transform/OutputKeys.java line 35:

> 33:  *
> 34:  * @spec https://www.w3.org/TR/xslt xslt cover page - W3C
> 35:  * @see <a href="http://www.w3.org/TR/xslt#output">

The pages for XSLT and XPath at W3C are organized differently from the days when this javadoc was created. The "latest version" now points to the "cover page". Could you change the spec to the following? 
      https://www.w3.org/TR/1999/REC-xslt-19991116 XSL Transformations (XSLT) Version 1.0
      
The @spec points to the general spec while @see also a specific section (similar situation as other classes in the package), if we want to keep @see ref here, it would be: 
    https://www.w3.org/TR/1999/REC-xslt-19991116#output

src/java.xml/share/classes/javax/xml/xpath/XPath.java line 104:

> 102:  * @author  Norman Walsh
> 103:  * @author  Jeff Suttor
> 104:  * @see <a href="http://www.w3.org/TR/xpath">XML Path Language (XPath) Version 1.0</a>

Similar situation as XSLT above, the latest version now points to "cover page". For this javadoc then, it needs to be:
    https://www.w3.org/TR/1999/REC-xpath-19991116/ XML Path Language (XPath) Version 1.0
    
Unlike XSLT, the original @see ref also points to the spec generally (not a specific section), we could then drop it to keep just the @spec ref.

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

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

From alanb at openjdk.org  Thu Nov 24 10:56:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 10:56:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <W_PDXjCTWZO6xXPHhF-LLKnDxtRgwgI9zdv9Se52Rqo=.0ae98a38-5f76-4839-b579-ab19faf1945b@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

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

src/java.se/share/classes/module-info.java line 39:

> 37:  *
> 38:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 39:  * @spec jni/index.html Java Native Interface Specification

One thing that that bothers me a bit here is that the JNI and JDWP specs will be listed as "External Specifications" in the generated javadoc. This heading is appropriate for RFCs and other standards that we reference but seems misleading for specifications that are part of Java SE. Has this come up already?

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

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

From abimpoudis at openjdk.org  Thu Nov 24 11:28:20 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Nov 2022 11:28:20 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v14]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <4ua1v5oyaazO-QqoCtoMudaERyBJtrOEXqcjqUjzGZI=.61537397-5154-4cbf-be9a-e44f0c6ffc5e@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'JDK-8294942' into for-patterns
 - Fix selector type
 - Merge branch 'JDK-8294942' into for-patterns
 - Improve error message on non-exhaustive enhanced for
 - Merge branch 'JDK-8294942' into for-patterns
   
   # Conflicts:
   #	test/langtools/tools/javac/patterns/GenericRecordDeconstructionPattern.java
 - Cleanup
 - Fix parsing error in presence of lambdas
 - Fix parsing error in presence of nested patterns
 - Merge pull request #1 from lahodaj/for-patterns
   
   Fixing record patterns with primitive components in enhanced for
 - Cleanup
 - ... and 11 more: https://git.openjdk.org/jdk/compare/5e8e554a...44d4f068

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

Changes: https://git.openjdk.org/jdk/pull/10798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=13
  Stats: 756 lines in 26 files changed: 686 ins; 7 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

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

From abimpoudis at openjdk.org  Thu Nov 24 11:58:26 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Nov 2022 11:58:26 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v15]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <c9dyNIQs4Kg-8WmsiRF2w8jhs0k5B06VtUO6f51bCCY=.29b6282b-ae92-4c47-9996-6efe7c146708@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

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

  Add @enablePreview

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/44d4f068..861aaa3a

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

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

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

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 mcimadamore at openjdk.org  Thu Nov 24 17:14:30 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 17:14:30 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v15]
In-Reply-To: <c9dyNIQs4Kg-8WmsiRF2w8jhs0k5B06VtUO6f51bCCY=.29b6282b-ae92-4c47-9996-6efe7c146708@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <c9dyNIQs4Kg-8WmsiRF2w8jhs0k5B06VtUO6f51bCCY=.29b6282b-ae92-4c47-9996-6efe7c146708@github.com>
Message-ID: <l5HDTKCP4FUY4gSy2CrcSMg8POWjwHvhu3PoAT9voOY=.c3e0c771-7dc2-4439-944a-de9cb75b9227@github.com>

On Thu, 24 Nov 2022 11:58:26 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
>> 
>> 
>> record Complex(double real, double img) {}
>> 
>> List<Complex> list = ...;
>> 
>> for (Complex(var real, var img) : list) {
>>     // can use ?real? and ?img? directly
>> }
>> 
>> 
>> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
>> 
>> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
>> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
>> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
>> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
>> - The enhanced for, supports record patterns for both arrays and reference types.
>> 
>> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
>> 
>> For more information on the changes please see:
>> 
>> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
>> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
>> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
>> 
>> Looking forward for your review.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @enablePreview

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

> 2985:         boolean inType = false;
> 2986:         boolean inSelectionAndParenthesis = false;
> 2987:         ForInitResult defaultResult = ForInitResult.LocalVarDecl;

I don't think this is  needed - this is just the return of the "default" path

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

> 3014:                             return ForInitResult.LocalVarDecl;
> 3015:                         }
> 3016:                         else if(peekToken(lookahead, COLON)) {

Does this logic works with nested record patterns? You don't seem to "count" the parenthesis... I do see tests with it though...

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

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

From mcimadamore at openjdk.org  Thu Nov 24 17:14:30 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 17:14:30 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v15]
In-Reply-To: <l5HDTKCP4FUY4gSy2CrcSMg8POWjwHvhu3PoAT9voOY=.c3e0c771-7dc2-4439-944a-de9cb75b9227@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <c9dyNIQs4Kg-8WmsiRF2w8jhs0k5B06VtUO6f51bCCY=.29b6282b-ae92-4c47-9996-6efe7c146708@github.com>
 <l5HDTKCP4FUY4gSy2CrcSMg8POWjwHvhu3PoAT9voOY=.c3e0c771-7dc2-4439-944a-de9cb75b9227@github.com>
Message-ID: <HBcgmCNQlhBYSfTvXyKDYr8sECHC6tJd7lprgvRAZCM=.811720ac-ab41-4613-ba97-5ff818afacd8@github.com>

On Thu, 24 Nov 2022 13:43:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @enablePreview
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3016:
> 
>> 3014:                             return ForInitResult.LocalVarDecl;
>> 3015:                         }
>> 3016:                         else if(peekToken(lookahead, COLON)) {
> 
> Does this logic works with nested record patterns? You don't seem to "count" the parenthesis... I do see tests with it though...

This is an example I found where classification goes wrong:


for (m(a ? b() : c) ; ;) {}

This used to parse correctly, but now parsing fails because the classification sees ")" followed by a ":".

This a nasty one: we can't just bail out on "?" as that is useful for generic types. But once you accept "?" then it could be a conditional as well, and conditionals also feature a ":" which means here we have a problem.

I think "?" should only conditionally be accepted if we're inside generic brackets. But then again, you could still have `a < b ? c() : d` which is not a type.

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

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

From mcimadamore at openjdk.org  Thu Nov 24 18:23:25 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 18:23:25 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v15]
In-Reply-To: <HBcgmCNQlhBYSfTvXyKDYr8sECHC6tJd7lprgvRAZCM=.811720ac-ab41-4613-ba97-5ff818afacd8@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <c9dyNIQs4Kg-8WmsiRF2w8jhs0k5B06VtUO6f51bCCY=.29b6282b-ae92-4c47-9996-6efe7c146708@github.com>
 <l5HDTKCP4FUY4gSy2CrcSMg8POWjwHvhu3PoAT9voOY=.c3e0c771-7dc2-4439-944a-de9cb75b9227@github.com>
 <HBcgmCNQlhBYSfTvXyKDYr8sECHC6tJd7lprgvRAZCM=.811720ac-ab41-4613-ba97-5ff818afacd8@github.com>
Message-ID: <HR9_HdThMtdchvHvZvV3cxXvhrV1dJ6FVWUkjJsWddc=.ca21a151-6b38-4ea9-a849-097bf839ede0@github.com>

On Thu, 24 Nov 2022 17:12:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3016:
>> 
>>> 3014:                             return ForInitResult.LocalVarDecl;
>>> 3015:                         }
>>> 3016:                         else if(peekToken(lookahead, COLON)) {
>> 
>> Does this logic works with nested record patterns? You don't seem to "count" the parenthesis... I do see tests with it though...
>
> This is an example I found where classification goes wrong:
> 
> 
> for (m(a ? b() : c) ; ;) {}
> 
> This used to parse correctly, but now parsing fails because the classification sees ")" followed by a ":".
> 
> This a nasty one: we can't just bail out on "?" as that is useful for generic types. But once you accept "?" then it could be a conditional as well, and conditionals also feature a ":" which means here we have a problem.
> 
> I think "?" should only conditionally be accepted if we're inside generic brackets. But then again, you could still have `a < b ? c() : d` which is not a type.

Ok, after some offline discussion, I put together a patch which addresses these (and other) issues:

https://github.com/biboudis/jdk/pull/3

The core idea is to detect whether a `?` is part of a generic type or not. See the above PR for more details.

Sadly, one of the tests I've added seems to crash the compiler, because a type annotation is found in an unexpected place. So that needs more work.

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

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

From abimpoudis at openjdk.org  Thu Nov 24 18:56:11 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Nov 2022 18:56:11 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v15]
In-Reply-To: <HR9_HdThMtdchvHvZvV3cxXvhrV1dJ6FVWUkjJsWddc=.ca21a151-6b38-4ea9-a849-097bf839ede0@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <c9dyNIQs4Kg-8WmsiRF2w8jhs0k5B06VtUO6f51bCCY=.29b6282b-ae92-4c47-9996-6efe7c146708@github.com>
 <l5HDTKCP4FUY4gSy2CrcSMg8POWjwHvhu3PoAT9voOY=.c3e0c771-7dc2-4439-944a-de9cb75b9227@github.com>
 <HBcgmCNQlhBYSfTvXyKDYr8sECHC6tJd7lprgvRAZCM=.811720ac-ab41-4613-ba97-5ff818afacd8@github.com>
 <HR9_HdThMtdchvHvZvV3cxXvhrV1dJ6FVWUkjJsWddc=.ca21a151-6b38-4ea9-a849-097bf839ede0@github.com>
Message-ID: <oWhPNewCy5kY8SujKrtoUPf-1HjAcRfEcAkBOzEgFvk=.fb44ed10-05d3-45fa-9f0b-5714f919f09e@github.com>

On Thu, 24 Nov 2022 18:19:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is an example I found where classification goes wrong:
>> 
>> 
>> for (m(a ? b() : c) ; ;) {}
>> 
>> This used to parse correctly, but now parsing fails because the classification sees ")" followed by a ":".
>> 
>> This a nasty one: we can't just bail out on "?" as that is useful for generic types. But once you accept "?" then it could be a conditional as well, and conditionals also feature a ":" which means here we have a problem.
>> 
>> I think "?" should only conditionally be accepted if we're inside generic brackets. But then again, you could still have `a < b ? c() : d` which is not a type.
>
> Ok, after some offline discussion, I put together a patch which addresses these (and other) issues:
> 
> https://github.com/biboudis/jdk/pull/3
> 
> The core idea is to detect whether a `?` is part of a generic type or not. See the above PR for more details.
> 
> Sadly, one of the tests I've added seems to crash the compiler, because a type annotation is found in an unexpected place. So that needs more work.

This seems related to pattern matching in general (I left `?` out, since it happens with explicit types as well).

https://bugs.openjdk.org/browse/JDK-8297602

I am commenting out that line in your PR @mcimadamore and merging. The rest seem good.

Thanks for the investigation and the quick fix ???

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

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

From abimpoudis at openjdk.org  Thu Nov 24 18:59:21 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Nov 2022 18:59:21 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v16]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <PV_lK1t3PLAcEvOfGy1t1lnjzJRjEpj1cO0-EGOCVC4=.0740486c-2496-4f82-a5f3-6a8ded0baa6a@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

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

  Fix some classification issues (#3)
  
  * Fix some classification issues
  
  * Add tests
  (Note: compiler crashes on the type annotation)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/861aaa3a..7892550a

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

  Stats: 40 lines in 2 files changed: 25 ins; 8 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

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

From abimpoudis at openjdk.org  Thu Nov 24 19:14:24 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Nov 2022 19:14:24 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v17]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <NwLVYmScIPTt7B4V49dhmZLbVxaL8VgXABvBBTmKN40=.564ed040-0981-41af-88e2-30b0aa892d51@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

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

  Disable parsing test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/7892550a..72264d59

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

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

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

From abimpoudis at openjdk.org  Thu Nov 24 19:16:14 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Nov 2022 19:16:14 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v15]
In-Reply-To: <l5HDTKCP4FUY4gSy2CrcSMg8POWjwHvhu3PoAT9voOY=.c3e0c771-7dc2-4439-944a-de9cb75b9227@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
 <c9dyNIQs4Kg-8WmsiRF2w8jhs0k5B06VtUO6f51bCCY=.29b6282b-ae92-4c47-9996-6efe7c146708@github.com>
 <l5HDTKCP4FUY4gSy2CrcSMg8POWjwHvhu3PoAT9voOY=.c3e0c771-7dc2-4439-944a-de9cb75b9227@github.com>
Message-ID: <i6qCQQXCZWDxtVyf-aePyej8bZ2Uv94hJGy-cb2Os_8=.204dc04e-5b58-456b-8d69-b74c84dbc87d@github.com>

On Thu, 24 Nov 2022 16:39:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @enablePreview
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2987:
> 
>> 2985:         boolean inType = false;
>> 2986:         boolean inSelectionAndParenthesis = false;
>> 2987:         ForInitResult defaultResult = ForInitResult.LocalVarDecl;
> 
> I don't think this is  needed - this is just the return of the "default" path

Thx for the fix

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

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

From aturbanov at openjdk.org  Thu Nov 24 20:22:12 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 24 Nov 2022 20:22:12 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>
Message-ID: <XRoBz-nmoTWrtm7P8OoZDgYQ1QA1FGgifOxd6VGpNFc=.15d3bc1f-2fc0-4fc6-8b07-94af49d0ab1c@github.com>

On Tue, 22 Nov 2022 23:40:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
>> 
>> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix typo #2
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Fix typo
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

make/langtools/tools/javacserver/server/Server.java line 69:

> 67:     private static LazyInitFileLog errorLog;
> 68: 
> 69:     public static void main(String... args)  {

Nit:
Suggestion:

    public static void main(String... args) {

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

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

From ihse at openjdk.org  Thu Nov 24 20:36:06 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 24 Nov 2022 20:36:06 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v3]
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <OlS33zMeauZeFqPD85eKiYa4Pra2PypEp2_BKNdF3Tw=.5ab80a9f-94bc-4802-9c2a-be702f93e9ba@github.com>

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11298/files
  - new: https://git.openjdk.org/jdk/pull/11298/files/2a0e0975..82998663

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

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

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

From abimpoudis at openjdk.org  Fri Nov 25 10:31:58 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 25 Nov 2022 10:31:58 GMT
Subject: RFR: 8294943: Implement record patterns in enhanced for [v18]
In-Reply-To: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
References: <eeje8MPZRahO_5itA5YsidMgjO6uiOIlkAsLnFqwCYY=.7defeceb-b42e-424e-959c-b62a01b94512@github.com>
Message-ID: <fcoBKuqKL689Fj3l-BV4ZKmemBGqGGODxpbe02N-hJ4=.a0a13ea3-8cdc-42a1-8493-ab46357965aa@github.com>

> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
> 
> 
> record Complex(double real, double img) {}
> 
> List<Complex> list = ...;
> 
> for (Complex(var real, var img) : list) {
>     // can use ?real? and ?img? directly
> }
> 
> 
> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
> 
> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
> - The enhanced for, supports record patterns for both arrays and reference types.
> 
> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
> 
> For more information on the changes please see:
> 
> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
> 
> Looking forward for your review.

Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:

 - Move parsing tests to DisambiguatePatterns.java
 - Fixing handling of brackets in for/enhanced for/pattern enhanced for disambiguation. (#2)
   
   Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10798/files
  - new: https://git.openjdk.org/jdk/pull/10798/files/72264d59..9858ee8c

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

  Stats: 138 lines in 3 files changed: 103 ins; 33 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798

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

From abimpoudis at openjdk.org  Fri Nov 25 11:37:01 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 25 Nov 2022 11:37:01 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
Message-ID: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>

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.

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

Commit messages:
 - 8296012: jshell crashes on mismatched record pattern

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

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

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 abimpoudis at openjdk.org  Sat Nov 26 15:57:15 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 26 Nov 2022 15:57:15 GMT
Subject: Integrated: 8295447: NullPointerException with invalid pattern
 matching construct in constructor call
In-Reply-To: <mlgMQGuS8W7aqLo81LOV3WOXRO-w3q4kjRSt33HU4C0=.4762ab98-a5b8-48a7-93e2-ad1543a9d213@github.com>
References: <mlgMQGuS8W7aqLo81LOV3WOXRO-w3q4kjRSt33HU4C0=.4762ab98-a5b8-48a7-93e2-ad1543a9d213@github.com>
Message-ID: <FgDuiuaxPjebTVSf5zQOS97mUC7YkornW4ETkaFNYn0=.8d2851f8-6ba2-414c-b530-9693a22d16bc@github.com>

On Thu, 20 Oct 2022 11:30:41 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In the examples below:
> 
> 
> int i = (o instanceof Bar(int x))? 0 : 1;
> meth(i);
> 
> 
> 
> meth((o instanceof Bar(int x))? 0 : 1);
> 
> 
> the error `DeconstructionPatternOnlyRecords` was reported only on the first case but the compiler was still crashing in both occasions. `NoType` was passed and `checkCastablePattern` was letting an erroneous type to pass through the subtyping checks. The proposed fix addresses that in `checkCastablePattern`.

This pull request has now been integrated.

Changeset: 6c05771b
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c05771b9be3dd5cbcdb40d2e53cc53959926cdd
Stats:     57 lines in 3 files changed: 56 ins; 0 del; 1 mod

8295447: NullPointerException with invalid pattern matching construct in constructor call

Reviewed-by: vromero

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

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

From aturbanov at openjdk.org  Sun Nov 27 13:19:42 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 27 Nov 2022 13:19:42 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
Message-ID: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>

Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

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

Commit messages:
 - [PATCH] Use Collections.emptyIterator where applicable

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

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

From stsypanov at openjdk.org  Sun Nov 27 13:19:42 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 27 Nov 2022 13:19:42 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
In-Reply-To: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
References: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
Message-ID: <6rFqYLhDhYjxOfHSG050VYx2UXZT9Abc6yktHUS1Q8o=.9445de4e-aadd-4b8a-93b8-195e0f8efb89@github.com>

On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
> Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

LGTM

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

Marked as reviewed by stsypanov (Author).

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

From alanb at openjdk.org  Sun Nov 27 15:34:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Nov 2022 15:34:55 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
In-Reply-To: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
References: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
Message-ID: <DnrMBX7jSE0YBN1SRWgMjbWSKGBgU8fqlpsdyNb36DI=.8e27e4d0-186f-4d5f-b646-5ab273aae853@github.com>

On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
> Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

The change to UnixFileSystem::getRootDirectories looks okay.

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

Marked as reviewed by alanb (Reviewer).

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

From mernst at openjdk.org  Sun Nov 27 17:53:30 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 27 Nov 2022 17:53:30 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>

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

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

Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.

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

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

From jpai at openjdk.org  Mon Nov 28 09:02:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 09:02:13 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
Message-ID: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>

On Sun, 27 Nov 2022 17:49:57 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.

I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

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

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

From 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 jpai at openjdk.org  Mon Nov 28 10:16:24 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:16:24 GMT
Subject: RFR: 8297695: Fix typos in test/langtools files
Message-ID: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>

Can I please get a review of this change which fixes some typos in the `test/langtools` files? This was originally raised by @mernst in https://github.com/openjdk/jdk/pull/10029, but given that the other PR touches multiple other areas and files, progress was stalled.

The commit in this PR only fixes the typos in `test/langtools` files.

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

Commit messages:
 - 8297695: Fix typos in test/langtools files

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

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

From shade at openjdk.org  Mon Nov 28 12:09:08 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Nov 2022 12:09:08 GMT
Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class
 files in current directory [v2]
In-Reply-To: <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>
References: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
 <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>
Message-ID: <7jXzpo2jiJQKxSFTVpuanwyEe1j74uOI0qqL_ZI9IRo=.ed533750-9dce-41f1-b0b0-49206bc04b1a@github.com>

On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
>> ...
>> 
>> $ ls
>> Apan.class
>> ``` 
>> 
>> Additional testing:
>>  - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers
>
> Aleksey Shipilev 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8296645-javac-bench-class-files
>  - Fix indenting
>  - Fix

Anyone? :)

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

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

From redestad at openjdk.org  Mon Nov 28 12:56:34 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 28 Nov 2022 12:56:34 GMT
Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class
 files in current directory [v2]
In-Reply-To: <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>
References: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
 <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>
Message-ID: <HpYrBQTYJF8WVJuE9WFq7Fpb_93IO7D7IzJWnwMCRQM=.4c074988-13ba-46c2-814e-4203ba130934@github.com>

On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
>> ...
>> 
>> $ ls
>> Apan.class
>> ``` 
>> 
>> Additional testing:
>>  - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers
>
> Aleksey Shipilev 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8296645-javac-bench-class-files
>  - Fix indenting
>  - Fix

LGTM

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

Marked as reviewed by redestad (Reviewer).

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

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 prappo at openjdk.org  Mon Nov 28 13:52:21 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 28 Nov 2022 13:52:21 GMT
Subject: RFR: 8297695: Fix typos in test/langtools files
In-Reply-To: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
References: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
Message-ID: <ZAinSq0xFkKRneSCstiNJ9WWVlIg8BlHZvU5-8vvyyM=.fc6f72b5-1e42-4841-a7fc-80c8d0c5f08f@github.com>

On Mon, 28 Nov 2022 10:06:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes some typos in the `test/langtools` files? This was originally raised by @mernst in https://github.com/openjdk/jdk/pull/10029, but given that the other PR touches multiple other areas and files, progress was stalled.
> 
> The commit in this PR only fixes the typos in `test/langtools` files.

Changes to jdk.javadoc test infrastructure look good to me.

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

Marked as reviewed by prappo (Reviewer).

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

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 prappo at openjdk.org  Mon Nov 28 15:04:12 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 28 Nov 2022 15:04:12 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
In-Reply-To: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
References: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
Message-ID: <c9hwrb-rLzgptbzcWoMtWj_ql0SndkSSSpepBOvqcGg=.1968e2b7-5953-4e28-b230-0bc538bd4b80@github.com>

On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
> Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 192:

> 190:                     return allowedList.iterator();
> 191:                 } catch (SecurityException x) {
> 192:                     return Collections.emptyIterator(); //disallowed

Alternatively, you could use the exception parameter to capture that comment:

    } catch (SecurityException disallowed) {

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

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

From vromero at openjdk.org  Mon Nov 28 17:21:29 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Nov 2022 17:21:29 GMT
Subject: RFR: 8295401: Error recovery in module-info.java could be improved
In-Reply-To: <UUh0G7yZZfZJ1sINXAEdnejnC4R_D39aO7R0XP7UtaM=.0211acf3-8942-4b29-a6ba-e67e10baf1ec@github.com>
References: <UUh0G7yZZfZJ1sINXAEdnejnC4R_D39aO7R0XP7UtaM=.0211acf3-8942-4b29-a6ba-e67e10baf1ec@github.com>
Message-ID: <0h4ckrwIOMJuaHMMZB_au05kBW0OqBFhnoObrY2igxU=.a893daa6-8d29-4600-ac6e-5d50a199b3c1@github.com>

On Mon, 17 Oct 2022 14:19:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider an erroneous `module-info.java` like:
> 
> module m {
>     provides javax.util.;
> }
> 
> 
> When javac parses this code, the resulting AST will not contain the (incomplete) directive for provides. This is different from the other directives, which are included, and complicates developing features, like code completion, over the AST.
> 
> The proposal is to simply include the incomplete provides directive in the list of directives.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.org  Mon Nov 28 17:28:53 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Nov 2022 17:28:53 GMT
Subject: RFR: 8296390: Incremental build failed with a NPE
In-Reply-To: <ELodOjBLAO1exPcb_tDxfi_3Mrgaoc_m_cLgBVIZULQ=.ff3b5258-e368-4d1f-98e2-7fbd5f2ce319@github.com>
References: <ELodOjBLAO1exPcb_tDxfi_3Mrgaoc_m_cLgBVIZULQ=.ff3b5258-e368-4d1f-98e2-7fbd5f2ce319@github.com>
Message-ID: <5TTYe4oUrJ7UqxX-yPC6QmVl_LaZMRa263fkhBNQlQ4=.4d855340-0c4d-4cff-bcee-7a33c31fbe74@github.com>

On Fri, 4 Nov 2022 14:05:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> In [Enter](https://github.com/openjdk/jdk/blob/22347e46f7e66a864ea987fa084c44792cae2e6a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java#L617), we finish verification that imports in files are valid. But, if the module graph is not finished yet (modules are not initialized), we defer checking imports in module-infos until the modules are setup.
> 
> What can happen is that `java.base`', if load lazily, may not be completed as part of module system initialization, and can trigger imports check in other module prematurely.
> 
> The proposal is to explicitly complete `java.base` while setting up the compile-time module system. Other (named) modules are normally completed around the same time while [building all modules](https://github.com/openjdk/jdk/blob/22347e46f7e66a864ea987fa084c44792cae2e6a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1414).

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.org  Mon Nov 28 17:31:40 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 28 Nov 2022 17:31:40 GMT
Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a
 reusable module for other JDK tools [v3]
In-Reply-To: <T7QZxCPzluyJvgD23inJkhYALs2Tgt-2tQzDz1rJhc8=.cf466bfe-8276-45de-a637-6962f56566fb@github.com>
References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
 <T7QZxCPzluyJvgD23inJkhYALs2Tgt-2tQzDz1rJhc8=.cf466bfe-8276-45de-a637-6962f56566fb@github.com>
Message-ID: <gvlpLqh85kSUz9_WcUk7WL-cw3uUyT19b3cihUjS-Vc=.9f1a1efc-ff15-47a1-a33a-8cd3cd5ffc2a@github.com>

On Wed, 23 Nov 2022 15:59:42 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules:
>> - `jdk.jartool`
>> - `jdk.jlink`
>> - `jdk.jpackage`
>> 
>> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21)  the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module.
>> 
>> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule".
>> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule".
>> - [x] Remove `CommandLine.java` from `jdk.jartool` module
>> - [x] Remove `CommandLine.java` from `jdk.jlink` module
>> - [x] Remove `CommandLine.java` from `jdk.jpackage` module
>> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ...
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove entire "scary warning" paragraph

Marked as reviewed by jjg (Reviewer).

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

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

From cstein at openjdk.org  Mon Nov 28 17:37:38 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 28 Nov 2022 17:37:38 GMT
Subject: Integrated: 8236919: Refactor com.sun.tools.javac.main.CommandLine
 into a reusable module for other JDK tools
In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com>
Message-ID: <_jaH15voFPIFFZjhJQxCQkfWaRmmDfixLhKiSMGiEjs=.6662aab3-6aae-49f0-b24c-11b78a7cf3d1@github.com>

On Mon, 21 Nov 2022 15:40:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules:
> - `jdk.jartool`
> - `jdk.jlink`
> - `jdk.jpackage`
> 
> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21)  the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module.
> 
> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule".
> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule".
> - [x] Remove `CommandLine.java` from `jdk.jartool` module
> - [x] Remove `CommandLine.java` from `jdk.jlink` module
> - [x] Remove `CommandLine.java` from `jdk.jpackage` module
> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ...

This pull request has now been integrated.

Changeset: a80552e1
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a80552e1e15fba42e0e647248a3d50fa44c5bf53
Stats:     519 lines in 10 files changed: 35 ins; 477 del; 7 mod

8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools

Reviewed-by: jjg

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

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

From archie.cobbs at gmail.com  Mon Nov 28 17:45:41 2022
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 28 Nov 2022 11:45:41 -0600
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <CANSoFxuXWStZv+2oBFo3WO5mvFava6+9ESxS3RUk-PjHp2koEw@mail.gmail.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
 <CANSoFxuXWStZv+2oBFo3WO5mvFava6+9ESxS3RUk-PjHp2koEw@mail.gmail.com>
Message-ID: <CANSoFxv9mMoCaTvAOBR08TkuNooft2kBeTEft7fDFtJOWGjuNw@mail.gmail.com>

It looks like nobody wants to do anything about this issue.

If that's the case, could someone please close JDK-8193904
<https://bugs.openjdk.org/browse/JDK-8193904> (and then I'll retract my PR)?

Thanks,
-Archie

On Fri, Nov 18, 2022 at 9:49 AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Wed, Nov 2, 2022 at 3:18 PM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> On Wed, Nov 2, 2022 at 2:47 PM Alex Buckley <alex.buckley at oracle.com>
>> wrote:
>>
>>> JLS ch.16 is specific that only `foo` and `this.foo` cause an error. See
>>> the definition of "access" in the opening paragraphs of the chapter.
>>>
>>
>> Thanks for pointing that out, which I forgot to do. The JLS language is:
>>
>> An access to its value consists of the simple name of the variable (or,
>> for a field, the simple name of the field qualified by this) occurring
>> anywhere in an expression except as the left-hand operand of the simple
>> assignment operator =
>>
>> In theory one could argue that MyClass.this.foo is also an example of
>> "the simple name of the field qualified by this" - just look at the
>> latter part, no?
>>
>> Regardless, it looks like there needs to be a spec change... right? I'm
>> assuming we'd rather do that than continue to allow the current behavior.
>>
>
> Any further thoughts on this one?
>
> It seems to me that regardless of what you think the right answer is, the
> current situation could use some improvement.
>
> Here's how the compiler currently behaves:
>
> // This class compiles without error
> public class Example1 {
>     final int foo;
>     public Example1() {
>         System.err.println(Example1.this.foo);  // no error generated here
>         this.foo = 42;
>     }
> }
>
> // This class fails to compile
> public class Example2 {
>     private final int foo;
>     public Example2() {
>         Example2.this.foo = 42; // "cannot assign a value to final
> variable foo"
>     }
> }
>
> My thoughts...
>
>    - If the compiler is not following the spec, then we need to fix the
>    compiler
>    - If the compiler is following the spec, then shouldn't the spec be
>    corrected so that it treats Foo.this and this the same way?
>
> In another email Alex said:
>
>> DU/DA analysis is about whether names have bindings. `x.foo` and `new
>>
> C().foo` and `m().foo` are expressions, not names, so we don't attempt
>> the analysis on them. As Jan points out [1], access via expressions is
>> hard to track. `this.foo` is an expression, but a very easy one, so we
>> treat it like the name `foo` and do the analysis. `A.B.C.this.foo` is an
>> expression with a qualified-this subexpression and now you need a bunch
>> of analysis to figure out whether it means the same as the name `foo`.
>
>
> I don't see that you "need a bunch of analysis". The required analysis is
> already being done, for example, when handling expressions that could refer
> to outer 'this' instances. We're not talking about arbitrarily complex
> expressions. The only two options are 'this' or 'this' qualified by a type
> name.
>
> Apologies if I'm missing something, just trying to understand what the
> issue is here.
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221128/1f67e68b/attachment.htm>

From prr at openjdk.org  Mon Nov 28 23:27:55 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Nov 2022 23:27:55 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

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

src/java.desktop/share/classes/java/awt/package-info.java line 58:

> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
> 58:  *                  The Java AWT Native Interface (JAWT)</a>

Why only 1 of these 3 ?

src/java.desktop/share/classes/java/awt/package-info.java line 62:

> 60:  *
> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
> 62:  * @since 1.0

I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
But I also wonder why only the native_interface spec was added and not the other two ?

src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:

> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
> 225:      * @see #TAG_COMPRESSION
> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>

Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?

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

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

From 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 darcy at openjdk.org  Tue Nov 29 04:21:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 29 Nov 2022 04:21:14 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
Message-ID: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>

Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

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

Commit messages:
 - Fix failed HotSpot regression tests.
 - Merge branch 'master' into JDK-8296149
 - Update symbol information to JDK 20 build 24.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbols for JDK 20 b23.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbols for JDK 20 build 22.
 - Update expected GA date.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/105d9d75...5810345e

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

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

From darcy at openjdk.org  Tue Nov 29 04:21:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 29 Nov 2022 04:21:14 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <TGeJqrnxUet9tYSc3IHlT70IZWweJTiXs9JgVYlU2BA=.ce15b8cc-f341-42fe-b944-33d07ab90e80@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Flipping the draft-bit off for this PR ahead of the upcoming start of JDK 21.

Symbol information now up-to-date as of JDK 20 b25.

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

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

From dholmes at openjdk.org  Tue Nov 29 04:52:28 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Nov 2022 04:52:28 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

I looked at everything bar the sym files. All seems fine/usual.

One query below (probably one I ask each release).

Thanks.

src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java line 47:

> 45:  * @since 14
> 46:  */
> 47: @SupportedSourceVersion(RELEASE_21)

It is a pity these have to be updated each release. Is there no way to say `latest` here?

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

Marked as reviewed by dholmes (Reviewer).

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

From darcy at openjdk.org  Tue Nov 29 05:15:25 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 29 Nov 2022 05:15:25 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com>
Message-ID: <K_tK32mL4luBi0Wbhkx2c2nsRt4FvZi0FZvjAW6LlCc=.c5708fc8-1ef9-4f91-97c4-5f737d1266df@github.com>

On Tue, 29 Nov 2022 04:45:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java line 47:
> 
>> 45:  * @since 14
>> 46:  */
>> 47: @SupportedSourceVersion(RELEASE_21)
> 
> It is a pity these have to be updated each release. Is there no way to say `latest` here?

Not with the current language specification, no.

The only enum value "constant-enough" to use in an annotation is the name of an enum constant, a public static final field assigned an enum value is not enough.

On the flip side, I make the updates to these annotations using a one-line sed script I have saved away in a comment on one of the previous start-of-release-updates-for-JDK-N bugs. Using the annotations in this way is in lieu of adding another type specification for the JDK version. In other words, having AbstractAnnotationValueVisitor**14**.java with an annotation indicating RELEASE_21 prevents having AbstractAnnotationValueVisitor15, AbstractAnnotationValueVisitor16, ... , AbstractAnnotationValueVisitor21.

New visitors are now only introduced when adding new kinds of structures requires differences in behavior.

Thanks for the review.

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

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

From jpai at openjdk.org  Tue Nov 29 06:03:33 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 06:03:33 GMT
Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class
 files in current directory [v2]
In-Reply-To: <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>
References: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
 <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>
Message-ID: <GzmbDkk-qikvATVo9TQkNqDSAk1WQsKr1I0DlHD5Bb4=.6edad44b-8f92-4147-b279-acce50525c46@github.com>

On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
>> ...
>> 
>> $ ls
>> Apan.class
>> ``` 
>> 
>> Additional testing:
>>  - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers
>
> Aleksey Shipilev 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8296645-javac-bench-class-files
>  - Fix indenting
>  - Fix

Looks fine to me. The copyright year will need an update.

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

Marked as reviewed by jpai (Reviewer).

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

From iris at openjdk.org  Tue Nov 29 07:29:53 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 29 Nov 2022 07:29:53 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <3XmL-mIaH-juXigTJOSqPUWTLRwlBBvpYhpjQRLKofk=.e05f97cb-2ed6-468f-8184-07a0935c9645@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Marked as reviewed by iris (Reviewer).

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

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

From shade at openjdk.org  Tue Nov 29 11:08:51 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Nov 2022 11:08:51 GMT
Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class
 files in current directory [v2]
In-Reply-To: <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>
References: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
 <qIeE-IxQpA5fqGRQVJ-pM-VPkoyZG-ycP6a4YuDJ5R8=.b89f444d-6fbc-4b43-ad84-16b9a93a9f6f@github.com>
Message-ID: <mMgY7gHUePmS3hgEv03C1hHMlG8mZkIOzd03NL2qObo=.9ad2e481-c39a-4c68-b7f3-3d476933c55d@github.com>

On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
>> ...
>> 
>> $ ls
>> Apan.class
>> ``` 
>> 
>> Additional testing:
>>  - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers
>
> Aleksey Shipilev 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8296645-javac-bench-class-files
>  - Fix indenting
>  - Fix

Thanks!

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

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

From shade at openjdk.org  Tue Nov 29 11:12:14 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Nov 2022 11:12:14 GMT
Subject: Integrated: 8296645: org.openjdk.bench.javax.tools.Javac leaves class
 files in current directory
In-Reply-To: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
References: <f_jU5gQvIkrKeW0ZfI3zVlbD9Iwe7wBLhcdCnhCc53s=.3a4b48c3-363f-407a-a081-b30f54a6dd56@github.com>
Message-ID: <AQEEvQpfZNaLYABKKGUawwKFaAwglTe6gniXW4eCAew=.112cf956-95a1-46ca-8640-d39eb107996c@github.com>

On Wed, 9 Nov 2022 09:00:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
> ...
> 
> $ ls
> Apan.class
> ``` 
> 
> Additional testing:
>  - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers

This pull request has now been integrated.

Changeset: bd51b7ea
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd51b7ea43b210ea07399b09d61c366594ac2cfd
Stats:     24 lines in 1 file changed: 23 ins; 0 del; 1 mod

8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory

Reviewed-by: redestad, jpai

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

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

From erikj at openjdk.org  Tue Nov 29 13:45:40 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 29 Nov 2022 13:45:40 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <t5vqaVJlp2R8PZy9nWDCDosphMLcV1DWzNRVEUBRKPs=.d143f6c5-190f-452e-ad97-07d1767a73d6@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Marked as reviewed by erikj (Reviewer).

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

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

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 cstein at openjdk.org  Tue Nov 29 14:52:57 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 29 Nov 2022 14:52:57 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
Message-ID: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>

Please review the change to update to using jtreg `7.1`.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This pull request was created by copying the following and using `7.1` at appropriate places:
- https://github.com/openjdk/jdk/pull/9393

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

Commit messages:
 - 8296710: Update to use jtreg 7.1

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

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

From alanb at openjdk.org  Tue Nov 29 16:09:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 16:09:24 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <H9LOzHSfN7PLpiF6oYdnlHFQLasj6FeRgZKUKm3XyXs=.591ef716-45eb-4bf5-a6d5-d9ebe887d82a@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Can you confirm that you've run all the tests with the change? Sometimes these updates need changes to a small number of tests.

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

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

From vromero at openjdk.org  Tue Nov 29 17:33:19 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 29 Nov 2022 17:33:19 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <mwcnBufA38Ydk1N9ghfGFvveyqmVXTmVmymYeUc4CAM=.10c9a603-813c-4404-b8ee-9afff26dce81@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vicente.romero at oracle.com  Tue Nov 29 17:40:32 2022
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 29 Nov 2022 12:40:32 -0500
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <CANSoFxv9mMoCaTvAOBR08TkuNooft2kBeTEft7fDFtJOWGjuNw@mail.gmail.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
 <CANSoFxuXWStZv+2oBFo3WO5mvFava6+9ESxS3RUk-PjHp2koEw@mail.gmail.com>
 <CANSoFxv9mMoCaTvAOBR08TkuNooft2kBeTEft7fDFtJOWGjuNw@mail.gmail.com>
Message-ID: <a5978712-38ab-ff46-e6a9-4791b70190ee@oracle.com>

Hi,

I think that given that we are so close to closing the development for 
20 that we push this early on 21 after the fork for 20 has been done,

Thanks,
Vicente

On 11/28/22 12:45, Archie Cobbs wrote:
> It looks like nobody wants to do anything about this issue.
>
> If that's the case, could someone please close JDK-8193904 
> <https://bugs.openjdk.org/browse/JDK-8193904> (and then I'll retract 
> my PR)?
>
> Thanks,
> -Archie
>
> On Fri, Nov 18, 2022 at 9:49 AM Archie Cobbs <archie.cobbs at gmail.com> 
> wrote:
>
>     On Wed, Nov 2, 2022 at 3:18 PM Archie Cobbs
>     <archie.cobbs at gmail.com> wrote:
>
>         On Wed, Nov 2, 2022 at 2:47 PM Alex Buckley
>         <alex.buckley at oracle.com> wrote:
>
>             JLS ch.16 is specific that only `foo` and `this.foo` cause
>             an error. See
>             the definition of "access" in the opening paragraphs of
>             the chapter.
>
>
>         Thanks for pointing that out, which I forgot to do. The JLS
>         language is:
>
>         An access to its value consists of the simple name of the
>         variable (or, for a field, the simple name of the field
>         qualified by |this|) occurring anywhere in an expression
>         except as the left-hand operand of the simple assignment
>         operator |=| ||
>
>         In theory one could argue that MyClass.this.foo is also an
>         example of "the simple name of the field qualified by |this" -
>         just look at the latter part, no?
>         |
>         |
>         |
>         Regardless, it looks like there needs to be a spec change...
>         right? I'm assuming we'd rather do that than continue to allow
>         the current behavior.
>
>     Any further thoughts on this one?
>
>     It seems to me that regardless of what you think the right answer
>     is, the current situation could use some improvement.
>
>     Here's how the compiler currently behaves:
>
>     // This class compiles without error
>     public class Example1 {
>     ? ? final int foo;
>     ? ? public Example1() {
>     System.err.println(Example1.this.foo);? // no error generated here
>     ? ? ? ? this.foo = 42;
>     ? ? }
>     }
>
>     // This class fails to compile
>     public class Example2 {
>     ? ? private final int foo;
>     ? ? public Example2() {
>     ? ? ? ? Example2.this.foo = 42; // "cannot assign a value to final
>     variable foo"
>     ? ? }
>     }
>
>     My thoughts...
>
>       * If the compiler is not following the spec, then we need to fix
>         the compiler
>       * If the compiler is following the spec, then shouldn't the spec
>         be corrected so that it treats Foo.this and this the same way?
>
>     In another email Alex said:
>
>         DU/DA analysis is about whether names have bindings. `x.foo`
>         and `new
>
>         C().foo` and `m().foo` are expressions, not names, so we don't
>         attempt
>         the analysis on them. As Jan points out [1], access via
>         expressions is
>         hard to track. `this.foo` is an expression, but a very easy
>         one, so we
>         treat it like the name `foo` and do the analysis.
>         `A.B.C.this.foo` is an
>         expression with a qualified-this subexpression and now you
>         need a bunch
>         of analysis to figure out whether it means the same as the
>         name `foo`.
>
>
>     I don't see that you "need a bunch of analysis". The required
>     analysis is already being done, for example, when handling
>     expressions that could refer to outer 'this' instances. We're not
>     talking about arbitrarily complex expressions. The only two
>     options are 'this' or 'this' qualified by a type name.
>
>     Apologies if I'm missing something, just trying to understand what
>     the issue is here.
>
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221129/2a60b592/attachment-0001.htm>

From erikj at openjdk.org  Tue Nov 29 17:57:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 29 Nov 2022 17:57:22 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <3MbFV3Yz1mkexhdEMXTtpXXGdr-yJvvM7Z9FyyVu9Do=.2c003086-a5b8-45f7-86d0-4574425677c7@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Marked as reviewed by erikj (Reviewer).

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

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

From archie.cobbs at gmail.com  Tue Nov 29 18:02:45 2022
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 29 Nov 2022 12:02:45 -0600
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <a5978712-38ab-ff46-e6a9-4791b70190ee@oracle.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
 <CANSoFxuXWStZv+2oBFo3WO5mvFava6+9ESxS3RUk-PjHp2koEw@mail.gmail.com>
 <CANSoFxv9mMoCaTvAOBR08TkuNooft2kBeTEft7fDFtJOWGjuNw@mail.gmail.com>
 <a5978712-38ab-ff46-e6a9-4791b70190ee@oracle.com>
Message-ID: <CANSoFxtGd-yzutFbD5gwU1sAmqzOaGFAxa6matrzD6_1dFt1QA@mail.gmail.com>

Hi Vicente,

On Tue, Nov 29, 2022 at 11:45 AM Vicente Romero <vicente.romero at oracle.com>
wrote:

> I think that given that we are so close to closing the development for 20
> that we push this early on 21 after the fork for 20 has been done,
>

That makes sense.

(Thank you for replying!)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221129/e8db7ab4/attachment.htm>

From vicente.romero at oracle.com  Tue Nov 29 18:11:56 2022
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 29 Nov 2022 13:11:56 -0500
Subject: [External] : Re: RFR: 8193904: Uninitialized final field access
 and qualified this
In-Reply-To: <CANSoFxtGd-yzutFbD5gwU1sAmqzOaGFAxa6matrzD6_1dFt1QA@mail.gmail.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
 <CANSoFxuXWStZv+2oBFo3WO5mvFava6+9ESxS3RUk-PjHp2koEw@mail.gmail.com>
 <CANSoFxv9mMoCaTvAOBR08TkuNooft2kBeTEft7fDFtJOWGjuNw@mail.gmail.com>
 <a5978712-38ab-ff46-e6a9-4791b70190ee@oracle.com>
 <CANSoFxtGd-yzutFbD5gwU1sAmqzOaGFAxa6matrzD6_1dFt1QA@mail.gmail.com>
Message-ID: <0e31b146-8d3f-795e-86c7-df9d6ba534c1@oracle.com>



On 11/29/22 13:02, Archie Cobbs wrote:
> Hi Vicente,
>
> On Tue, Nov 29, 2022 at 11:45 AM Vicente Romero 
> <vicente.romero at oracle.com> wrote:
>
>     I think that given that we are so close to closing the development
>     for 20 that we push this early on 21 after the fork for 20 has
>     been done,
>
>
> That makes sense.
>
> (Thank you for replying!)

sure np,

>
> -Archie
>
> -- 
> Archie L. Cobbs

Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221129/7f5542f3/attachment.htm>

From vromero at openjdk.org  Tue Nov 29 18:18:23 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 29 Nov 2022 18:18:23 GMT
Subject: RFR: 8193904: Uninitialized final field access and qualified this
 [v2]
In-Reply-To: <2p11BvHQ9v3hUxKasK-izVlTleuJkdxSLIJ7HVu0sH4=.857f50c9-6eea-4239-aa6f-1c300aa0b497@github.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <2p11BvHQ9v3hUxKasK-izVlTleuJkdxSLIJ7HVu0sH4=.857f50c9-6eea-4239-aa6f-1c300aa0b497@github.com>
Message-ID: <hxeMQwI-Ly2vXjdFA_WuC_VGKalN-B6vfZgnr_DHB6M=.821063c4-6431-4618-ad15-5f468f4ccf61@github.com>

On Thu, 17 Nov 2022 19:10:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> If a class `MyClass` has a blank final field `foo` that has not yet been assigned, the compiler prevents you from accessing it via the expressions `foo` or `this.foo`. However, it does not prevent you from accessing it via the expression `MyClass.this.foo`.
>> 
>> Here's a simple example:
>> 
>> class QualifiedThis {
>>     final int foo;
>>     QualifiedThis() {
>>         System.err.println(QualifiedThis.this.foo);   // should get an error here
>>         this.foo = 42;
>>     }
>> }
>> 
>> 
>> This patch fixes that omission.
>> 
>> I couldn't find an existing method that answers the question "Is this AST tree a reference to the current instance of the class I'm now compiling?" so I wrote a new one `TreeInfo.isThisReference()`.
>> 
>> The question itself is a little tricky. For example, `this` alone always is, but `Foo.this` is if the class being compiled is `Foo` or any supertype of `Foo`, *except* when `Foo` is an outer class containing the class being compiled, when it instead refers to that outer instance.
>> 
>> On the other hand, `Foo.super` (which, unlike `Foo.this`, can only be used to invoke a method), when `Foo` is a type and not a variable, refers to the current 'this' instance when the class being compiled is `Foo` or any supertype of `Foo`, period.
>
> Archie L. Cobbs 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 three additional commits since the last revision:
> 
>  - Replace any remaining uses of TreeInfo.isThisQualifier().
>    
>    Bug 8193904 describes how "A.this.foo" is not detected as an early reference to
>    the uninitialized final variable "foo". There is also a flip-side to this bug,
>    which is that "A.this.foo = ..." is not accepted as a valid assignment to the
>    uninitialized final variable "foo". This commit fixes that part of the bug.
>    
>    Also do some minor refactoring for clarity.
>  - Merge branch 'master' into JDK-8193904
>  - Disallow early access to final fields via qualified 'this'.

we should push this one early on JDK 21, a bit late for 20 already

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

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

From alex.buckley at oracle.com  Tue Nov 29 18:35:34 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 29 Nov 2022 10:35:34 -0800
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <a5978712-38ab-ff46-e6a9-4791b70190ee@oracle.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
 <CANSoFxuXWStZv+2oBFo3WO5mvFava6+9ESxS3RUk-PjHp2koEw@mail.gmail.com>
 <CANSoFxv9mMoCaTvAOBR08TkuNooft2kBeTEft7fDFtJOWGjuNw@mail.gmail.com>
 <a5978712-38ab-ff46-e6a9-4791b70190ee@oracle.com>
Message-ID: <3b09867c-e687-4379-908a-2110825b1029@oracle.com>

IIRC this javac change first requires a JLS change to specify the 
analysis of the receiver (the entity whose self is being accessed via 
qualified this).

Alex

On 11/29/2022 9:40 AM, Vicente Romero wrote:
> Hi,
> 
> I think that given that we are so close to closing the development for 
> 20 that we push this early on 21 after the fork for 20 has been done,
> 
> Thanks,
> Vicente
> 
> On 11/28/22 12:45, Archie Cobbs wrote:
>> It looks like nobody wants to do anything about this issue.
>>
>> If that's the case, could someone please close JDK-8193904 
>> <https://bugs.openjdk.org/browse/JDK-8193904> (and then I'll retract 
>> my PR)?
>>
>> Thanks,
>> -Archie
>>
>> On Fri, Nov 18, 2022 at 9:49 AM Archie Cobbs <archie.cobbs at gmail.com> 
>> wrote:
>>
>>     On Wed, Nov 2, 2022 at 3:18 PM Archie Cobbs
>>     <archie.cobbs at gmail.com> wrote:
>>
>>         On Wed, Nov 2, 2022 at 2:47 PM Alex Buckley
>>         <alex.buckley at oracle.com> wrote:
>>
>>             JLS ch.16 is specific that only `foo` and `this.foo` cause
>>             an error. See
>>             the definition of "access" in the opening paragraphs of
>>             the chapter.
>>
>>
>>         Thanks for pointing that out, which I forgot to do. The JLS
>>         language is:
>>
>>         An access to its value consists of the simple name of the
>>         variable (or, for a field, the simple name of the field
>>         qualified by |this|) occurring anywhere in an expression
>>         except as the left-hand operand of the simple assignment
>>         operator |=| ||
>>
>>         In theory one could argue that MyClass.this.foo is also an
>>         example of "the simple name of the field qualified by |this" -
>>         just look at the latter part, no?
>>         |
>>         |
>>         |
>>         Regardless, it looks like there needs to be a spec change...
>>         right? I'm assuming we'd rather do that than continue to allow
>>         the current behavior.
>>
>>     Any further thoughts on this one?
>>
>>     It seems to me that regardless of what you think the right answer
>>     is, the current situation could use some improvement.
>>
>>     Here's how the compiler currently behaves:
>>
>>     // This class compiles without error
>>     public class Example1 {
>>     ? ? final int foo;
>>     ? ? public Example1() {
>>     System.err.println(Example1.this.foo);? // no error generated here
>>     ? ? ? ? this.foo = 42;
>>     ? ? }
>>     }
>>
>>     // This class fails to compile
>>     public class Example2 {
>>     ? ? private final int foo;
>>     ? ? public Example2() {
>>     ? ? ? ? Example2.this.foo = 42; // "cannot assign a value to final
>>     variable foo"
>>     ? ? }
>>     }
>>
>>     My thoughts...
>>
>>       * If the compiler is not following the spec, then we need to fix
>>         the compiler
>>       * If the compiler is following the spec, then shouldn't the spec
>>         be corrected so that it treats Foo.this and this the same way?
>>
>>     In another email Alex said:
>>
>>         DU/DA analysis is about whether names have bindings. `x.foo`
>>         and `new
>>
>>         C().foo` and `m().foo` are expressions, not names, so we don't
>>         attempt
>>         the analysis on them. As Jan points out [1], access via
>>         expressions is
>>         hard to track. `this.foo` is an expression, but a very easy
>>         one, so we
>>         treat it like the name `foo` and do the analysis.
>>         `A.B.C.this.foo` is an
>>         expression with a qualified-this subexpression and now you
>>         need a bunch
>>         of analysis to figure out whether it means the same as the
>>         name `foo`.
>>
>>
>>     I don't see that you "need a bunch of analysis". The required
>>     analysis is already being done, for example, when handling
>>     expressions that could refer to outer 'this' instances. We're not
>>     talking about arbitrarily complex expressions. The only two
>>     options are 'this' or 'this' qualified by a type name.
>>
>>     Apologies if I'm missing something, just trying to understand what
>>     the issue is here.
>>
>>
>> -- 
>> Archie L. Cobbs
> 

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 archie.cobbs at gmail.com  Tue Nov 29 18:54:33 2022
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 29 Nov 2022 12:54:33 -0600
Subject: RFR: 8193904: Uninitialized final field access and qualified this
In-Reply-To: <3b09867c-e687-4379-908a-2110825b1029@oracle.com>
References: <xTm1WEk7VxHsLKUK8xuaB4Jq1ak2mhW2URd_n8hFhu0=.2ca1371f-edf8-4b51-9619-429805cce112@github.com>
 <bc10da44-e139-7042-0632-14e0d6754c59@oracle.com>
 <CANSoFxsE-T-8Wc_m9xP8iEzheE+amO0uwKGxEfwv0P3+-xTo+A@mail.gmail.com>
 <CANSoFxuXWStZv+2oBFo3WO5mvFava6+9ESxS3RUk-PjHp2koEw@mail.gmail.com>
 <CANSoFxv9mMoCaTvAOBR08TkuNooft2kBeTEft7fDFtJOWGjuNw@mail.gmail.com>
 <a5978712-38ab-ff46-e6a9-4791b70190ee@oracle.com>
 <3b09867c-e687-4379-908a-2110825b1029@oracle.com>
Message-ID: <CANSoFxt1MUQXay=K8jR3jjpxYsWxaRt9Ythsix9sBFeUjaqjNw@mail.gmail.com>

On Tue, Nov 29, 2022 at 12:36 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> IIRC this javac change first requires a JLS change to specify the
> analysis of the receiver (the entity whose self is being accessed via
> qualified this).
>

Yes I think so... where would be the appropriate place to propose and
discuss that JLS change? amber-dev? or here?

It doesn't look like csr-discuss is very active (one unanswered email in
over two years).

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221129/fad79509/attachment-0001.htm>

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 mernst at openjdk.org  Tue Nov 29 20:26:16 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 29 Nov 2022 20:26:16 GMT
Subject: RFR: 8297695: Fix typos in test/langtools files
In-Reply-To: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
References: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
Message-ID: <ZUewX9tWLgQZDYClpRA1K7i9IFME1zK_ydXP7P2F8lI=.f2873647-64ca-4216-9b15-55753292f151@github.com>

On Mon, 28 Nov 2022 10:06:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes some typos in the `test/langtools` files? This was originally raised by @mernst in https://github.com/openjdk/jdk/pull/10029, but given that the other PR touches multiple other areas and files, progress was stalled.
> 
> The commit in this PR only fixes the typos in `test/langtools` files.

@jaikiran Many thanks for your help with this pull request.

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

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

From jjg at openjdk.org  Tue Nov 29 20:55:19 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 29 Nov 2022 20:55:19 GMT
Subject: RFR: 8297695: Fix typos in test/langtools files
In-Reply-To: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
References: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
Message-ID: <pIT_n199NnW-XokPnPopy5Sso8YE-XRhqW7K9slF7Xc=.1143c849-b092-44e0-8a50-59e78c2c5c83@github.com>

On Mon, 28 Nov 2022 10:06:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes some typos in the `test/langtools` files? This was originally raised by @mernst in https://github.com/openjdk/jdk/pull/10029, but given that the other PR touches multiple other areas and files, progress was stalled.
> 
> The commit in this PR only fixes the typos in `test/langtools` files.

Marked as reviewed by jjg (Reviewer).

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

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

From iris at openjdk.org  Tue Nov 29 21:51:46 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 29 Nov 2022 21:51:46 GMT
Subject: RFR: 8297695: Fix typos in test/langtools files
In-Reply-To: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
References: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
Message-ID: <_3CwlvThzVoLzrpTQimDAbQTlEUuv923hf0nNGSupc8=.61e6754d-01a2-4ab4-a529-082093ba2916@github.com>

On Mon, 28 Nov 2022 10:06:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes some typos in the `test/langtools` files? This was originally raised by @mernst in https://github.com/openjdk/jdk/pull/10029, but given that the other PR touches multiple other areas and files, progress was stalled.
> 
> The commit in this PR only fixes the typos in `test/langtools` files.

Marked as reviewed by iris (Reviewer).

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

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

From peter.firmstone at zeus.net.au  Tue Nov  1 08:07:20 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 01 Nov 2022 08:07:20 -0000
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@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>
 <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@github.com>
Message-ID: <bdecb2f9-b1a9-332f-58a2-4ff0ce75706c@zeus.net.au>

On 1/11/2022 5:52 pm, Alan Bateman wrote:
> 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.

We found there were some common cases, we made static convenience 
methods to address them:

Fix MS Windows file URI strings, by converting back slashes to forward 
slashes and inserting a forward slash before the drive letter if missing.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L289

Convert java.io.File to Uri, ensure compatibility with URLClassLoader, 
when trailing directory character is dropped by java.io.File.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L341

Escape illegal characters when string doesn't contain any existing 
escape sequences.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L926

Parse and fix a string that contains escaped sequences, any illegal 
characters are escaped and any that should't be escaped are un-escaped.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L939

Convert java.net.URL to Uri, automatically fixing MS Windows URI syntax.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L324

Cheers,

Peter.


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

From mstjohns at comcast.net  Tue Nov 29 03:14:20 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 28 Nov 2022 22:14:20 -0500
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
Message-ID: <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net>

Hi -

I need to repeat again.? Please avoid using www.ietf.org as the URL base 
for referencing RFCs.? The appropriate location is www.rfc-editor.org 
and is going to be more stable in the long run than any reference to an 
RFC that runs through the IETF's website.? These two websites have 
different purposes, and the structure of the IETF website has changed at 
least once recently and may change again relatively (~5 years) soon.

The most general and correct form for referencing RFCs is 
"https://www.rfc-editor.org/info/rfc<number>"? That will get you to the 
front page with pointers to all of the current semi-canonical versions 
of the spec (e.g. text, pdf-a, html, and xml).

Mike



On 11/28/2022 6:27 PM, Phil Race wrote:
> On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>
>>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>>>
>>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>>>
>>> "Normalized" means...
>>> * Use `https:` where possible (includes pretty much all cases)
>>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>>> * Point to the root page of a multi-page spec
>>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>>>
>>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>>>
>>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>>>
>>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>>>
>>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>>>
>>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>>>
>>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Remove updates from unexported files
> src/java.desktop/share/classes/java/awt/package-info.java line 58:
>
>> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
>> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
>> 58:  *                  The Java AWT Native Interface (JAWT)</a>
> Why only 1 of these 3 ?
>
> src/java.desktop/share/classes/java/awt/package-info.java line 62:
>
>> 60:  *
>> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
>> 62:  * @since 1.0
> I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
> But I also wonder why only the native_interface spec was added and not the other two ?
>
> src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:
>
>> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
>> 225:      * @see #TAG_COMPRESSION
>> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>
> Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11073



From jpai at openjdk.org  Wed Nov 30 00:43:19 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:43:19 GMT
Subject: RFR: 8297695: Fix typos in test/langtools files
In-Reply-To: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
References: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
Message-ID: <-JGp4yQRQ7CVGLpFS_fMkaEU90thfrtT2NY-1QnAChA=.8ec5b541-f2ee-4a83-b7a4-41549c9a4ce0@github.com>

On Mon, 28 Nov 2022 10:06:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes some typos in the `test/langtools` files? This was originally raised by @mernst in https://github.com/openjdk/jdk/pull/10029, but given that the other PR touches multiple other areas and files, progress was stalled.
> 
> The commit in this PR only fixes the typos in `test/langtools` files.

Thank you everyone for the reviews.

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

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

From jpai at openjdk.org  Wed Nov 30 00:45:24 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:45:24 GMT
Subject: Integrated: 8297695: Fix typos in test/langtools files
In-Reply-To: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
References: <v0JVvxa70TXMqw1bezwhtVMwRhphWhxY_4ueHNjWepM=.1305f2af-02f3-4111-8b9e-9d73541c0020@github.com>
Message-ID: <QN6O7r1gJNbYyjpoU1PdcutOm6NOUJdEKI5ukYt5bUE=.7522e2bf-acad-4514-a1a5-d21491dfff5d@github.com>

On Mon, 28 Nov 2022 10:06:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes some typos in the `test/langtools` files? This was originally raised by @mernst in https://github.com/openjdk/jdk/pull/10029, but given that the other PR touches multiple other areas and files, progress was stalled.
> 
> The commit in this PR only fixes the typos in `test/langtools` files.

This pull request has now been integrated.

Changeset: e10778ac
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e10778accef05bb17eea20d589086b50e366dc4d
Stats:     12 lines in 10 files changed: 0 ins; 0 del; 12 mod

8297695: Fix typos in test/langtools files

Co-authored-by: Michael Ernst <mernst at openjdk.org>
Reviewed-by: prappo, jjg, iris

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

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

From jlahoda at openjdk.org  Wed Nov 30 09:50:40 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Nov 2022 09:50:40 GMT
Subject: Integrated: 8296390: Incremental build failed with a NPE
In-Reply-To: <ELodOjBLAO1exPcb_tDxfi_3Mrgaoc_m_cLgBVIZULQ=.ff3b5258-e368-4d1f-98e2-7fbd5f2ce319@github.com>
References: <ELodOjBLAO1exPcb_tDxfi_3Mrgaoc_m_cLgBVIZULQ=.ff3b5258-e368-4d1f-98e2-7fbd5f2ce319@github.com>
Message-ID: <BfuBGTdJxL4UI3qHmN5KszJqIBQKsN6HTw7kRiMKxg8=.c8871929-9feb-4e4c-8bb4-b280a9a9f2c7@github.com>

On Fri, 4 Nov 2022 14:05:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> In [Enter](https://github.com/openjdk/jdk/blob/22347e46f7e66a864ea987fa084c44792cae2e6a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java#L617), we finish verification that imports in files are valid. But, if the module graph is not finished yet (modules are not initialized), we defer checking imports in module-infos until the modules are setup.
> 
> What can happen is that `java.base`', if load lazily, may not be completed as part of module system initialization, and can trigger imports check in other module prematurely.
> 
> The proposal is to explicitly complete `java.base` while setting up the compile-time module system. Other (named) modules are normally completed around the same time while [building all modules](https://github.com/openjdk/jdk/blob/22347e46f7e66a864ea987fa084c44792cae2e6a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java#L1414).

This pull request has now been integrated.

Changeset: 9e80cf9c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e80cf9c37f4dbc6e176a59dce92817c109dd561
Stats:     40 lines in 2 files changed: 39 ins; 0 del; 1 mod

8296390: Incremental build failed with a NPE

Reviewed-by: vromero

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

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

From alanb at openjdk.org  Wed Nov 30 09:51:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 09:51:26 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <-n11nKKODtr-Mua5vvwmAVEvevjYu2pv3iSzs7tIzzU=.2c8711c8-daab-42b4-a186-4c3f71b4bc73@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Christian has confirmed on the testing so I think this is good.

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

Marked as reviewed by alanb (Reviewer).

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

From jlahoda at openjdk.org  Wed Nov 30 09:52:49 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Nov 2022 09:52:49 GMT
Subject: Integrated: 8295401: Error recovery in module-info.java could be
 improved
In-Reply-To: <UUh0G7yZZfZJ1sINXAEdnejnC4R_D39aO7R0XP7UtaM=.0211acf3-8942-4b29-a6ba-e67e10baf1ec@github.com>
References: <UUh0G7yZZfZJ1sINXAEdnejnC4R_D39aO7R0XP7UtaM=.0211acf3-8942-4b29-a6ba-e67e10baf1ec@github.com>
Message-ID: <3dPiXlm2Z05SUuO--zwYDh51SmS08XjA7o8matoJAtI=.76b13092-0488-4760-bde0-cac9f8a32f13@github.com>

On Mon, 17 Oct 2022 14:19:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider an erroneous `module-info.java` like:
> 
> module m {
>     provides javax.util.;
> }
> 
> 
> When javac parses this code, the resulting AST will not contain the (incomplete) directive for provides. This is different from the other directives, which are included, and complicates developing features, like code completion, over the AST.
> 
> The proposal is to simply include the incomplete provides directive in the list of directives.

This pull request has now been integrated.

Changeset: b52611bc
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b52611bc36d4fa7b62d1bb1618aa5185f75bf5d0
Stats:     83 lines in 2 files changed: 77 ins; 2 del; 4 mod

8295401: Error recovery in module-info.java could be improved

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Wed Nov 30 13:35:05 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Nov 2022 13:35:05 GMT
Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second
 Preview) [v8]
In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com>
Message-ID: <rZS9pn1agt-3ucdwgl7zzxIdeQj-tgGgqDklg9OQh5M=.656d33e5-d993-4ad5-8929-aeb2f96f07c8@github.com>

> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements:
> 
>  - removal of named record patterns
>  - (preview) type inference for type test and record patterns
>  - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns)
>  - fixing exhaustiveness of certain switches
> 
> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798).
> 
> For more information on the changes please see:
>  - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433)
>  - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946)
>  - the current [specification draft](http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html)
> 
> Current total specdiff for both this PR and [the enhanced for PR](https://github.com/openjdk/jdk/pull/10798) is [here](http://cr.openjdk.java.net/~jlahoda/8294945/specdiff.preliminary.00/overview-summary.html).
> 
> Any feedback is welcome.
> 
> Thanks!

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into JDK-8294942
 - Merge branch 'master' into JDK-8294942
 - Using skipTypeVars as suggested.
 - Reflecting review feedback - proper handling of type vars and intersection types.
 - Not looking for common supertype, not solving in a loop.
 - Reflecting review comment.
 - Apply suggestions from code review
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Better tests for inference with recursive bounds, and related fixes.
 - Adding a kind to InstanceOfTree, as suggested.
 - Reflecting review feedback.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/7af6b4b5...4d01e003

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

Changes: https://git.openjdk.org/jdk/pull/10814/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10814&range=07
  Stats: 1565 lines in 39 files changed: 1176 ins; 279 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/10814.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10814/head:pull/10814

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

From vromero at openjdk.org  Wed Nov 30 17:31:17 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 30 Nov 2022 17:31:17 GMT
Subject: RFR: 8297294: compiler/c2/irTests/TestMulNodeIdealization.java failed
 compilation
Message-ID: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>

Given that the reported issue is intermittent I think we have two options here:

- change the most probable use of a non-deterministic data structure that could be provoking this bug, to a deterministic one
- change all uses of non-deterministic data structures

The current fix is going for the first option, if preferred I can provide another patch that fixes all uses of non-deterministic data structures in our inference engine. I don't think we will have any performance impact going for the second option but it could be unnecessary.

Comments?
TIA

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

Commit messages:
 - 8297294: compiler/c2/irTests/TestMulNodeIdealization.java failed compilation

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

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

From duke at openjdk.org  Wed Nov 30 18:24:25 2022
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 30 Nov 2022 18:24:25 GMT
Subject: RFR: 8297294: compiler/c2/irTests/TestMulNodeIdealization.java
 failed compilation
In-Reply-To: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>
References: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>
Message-ID: <09RU6-ocSvunZPgjuveojjZ2yUhSO1VZY157jHOWIrs=.6e052380-edff-49d6-b5da-3224ac8e6851@github.com>

On Wed, 30 Nov 2022 17:20:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Given that the reported issue is intermittent I think we have two options here:
> 
> - change the most probable use of a non-deterministic data structure that could be provoking this bug, to a deterministic one
> - change all uses of non-deterministic data structures
> 
> The current fix is going for the first option, if preferred I can provide another patch that fixes all uses of non-deterministic data structures in our inference engine. I don't think we will have any performance impact going for the second option but it could be unnecessary.
> 
> Comments?
> TIA

So just to confirm: while clearly changing `HashSet` to `LinkedHashSet` is going to eliminate some non-determinism, it also fixes the actual compiler logic bug rather than "papering over" it, correct?

If not - then is more investigation warranted?

If so - then doesn't that imply that the code that invokes `closure()` contains an implicit assumption about the ordering of the elements of that returned `Set`? And if so,?since that's a fairly subtle and suspicious assumption about a `Set`, shouldn't that assumption least be documented in a comment somewhere (or ideally, corrected by sorting the `Set` into a `List` or something)? Otherwise it seems a variant of this bug could easily crop up again.

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

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

From vromero at openjdk.org  Wed Nov 30 18:29:15 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 30 Nov 2022 18:29:15 GMT
Subject: RFR: 8297294: compiler/c2/irTests/TestMulNodeIdealization.java
 failed compilation [v2]
In-Reply-To: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>
References: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>
Message-ID: <Je1PdVZyuh4w6QJlisb1NVMyhV1vFPHDIxHKVMc4kio=.17c182fd-5c30-4ae4-bbff-41801fd4ac2e@github.com>

> Given that the reported issue is intermittent I think we have two options here:
> 
> - change the most probable use of a non-deterministic data structure that could be provoking this bug, to a deterministic one
> - change all uses of non-deterministic data structures
> 
> The current fix is going for the first option, if preferred I can provide another patch that fixes all uses of non-deterministic data structures in our inference engine. I don't think we will have any performance impact going for the second option but it could be unnecessary.
> 
> Comments?
> TIA

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8297294' of https://github.com/vicente-romero-oracle/jdk into JDK-8297294
 - 8297294: compiler/c2/irTests/TestMulNodeIdealization.java failed compilation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11437/files
  - new: https://git.openjdk.org/jdk/pull/11437/files/49e3b88a..f1d9e3cd

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

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

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

From cushon at openjdk.org  Wed Nov 30 18:57:48 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 30 Nov 2022 18:57:48 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
Message-ID: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>

This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

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

Commit messages:
 - 8297875: jar should not compress the manifest directory entry

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

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

From vromero at openjdk.org  Wed Nov 30 20:01:38 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 30 Nov 2022 20:01:38 GMT
Subject: RFR: 8297294: compiler/c2/irTests/TestMulNodeIdealization.java
 failed compilation
In-Reply-To: <09RU6-ocSvunZPgjuveojjZ2yUhSO1VZY157jHOWIrs=.6e052380-edff-49d6-b5da-3224ac8e6851@github.com>
References: <WHc5ImdfAZ0dAlJdlHgevNuRTzAR_yZnURbcAfPYl-4=.122d1242-e5e3-406b-b3d8-52bae99b4b7b@github.com>
 <09RU6-ocSvunZPgjuveojjZ2yUhSO1VZY157jHOWIrs=.6e052380-edff-49d6-b5da-3224ac8e6851@github.com>
Message-ID: <Nl4WVWtNnt62Olk6CdXzcyAOWgL0fG4uFjas0Htjvik=.884f8709-28e4-4c37-90dc-2ecebd83fe7a@github.com>

On Wed, 30 Nov 2022 18:20:22 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> So just to confirm: while clearly changing `HashSet` to `LinkedHashSet` is going to eliminate some non-determinism, it also fixes the actual compiler logic bug rather than "papering over" it, correct?
> 
> If not - then is more investigation warranted?
> 
> If so - then doesn't that imply that the code that invokes `closure()` contains an implicit assumption about the ordering of the elements of that returned `Set`? And if so,?since that's a fairly subtle and suspicious assumption about a `Set`, shouldn't that assumption least be documented in a comment somewhere (or ideally, corrected by sorting the `Set` into a `List` or something)? Otherwise it seems a variant of this bug could easily crop up again.

It is not clear that there is a compiler bug as the code is compiled sometimes and sometimes not. This patch is not claiming to fix the bug as a compiler failure can't be reproduced. All I want is to make the inference engine as deterministic as possible.

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

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

From lancea at openjdk.org  Wed Nov 30 21:48:35 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 30 Nov 2022 21:48:35 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <99rKynYUWs5Xu5RvmKquhYqGCDfRtKv3Uc4IWB-pRMA=.59d110d3-401d-43f9-b95e-de8a3198c669@github.com>

On Wed, 30 Nov 2022 18:48:30 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

I don't necessarily see anything wrong with the change.  This code dates back to at least  JDK 1.2.1.

I am not sure their is an actual issue based on my read of the APP.NOTE and a quick look at the generated bytes, but I also do not see any harm with the change as to your point this is done for other directories  via  the jar tool as well as other zip tools such as info zip

The test does not check to see if the method is stored.  I would also consider converting the test to TestNG as you can leverage its assertXXX methods and remove the need for the doTest() method

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

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

From cushon at openjdk.org  Wed Nov 30 22:05:46 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 30 Nov 2022 22:05:46 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <n-4gsDS0AmRQ8eMlQn8dYzrK6NOBZXb3hdWQYrIsZjg=.72a02dfe-5af5-4557-968a-59de80703a93@github.com>

On Wed, 30 Nov 2022 18:48:30 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

Thanks for the review!

> I am not sure their is an actual issue based on my read of the APP.NOTE and a quick look at the generated bytes, but I also do not see any harm with the change as to your point this is done for other directories via the jar tool as well as other zip tools such as info zip

I agree APP.NOTE isn't completely clear on this. I think "directories ... must not include file data" could be read as saying that the uncompressed size must be zero, or that the uncompressed and compressed size should be zero. But I also agree with your summary that seems harmless and is consistent with the handling of other directories. It seems likely to me this was an oversight in the original implementation.

> The test does not check to see if the method is stored.

Done

> I would also consider converting the test to TestNG as you can leverage its assertXXX methods and remove the need for the doTest() method

Done

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

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

From cushon at openjdk.org  Wed Nov 30 22:09:22 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 30 Nov 2022 22:09:22 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v2]
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Use TestNG, and assert on the compression method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11441/files
  - new: https://git.openjdk.org/jdk/pull/11441/files/f634b82b..eaab9b03

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

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

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

From lancea at openjdk.org  Wed Nov 30 22:28:35 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 30 Nov 2022 22:28:35 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v2]
In-Reply-To: <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>
Message-ID: <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>

On Wed, 30 Nov 2022 22:09:22 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use TestNG, and assert on the compression method

Thanks for the quick set up updates.  a few minor nit comments to make the test feel more  TestNG friendly and inline with a few of our other tests.

Will approve tomorrow with some of these tweaks and giving time for some others to scan.

Thank you again for your contribution, it is appreciated :-)

test/jdk/tools/jar/ManifestDirectoryCompression.java line 52:

> 50: 
> 51:     /** Remove dirs & files needed for test. */
> 52:     private static void cleanup(Path dir) {

This can leverage the @afterMethod annotation if the code is reworked slightly to make it more TestNG friendly

test/jdk/tools/jar/ManifestDirectoryCompression.java line 60:

> 58:             }
> 59:             Files.delete(dir);
> 60:         } catch (IOException e) {

Have the method throw IOException and you do not need the catch block

test/jdk/tools/jar/ManifestDirectoryCompression.java line 72:

> 70:             doTest(topDir.resolve("test.jar"), entry);
> 71:         } finally {
> 72:             cleanup(topDir);

See comment above regarding cleanup()

test/jdk/tools/jar/ManifestDirectoryCompression.java line 83:

> 81:         try (JarFile jarFile = new JarFile(jar.toFile())) {
> 82:             ZipEntry zipEntry = jarFile.getEntry("META-INF/");
> 83:             assertEquals(zipEntry.getMethod(), ZipEntry.STORED);

Probably worth verifying zipEntry is not null so you do not get an NPE

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

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