From darcy at openjdk.org  Tue Aug  1 05:08:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 1 Aug 2023 05:08:13 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types
Message-ID: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>

The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).

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

Commit messages:
 - JDK-8281169: Expand discussion of elements and types

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

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

From mcimadamore at openjdk.org  Tue Aug  1 09:37:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Aug 2023 09:37:49 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types
In-Reply-To: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
Message-ID: <YCld_ZXb_Qgh5acNem-IozSBGCCFslE944NCRoNrBtw=.62c5d9f5-ad41-4f12-87f1-5708a384037b@github.com>

On Tue, 1 Aug 2023 05:00:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).

I agree that a discussion on the distinction between types and elements is worthwhile. That said, in its current form the text, with its focus on annotations/type annotations, seems an attempts to show as to why j.l.m is better than core reflection, which I'm sure was not the intended goal. I'm not even sure that using annotations is a good example of this, given there is an example that Java developers probably see on a daily basis: generics. E.g. there is only one `ArrayList` class declararation, but there are *many* way to use that declaration (e.g. `ArrayList<String>`, `ArrayList<Number>`, `ArrayList<List<String>>` ...).

One key fact the reader should go away with is that declarations are typically reused - e.g. every use of ArrayList<X> (a type mirror), no matter the shape of its type arguments, will end up pointing at the "one and true" ArrayList declaration (an element). Perhaps it would be useful here to refer to concepts such as symbol tables, which are fairly common in compiler design.

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

PR Review: https://git.openjdk.org/jdk/pull/15097#pullrequestreview-1556568994

From prappo at openjdk.org  Tue Aug  1 11:11:47 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 1 Aug 2023 11:11:47 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types
In-Reply-To: <YCld_ZXb_Qgh5acNem-IozSBGCCFslE944NCRoNrBtw=.62c5d9f5-ad41-4f12-87f1-5708a384037b@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <YCld_ZXb_Qgh5acNem-IozSBGCCFslE944NCRoNrBtw=.62c5d9f5-ad41-4f12-87f1-5708a384037b@github.com>
Message-ID: <rZualJQMWyVI23u1DVet_81jFFZES1vAE82aeAeECQc=.5a0b7005-5bb0-496f-a2dd-32f29347bd09@github.com>

On Tue, 1 Aug 2023 09:35:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> in its current form the text, with its focus on annotations/type annotations, seems an attempts to show as to why j.l.m is better than core reflection

The proposed text reads well from the perspective of API design: that is, why separate interfaces for "use" and "definition" model this particular domain better. While such a perspective has its place, IMO it shouldn't be the primary perspective of that text.
 
> One key fact the reader should go away with is that declarations are typically reused - e.g. every use of ArrayList (a type mirror), no matter the shape of its type arguments, will end up pointing at the "one and true" ArrayList declaration (an element). Perhaps it would be useful here to refer to concepts such as symbol tables, which are fairly common in compiler design.

Perhaps the following issue could also be worked into this PR: https://bugs.openjdk.org/browse/JDK-8309666

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

PR Comment: https://git.openjdk.org/jdk/pull/15097#issuecomment-1660097564

From asotona at openjdk.org  Tue Aug  1 14:20:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 1 Aug 2023 14:20:58 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library
In-Reply-To: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
Message-ID: <zJ9tlUMgxI-2ILGl_h4-RRYROtTuD4xcLn5Rqvcol9w=.226eec91-a7e9-4fdd-a6d1-a0606a0ea0f7@github.com>

On Thu, 13 Jul 2023 17:29:44 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified 12 of 226 test/langtools/tools/javac test classes to replace com.sun.tools.classfile library.

This is great amount of work well done.

test/langtools/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest3.java line 571:

> 569:     }
> 570: 
> 571:     /************ Helper annotations counting methods ******************/

Arn't these test methods duplicated in the ClassfileTestHelper?

test/langtools/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest3.java line 744:

> 742:     int visibles;
> 743:     int invisibles;
> 744: }

Missing new line at the end

test/langtools/tools/javac/annotations/typeAnnotations/classfile/Scopes.java line 65:

> 63:     @Target({ElementType.TYPE_USE})
> 64:     @interface UniqueInner { };
> 65: }

missing new line

test/langtools/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultVerifier.java line 74:

> 72:             // need API to return unknown AnnotationValue's length
> 73: //            testCase.checkEquals(((BoundAttribute<?>)attr).payloadLen(), 1 + attr.defaultValue().payloadLen(),
> 74: //                    "attribute_length");

Is there still a problem with casting to BoundAttribute that the test is commented out?

test/langtools/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultVerifier.java line 257:

> 255:             // need ev.length() api to check length
> 256: //            testCase.checkEquals(((BoundAttribute<?>)attr).payloadLen(), 1 + 2 +
> 257: //                    (sizeOfTag + ev.length() / ev.values().size()) * ev.values().size(), "attribute_length");

The same as above.

test/langtools/tools/javac/classfiles/attributes/Signature/EnumTest.java line 1:

> 1: /*

This is probably a mistake, I see content of EnumTest replaced with Driver class.

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

PR Review: https://git.openjdk.org/jdk/pull/14874#pullrequestreview-1557008889
PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280647722
PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280648492
PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280655171
PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280683840
PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280684857
PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280700268

From duke at openjdk.org  Tue Aug  1 15:12:52 2023
From: duke at openjdk.org (Qing Xiao)
Date: Tue, 1 Aug 2023 15:12:52 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library [v2]
In-Reply-To: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
Message-ID: <BQ9dH_lWLJycy_dWza1w5Wo8laygFrFU1IuXFBzUxpM=.666990f1-8b79-490e-af3f-56509aa62b41@github.com>

> Modified 12 of 226 test/langtools/tools/javac test classes to replace com.sun.tools.classfile library.

Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  Modified 3 files according to reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14874/files
  - new: https://git.openjdk.org/jdk/pull/14874/files/27cc2f10..88d6c9ee

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

  Stats: 291 lines in 3 files changed: 6 ins; 259 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/14874.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14874/head:pull/14874

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

From duke at openjdk.org  Tue Aug  1 15:12:56 2023
From: duke at openjdk.org (Qing Xiao)
Date: Tue, 1 Aug 2023 15:12:56 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library [v2]
In-Reply-To: <zJ9tlUMgxI-2ILGl_h4-RRYROtTuD4xcLn5Rqvcol9w=.226eec91-a7e9-4fdd-a6d1-a0606a0ea0f7@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
 <zJ9tlUMgxI-2ILGl_h4-RRYROtTuD4xcLn5Rqvcol9w=.226eec91-a7e9-4fdd-a6d1-a0606a0ea0f7@github.com>
Message-ID: <rhIfX45-RscUB2VG-kdLaqfiwNjlTFUZOlb7k7ZNCqk=.f2856ed6-b5d2-428d-9f4c-a6660d38e321@github.com>

On Tue, 1 Aug 2023 13:28:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified 3 files according to reviews
>
> test/langtools/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest3.java line 571:
> 
>> 569:     }
>> 570: 
>> 571:     /************ Helper annotations counting methods ******************/
> 
> Arn't these test methods duplicated in the ClassfileTestHelper?

Modified in the latest commit. I keep extending the ClassfileTestHelper, and only migrate the Test methods.

> test/langtools/tools/javac/annotations/typeAnnotations/classfile/Scopes.java line 65:
> 
>> 63:     @Target({ElementType.TYPE_USE})
>> 64:     @interface UniqueInner { };
>> 65: }
> 
> missing new line

Modified in the latest commit

> test/langtools/tools/javac/classfiles/attributes/Signature/EnumTest.java line 1:
> 
>> 1: /*
> 
> This is probably a mistake, I see content of EnumTest replaced with Driver class.

Modified in the latest commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280787466
PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280785773
PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1280785593

From jlaskey at openjdk.org  Tue Aug  1 15:34:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Aug 2023 15:34:59 GMT
Subject: RFR: 8312821: Javac accepts char literal as template
Message-ID: <tKjKuaEGXDxc3doE81eenMpGEnFVW2HF3NmI3u9awDM=.8e56cfe6-ee6d-4ad9-8412-c59ca6a2b850@github.com>

Embedded expressions in character literals are accepted. Fix is to reject `{` sequence in character literals.

Additional code was added to skip to end of literal when error is detected. This avoids many misleading error messages.

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

Commit messages:
 - 8312821 Javac accepts char literal as template

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

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

From rriggs at openjdk.org  Tue Aug  1 15:38:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Aug 2023 15:38:55 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types
In-Reply-To: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
Message-ID: <Jhubu5w97LMT_0oZESREt404w-DLV2LXSv-UjCROmcc=.950f0647-453b-4686-a684-8e1397cf33ea@github.com>

On Tue, 1 Aug 2023 05:00:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).

To make the text a bit more timeless, use the present tense,  "are pulled out" instead of "were pulled out".

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

PR Comment: https://git.openjdk.org/jdk/pull/15097#issuecomment-1660572244

From jlaskey at openjdk.org  Tue Aug  1 16:30:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Aug 2023 16:30:06 GMT
Subject: RFR: 8312814: Compiler crash when template processor type is a
 captured wildcard
Message-ID: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>

Missing JCStringTemplate.processor in TransTypes

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

Commit messages:
 - Missing JCStringTemplate.processor in TransTypes

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

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

From jlaskey at openjdk.org  Tue Aug  1 16:49:35 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Aug 2023 16:49:35 GMT
Subject: RFR: 8312814: Compiler crash when template processor type is a
 captured wildcard [v2]
In-Reply-To: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
References: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
Message-ID: <9sK_Hu2TW4xJaeMF-pV5aKKyBRXkdMhSRjQZPjHKJ1A=.995c8732-1cf5-4788-81a6-0ce6d1baa7cf@github.com>

> Missing JCStringTemplate.processor translation in TransTypes

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15107/files
  - new: https://git.openjdk.org/jdk/pull/15107/files/c77ebe95..38bbc959

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

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

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

From jlahoda at openjdk.org  Tue Aug  1 17:06:43 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 1 Aug 2023 17:06:43 GMT
Subject: RFR: 8312814: Compiler crash when template processor type is a
 captured wildcard [v2]
In-Reply-To: <9sK_Hu2TW4xJaeMF-pV5aKKyBRXkdMhSRjQZPjHKJ1A=.995c8732-1cf5-4788-81a6-0ce6d1baa7cf@github.com>
References: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
 <9sK_Hu2TW4xJaeMF-pV5aKKyBRXkdMhSRjQZPjHKJ1A=.995c8732-1cf5-4788-81a6-0ce6d1baa7cf@github.com>
Message-ID: <Cryv6DZFUe3tAYmLCx5_5R1LDgmbeFmlsi0jlL8bQu0=.3fe4475b-07c0-417a-ba63-6465803b6832@github.com>

On Tue, 1 Aug 2023 16:49:35 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Missing JCStringTemplate.processor translation in TransTypes
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15107#pullrequestreview-1557456182

From mcimadamore at openjdk.org  Tue Aug  1 17:36:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Aug 2023 17:36:42 GMT
Subject: RFR: 8312814: Compiler crash when template processor type is a
 captured wildcard [v2]
In-Reply-To: <9sK_Hu2TW4xJaeMF-pV5aKKyBRXkdMhSRjQZPjHKJ1A=.995c8732-1cf5-4788-81a6-0ce6d1baa7cf@github.com>
References: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
 <9sK_Hu2TW4xJaeMF-pV5aKKyBRXkdMhSRjQZPjHKJ1A=.995c8732-1cf5-4788-81a6-0ce6d1baa7cf@github.com>
Message-ID: <dadi5UcaaH9PPDsM9EqYC-3Rt3uYzex1dPnqdPGScB8=.02611c87-e4c4-48e1-b0c7-da8877a9a3ac@github.com>

On Tue, 1 Aug 2023 16:49:35 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Missing JCStringTemplate.processor translation in TransTypes
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15107#pullrequestreview-1557502018

From darcy at openjdk.org  Tue Aug  1 17:44:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 1 Aug 2023 17:44:40 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types
In-Reply-To: <rZualJQMWyVI23u1DVet_81jFFZES1vAE82aeAeECQc=.5a0b7005-5bb0-496f-a2dd-32f29347bd09@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <YCld_ZXb_Qgh5acNem-IozSBGCCFslE944NCRoNrBtw=.62c5d9f5-ad41-4f12-87f1-5708a384037b@github.com>
 <rZualJQMWyVI23u1DVet_81jFFZES1vAE82aeAeECQc=.5a0b7005-5bb0-496f-a2dd-32f29347bd09@github.com>
Message-ID: <MXs6bMtLjz_xWnSyKYGUkcpmZCNH69Aht9fA-q-FsGY=.e5fb099a-1120-462f-b7e9-fd927ea55859@github.com>

On Tue, 1 Aug 2023 11:08:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > in its current form the text, with its focus on annotations/type annotations, seems an attempts to show as to why j.l.m is better than core reflection
> 
> The proposed text reads well from the perspective of API design: that is, why separate interfaces for "use" and "definition" model this particular domain better. While such a perspective has its place, IMO it shouldn't be the primary perspective of that text.
> 
> > One key fact the reader should go away with is that declarations are typically reused - e.g. every use of ArrayList (a type mirror), no matter the shape of its type arguments, will end up pointing at the "one and true" ArrayList declaration (an element). Perhaps it would be useful here to refer to concepts such as symbol tables, which are fairly common in compiler design.
> 
> Perhaps the following issue could also be worked into this PR: https://bugs.openjdk.org/browse/JDK-8309666

Thanks for the feedback; I'll mull over how to reformulate the discussion.

I'll state my intentions more explicitly in hopes of distilling more effective examples. One point in explaining elements vs types is delineating the distinction uses and definitions, "def-use" being another concept common in compilers. I intended the type annotation example to help motivate the distinction: "something" must encapsulate the difference between String with one set of annotations as a return type and String with a different set of annotations as the parameter type.

It would be technically possible to embed all the shared element/definition information into the type mirrors, but that would not be well-factored OO code.

I agree a generics example is a good one, which is why I included an abbreviated version of that in the "Mapping" discussion.

With the benefit of hindsight, as detailed in the "Mirror" paper cited earlier in the package-info file, core reflection has multiple design issues we were trying to do differently in the javax.lang.model API.

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

PR Comment: https://git.openjdk.org/jdk/pull/15097#issuecomment-1660803194

From jlaskey at openjdk.org  Tue Aug  1 17:58:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Aug 2023 17:58:34 GMT
Subject: RFR: 8312814: Compiler crash when template processor type is a
 captured wildcard [v3]
In-Reply-To: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
References: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
Message-ID: <Sy_-KzC3qx8R3ppyINYcRm11VBdtUEcqZQpX3musOs4=.a4323f6e-c33a-4b40-9515-c583c1d1b5da@github.com>

> Missing JCStringTemplate.processor translation in TransTypes

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested by Vicente

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15107/files
  - new: https://git.openjdk.org/jdk/pull/15107/files/38bbc959..a5ca1464

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

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

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

From vromero at openjdk.org  Tue Aug  1 17:58:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 1 Aug 2023 17:58:35 GMT
Subject: RFR: 8312814: Compiler crash when template processor type is a
 captured wildcard [v3]
In-Reply-To: <Sy_-KzC3qx8R3ppyINYcRm11VBdtUEcqZQpX3musOs4=.a4323f6e-c33a-4b40-9515-c583c1d1b5da@github.com>
References: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
 <Sy_-KzC3qx8R3ppyINYcRm11VBdtUEcqZQpX3musOs4=.a4323f6e-c33a-4b40-9515-c583c1d1b5da@github.com>
Message-ID: <DlgPRrd3AIFJ8yN0uWhKNKvPnxQUibXvUQkek6eUOIU=.7498c451-df24-49f0-b630-4ffb2a2e410f@github.com>

On Tue, 1 Aug 2023 17:53:16 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Missing JCStringTemplate.processor translation in TransTypes
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested by Vicente

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15107#pullrequestreview-1557529707

From mcimadamore at openjdk.org  Tue Aug  1 18:19:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Aug 2023 18:19:49 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types
In-Reply-To: <MXs6bMtLjz_xWnSyKYGUkcpmZCNH69Aht9fA-q-FsGY=.e5fb099a-1120-462f-b7e9-fd927ea55859@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <YCld_ZXb_Qgh5acNem-IozSBGCCFslE944NCRoNrBtw=.62c5d9f5-ad41-4f12-87f1-5708a384037b@github.com>
 <rZualJQMWyVI23u1DVet_81jFFZES1vAE82aeAeECQc=.5a0b7005-5bb0-496f-a2dd-32f29347bd09@github.com>
 <MXs6bMtLjz_xWnSyKYGUkcpmZCNH69Aht9fA-q-FsGY=.e5fb099a-1120-462f-b7e9-fd927ea55859@github.com>
Message-ID: <qX4rgyYZVfCBt60lCuFRo545xINQSKxhDSJbZb7P25E=.1a943ada-de80-4b2c-af68-9597d3ce6ecb@github.com>

On Tue, 1 Aug 2023 17:42:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > > in its current form the text, with its focus on annotations/type annotations, seems an attempts to show as to why j.l.m is better than core reflection
> > 
> > 
> > The proposed text reads well from the perspective of API design: that is, why separate interfaces for "use" and "definition" model this particular domain better. While such a perspective has its place, IMO it shouldn't be the primary perspective of that text.
> > > One key fact the reader should go away with is that declarations are typically reused - e.g. every use of ArrayList (a type mirror), no matter the shape of its type arguments, will end up pointing at the "one and true" ArrayList declaration (an element). Perhaps it would be useful here to refer to concepts such as symbol tables, which are fairly common in compiler design.
> > 
> > 
> > Perhaps the following issue could also be worked into this PR: https://bugs.openjdk.org/browse/JDK-8309666
> 
> Thanks for the feedback; I'll mull over how to reformulate the discussion.
> 
> I'll state my intentions more explicitly in hopes of distilling more effective examples. One point in explaining elements vs types is delineating the distinction uses and definitions, "def-use" being another concept common in compilers. I intended the type annotation example to help motivate the distinction: "something" must encapsulate the difference between String with one set of annotations as a return type and String with a different set of annotations as the parameter type.
> 
> It would be technically possible to embed all the shared element/definition information into the type mirrors, but that would not be well-factored OO code.
> 
> I agree a generics example is a good one, which is why I included an abbreviated version of that in the "Mapping" discussion.
> 
> With the benefit of hindsight, as detailed in the "Mirror" paper cited earlier in the package-info file, core reflection has multiple design issues we were trying to do differently in the javax.lang.model API.

Maybe we need more examples where use/def might differ:
* annotated types
* generics
* constant types (e.g. the type of 42 is not exactly `int`, but `int(value = 42)`

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

PR Comment: https://git.openjdk.org/jdk/pull/15097#issuecomment-1660850403

From jlu at openjdk.org  Tue Aug  1 23:19:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 1 Aug 2023 23:19:58 GMT
Subject: Integrated: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
Message-ID: <J-7QWUZ9dqBcFUe2nYIM8YKFKqgzot9vDiiIAzuwmoo=.08144cb7-7a84-4b68-9d66-e89b87682b88@github.com>

On Wed, 26 Jul 2023 20:41:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1.
> 
> Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.
> 
> The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).
> 
> - src/java.base/share/classes/sun/launcher/resources/launcher.properties
> - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
> - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
> 
> It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.

This pull request has now been integrated.

Changeset: 9b55e9a7
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18
Stats:     223 lines in 32 files changed: 36 ins; 15 del; 172 mod

8312572: JDK 21 RDP2 L10n resource files update

Reviewed-by: naoto

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

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

From jlaskey at openjdk.org  Wed Aug  2 00:51:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Aug 2023 00:51:08 GMT
Subject: Integrated: 8312814: Compiler crash when template processor type is a
 captured wildcard
In-Reply-To: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
References: <qj43ejTJYTE5nJD6UJifBUGi_godnTVMUFJCAEjqRRM=.37acd3f5-3cf5-496c-ad27-e25cfd7d1438@github.com>
Message-ID: <GpQcC-uY-YjyAou_q2Sp8tf2g0yYDvFRBVRfBBk0WAY=.5e1532da-156e-4457-a864-f9a30157157f@github.com>

On Tue, 1 Aug 2023 16:22:26 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Missing JCStringTemplate.processor translation in TransTypes

This pull request has now been integrated.

Changeset: f14245b3
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f14245b3880ff735ae231b4c7d2c6b6907c5f7d4
Stats:     40 lines in 2 files changed: 40 ins; 0 del; 0 mod

8312814: Compiler crash when template processor type is a captured wildcard

Reviewed-by: jlahoda, mcimadamore, vromero

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

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

From darcy at openjdk.org  Wed Aug  2 01:55:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 2 Aug 2023 01:55:40 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types
In-Reply-To: <qX4rgyYZVfCBt60lCuFRo545xINQSKxhDSJbZb7P25E=.1a943ada-de80-4b2c-af68-9597d3ce6ecb@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <YCld_ZXb_Qgh5acNem-IozSBGCCFslE944NCRoNrBtw=.62c5d9f5-ad41-4f12-87f1-5708a384037b@github.com>
 <rZualJQMWyVI23u1DVet_81jFFZES1vAE82aeAeECQc=.5a0b7005-5bb0-496f-a2dd-32f29347bd09@github.com>
 <MXs6bMtLjz_xWnSyKYGUkcpmZCNH69Aht9fA-q-FsGY=.e5fb099a-1120-462f-b7e9-fd927ea55859@github.com>
 <qX4rgyYZVfCBt60lCuFRo545xINQSKxhDSJbZb7P25E=.1a943ada-de80-4b2c-af68-9597d3ce6ecb@github.com>
Message-ID: <UsX8FXH2Jc-G2AIwdVGJkSD3xnrc1PDO_ZxHDMp30wo=.de20b12a-da4a-4d75-b9d6-61b6cfc398c3@github.com>

On Tue, 1 Aug 2023 18:16:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > > > in its current form the text, with its focus on annotations/type annotations, seems an attempts to show as to why j.l.m is better than core reflection
> > > 
> > > 
> > > The proposed text reads well from the perspective of API design: that is, why separate interfaces for "use" and "definition" model this particular domain better. While such a perspective has its place, IMO it shouldn't be the primary perspective of that text.
> > > > One key fact the reader should go away with is that declarations are typically reused - e.g. every use of ArrayList (a type mirror), no matter the shape of its type arguments, will end up pointing at the "one and true" ArrayList declaration (an element). Perhaps it would be useful here to refer to concepts such as symbol tables, which are fairly common in compiler design.
> > > 
> > > 
> > > Perhaps the following issue could also be worked into this PR: https://bugs.openjdk.org/browse/JDK-8309666
> > 
> > 
> > Thanks for the feedback; I'll mull over how to reformulate the discussion.
> > I'll state my intentions more explicitly in hopes of distilling more effective examples. One point in explaining elements vs types is delineating the distinction uses and definitions, "def-use" being another concept common in compilers. I intended the type annotation example to help motivate the distinction: "something" must encapsulate the difference between String with one set of annotations as a return type and String with a different set of annotations as the parameter type.
> > It would be technically possible to embed all the shared element/definition information into the type mirrors, but that would not be well-factored OO code.
> > I agree a generics example is a good one, which is why I included an abbreviated version of that in the "Mapping" discussion.
> > With the benefit of hindsight, as detailed in the "Mirror" paper cited earlier in the package-info file, core reflection has multiple design issues we were trying to do differently in the javax.lang.model API.
> 

PS In fairness to the designers of core reflection, at the time core reflection added, there wasn't really any use-site specific information, predating generics and any kind of annotations. So the (future) benefits of separating definition and use might not necessarily be clear if one had not already worked with such APIs for other environments.

Also core reflection is in the java._lang_ and java._lang_.reflect packages but generally present a VM-centric view of the world and starting with generics the VM type system and the language type system were much more different than before that change.

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

PR Comment: https://git.openjdk.org/jdk/pull/15097#issuecomment-1661366318

From mcimadamore at openjdk.org  Wed Aug  2 09:31:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 2 Aug 2023 09:31:50 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types
In-Reply-To: <UsX8FXH2Jc-G2AIwdVGJkSD3xnrc1PDO_ZxHDMp30wo=.de20b12a-da4a-4d75-b9d6-61b6cfc398c3@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <YCld_ZXb_Qgh5acNem-IozSBGCCFslE944NCRoNrBtw=.62c5d9f5-ad41-4f12-87f1-5708a384037b@github.com>
 <rZualJQMWyVI23u1DVet_81jFFZES1vAE82aeAeECQc=.5a0b7005-5bb0-496f-a2dd-32f29347bd09@github.com>
 <MXs6bMtLjz_xWnSyKYGUkcpmZCNH69Aht9fA-q-FsGY=.e5fb099a-1120-462f-b7e9-fd927ea55859@github.com>
 <qX4rgyYZVfCBt60lCuFRo545xINQSKxhDSJbZb7P25E=.1a943ada-de80-4b2c-af68-9597d3ce6ecb@github.com>
 <UsX8FXH2Jc-G2AIwdVGJkSD3xnrc1PDO_ZxHDMp30wo=.de20b12a-da4a-4d75-b9d6-61b6cfc398c3@github.com>
Message-ID: <A2ZgXepUZr4NtEMCOkbYY6BMqUs2jdX-ZsfHWfONtrI=.a49b2830-a2f6-4724-a24b-0d526314aec8@github.com>

On Wed, 2 Aug 2023 01:52:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Also core reflection is in the java._lang_ and java._lang_.reflect packages but generally present a VM-centric view of the world and starting with generics the VM type system and the language type system were much more different than before that change.

Precisely - core reflection is about modelling runtime types, which feature a much simpler type systems (at least w/o type specialization). While core reflection does try to model language concepts, annotations and generics are generally immaterial to JVM decisions. That's why it felt odd to compare the j.l.m API to core reflection, as the two API exists with two very different purposes, and so they settled for different points in the design space.

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

PR Comment: https://git.openjdk.org/jdk/pull/15097#issuecomment-1661863148

From stuefe at openjdk.org  Wed Aug  2 10:17:00 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 2 Aug 2023 10:17:00 GMT
Subject: RFR: JDK-8313582: Problemlist failing test on linux x86
Message-ID: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>

Trivial patch to problemlist two tests on linux x86 that keep failing in GHAs.

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

Commit messages:
 - JDK-8313582-Problemlist-x86-tests

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

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

From jlahoda at openjdk.org  Wed Aug  2 12:16:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 2 Aug 2023 12:16:41 GMT
Subject: RFR: 8312821: Javac accepts char literal as template
In-Reply-To: <tKjKuaEGXDxc3doE81eenMpGEnFVW2HF3NmI3u9awDM=.8e56cfe6-ee6d-4ad9-8412-c59ca6a2b850@github.com>
References: <tKjKuaEGXDxc3doE81eenMpGEnFVW2HF3NmI3u9awDM=.8e56cfe6-ee6d-4ad9-8412-c59ca6a2b850@github.com>
Message-ID: <GkzvqHh0hZjGlJ29I2P7GewZdrggxnHy0qF_6t6yLHc=.d6e772ff-edb4-4655-8c05-6f4d4d5811b7@github.com>

On Tue, 1 Aug 2023 15:28:06 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Embedded expressions in character literals are accepted. Fix is to reject `{` sequence in character literals.
> 
> Additional code was added to skip to end of literal when error is detected. This avoids many misleading error messages.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15106#pullrequestreview-1558870579

From stuefe at openjdk.org  Wed Aug  2 16:02:51 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 2 Aug 2023 16:02:51 GMT
Subject: RFR: JDK-8313582: Problemlist failing test on linux x86
In-Reply-To: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
References: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
Message-ID: <1Xdx0bmDMFRMdOEDGSk6_FCS-xA8fir9r2m7gC9ib_w=.72ec0f7e-22fb-453b-a7b6-da8503ad7838@github.com>

On Wed, 2 Aug 2023 05:35:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial patch to problemlist two tests on linux x86 that keep failing in GHAs.

RiscV GHA errors unrelated

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

PR Comment: https://git.openjdk.org/jdk/pull/15117#issuecomment-1662483809

From duke at openjdk.org  Wed Aug  2 16:07:03 2023
From: duke at openjdk.org (Qing Xiao)
Date: Wed, 2 Aug 2023 16:07:03 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library [v3]
In-Reply-To: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
Message-ID: <fVgtKYUCStpUtFLZBJvxTJabsrq4DpqczkjyVEwwURM=.e1ed053b-d6ae-495e-a5fd-1b35f00c48b5@github.com>

> Modified 12 of 226 test/langtools/tools/javac test classes to replace com.sun.tools.classfile library.

Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  Added testLength method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14874/files
  - new: https://git.openjdk.org/jdk/pull/14874/files/88d6c9ee..86636785

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

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

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

From jlu at openjdk.org  Wed Aug  2 17:11:07 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 2 Aug 2023 17:11:07 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
Message-ID: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>

Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This change is required to keep the localized translations up to date with the English source resource files.

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

Commit messages:
 - Backport 9b55e9a706de9893b1a71c7a6a4e23c4b8842f18

Changes: https://git.openjdk.org/jdk21/pull/160/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312572
  Stats: 223 lines in 32 files changed: 36 ins; 15 del; 172 mod
  Patch: https://git.openjdk.org/jdk21/pull/160.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/160/head:pull/160

PR: https://git.openjdk.org/jdk21/pull/160

From naoto at openjdk.org  Wed Aug  2 17:46:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Aug 2023 17:46:53 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <0qmatseGr9WvMxmSIZhofWEmd4usRDuDVJqqsKl2pI0=.56d1c812-a9ab-4b22-88cf-9183fca693ba@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/160#pullrequestreview-1559541428

From iris at openjdk.org  Wed Aug  2 18:23:57 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 2 Aug 2023 18:23:57 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <O9s7CY1Q5EhtKtkkRGQVZWjNzLIBmk9Qh0k-4AS9BC0=.90c29ca1-8fdf-4501-846a-3c24a5b3cd83@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/160#pullrequestreview-1559601318

From vromero at openjdk.org  Wed Aug  2 19:37:42 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Aug 2023 19:37:42 GMT
Subject: RFR: 8312984: javac may crash on a record pattern with too few
 components
In-Reply-To: <bynqITbAsz-MNULrzDftP5H0ZUEXgDG8GlX4uv_fDB8=.2a635116-a2bc-4691-a8c9-c1b8636fc2e2@github.com>
References: <bynqITbAsz-MNULrzDftP5H0ZUEXgDG8GlX4uv_fDB8=.2a635116-a2bc-4691-a8c9-c1b8636fc2e2@github.com>
Message-ID: <VUWJrAONzQUL_kNgHy4OZG4klZaTPvxQh-Lx3PNYdmw=.e0dc8ce8-1fab-4385-a32a-695340ab390a@github.com>

On Tue, 25 Jul 2023 18:08:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Processing code like:
> 
> public class Err {
>     record R(String x) {}
> 
>     public void(Object obj) {
>         switch(obj) {
>             case R(var v, ) -> 1; //note the missing component/nested pattern
>         }
>     }
> } 
> 
> 
> may crash with an ArrayIndexOutOfBoundsException, because requesting component type for a non-existing component, while evaluating exhaustivity.
> 
> The proposal is to simply use `errType` for this case, to prevent the crash.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15024#pullrequestreview-1559719602

From jlaskey at openjdk.org  Wed Aug  2 21:04:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 2 Aug 2023 21:04:59 GMT
Subject: Integrated: 8312821: Javac accepts char literal as template
In-Reply-To: <tKjKuaEGXDxc3doE81eenMpGEnFVW2HF3NmI3u9awDM=.8e56cfe6-ee6d-4ad9-8412-c59ca6a2b850@github.com>
References: <tKjKuaEGXDxc3doE81eenMpGEnFVW2HF3NmI3u9awDM=.8e56cfe6-ee6d-4ad9-8412-c59ca6a2b850@github.com>
Message-ID: <3u69sczBw5-VbT__MgHv52f2n49dAmoyvpP4D-rHzGQ=.8ea3c3b2-966c-4a67-a7fb-78026779eedd@github.com>

On Tue, 1 Aug 2023 15:28:06 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Embedded expressions in character literals are accepted. Fix is to reject `{` sequence in character literals.
> 
> Additional code was added to skip to end of literal when error is detected. This avoids many misleading error messages.

This pull request has now been integrated.

Changeset: bc1d2eac
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc1d2eac9abd5fb38402113c7f0805c21ef7787f
Stats:     29 lines in 3 files changed: 14 ins; 3 del; 12 mod

8312821: Javac accepts char literal as template

Reviewed-by: jlahoda

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

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

From jjg at openjdk.org  Wed Aug  2 21:18:52 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 2 Aug 2023 21:18:52 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
Message-ID: <cFRdrD4uxwdZtqzpWAo63pmCNYb48GygqLpmzJ2_isE=.a5b1d74b-48fd-48b6-9a40-1b36653a7f53@github.com>

On Fri, 28 Jul 2023 05:51:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start by just reformatting the existing specs to highlight subsequent spec changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 286:

> 284:      * begins with "{@code /**}", ends with a separate
> 285:      * "<code>*&#47;</code>", and immediately precedes the element,
> 286:      * ignoring white space and annotations and end-of-line-comments ({@code "//"} comments).

(minor/grammar)
instead of `A and B and C` consider using `A, B, and C`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1282425976

From jjg at openjdk.org  Wed Aug  2 21:29:43 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 2 Aug 2023 21:29:43 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
Message-ID: <CbSC_xN0vFwakDhJpYsM-acraI06MeDSX8wQ1bszKX0=.3baf3740-cf1b-4de3-888d-4887a87088fa@github.com>

On Fri, 28 Jul 2023 05:51:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start by just reformatting the existing specs to highlight subsequent spec changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 300:

> 298:      * if the lines start with <em>zero</em> or more white space characters followed by
> 299:      * <em>one</em> or more "{@code *}" characters,
> 300:      * those leading white space characters are discarded as are any

FWIW, I checked `javac` and it allows form-feed in the leading whitespace characters

As an adjective "white space" is normally a single word, at least in JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1282434177

From jjg at openjdk.org  Wed Aug  2 21:36:50 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 2 Aug 2023 21:36:50 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
Message-ID: <qKZl0EAQixUz6WCEYvLOFSUWD_hJuCwxa7yjW9PPuRM=.c39aa540-a6f5-4375-a77c-136ad2da5561@github.com>

On Fri, 28 Jul 2023 05:51:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start by just reformatting the existing specs to highlight subsequent spec changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

test/langtools/tools/javac/processing/model/util/elements/TestGetDocComments.java line 80:

> 78:             System.out.println("Strings have different lengths");
> 79:         }
> 80:     }

Not critical, but for bonus points, you could identify the first line that is different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1282441764

From jjg at openjdk.org  Wed Aug  2 21:44:51 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 2 Aug 2023 21:44:51 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
Message-ID: <1aO9dXw9bj1yZoJd2Ns9XiGXXqfepKWk2FuFHUlCC8o=.7e853a38-4b4c-463f-9bba-380bfc482870@github.com>

On Fri, 28 Jul 2023 05:51:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start by just reformatting the existing specs to highlight subsequent spec changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

General feedback: while the text is good at describing when non-newline characters are removed, it is less good at describing the treatment of newlines ... are they line-terminators or line-separators; how do such characters in the result of `getDocComment` relate to the characters in the source file?  For example, does `getDocComment` "copy" the newline characters found in the source file or are they always normalized to `\n` ?

test/langtools/tools/javac/processing/model/util/elements/TestGetDocComments.java line 143:

> 141:      * eiusmod tempor incididunt ut labore et dolore magna aliqua.
> 142:      */
> 143:     @ExpectedComment( // Cannot used a text block here since leading spaces are removed

You could use a text block, by carefully adjusting the indentation of the trailing `"""`

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

PR Comment: https://git.openjdk.org/jdk/pull/15062#issuecomment-1662997672
PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1282447161

From jjg at openjdk.org  Wed Aug  2 21:51:42 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 2 Aug 2023 21:51:42 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
Message-ID: <P-phW0U_4eicyfzSrtt40KE4SOFn8GDgRVupGrIsI6g=.e8873a3c-cb72-4961-ab94-7107a52ce1f6@github.com>

On Fri, 28 Jul 2023 05:51:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start by just reformatting the existing specs to highlight subsequent spec changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 286:

> 284:      * begins with "{@code /**}", ends with a separate
> 285:      * "<code>*&#47;</code>", and immediately precedes the element,
> 286:      * ignoring white space and annotations and end-of-line-comments ({@code "//"} comments).

Turns out that simple block comments are ignored as well. Try:

/**
 * This is HW.
 */
/* block comment. */
// line comment
public class HW { }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1282451927

From vromero at openjdk.org  Wed Aug  2 22:08:42 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Aug 2023 22:08:42 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
Message-ID: <8FjZK27enls_IqDb-MkuXCi3GN2lG7skxOMBAzlnzt0=.2776a9ef-fde6-4cdf-a32f-fc125db65833@github.com>

On Fri, 28 Jul 2023 05:51:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start by just reformatting the existing specs to highlight subsequent spec changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15062#pullrequestreview-1559907695

From stuefe at openjdk.org  Thu Aug  3 04:33:28 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 3 Aug 2023 04:33:28 GMT
Subject: RFR: JDK-8313582: Problemlist failing test on linux x86
In-Reply-To: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
References: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
Message-ID: <ZGWVCg0Z5Va9wpSp47XSECD_CMw_aX2U7aVc8KmS-qA=.6fbea65c-06c3-4486-9e03-068547d37489@github.com>

On Wed, 2 Aug 2023 05:35:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial patch to problemlist two tests on linux x86 that keep failing in GHAs.

Ping. This is trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/15117#issuecomment-1663274189

From tschatzl at openjdk.org  Thu Aug  3 08:01:35 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Aug 2023 08:01:35 GMT
Subject: RFR: JDK-8313582: Problemlist failing test on linux x86
In-Reply-To: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
References: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
Message-ID: <hmNyUbgRSn1_7C0-QxrWP71mp2FFxsIBa-Qx8bpYdHY=.f2aa8cca-e9f8-4f19-b24c-f3d6d923b583@github.com>

On Wed, 2 Aug 2023 05:35:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial patch to problemlist two tests on linux x86 that keep failing in GHAs.

trivial, ship it

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15117#pullrequestreview-1560463464

From stuefe at openjdk.org  Thu Aug  3 08:35:37 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 3 Aug 2023 08:35:37 GMT
Subject: RFR: JDK-8313582: Problemlist failing test on linux x86
In-Reply-To: <hmNyUbgRSn1_7C0-QxrWP71mp2FFxsIBa-Qx8bpYdHY=.f2aa8cca-e9f8-4f19-b24c-f3d6d923b583@github.com>
References: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
 <hmNyUbgRSn1_7C0-QxrWP71mp2FFxsIBa-Qx8bpYdHY=.f2aa8cca-e9f8-4f19-b24c-f3d6d923b583@github.com>
Message-ID: <4pCW6J3EXNua6ApfQ1OBrFTc8N1c9B4Nt7-VgY52xcI=.b6082d66-54b3-4edf-8641-33e1650f17f1@github.com>

On Thu, 3 Aug 2023 07:58:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Trivial patch to problemlist two tests on linux x86 that keep failing in GHAs.
>
> trivial, ship it

Thanks @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/15117#issuecomment-1663524919

From stuefe at openjdk.org  Thu Aug  3 08:35:38 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 3 Aug 2023 08:35:38 GMT
Subject: Integrated: JDK-8313582: Problemlist failing test on linux x86
In-Reply-To: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
References: <iofLU63JriXTNJA4b5Yhw9VjmNWPbez-8C4rSvPH-5A=.be66e5c0-b338-4236-b98f-0a93fed4f6a7@github.com>
Message-ID: <YQPuNzAJHpg0JpftlDA6jJGBVLm6O7LktS4MtyyA1Wg=.ccfed9e0-0b4f-4bd6-afb4-816446a43254@github.com>

On Wed, 2 Aug 2023 05:35:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial patch to problemlist two tests on linux x86 that keep failing in GHAs.

This pull request has now been integrated.

Changeset: 3212b64f
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3212b64f8efc32a95808cd33e16b6cf989173a3f
Stats:     19 lines in 1 file changed: 19 ins; 0 del; 0 mod

8313582: Problemlist failing test on linux x86

Reviewed-by: tschatzl

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

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

From jlahoda at openjdk.org  Thu Aug  3 08:40:39 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Aug 2023 08:40:39 GMT
Subject: Integrated: 8312984: javac may crash on a record pattern with too few
 components
In-Reply-To: <bynqITbAsz-MNULrzDftP5H0ZUEXgDG8GlX4uv_fDB8=.2a635116-a2bc-4691-a8c9-c1b8636fc2e2@github.com>
References: <bynqITbAsz-MNULrzDftP5H0ZUEXgDG8GlX4uv_fDB8=.2a635116-a2bc-4691-a8c9-c1b8636fc2e2@github.com>
Message-ID: <7veGcu7y-9Wly16GGxO_6hiKgycmjnFkzoxHvL35VP8=.958e6502-8066-4685-8be0-6b6bcf9dcd95@github.com>

On Tue, 25 Jul 2023 18:08:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Processing code like:
> 
> public class Err {
>     record R(String x) {}
> 
>     public void(Object obj) {
>         switch(obj) {
>             case R(var v, ) -> 1; //note the missing component/nested pattern
>         }
>     }
> } 
> 
> 
> may crash with an ArrayIndexOutOfBoundsException, because requesting component type for a non-existing component, while evaluating exhaustivity.
> 
> The proposal is to simply use `errType` for this case, to prevent the crash.

This pull request has now been integrated.

Changeset: c3860917
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3860917346fb53ed3d23f11d112b58b8cd8448a
Stats:     19 lines in 4 files changed: 14 ins; 0 del; 5 mod

8312984: javac may crash on a record pattern with too few components

Reviewed-by: vromero

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

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

From jlu at openjdk.org  Thu Aug  3 20:52:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 3 Aug 2023 20:52:41 GMT
Subject: [jdk21] Integrated: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <xtjzSrMie_mGi87AdfSi6ZDaEzsx4XmfSJLA3JoMTJc=.ee4f76c2-305f-4e0c-91fd-155583f69915@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

This pull request has now been integrated.

Changeset: fd789db5
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/fd789db510181886ffd3aa36ab06389a76d53e0b
Stats:     223 lines in 32 files changed: 36 ins; 15 del; 172 mod

8312572: JDK 21 RDP2 L10n resource files update

Reviewed-by: naoto, iris
Backport-of: 9b55e9a706de9893b1a71c7a6a4e23c4b8842f18

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

PR: https://git.openjdk.org/jdk21/pull/160

From prappo at openjdk.org  Fri Aug  4 13:37:00 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Aug 2023 13:37:00 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation
Message-ID: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>

Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.

The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:

    $ git hlpe
    git: 'hlpe' is not a git command. See 'git --help'.
    
    The most similar commands are
	    grep
	    help

or

    $ hg clonmit
    hg: unknown command 'clonmit'
    (did you mean one of clone, commit, config?)

Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:

    exports com.sun.tools.javac.util to
            jdk.jdeps,
            jdk.javadoc,
            jdk.jshell;

---


The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.

The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.

Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.

Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such as `_` and `-`.

The algorithm that this PR proposes is my port of the algorithm from a 1975 paper freely available at https://dl.acm.org/doi/10.1145/321879.321880, with a few Java-related tweaks which when benchmarked seem to speed up (x1.3) the ASCII strings case.

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

Commit messages:
 - Initial commit

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

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

From aturbanov at openjdk.org  Fri Aug  4 14:08:30 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 4 Aug 2023 14:08:30 GMT
Subject: RFR: 8312204: unexpected else with statement causes compiler crash
In-Reply-To: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>
References: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>
Message-ID: <RVgtkpFHToTuOWjil6WnGwywDuhpJxPlU9-WGoYiPIY=.f7ef664c-94e8-44a9-aeb2-8dbe9bdeb425@github.com>

On Mon, 31 Jul 2023 08:43:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Compiling (erroneous) code like:
> 
> void main() {
>     else ;
> }
> 
> 
> Leads to:
> 
> $ javac --enable-preview -source 22 /tmp/Test.java 
> An exception has occurred in the compiler (22-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.parser.VirtualParser$VirtualScanner.errPos(VirtualParser.java:151)
>         at jdk.compiler/com.sun.tools.javac.parser.JavacParser.doRecover(JavacParser.java:3122)
> ...
> 
> 
> The proposed solution is to implement the two corresponding `errPos` methods for `VirtualScanner`.

test/langtools/tools/javac/parser/JavacParserTest.java line 2481:

> 2479: 
> 2480:         for (Diagnostic<? extends JavaFileObject> d : coll.getDiagnostics()) {
> 2481:             codes.add(d.getLineNumber() + ":" + d.getColumnNumber() + ":" +  d.getCode());

Suggestion:

            codes.add(d.getLineNumber() + ":" + d.getColumnNumber() + ":" + d.getCode());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15086#discussion_r1284469551

From aturbanov at openjdk.org  Fri Aug  4 14:50:32 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 4 Aug 2023 14:50:32 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library [v3]
In-Reply-To: <fVgtKYUCStpUtFLZBJvxTJabsrq4DpqczkjyVEwwURM=.e1ed053b-d6ae-495e-a5fd-1b35f00c48b5@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
 <fVgtKYUCStpUtFLZBJvxTJabsrq4DpqczkjyVEwwURM=.e1ed053b-d6ae-495e-a5fd-1b35f00c48b5@github.com>
Message-ID: <9Eg9L9834jdC8x_InxXm_KLLxULDm1XKhFTra0r4-G8=.d9fd7b17-a159-4622-8f63-992ac6a520f9@github.com>

On Wed, 2 Aug 2023 16:07:03 GMT, Qing Xiao <duke at openjdk.org> wrote:

>> Modified 12 of 226 test/langtools/tools/javac test classes to replace com.sun.tools.classfile library.
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added testLength method

test/langtools/tools/javac/annotations/typeAnnotations/classfile/TestAnonInnerClasses.java line 284:

> 282: 
> 283:     public <T extends Attribute<T>>void run() {
> 284:         ClassModel cm   = null;

Suggestion:

        ClassModel cm  = null;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14874#discussion_r1284520845

From acobbs at openjdk.org  Fri Aug  4 15:48:31 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 4 Aug 2023 15:48:31 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation
In-Reply-To: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
Message-ID: <-6vy9d1VG6U-ST35X5_l_e8Xig8JBtz9SDoTt_NCTl8=.61096783-2e62-4cb4-ac36-1ea9861c3c4c@github.com>

On Fri, 4 Aug 2023 13:29:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
> 
> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
> 
>     $ git hlpe
>     git: 'hlpe' is not a git command. See 'git --help'.
>     
>     The most similar commands are
> 	    grep
> 	    help
> 
> or
> 
>     $ hg clonmit
>     hg: unknown command 'clonmit'
>     (did you mean one of clone, commit, config?)
> 
> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
> 
>     exports com.sun.tools.javac.util to
>             jdk.jdeps,
>             jdk.javadoc,
>             jdk.jshell;
> 
> ---
> 
> 
> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
> 
> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
> 
> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
> 
> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such as `_` and `-`.
> 
> The algorithm that this PR proposes is my port of ...

test/langtools/tools/javac/util/StringUtilsTest.java line 62:

> 60: 
> 61:         assertEquals(3, DamerauLevenshteinDistance.of("kitten", "sitting"));
> 62:         // note that the unrestricted Damerau-Levenshtein distance would be 3, not 2:

I think the "unrestricted" in this comment should instead be "restricted".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15157#discussion_r1284582851

From duke at openjdk.org  Fri Aug  4 15:56:03 2023
From: duke at openjdk.org (Qing Xiao)
Date: Fri, 4 Aug 2023 15:56:03 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library [v4]
In-Reply-To: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
Message-ID: <-qLZtGLD_9CAWTX6zcKj2rugBKJ6eXXTHNVj5xalpKE=.add610e8-9d8f-4d44-ac40-cf2f658fb7dc@github.com>

> Modified 12 of 226 test/langtools/tools/javac test classes to replace com.sun.tools.classfile library.

Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  Update test/langtools/tools/javac/annotations/typeAnnotations/classfile/TestAnonInnerClasses.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14874/files
  - new: https://git.openjdk.org/jdk/pull/14874/files/86636785..df9c205a

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

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

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

From prappo at openjdk.org  Fri Aug  4 15:57:54 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Aug 2023 15:57:54 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v2]
In-Reply-To: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
Message-ID: <rDW4gc3mx1TkMwhrBVbpo4dCVF_dTvRMTe3NLc34upc=.1572851a-c1f4-4cbf-9e9a-ca995113c1a8@github.com>

> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
> 
> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
> 
>     $ git hlpe
>     git: 'hlpe' is not a git command. See 'git --help'.
>     
>     The most similar commands are
> 	    grep
> 	    help
> 
> or
> 
>     $ hg clonmit
>     hg: unknown command 'clonmit'
>     (did you mean one of clone, commit, config?)
> 
> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
> 
>     exports com.sun.tools.javac.util to
>             jdk.jdeps,
>             jdk.javadoc,
>             jdk.jshell;
> 
> ---
> 
> 
> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
> 
> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
> 
> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
> 
> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such as `_` and `-`.
> 
> The algorithm that this PR proposes is my port of ...

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15157/files
  - new: https://git.openjdk.org/jdk/pull/15157/files/3cfb1447..20db7d5d

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

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

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

From prappo at openjdk.org  Fri Aug  4 15:57:54 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Aug 2023 15:57:54 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation
In-Reply-To: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
Message-ID: <A0wp4zGUVKyDujZUZgcCmF0iFfssTcxrqEZzPWjnmZE=.f08e53c2-9614-447c-99fb-3e7513084102@github.com>

On Fri, 4 Aug 2023 13:29:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
> 
> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
> 
>     $ git hlpe
>     git: 'hlpe' is not a git command. See 'git --help'.
>     
>     The most similar commands are
> 	    grep
> 	    help
> 
> or
> 
>     $ hg clonmit
>     hg: unknown command 'clonmit'
>     (did you mean one of clone, commit, config?)
> 
> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
> 
>     exports com.sun.tools.javac.util to
>             jdk.jdeps,
>             jdk.javadoc,
>             jdk.jshell;
> 
> ---
> 
> 
> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
> 
> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
> 
> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
> 
> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such as `_` and `-`.
> 
> The algorithm that this PR proposes is my port of ...

I was asked elsewhere to provide demonstration of intended use, for example in jdk.javadoc. Okay:

        var knownTags = """
                author
                code
                deprecated
                docRoot
                exception
                hidden
                index
                inheritDoc
                link
                linkplain
                literal
                param
                provides
                return
                see
                serial
                serialData
                serialField
                since
                snippet
                summary
                systemProperty
                throws
                uses
                value
                version"""
                .lines().toList();

        record Pair(String tag, int distance) { }

        for (var misspelled : """
                serial-filed
                inherotDoc
                inheritdoc
                param
                parm
                returns
                throw
                depreciated
                """.lines().toList()) {
            knownTags.stream()
                    .map(tag -> new Pair(tag, DamerauLevenshteinDistance.of(misspelled, tag)))
                    .filter(i -> Double.compare(1 / 3.0, ((double) i.distance()) / i.tag().length()) >= 0)
                    .sorted(Comparator.comparingDouble(Pair::distance))
                    .limit(3)
                    .forEach(p -> System.out.println(misspelled + "\n\tdid you mean " + p.tag() + "?"));
        }

results in this

serial-filed
	did you mean serialField?
inherotDoc
	did you mean inheritDoc?
inheritdoc
	did you mean inheritDoc?
param
	did you mean param?
parm
	did you mean param?
returns
	did you mean return?
throw
	did you mean throws?
depreciated
	did you mean deprecated?

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

PR Comment: https://git.openjdk.org/jdk/pull/15157#issuecomment-1665830370

From prappo at openjdk.org  Fri Aug  4 15:57:54 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Aug 2023 15:57:54 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v2]
In-Reply-To: <-6vy9d1VG6U-ST35X5_l_e8Xig8JBtz9SDoTt_NCTl8=.61096783-2e62-4cb4-ac36-1ea9861c3c4c@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
 <-6vy9d1VG6U-ST35X5_l_e8Xig8JBtz9SDoTt_NCTl8=.61096783-2e62-4cb4-ac36-1ea9861c3c4c@github.com>
Message-ID: <6C8IoeU-yBwgvVT4DGa7qqkpmqwpDw8-Ys795-MFpEc=.3ece71e7-d71f-482f-a53b-f5e11f0d3bde@github.com>

On Fri, 4 Aug 2023 15:45:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback
>
> test/langtools/tools/javac/util/StringUtilsTest.java line 62:
> 
>> 60: 
>> 61:         assertEquals(3, DamerauLevenshteinDistance.of("kitten", "sitting"));
>> 62:         // note that the unrestricted Damerau-Levenshtein distance would be 3, not 2:
> 
> I think the "unrestricted" in this comment should instead be "restricted".

Fixed; thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15157#discussion_r1284590504

From jlaskey at openjdk.org  Fri Aug  4 16:40:32 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 4 Aug 2023 16:40:32 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v2]
In-Reply-To: <rDW4gc3mx1TkMwhrBVbpo4dCVF_dTvRMTe3NLc34upc=.1572851a-c1f4-4cbf-9e9a-ca995113c1a8@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
 <rDW4gc3mx1TkMwhrBVbpo4dCVF_dTvRMTe3NLc34upc=.1572851a-c1f4-4cbf-9e9a-ca995113c1a8@github.com>
Message-ID: <42qphGco-c8NtIQDHCHN3ES4hHDFRV7yIGofHanegok=.d55efeb6-4657-4ba4-be6c-e32b5ab58a70@github.com>

On Fri, 4 Aug 2023 15:57:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
>> 
>> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
>> 
>>     $ git hlpe
>>     git: 'hlpe' is not a git command. See 'git --help'.
>>     
>>     The most similar commands are
>> 	    grep
>> 	    help
>> 
>> or
>> 
>>     $ hg clonmit
>>     hg: unknown command 'clonmit'
>>     (did you mean one of clone, commit, config?)
>> 
>> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
>> 
>>     exports com.sun.tools.javac.util to
>>             jdk.jdeps,
>>             jdk.javadoc,
>>             jdk.jshell;
>> 
>> ---
>> 
>> 
>> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
>> 
>> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
>> 
>> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
>> 
>> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such...
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback

Brilliant application BTW.

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

PR Comment: https://git.openjdk.org/jdk/pull/15157#issuecomment-1665895440

From jjg at openjdk.org  Fri Aug  4 17:22:31 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 4 Aug 2023 17:22:31 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v2]
In-Reply-To: <rDW4gc3mx1TkMwhrBVbpo4dCVF_dTvRMTe3NLc34upc=.1572851a-c1f4-4cbf-9e9a-ca995113c1a8@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
 <rDW4gc3mx1TkMwhrBVbpo4dCVF_dTvRMTe3NLc34upc=.1572851a-c1f4-4cbf-9e9a-ca995113c1a8@github.com>
Message-ID: <6uOKmpd9C5nKcLD6AeqEyyRCHTUh_fCX4MrJvvLs14o=.00ec7ccb-5189-41ac-aa21-da38108b5ae7@github.com>

On Fri, 4 Aug 2023 15:57:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
>> 
>> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
>> 
>>     $ git hlpe
>>     git: 'hlpe' is not a git command. See 'git --help'.
>>     
>>     The most similar commands are
>> 	    grep
>> 	    help
>> 
>> or
>> 
>>     $ hg clonmit
>>     hg: unknown command 'clonmit'
>>     (did you mean one of clone, commit, config?)
>> 
>> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
>> 
>>     exports com.sun.tools.javac.util to
>>             jdk.jdeps,
>>             jdk.javadoc,
>>             jdk.jshell;
>> 
>> ---
>> 
>> 
>> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
>> 
>> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
>> 
>> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
>> 
>> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such...
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback

test/langtools/tools/javac/util/StringUtilsTest.java line 125:

> 123:     void assertTrue(boolean cond) {
> 124:         if (!cond) {
> 125:             throw new IllegalStateException();

Mildly surprising to see `IllegalStateException` in `assert...` methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15157#discussion_r1284675538

From prappo at openjdk.org  Fri Aug  4 18:36:33 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Aug 2023 18:36:33 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v2]
In-Reply-To: <6uOKmpd9C5nKcLD6AeqEyyRCHTUh_fCX4MrJvvLs14o=.00ec7ccb-5189-41ac-aa21-da38108b5ae7@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
 <rDW4gc3mx1TkMwhrBVbpo4dCVF_dTvRMTe3NLc34upc=.1572851a-c1f4-4cbf-9e9a-ca995113c1a8@github.com>
 <6uOKmpd9C5nKcLD6AeqEyyRCHTUh_fCX4MrJvvLs14o=.00ec7ccb-5189-41ac-aa21-da38108b5ae7@github.com>
Message-ID: <v07VMoOROxuSwfd_K_c0pVB6UmGS5KewEuVE8eqLCrU=.75581dad-5468-4284-a9f4-b9b7077152c2@github.com>

On Fri, 4 Aug 2023 17:19:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback
>
> test/langtools/tools/javac/util/StringUtilsTest.java line 125:
> 
>> 123:     void assertTrue(boolean cond) {
>> 124:         if (!cond) {
>> 125:             throw new IllegalStateException();
> 
> Mildly surprising to see `IllegalStateException` in `assert...` methods.

I simply followed the style of the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15157#discussion_r1284730704

From darcy at openjdk.org  Fri Aug  4 20:33:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Aug 2023 20:33:32 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <1aO9dXw9bj1yZoJd2Ns9XiGXXqfepKWk2FuFHUlCC8o=.7e853a38-4b4c-463f-9bba-380bfc482870@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
 <1aO9dXw9bj1yZoJd2Ns9XiGXXqfepKWk2FuFHUlCC8o=.7e853a38-4b4c-463f-9bba-380bfc482870@github.com>
Message-ID: <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>

On Wed, 2 Aug 2023 21:39:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> General feedback: while the text is good at describing when non-newline characters are removed, it is less good at describing the treatment of newlines ... are they line-terminators or line-separators; how do such characters in the result of `getDocComment` relate to the characters in the source file? For example, does `getDocComment` "copy" the newline characters found in the source file or are they always normalized to `\n` ?

Hmm. Does the precise handling of line terminators matter enough to specify?

> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 286:
> 
>> 284:      * begins with "{@code /**}", ends with a separate
>> 285:      * "<code>*&#47;</code>", and immediately precedes the element,
>> 286:      * ignoring white space and annotations and end-of-line-comments ({@code "//"} comments).
> 
> Turns out that simple block comments are ignored as well. Try:
> 
> /**
>  * This is HW.
>  */
> /* block comment. */
> // line comment
> public class HW { }

Will update accordingly.

> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 300:
> 
>> 298:      * if the lines start with <em>zero</em> or more white space characters followed by
>> 299:      * <em>one</em> or more "{@code *}" characters,
>> 300:      * those leading white space characters are discarded as are any
> 
> FWIW, I checked `javac` and it allows form-feed in the leading whitespace characters
> 
> As an adjective "white space" is normally a single word, at least in JDK.

Hmm. java.lang.Character contains both "whitespace" and "white space" in its textual comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/15062#issuecomment-1666140009
PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1284822082
PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1284823732

From prappo at openjdk.org  Fri Aug  4 21:05:29 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Aug 2023 21:05:29 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation
In-Reply-To: <A0wp4zGUVKyDujZUZgcCmF0iFfssTcxrqEZzPWjnmZE=.f08e53c2-9614-447c-99fb-3e7513084102@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
 <A0wp4zGUVKyDujZUZgcCmF0iFfssTcxrqEZzPWjnmZE=.f08e53c2-9614-447c-99fb-3e7513084102@github.com>
Message-ID: <Fl3PlSuB3MNBUMtd7nh1yfyKWyfEWZkX97VaFpehqSs=.3c8b03be-6684-4b1c-8023-8165a9e0e6a7@github.com>

On Fri, 4 Aug 2023 15:50:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>         for (var misspelled : """
>                 serial-filed
>                 inherotDoc
>                 inheritdoc
>                 param

(snip)

> ```
> param
> 	did you mean param?
> ```

I was asked elsewhere about "param". It's a typo that should've been "params", which is a real-world misspelling captured in https://bugs.openjdk.org/browse/JDK-8288660.

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

PR Comment: https://git.openjdk.org/jdk/pull/15157#issuecomment-1666177748

From alex.buckley at oracle.com  Fri Aug  4 21:14:52 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 4 Aug 2023 14:14:52 -0700
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
 <1aO9dXw9bj1yZoJd2Ns9XiGXXqfepKWk2FuFHUlCC8o=.7e853a38-4b4c-463f-9bba-380bfc482870@github.com>
 <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>
Message-ID: <9cc23aa4-f852-499a-a051-6a5bbde3c381@oracle.com>

On 8/4/2023 1:33 PM, Joe Darcy wrote:
>> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 300:
>>
>>> 298:      * if the lines start with <em>zero</em> or more white space characters followed by
>>> 299:      * <em>one</em> or more "{@code *}" characters,
>>> 300:      * those leading white space characters are discarded as are any
>>
>> FWIW, I checked `javac` and it allows form-feed in the leading whitespace characters
>>
>> As an adjective "white space" is normally a single word, at least in JDK.
> 
> Hmm. java.lang.Character contains both "whitespace" and "white space" in its textual comments.

The JLS is careful to speak only of "white space" as a noun, never as an 
adjective for "character". But I think that when the adjective is 
needed, it's "whitespace". java.lang.Character follows this rule, e.g., 
"ISO control characters that are not whitespace" (i.e., are not 
whitespace characters).

Alex

From darcy at openjdk.org  Fri Aug  4 21:31:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Aug 2023 21:31:52 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v6]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <hk0oiqdK4he1gdHbJFeGPpgx-oQJJdo_cVYOHXSvwoQ=.045e1b85-cd26-4584-8a29-ed29a3b147fc@github.com>

> Start by just reformatting the existing specs to highlight subsequent spec changes.

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 seven additional commits since the last revision:

 - Respond to review comments.
 - Merge branch 'master' into JDK-8307184
 - Appease jcheck.
 - Updates.
 - Add tests; adjust spec.
 - Update non-beginning, non-eneding lines of the spec.
 - JDK-8307184: Incorrect/inconsistent specification and implementation for Elements.getDocComment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15062/files
  - new: https://git.openjdk.org/jdk/pull/15062/files/9b436d26..79b11319

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

  Stats: 2840 lines in 123 files changed: 1130 ins; 859 del; 851 mod
  Patch: https://git.openjdk.org/jdk/pull/15062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15062/head:pull/15062

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

From darcy at openjdk.org  Fri Aug  4 21:31:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Aug 2023 21:31:53 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <qKZl0EAQixUz6WCEYvLOFSUWD_hJuCwxa7yjW9PPuRM=.c39aa540-a6f5-4375-a77c-136ad2da5561@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
 <qKZl0EAQixUz6WCEYvLOFSUWD_hJuCwxa7yjW9PPuRM=.c39aa540-a6f5-4375-a77c-136ad2da5561@github.com>
Message-ID: <n1yZgf0YZ-W991wV9hn27eW0aicz5NzieFYNjP6QPJc=.b826cb78-dab8-4bf1-8d27-ff95e3092b0e@github.com>

On Wed, 2 Aug 2023 21:33:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Appease jcheck.
>
> test/langtools/tools/javac/processing/model/util/elements/TestGetDocComments.java line 80:
> 
>> 78:             System.out.println("Strings have different lengths");
>> 79:         }
>> 80:     }
> 
> Not critical, but for bonus points, you could identify the first line that is different.

Do you know of an existing utility usable in the JDK that does this?
(I didn't want to write a utility like that for the purpose of this bug.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1284859642

From darcy at openjdk.org  Fri Aug  4 21:42:43 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Aug 2023 21:42:43 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v7]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <SJidLC4w0PQtwfynyEsz8bKAzurmMwcDG4jWJQjzykY=.d46f563e-01a1-411a-8d69-89329ef459f9@github.com>

> Start by just reformatting the existing specs to highlight subsequent spec changes.

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

  Augment test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15062/files
  - new: https://git.openjdk.org/jdk/pull/15062/files/79b11319..32c99b29

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

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

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

From darcy at openjdk.org  Sat Aug  5 20:27:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 5 Aug 2023 20:27:54 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v8]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <vRTib5UWdKS6H_vX5AQ0Se5ifzDOlZwtEvKNsHzsoqk=.a0d6ca71-0296-4f7e-bd16-9cd926c3bcd3@github.com>

> Start by just reformatting the existing specs to highlight subsequent spec changes.

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

  Use "whitespace" as an adjective.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15062/files
  - new: https://git.openjdk.org/jdk/pull/15062/files/32c99b29..34aa6ed8

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

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

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

From darcy at openjdk.org  Sun Aug  6 20:48:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 6 Aug 2023 20:48:51 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v9]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <xPXIT7ejj9lTVsSS_nImQ0MVrYw8klpD--dOfU-Tsa8=.9f1b358c-0e3f-4d04-91a2-d3c7967e323a@github.com>

> Start by just reformatting the existing specs to highlight subsequent spec changes.

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

  Add test case for newlines.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15062/files
  - new: https://git.openjdk.org/jdk/pull/15062/files/34aa6ed8..99fae194

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

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

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

From darcy at openjdk.org  Sun Aug  6 20:48:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 6 Aug 2023 20:48:51 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
 <1aO9dXw9bj1yZoJd2Ns9XiGXXqfepKWk2FuFHUlCC8o=.7e853a38-4b4c-463f-9bba-380bfc482870@github.com>
 <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>
Message-ID: <O-e_r8JOe01PFEEzXt6TLPq7FhS-26IT-3zMuC0ZcDs=.a0056be8-b29d-4e22-8451-300bb138aac6@github.com>

On Fri, 4 Aug 2023 20:27:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > General feedback: while the text is good at describing when non-newline characters are removed, it is less good at describing the treatment of newlines ... are they line-terminators or line-separators; how do such characters in the result of `getDocComment` relate to the characters in the source file? For example, does `getDocComment` "copy" the newline characters found in the source file or are they always normalized to `\n` ?
> 
> Hmm. Does the precise handling of line terminators matter enough to specify?

PS FWIW, the javac implementation does normalize line terminators, test case added.

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

PR Comment: https://git.openjdk.org/jdk/pull/15062#issuecomment-1666963739

From asotona at openjdk.org  Mon Aug  7 13:27:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 7 Aug 2023 13:27:33 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library [v4]
In-Reply-To: <-qLZtGLD_9CAWTX6zcKj2rugBKJ6eXXTHNVj5xalpKE=.add610e8-9d8f-4d44-ac40-cf2f658fb7dc@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
 <-qLZtGLD_9CAWTX6zcKj2rugBKJ6eXXTHNVj5xalpKE=.add610e8-9d8f-4d44-ac40-cf2f658fb7dc@github.com>
Message-ID: <_G57w6GA4ystTLhTlFLKT0FzJ9MPCPDs-WGFq3H_FLw=.34242b84-b1d1-449b-836f-badcf4176730@github.com>

On Fri, 4 Aug 2023 15:56:03 GMT, Qing Xiao <duke at openjdk.org> wrote:

>> Modified 12 of 226 test/langtools/tools/javac test classes to replace com.sun.tools.classfile library.
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/langtools/tools/javac/annotations/typeAnnotations/classfile/TestAnonInnerClasses.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

It looks good.
I think it can go in if you sync PR title "116 tests classes"  with bug title "116 test classes".
Thanks for the work.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14874#pullrequestreview-1565327319

From aturbanov at openjdk.org  Mon Aug  7 15:13:35 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 7 Aug 2023 15:13:35 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 test classes uses
 com.sun.tools.classfile library [v4]
In-Reply-To: <-qLZtGLD_9CAWTX6zcKj2rugBKJ6eXXTHNVj5xalpKE=.add610e8-9d8f-4d44-ac40-cf2f658fb7dc@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
 <-qLZtGLD_9CAWTX6zcKj2rugBKJ6eXXTHNVj5xalpKE=.add610e8-9d8f-4d44-ac40-cf2f658fb7dc@github.com>
Message-ID: <Rc2fMbJfp-Mtj7NH1aGxM8B2usL8YZY2Xqfu5zn7KAU=.24d6b35f-fa0f-4b0f-9da3-218346c82079@github.com>

On Fri, 4 Aug 2023 15:56:03 GMT, Qing Xiao <duke at openjdk.org> wrote:

>> Modified 12 of 226 test/langtools/tools/javac test classes to replace com.sun.tools.classfile library.
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/langtools/tools/javac/annotations/typeAnnotations/classfile/TestAnonInnerClasses.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

>Modified 12 of 226 test/langtools/tools/javac test classes to replace com.sun.tools.classfile library.

Is this is still actual number? I mean 12.

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

PR Comment: https://git.openjdk.org/jdk/pull/14874#issuecomment-1668059599

From duke at openjdk.org  Mon Aug  7 15:52:43 2023
From: duke at openjdk.org (Qing Xiao)
Date: Mon, 7 Aug 2023 15:52:43 GMT
Subject: Integrated: 8295058: test/langtools/tools/javac 116 test classes uses
 com.sun.tools.classfile library
In-Reply-To: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
Message-ID: <DV1n4a5PgdpOduX6cS7mFTQfCwA2nJKj8OjSC5EKHxw=.eb6945da-f907-4fd4-b7d4-6f8add19a85a@github.com>

On Thu, 13 Jul 2023 17:29:44 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified 116 tests with new Class-File API, and migrate helper methods to test/langtools/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest3.java while keep using old Class-File API

This pull request has now been integrated.

Changeset: 380418fa
Author:    Qing Xiao <xqoasis at gmail.com>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/380418fad07c0526bb698b4bfcbacbd65a8615be
Stats:     2840 lines in 117 files changed: 847 ins; 714 del; 1279 mod

8295058: test/langtools/tools/javac 116 test classes uses com.sun.tools.classfile library

Reviewed-by: asotona

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

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

From vromero at openjdk.org  Mon Aug  7 15:54:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Aug 2023 15:54:29 GMT
Subject: RFR: 8312204: unexpected else with statement causes compiler crash
In-Reply-To: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>
References: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>
Message-ID: <Ugcpi_wzAZOtAnDRmlNKUikFemr65SaTtmd25Iw_ryc=.5cb93e88-a828-48f4-ae8e-8e47ee73677c@github.com>

On Mon, 31 Jul 2023 08:43:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Compiling (erroneous) code like:
> 
> void main() {
>     else ;
> }
> 
> 
> Leads to:
> 
> $ javac --enable-preview -source 22 /tmp/Test.java 
> An exception has occurred in the compiler (22-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.parser.VirtualParser$VirtualScanner.errPos(VirtualParser.java:151)
>         at jdk.compiler/com.sun.tools.javac.parser.JavacParser.doRecover(JavacParser.java:3122)
> ...
> 
> 
> The proposed solution is to implement the two corresponding `errPos` methods for `VirtualScanner`.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15086#pullrequestreview-1565669717

From acobbs at openjdk.org  Mon Aug  7 20:36:35 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 7 Aug 2023 20:36:35 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v2]
In-Reply-To: <x-Rxw4lDuUoyqSvj6lj_J5GUFRQj_1KeLBc-PfBauDg=.904d293c-467c-41e7-b176-1bee7c7ca387@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <x-Rxw4lDuUoyqSvj6lj_J5GUFRQj_1KeLBc-PfBauDg=.904d293c-467c-41e7-b176-1bee7c7ca387@github.com>
Message-ID: <nYIfZOzY7fR92SZ5-vqo9fhwc4jwSmItyxEjgfc0Kg8=.a239dc1f-df5d-4845-bff6-989de6e3a731@github.com>

On Mon, 12 Jun 2023 15:02:46 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
>> 
>> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
>> 
>> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
>> 
>> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
>> 
>> Changes:
>> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
>> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
>> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
>> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
>> * Add new `StringNameTable` implementation.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Move equals() table check into common superclass.
>  - Add Name.Table factory methods to Names class.
>  - Add StringNameTable as a new (optional) Name.Table implementation.
>  - Add a few more default method implementations to Name superclass.
>  - Revert some unnecessary changes.
>  - Merge branch 'master' into JDK-8269957
>  - Refactor Name and friends to facilitate future improvements.

pingbot

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

PR Comment: https://git.openjdk.org/jdk/pull/13282#issuecomment-1668542244

From jlahoda at openjdk.org  Tue Aug  8 09:33:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Aug 2023 09:33:56 GMT
Subject: RFR: 8312204: unexpected else with statement causes compiler crash
 [v2]
In-Reply-To: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>
References: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>
Message-ID: <DPV47SoHy6LpKiOmnydzM1Y2vy0BTkfRlTahrgfGqBQ=.e25d2551-995d-4372-a750-a226652a1800@github.com>

> Compiling (erroneous) code like:
> 
> void main() {
>     else ;
> }
> 
> 
> Leads to:
> 
> $ javac --enable-preview -source 22 /tmp/Test.java 
> An exception has occurred in the compiler (22-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.parser.VirtualParser$VirtualScanner.errPos(VirtualParser.java:151)
>         at jdk.compiler/com.sun.tools.javac.parser.JavacParser.doRecover(JavacParser.java:3122)
> ...
> 
> 
> The proposed solution is to implement the two corresponding `errPos` methods for `VirtualScanner`.

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

  Update test/langtools/tools/javac/parser/JavacParserTest.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15086/files
  - new: https://git.openjdk.org/jdk/pull/15086/files/a2c898b4..723c1577

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

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

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

From jlahoda at openjdk.org  Tue Aug  8 09:33:57 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Aug 2023 09:33:57 GMT
Subject: Integrated: 8312204: unexpected else with statement causes compiler
 crash
In-Reply-To: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>
References: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>
Message-ID: <quG4rEMIno97y3PJbAzAFDSN0qjp0fMj1aGVZD6ayDI=.2df70e06-6820-40de-b40c-f6939b639598@github.com>

On Mon, 31 Jul 2023 08:43:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Compiling (erroneous) code like:
> 
> void main() {
>     else ;
> }
> 
> 
> Leads to:
> 
> $ javac --enable-preview -source 22 /tmp/Test.java 
> An exception has occurred in the compiler (22-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.parser.VirtualParser$VirtualScanner.errPos(VirtualParser.java:151)
>         at jdk.compiler/com.sun.tools.javac.parser.JavacParser.doRecover(JavacParser.java:3122)
> ...
> 
> 
> The proposed solution is to implement the two corresponding `errPos` methods for `VirtualScanner`.

This pull request has now been integrated.

Changeset: a1115a7a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1115a7a39438438ec247743718cdc1ec59823d6
Stats:     41 lines in 2 files changed: 38 ins; 0 del; 3 mod

8312204: unexpected else with statement causes compiler crash

Reviewed-by: vromero

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

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

From jlaskey at openjdk.org  Tue Aug  8 19:39:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 8 Aug 2023 19:39:44 GMT
Subject: [jdk21] RFR: 8312814: Compiler crash when template processor type is a
 captured wildcard
Message-ID: <dxeI2b_42qImbCQwXc1VqXyfQMAkvHzsPdu2hkqMzHE=.8d3640c2-2226-41ad-81b8-d9f328deee5a@github.com>

8312814: Compiler crash when template processor type is a captured wildcard

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

Commit messages:
 - Backport f14245b3880ff735ae231b4c7d2c6b6907c5f7d4

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

PR: https://git.openjdk.org/jdk21/pull/167

From jjg at openjdk.org  Tue Aug  8 19:59:38 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 8 Aug 2023 19:59:38 GMT
Subject: [jdk21] RFR: 8312814: Compiler crash when template processor type
 is a captured wildcard
In-Reply-To: <dxeI2b_42qImbCQwXc1VqXyfQMAkvHzsPdu2hkqMzHE=.8d3640c2-2226-41ad-81b8-d9f328deee5a@github.com>
References: <dxeI2b_42qImbCQwXc1VqXyfQMAkvHzsPdu2hkqMzHE=.8d3640c2-2226-41ad-81b8-d9f328deee5a@github.com>
Message-ID: <AhnayoDdfuKZdlJW_5h4swlS53qGpKzn0Nl2LWqGR_A=.a933d1f3-55c8-4559-b3ff-4049bf4aa7ba@github.com>

On Tue, 8 Aug 2023 19:30:48 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> 8312814: Compiler crash when template processor type is a captured wildcard

Marked as reviewed by jjg (Reviewer).

Yes, looks the same as the original

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

PR Review: https://git.openjdk.org/jdk21/pull/167#pullrequestreview-1568086957
PR Comment: https://git.openjdk.org/jdk21/pull/167#issuecomment-1670223068

From vromero at openjdk.org  Tue Aug  8 19:59:39 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 8 Aug 2023 19:59:39 GMT
Subject: [jdk21] RFR: 8312814: Compiler crash when template processor type
 is a captured wildcard
In-Reply-To: <dxeI2b_42qImbCQwXc1VqXyfQMAkvHzsPdu2hkqMzHE=.8d3640c2-2226-41ad-81b8-d9f328deee5a@github.com>
References: <dxeI2b_42qImbCQwXc1VqXyfQMAkvHzsPdu2hkqMzHE=.8d3640c2-2226-41ad-81b8-d9f328deee5a@github.com>
Message-ID: <wEC2ajnt9EvNZzNX454vNQ06z1SYmrad7hRKZ1d6a6E=.da2026c4-ea89-4adc-aeba-e6982a1bbadd@github.com>

On Tue, 8 Aug 2023 19:30:48 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> 8312814: Compiler crash when template processor type is a captured wildcard

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/167#pullrequestreview-1568088722

From jlaskey at openjdk.org  Wed Aug  9 11:02:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Aug 2023 11:02:28 GMT
Subject: [jdk21] Integrated: 8312814: Compiler crash when template processor
 type is a captured wildcard
In-Reply-To: <dxeI2b_42qImbCQwXc1VqXyfQMAkvHzsPdu2hkqMzHE=.8d3640c2-2226-41ad-81b8-d9f328deee5a@github.com>
References: <dxeI2b_42qImbCQwXc1VqXyfQMAkvHzsPdu2hkqMzHE=.8d3640c2-2226-41ad-81b8-d9f328deee5a@github.com>
Message-ID: <GbdJk40UG4PG6IUYiZkL3J1Ee6CdaaotN5HB4GlvAj8=.a2f80868-a454-41bf-8e46-397bc6ebbf84@github.com>

On Tue, 8 Aug 2023 19:30:48 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> 8312814: Compiler crash when template processor type is a captured wildcard

This pull request has now been integrated.

Changeset: a0735305
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a07353053d3103a48ee1c5f208f055e580dd15ff
Stats:     40 lines in 2 files changed: 40 ins; 0 del; 0 mod

8312814: Compiler crash when template processor type is a captured wildcard

Reviewed-by: jjg, vromero
Backport-of: f14245b3880ff735ae231b4c7d2c6b6907c5f7d4

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

PR: https://git.openjdk.org/jdk21/pull/167

From prappo at openjdk.org  Wed Aug  9 13:25:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 9 Aug 2023 13:25:03 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v3]
In-Reply-To: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
Message-ID: <f1WeRkgY9OZBxhBGbfwgCvMA8MFZxnSK24MPbL_1p5Y=.2300b20c-a684-4010-8ddc-9777e267d1b3@github.com>

> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
> 
> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
> 
>     $ git hlpe
>     git: 'hlpe' is not a git command. See 'git --help'.
>     
>     The most similar commands are
> 	    grep
> 	    help
> 
> or
> 
>     $ hg clonmit
>     hg: unknown command 'clonmit'
>     (did you mean one of clone, commit, config?)
> 
> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
> 
>     exports com.sun.tools.javac.util to
>             jdk.jdeps,
>             jdk.javadoc,
>             jdk.jshell;
> 
> ---
> 
> 
> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
> 
> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
> 
> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
> 
> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such as `_` and `-`.
> 
> The algorithm that this PR proposes is my port of ...

Pavel Rappo 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:

 - Feedback: provide a usage example
 - Merge branch 'master' into 8313693
 - Feedback
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15157/files
  - new: https://git.openjdk.org/jdk/pull/15157/files/20db7d5d..5233e68d

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

  Stats: 9369 lines in 434 files changed: 3339 ins; 2874 del; 3156 mod
  Patch: https://git.openjdk.org/jdk/pull/15157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15157/head:pull/15157

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

From jlahoda at openjdk.org  Wed Aug  9 13:48:00 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Aug 2023 13:48:00 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v3]
In-Reply-To: <f1WeRkgY9OZBxhBGbfwgCvMA8MFZxnSK24MPbL_1p5Y=.2300b20c-a684-4010-8ddc-9777e267d1b3@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
 <f1WeRkgY9OZBxhBGbfwgCvMA8MFZxnSK24MPbL_1p5Y=.2300b20c-a684-4010-8ddc-9777e267d1b3@github.com>
Message-ID: <tDsYWOsGixWo_fSj0UD7jf7f_ScI8Jt4cxljqrpLNpw=.ac080651-65b4-436d-a406-7bda71f3d8c3@github.com>

On Wed, 9 Aug 2023 13:25:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
>> 
>> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
>> 
>>     $ git hlpe
>>     git: 'hlpe' is not a git command. See 'git --help'.
>>     
>>     The most similar commands are
>> 	    grep
>> 	    help
>> 
>> or
>> 
>>     $ hg clonmit
>>     hg: unknown command 'clonmit'
>>     (did you mean one of clone, commit, config?)
>> 
>> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
>> 
>>     exports com.sun.tools.javac.util to
>>             jdk.jdeps,
>>             jdk.javadoc,
>>             jdk.jshell;
>> 
>> ---
>> 
>> 
>> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
>> 
>> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
>> 
>> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
>> 
>> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such...
>
> Pavel Rappo 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:
> 
>  - Feedback: provide a usage example
>  - Merge branch 'master' into 8313693
>  - Feedback
>  - Initial commit

Looks reasonable to me. (FWIW, I have some prototype for suggesting similar names for mistypes elements, although I was always on the fence on how useful is that in the real world.)

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15157#pullrequestreview-1569593108

From prappo at openjdk.org  Wed Aug  9 14:18:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 9 Aug 2023 14:18:28 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v3]
In-Reply-To: <tDsYWOsGixWo_fSj0UD7jf7f_ScI8Jt4cxljqrpLNpw=.ac080651-65b4-436d-a406-7bda71f3d8c3@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
 <f1WeRkgY9OZBxhBGbfwgCvMA8MFZxnSK24MPbL_1p5Y=.2300b20c-a684-4010-8ddc-9777e267d1b3@github.com>
 <tDsYWOsGixWo_fSj0UD7jf7f_ScI8Jt4cxljqrpLNpw=.ac080651-65b4-436d-a406-7bda71f3d8c3@github.com>
Message-ID: <4SNcIrB24z7ZzgL4wEE1KDqf7e7wPM1gxBX9v0Atccg=.2ae44c27-ec0b-42ae-bb11-836bba43e871@github.com>

On Wed, 9 Aug 2023 13:41:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> (FWIW, I have some prototype for suggesting similar names for mistypes elements, although I was always on the fence on how useful is that in the real world.)

It remains to be seen how useful it will be. I'd imagine it'll be helpful to [on-ramp audience](https://openjdk.org/projects/amber/design-notes/on-ramp) in CLI and REPL. Additionally, it might be helpful for mistyped tags in jdk.javadoc. Unlike command-line options, the list of javadoc tags is not the easiest thing to obtain. Even if it were, sometimes even seasoned developers occasionally stumble upon `@returns` or `@throw`. In which case, a helpful error message will likely reduce head-scratching.

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

PR Comment: https://git.openjdk.org/jdk/pull/15157#issuecomment-1671379640

From jjg at openjdk.org  Wed Aug  9 16:26:30 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 9 Aug 2023 16:26:30 GMT
Subject: RFR: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation [v3]
In-Reply-To: <f1WeRkgY9OZBxhBGbfwgCvMA8MFZxnSK24MPbL_1p5Y=.2300b20c-a684-4010-8ddc-9777e267d1b3@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
 <f1WeRkgY9OZBxhBGbfwgCvMA8MFZxnSK24MPbL_1p5Y=.2300b20c-a684-4010-8ddc-9777e267d1b3@github.com>
Message-ID: <Sv9CePgadu9TEyggiIiAw4iveFV1rimWdwtwPuU_XZo=.fb62c64c-3970-44e1-b08c-c6cf64cfef9c@github.com>

On Wed, 9 Aug 2023 13:25:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
>> 
>> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
>> 
>>     $ git hlpe
>>     git: 'hlpe' is not a git command. See 'git --help'.
>>     
>>     The most similar commands are
>> 	    grep
>> 	    help
>> 
>> or
>> 
>>     $ hg clonmit
>>     hg: unknown command 'clonmit'
>>     (did you mean one of clone, commit, config?)
>> 
>> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
>> 
>>     exports com.sun.tools.javac.util to
>>             jdk.jdeps,
>>             jdk.javadoc,
>>             jdk.jshell;
>> 
>> ---
>> 
>> 
>> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
>> 
>> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
>> 
>> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
>> 
>> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such...
>
> Pavel Rappo 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:
> 
>  - Feedback: provide a usage example
>  - Merge branch 'master' into 8313693
>  - Feedback
>  - Initial commit

Marked as reviewed by jjg (Reviewer).

Very nice; it will be interesting to see this used in practice, especially in terms of improving user-feedback in the case of mistakes or errors.

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

PR Review: https://git.openjdk.org/jdk/pull/15157#pullrequestreview-1570011786
PR Comment: https://git.openjdk.org/jdk/pull/15157#issuecomment-1671726204

From prappo at openjdk.org  Wed Aug  9 16:26:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 9 Aug 2023 16:26:32 GMT
Subject: Integrated: 8313693: Introduce an internal utility for the
 =?UTF-8?B?RGFtZXJhdeKAk0xldmVuc2h0ZWlu?= distance calculation
In-Reply-To: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
References: <oT9vakNfoMXAzkRPmjYADHd_qq65tZMxM7bwxpnZ1sM=.26e6448a-af6a-4e1f-8437-abe12ed1cd78@github.com>
Message-ID: <6YDQWae9_Mt3M-xMPd_1zHp2DHvNIey5Pvi3RG97LCY=.f4e9b8ee-514b-45c9-83ac-28d3c675198b@github.com>

On Fri, 4 Aug 2023 13:29:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to introduce the Damerau?Levenshtein distance calculation for later use in REPL and CLI.
> 
> The Damerau?Levenshtein distance (DL) is a string similarity metric, variants of which have been successfully used in REPL and CLI:
> 
>     $ git hlpe
>     git: 'hlpe' is not a git command. See 'git --help'.
>     
>     The most similar commands are
> 	    grep
> 	    help
> 
> or
> 
>     $ hg clonmit
>     hg: unknown command 'clonmit'
>     (did you mean one of clone, commit, config?)
> 
> Originally, DL was requested by https://bugs.openjdk.org/browse/JDK-8288660 to provide helpful error messages for mistyped javadoc tags. However, given its wider applicability (e.g. mistyped command-line options), it was suggested that DL is put somewhere more internally accessible, for example, in `com.sun.tools.javac.util`, which is available in `jdk.compiler` and already exported to some other potential clients:
> 
>     exports com.sun.tools.javac.util to
>             jdk.jdeps,
>             jdk.javadoc,
>             jdk.jshell;
> 
> ---
> 
> 
> The Levenshtein edit distance is concerned with three types of edits: insertions, deletions, and substitutions. The Damerau-Levenshtein distance adds the fourth type: transpositions of two adjacent characters. This considerably complicates the algorithm, which is currently known in two main forms: restricted and unrestricted.
> 
> The difference between the two forms is that the simpler form, restricted, operates under the assumption that no substring is edited more than once. This results in different distances between some strings, for example, "CA" and "ABC". Restricted DL gives 3, whereas unrestricted DL gives 2.
> 
> Git seems to have [chosen](https://git.kernel.org/pub/scm/git/git.git/commit/?id=8af84dadb142f7321ff0ce8690385e99da8ede2f) restricted DL. This PR proposes **un**restricted DL. From my nonexpert perspective, while unrestricted DL does not necessarily guarantee a better end result, it feels a better place to start. Additionally, unrestricted DL is a proper metric. That property could probably be used to quickly estimate the upper bound of DL in some applications.
> 
> Like restricted DL, unrestricted DL runs in `O(s1.length() * s2.length())` in time. However, unrestricted DL requires more space: `O(s1.length() * s2.length())` plus the space for the alphabet, which for the purposes stated in this PR should be relatively small: `[a-zA-Z0-9]` plus maybe a dozen of additional symbols, such as `_` and `-`.
> 
> The algorithm that this PR proposes is my port of ...

This pull request has now been integrated.

Changeset: 593ba2fe
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/593ba2fe47ce6bd341ee6e1329aa02d4b472fb60
Stats:     246 lines in 2 files changed: 243 ins; 0 del; 3 mod

8313693: Introduce an internal utility for the Damerau?Levenshtein distance calculation

Reviewed-by: jlahoda, jjg

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

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

From acobbs at openjdk.org  Wed Aug  9 16:27:04 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Aug 2023 16:27:04 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v3]
In-Reply-To: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
Message-ID: <-9DpongXz3ucY03cgUV-kftKWGHgQzf6mPAzDXKV5mw=.5b9d82bf-58de-4189-b725-7f82591f7262@github.com>

> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
> 
> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
> 
> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
> 
> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
> 
> Changes:
> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
> * Add new `StringNameTable` implementation.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into JDK-8269957
 - Merge branch 'master' into JDK-8269957
 - Merge branch 'master' into JDK-8269957
 - Move equals() table check into common superclass.
 - Add Name.Table factory methods to Names class.
 - Add StringNameTable as a new (optional) Name.Table implementation.
 - Add a few more default method implementations to Name superclass.
 - Revert some unnecessary changes.
 - Merge branch 'master' into JDK-8269957
 - Refactor Name and friends to facilitate future improvements.

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

Changes: https://git.openjdk.org/jdk/pull/13282/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13282&range=02
  Stats: 834 lines in 11 files changed: 571 ins; 162 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/13282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13282/head:pull/13282

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

From jjg at openjdk.org  Wed Aug  9 16:37:58 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 9 Aug 2023 16:37:58 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <O-e_r8JOe01PFEEzXt6TLPq7FhS-26IT-3zMuC0ZcDs=.a0056be8-b29d-4e22-8451-300bb138aac6@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
 <1aO9dXw9bj1yZoJd2Ns9XiGXXqfepKWk2FuFHUlCC8o=.7e853a38-4b4c-463f-9bba-380bfc482870@github.com>
 <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>
 <O-e_r8JOe01PFEEzXt6TLPq7FhS-26IT-3zMuC0ZcDs=.a0056be8-b29d-4e22-8451-300bb138aac6@github.com>
Message-ID: <uf7tJCfaaCA71k1uCy2e3bwA2uAoI5kSgtoMdzLDHyM=.b8b291f9-b182-4417-b30f-dbe5dcaa1024@github.com>

On Sun, 6 Aug 2023 20:43:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > General feedback: while the text is good at describing when non-newline characters are removed, it is less good at describing the treatment of newlines ... are they line-terminators or line-separators; how do such characters in the result of `getDocComment` relate to the characters in the source file? For example, does `getDocComment` "copy" the newline characters found in the source file or are they always normalized to `\n` ?
> 
> Hmm. Does the precise handling of line terminators matter enough to specify?

Medium yes. For anyone parsing the contents of a doc comment, it helps to know whether the terminators are "as in the source file" or "always `\n`".   I guess if unspecified, users will have to assume the worst case (may be as in the source file) even if that is not typically the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/15062#issuecomment-1671751731

From jjg at openjdk.org  Wed Aug  9 16:37:29 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 9 Aug 2023 16:37:29 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v9]
In-Reply-To: <xPXIT7ejj9lTVsSS_nImQ0MVrYw8klpD--dOfU-Tsa8=.9f1b358c-0e3f-4d04-91a2-d3c7967e323a@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <xPXIT7ejj9lTVsSS_nImQ0MVrYw8klpD--dOfU-Tsa8=.9f1b358c-0e3f-4d04-91a2-d3c7967e323a@github.com>
Message-ID: <s5UAXlpSathFDg1D_JBksKskYi9-9R5F0rx3XU2Cp1Y=.c4756dcf-d6d7-47d8-95e1-bf7f512f2c0b@github.com>

On Sun, 6 Aug 2023 20:48:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start by just reformatting the existing specs to highlight subsequent spec changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test case for newlines.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15062#pullrequestreview-1570072779

From jjg at openjdk.org  Wed Aug  9 16:39:58 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 9 Aug 2023 16:39:58 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
 <1aO9dXw9bj1yZoJd2Ns9XiGXXqfepKWk2FuFHUlCC8o=.7e853a38-4b4c-463f-9bba-380bfc482870@github.com>
 <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>
Message-ID: <icsTTZpBEDHDA_RUhTgWIj-fMsKUna0u9peDPCN5Ua8=.47a00176-01c4-445f-b039-3e87f5f867b0@github.com>

On Fri, 4 Aug 2023 20:29:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 300:
>> 
>>> 298:      * if the lines start with <em>zero</em> or more white space characters followed by
>>> 299:      * <em>one</em> or more "{@code *}" characters,
>>> 300:      * those leading white space characters are discarded as are any
>> 
>> FWIW, I checked `javac` and it allows form-feed in the leading whitespace characters
>> 
>> As an adjective "white space" is normally a single word, at least in JDK.
>
> Hmm. java.lang.Character contains both "whitespace" and "white space" in its textual comments.

Yes, the difference is typically `whitespace` (adjective) and `white space` noun.  But no matter.

>> test/langtools/tools/javac/processing/model/util/elements/TestGetDocComments.java line 80:
>> 
>>> 78:             System.out.println("Strings have different lengths");
>>> 79:         }
>>> 80:     }
>> 
>> Not critical, but for bonus points, you could identify the first line that is different.
>
> Do you know of an existing utility usable in the JDK that does this?
> (I didn't want to write a utility like that for the purpose of this bug.)

`ToolBox.checkEqual`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1288852934
PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1288855763

From darcy at openjdk.org  Wed Aug  9 20:40:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 9 Aug 2023 20:40:05 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v10]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <nmhtbOnxJpBlM-tRsy41smdkz9_NcK9e8z7zlj6gL2I=.607e7d68-f34b-4e78-be16-8393e54151b2@github.com>

> Start by just reformatting the existing specs to highlight subsequent spec changes.

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 12 additional commits since the last revision:

 - Implement review feedback.
 - Merge branch 'master' into JDK-8307184
 - Add test case for newlines.
 - Use "whitespace" as an adjective.
 - Augment test.
 - Respond to review comments.
 - Merge branch 'master' into JDK-8307184
 - Appease jcheck.
 - Updates.
 - Add tests; adjust spec.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/c3976970...9e5c7b04

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15062/files
  - new: https://git.openjdk.org/jdk/pull/15062/files/99fae194..9e5c7b04

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

  Stats: 7717 lines in 306 files changed: 4545 ins; 1532 del; 1640 mod
  Patch: https://git.openjdk.org/jdk/pull/15062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15062/head:pull/15062

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

From jjg at openjdk.org  Wed Aug  9 20:40:07 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 9 Aug 2023 20:40:07 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v10]
In-Reply-To: <nmhtbOnxJpBlM-tRsy41smdkz9_NcK9e8z7zlj6gL2I=.607e7d68-f34b-4e78-be16-8393e54151b2@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <nmhtbOnxJpBlM-tRsy41smdkz9_NcK9e8z7zlj6gL2I=.607e7d68-f34b-4e78-be16-8393e54151b2@github.com>
Message-ID: <jtPxXd98F3OpNqKu352Dddppg0rv_Pmgb6EIo9WIh-Q=.032e2db5-7ffc-4161-9ad2-81bb58fd6a85@github.com>

On Wed, 9 Aug 2023 20:25:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start by just reformatting the existing specs to highlight subsequent spec changes.
>
> 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 12 additional commits since the last revision:
> 
>  - Implement review feedback.
>  - Merge branch 'master' into JDK-8307184
>  - Add test case for newlines.
>  - Use "whitespace" as an adjective.
>  - Augment test.
>  - Respond to review comments.
>  - Merge branch 'master' into JDK-8307184
>  - Appease jcheck.
>  - Updates.
>  - Add tests; adjust spec.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/c3976970...9e5c7b04

Marked as reviewed by jjg (Reviewer).

test/langtools/tools/javac/processing/model/util/elements/TestGetDocComments.java line 60:

> 58:                         if (!expectedCommentStr.equals(actualComment)) {
> 59:                             messager.printError("Unexpected doc comment found", element);
> 60:                             (new ToolBox()).checkEqual(expectedCommentStr.lines().toList(),

:-)

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

PR Review: https://git.openjdk.org/jdk/pull/15062#pullrequestreview-1570489413
PR Review Comment: https://git.openjdk.org/jdk/pull/15062#discussion_r1289153401

From jjg at openjdk.org  Wed Aug  9 20:40:07 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 9 Aug 2023 20:40:07 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <uf7tJCfaaCA71k1uCy2e3bwA2uAoI5kSgtoMdzLDHyM=.b8b291f9-b182-4417-b30f-dbe5dcaa1024@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>
 <1aO9dXw9bj1yZoJd2Ns9XiGXXqfepKWk2FuFHUlCC8o=.7e853a38-4b4c-463f-9bba-380bfc482870@github.com>
 <6-Bafuc_dS9zEI0K_Z3v9fi4j9Y-3_U7AbWqHnqPrt0=.51aa480d-1cea-4c3f-88d2-ee90c90c765d@github.com>
 <O-e_r8JOe01PFEEzXt6TLPq7FhS-26IT-3zMuC0ZcDs=.a0056be8-b29d-4e22-8451-300bb138aac6@github.com>
 <uf7tJCfaaCA71k1uCy2e3bwA2uAoI5kSgtoMdzLDHyM=.b8b291f9-b182-4417-b30f-dbe5dcaa1024@github.com>
Message-ID: <KoAEiVacNhjQExFzvS715VXZMlTrJTjGY_9nL9HzRmA=.f2b20032-8c88-4c2e-9bab-7e4bd4243dcd@github.com>

On Wed, 9 Aug 2023 16:24:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> > > General feedback: while the text is good at describing when non-newline characters are removed, it is less good at describing the treatment of newlines ... are they line-terminators or line-separators; how do such characters in the result of `getDocComment` relate to the characters in the source file? For example, does `getDocComment` "copy" the newline characters found in the source file or are they always normalized to `\n` ?
> > 
> > 
> > Hmm. Does the precise handling of line terminators matter enough to specify?
> 
> Medium yes. For anyone parsing the contents of a doc comment, it helps to know whether the terminators are "as in the source file" or "always `\n`". I guess if unspecified, users will have to assume the worst case (may be as in the source file) even if that is not typically the case.

I guess for anyone doing character-based parsing, handling line-ending sequences is no biggie.  For folk doing line-based parsing `String.lines()` comes to mind ...

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

PR Comment: https://git.openjdk.org/jdk/pull/15062#issuecomment-1672098087

From darcy at openjdk.org  Wed Aug  9 21:36:59 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 9 Aug 2023 21:36:59 GMT
Subject: Integrated: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <wZcJ2OeJv77fdm-_and07zX_lJ68k9FMnhjAsX3iPcs=.1dccef66-6666-4072-881c-f08842ce6ba8@github.com>

On Fri, 28 Jul 2023 02:24:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start by just reformatting the existing specs to highlight subsequent spec changes.

This pull request has now been integrated.

Changeset: c307391a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c307391ab1f071b1473cd5f4c12437b8d5e0ca93
Stats:     217 lines in 2 files changed: 211 ins; 0 del; 6 mod

8307184: Incorrect/inconsistent specification and implementation for Elements.getDocComment

Reviewed-by: vromero, jjg

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

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

From darcy at openjdk.org  Thu Aug 10 22:37:33 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 10 Aug 2023 22:37:33 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
Message-ID: <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>

> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).

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

 - Iteration of spec update.
 - Merge branch 'master' into JDK-8281169
 - Checkpoint intermediate state.
 - Merge branch 'master' into JDK-8281169
 - JDK-8281169: Expand discussion of elements and types

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15097/files
  - new: https://git.openjdk.org/jdk/pull/15097/files/9a06ca1a..350a5d1f

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

  Stats: 18487 lines in 793 files changed: 8431 ins; 4965 del; 5091 mod
  Patch: https://git.openjdk.org/jdk/pull/15097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15097/head:pull/15097

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

From jwaters at openjdk.org  Fri Aug 11 06:38:58 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 11 Aug 2023 06:38:58 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac [v2]
In-Reply-To: <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
Message-ID: <pnQxYZ_8wbYvQs7ISt-t-wHLTH64ZX-JM87q8Jfpqtc=.312b704e-dcf6-411a-8d3b-32c3e630c743@github.com>

On Fri, 23 Jun 2023 02:45:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)
>
> Julian Waters 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 'openjdk:master' into patch-2
>  - Remove Visual C++ specific workaround in javac

Don't do that Skara, I will return to this patch in due time

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

PR Comment: https://git.openjdk.org/jdk/pull/13457#issuecomment-1674257025

From prappo at openjdk.org  Fri Aug 11 12:28:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 11 Aug 2023 12:28:28 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
Message-ID: <jggDq28Oy7MDpvGCa5sEG0R_9223e8vS3iijBk6bfvw=.9c4cc53c-011e-4ad2-8a71-31b7168b6564@github.com>

On Thu, 10 Aug 2023 22:37:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> 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 five additional commits since the last revision:
> 
>  - Iteration of spec update.
>  - Merge branch 'master' into JDK-8281169
>  - Checkpoint intermediate state.
>  - Merge branch 'master' into JDK-8281169
>  - JDK-8281169: Expand discussion of elements and types

I urge other reviewers to take an opportunity to look at the `javax.lang.model` specification holistically. This is to make sure that these concepts that package-info.java is talking about do paint the big picture and are uniform across many places, including but not limited to:

  * top-level doc comment for DeclaredType
  * top-level doc comment for TypeElement

FWIW, I like the concept of a _prototypical type_, coined and consistently used by javax.lang.model.

This iteration is succinct, albeit it might need if only a small bit of wordsmithing.

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

PR Comment: https://git.openjdk.org/jdk/pull/15097#issuecomment-1674653182

From prappo at openjdk.org  Fri Aug 11 15:10:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 11 Aug 2023 15:10:58 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
Message-ID: <knBx0PyasYqcFDfm3Ngq0bdYLzpCe-c98POK-hTLyhM=.86178fcb-f140-48bf-bc9f-c93818ed963a@github.com>

On Thu, 10 Aug 2023 22:37:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> 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 five additional commits since the last revision:
> 
>  - Iteration of spec update.
>  - Merge branch 'master' into JDK-8281169
>  - Checkpoint intermediate state.
>  - Merge branch 'master' into JDK-8281169
>  - JDK-8281169: Expand discussion of elements and types

Looks good to me.

So that it requires at least two _R_eviewers, not 1 Reviewer and 1 Author.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15097#pullrequestreview-1573823690
PR Comment: https://git.openjdk.org/jdk/pull/15097#issuecomment-1674922170

From ethan at mccue.dev  Mon Aug 14 22:39:35 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 14 Aug 2023 18:39:35 -0400
Subject: [External] : Re: Error examples page
In-Reply-To: <7205be7f-9227-6578-1b76-a9db8afce2c9@oracle.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>
 <bbeec72f-04e1-709c-cb4e-e173f5b15f06@oracle.com>
 <CA+NR86gm4gcZ+1nhYmAY2orUEhiOxjqtACPZ-GgA22g9JzYAQA@mail.gmail.com>
 <7205be7f-9227-6578-1b76-a9db8afce2c9@oracle.com>
Message-ID: <CA+NR86hwhV8FOw56gQj2d2WgT3Aq8MMVk2X715asoQJ_o-y_Rg@mail.gmail.com>

Following up on this thread, I published (to the best of my ability) the
result of the work with the students.

https://mccue.dev/pages/8-13-23-java-compiler-error-messages

(I know I haven't really responded to Maurizio's points about the inference
and parsing errors, the thrust of what I wrote and the prototype we made is
"we at least need a box to put the solutions into", if that makes sense.)



On Tue, Feb 7, 2023 at 8:57?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> there are two classes of errors that are hard. The first, as your example
> demonstrates, has to do with parser errors. When parsing it is hard to
> recover from errors. Javac tries to do its best, but if you are parsing a
> production, and you find a token that is unexpected for that production, it
> is not clear what should happen next. I mean, an error should be reported -
> but what then? Javac tries to figure out where to start parsing again - in
> some cases this can be done with some success (e.g. finding the matching
> closing brace, parens, etc.). In other cases it's harder, and it can lead
> to pathological situations such as the ones you describe. Some of these
> issues might be made worse by actual bugs (so it is possible that in the
> case of "expected class" there's an actual issue with javac - would be nice
> to have a reproducer).
>
> The other class of errors that are hard are errors related to overload
> resolution and inference. The problem there is that the error has to cover
> so much ground (too much). When you have an overload resolution failure,
> you can, at least in the general case, have many overload candidates, each
> of which fails for a different reason (which might be interesting or not).
> If there's inference, the reason as to why a candidate is not applicable
> might be obscure (e.g. incompatible bounds on an inference variable), and
> if you have nested or chained generic method calls, things tend to explode
> pretty quickly, so when your typical stream chain fails to type it's hard
> to understand exactly what needs to be fixed - often because the error
> typicall shows up in the wrong place. For instance, you might get an error
> message when you call `toList()` on a stream and assign it to a
> `List<String>` - but the real problem is that the type of the stream is not
> `Stream<String>` as you expect: something sent inference down the wrong
> path in an earlier call in the method chain, which caused the stream type
> to become `Stream<Object>`.
>
> These things can (and should!) be improved, but there's a limit on how
> much you can improve things when working with the command line interface.
> For instance, when diagnosing inference issues inside an IDE, I find myself
> hoovering on each component of the call chain, or try to use auto-complete
> after each subexpression, to have a rough idea of what the type might be at
> that point. Even doing that is not always possible: methods that are
> generic in their return type can be "influenced" by their surrounding
> context, so breaking up a method chain can sometimes result in changes to
> how a subexpression is typed. So... it's an hard problem - and the limited
> visual aids a terminal offer, combined with the lack of interaction makes
> these issues particularly pesky. Other langauges have explored the idea of
> a type debugger [1] - although I don't know what's the state of these
> initiatives.
>
> Cheers
> Maurizio
>
> [1] - https://infoscience.epfl.ch/record/179877?ln=en
>
>
>
> On 04/02/2023 03:48, Ethan McCue wrote:
>
> 1. The error messages that the student got were not helpful for them
> seeing their error. I don't have their original code so I can't dive in to
> why and say "ah, we could obviously make this case better", but I choose to
> believe there was some way to not vomit "class, interface, enum, or
> record expected" nine times.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230814/94e4a774/attachment.htm>

From ethan at mccue.dev  Mon Aug 14 23:48:03 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 14 Aug 2023 19:48:03 -0400
Subject: [External] : Re: Error examples page
In-Reply-To: <CA+NR86hwhV8FOw56gQj2d2WgT3Aq8MMVk2X715asoQJ_o-y_Rg@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>
 <bbeec72f-04e1-709c-cb4e-e173f5b15f06@oracle.com>
 <CA+NR86gm4gcZ+1nhYmAY2orUEhiOxjqtACPZ-GgA22g9JzYAQA@mail.gmail.com>
 <7205be7f-9227-6578-1b76-a9db8afce2c9@oracle.com>
 <CA+NR86hwhV8FOw56gQj2d2WgT3Aq8MMVk2X715asoQJ_o-y_Rg@mail.gmail.com>
Message-ID: <CA+NR86h6_wcBV4BxvPx6xQBWwbN1v5Gi_gbhykRFwO-U_KcPsg@mail.gmail.com>

Also coming out of some of the other discussions[1][2] I think there is one
table from a paper[3] that feels relevant to the discussion.

| Compiler Error Message                | n     | %     |
|---------------------------------------|-------|-------|
| cannot find symbol                    | 4,614 | 16.0% |
| ?)? expected                          | 3,317 | 11.5% |
| ?;? expected                          | 3,076 | 10.7% |
| not a statement                       | 2,142 | 7.4%  |
| illegal start of expression           | 1,825 | 6.3%  |
| reached end of file while parsing     | 1,406 | 4.9%  |
| illegal start of type                 | 1,316 | 4.6%  |
| ?else? without ?if?                   | 1,141 | 4.0%  |
| bad operand types for binary operator | 1,138 | 3.9%  |
| <identifier> expected                 | 1,091 | 3.8%  |

This shows the frequency at which their sample of students ran into
different errors.[4]



[1]:
https://www.reddit.com/r/programming/comments/15qzny5/better_java_compiler_error_messages/
[2]:
https://www.reddit.com/r/java/comments/15qzkh9/better_java_compiler_error_messages/
[3]:
https://drive.google.com/file/d/1GUj-KQMzWhuWTk7ksAIgABKiGkHseHQL/view?usp=sharing
[4]: I don't know whether this generalizes to the language as it will exist
in the future or whether that particular paper is reliable, but it's a
start.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230814/514109af/attachment.htm>

From mcimadamore at openjdk.org  Tue Aug 15 17:32:14 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Aug 2023 17:32:14 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
Message-ID: <HwWO0Af0zY-sNOWqSPipVH75kKGnwGAcFSaVirfIeRo=.a25304cb-717b-4979-992a-35050b23d374@github.com>

On Thu, 10 Aug 2023 22:37:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> 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 five additional commits since the last revision:
> 
>  - Iteration of spec update.
>  - Merge branch 'master' into JDK-8281169
>  - Checkpoint intermediate state.
>  - Merge branch 'master' into JDK-8281169
>  - JDK-8281169: Expand discussion of elements and types

src/java.compiler/share/classes/javax/lang/model/package-info.java line 114:

> 112:  *
> 113:  * <p>All elements can be {@linkplain
> 114:  * javax.lang.model.element.Element#asType() mapped to} some type. For

I find this sentence not very clear. I'd phrase it more directly as "Class and interface elements map to..." but I think "prototypical type" is also part of the problem (what is it?). Perhaps it would be worth mentioning that this type has some interesting properties:
* if the element is a non-generic class, then the type is equal to a type mirror corresponding to the unannotated use of that type.
* if the element is a generic class, then the type is a parameterization of the class declaration, where the type arguments are the type variables of the declaring class/interface.

src/java.compiler/share/classes/javax/lang/model/package-info.java line 117:

> 115:  * classes and interfaces, their elements get {@linkplain
> 116:  * javax.lang.model.element.TypeElement#asType() mapped to} a
> 117:  * prototypical type. Conversely, in general, many types can map to a

replace "to a given" with "to the same"

src/java.compiler/share/classes/javax/lang/model/package-info.java line 122:

> 120:  * java.util.Set<E>}, and the type {@code java.util.Set<String>} would
> 121:  * all {@linkplain javax.lang.model.type.DeclaredType#asElement() map
> 122:  * to} the element for {@code java.util.Set}. Several kinds of types

It would be good to mention at least one `e.g.` for each case - e.g. `DeclaredType` have an element, but `ExecutableType` does not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1294904085
PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1294904356
PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1294906404

From darcy at openjdk.org  Wed Aug 16 04:59:34 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 04:59:34 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v3]
In-Reply-To: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
Message-ID: <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>

> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).

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 seven additional commits since the last revision:

 - Implement review feedback.
 - Merge branch 'master' into JDK-8281169
 - Iteration of spec update.
 - Merge branch 'master' into JDK-8281169
 - Checkpoint intermediate state.
 - Merge branch 'master' into JDK-8281169
 - JDK-8281169: Expand discussion of elements and types

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15097/files
  - new: https://git.openjdk.org/jdk/pull/15097/files/350a5d1f..fe197d6c

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

  Stats: 7427 lines in 289 files changed: 3601 ins; 848 del; 2978 mod
  Patch: https://git.openjdk.org/jdk/pull/15097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15097/head:pull/15097

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

From liach at openjdk.org  Wed Aug 16 05:12:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Aug 2023 05:12:12 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
Message-ID: <E5Xz5FGKYnI7h_kYDSl59stFOjSKgfjipZ9RZTyHlKY=.ffc8b140-581c-4ae4-97b5-ec819936d4d0@github.com>

On Thu, 10 Aug 2023 22:37:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> 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 five additional commits since the last revision:
> 
>  - Iteration of spec update.
>  - Merge branch 'master' into JDK-8281169
>  - Checkpoint intermediate state.
>  - Merge branch 'master' into JDK-8281169
>  - JDK-8281169: Expand discussion of elements and types

src/java.compiler/share/classes/javax/lang/model/package-info.java line 49:

> 47:  * element} representing {@code java.util.Set}, and the family of
> 48:  * {@linkplain javax.lang.model.type types} that may be associated
> 49:  * with an element, like the raw type {@code java.util.Set},{@code

Suggestion:

 * with an element, like the raw type {@code java.util.Set}, {@code

Looks like an incorrect space deletion change here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1295257389

From darcy at openjdk.org  Wed Aug 16 05:16:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 05:16:11 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <HwWO0Af0zY-sNOWqSPipVH75kKGnwGAcFSaVirfIeRo=.a25304cb-717b-4979-992a-35050b23d374@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
 <HwWO0Af0zY-sNOWqSPipVH75kKGnwGAcFSaVirfIeRo=.a25304cb-717b-4979-992a-35050b23d374@github.com>
Message-ID: <ZKrpqibriZ1ADaUYZ02FmN4CZaV6_8cIVmoKtwGhC6s=.f265f511-3784-4b82-9ebe-e091b5c3168c@github.com>

On Tue, 15 Aug 2023 17:29:15 GMT, Maurizio Cimadamore <mcimadamore 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 five additional commits since the last revision:
>> 
>>  - Iteration of spec update.
>>  - Merge branch 'master' into JDK-8281169
>>  - Checkpoint intermediate state.
>>  - Merge branch 'master' into JDK-8281169
>>  - JDK-8281169: Expand discussion of elements and types
>
> src/java.compiler/share/classes/javax/lang/model/package-info.java line 122:
> 
>> 120:  * java.util.Set<E>}, and the type {@code java.util.Set<String>} would
>> 121:  * all {@linkplain javax.lang.model.type.DeclaredType#asElement() map
>> 122:  * to} the element for {@code java.util.Set}. Several kinds of types
> 
> It would be good to mention at least one `e.g.` for each case - e.g. `DeclaredType` have an element, but `ExecutableType` does not.

Updated per your suggestions, I'll reflow the paragraphs once we've settled on the final text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1295386867

From prappo at openjdk.org  Wed Aug 16 09:07:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 16 Aug 2023 09:07:12 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v3]
In-Reply-To: <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
Message-ID: <8WFuiLZ04laZc2sEGv-VgpE3FJ1rIDsT-smMc0M6-Ig=.79a9151c-f612-4ce6-a141-74d79355540d@github.com>

On Wed, 16 Aug 2023 04:59:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> 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 seven additional commits since the last revision:
> 
>  - Implement review feedback.
>  - Merge branch 'master' into JDK-8281169
>  - Iteration of spec update.
>  - Merge branch 'master' into JDK-8281169
>  - Checkpoint intermediate state.
>  - Merge branch 'master' into JDK-8281169
>  - JDK-8281169: Expand discussion of elements and types

Changes requested by prappo (Reviewer).

src/java.compiler/share/classes/javax/lang/model/element/package-info.java line 113:

> 111:  *
> 112:  * @see javax.lang.model.util.Elements
> 113:  * @see javax.lang.model##elementsAndTypes Element and Types

While it's a nice way to emphasize that one element maps to many types, I think it's a typo: the heading is "Elements and Types".
Suggestion:

 * @see javax.lang.model##elementsAndTypes Elements and Types

src/java.compiler/share/classes/javax/lang/model/type/package-info.java line 37:

> 35:  *
> 36:  * @see javax.lang.model.util.Types
> 37:  * @see javax.lang.model##elementsAndTypes Element and Types

Suggestion:

 * @see javax.lang.model##elementsAndTypes Elements and Types

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

PR Review: https://git.openjdk.org/jdk/pull/15097#pullrequestreview-1580099834
PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1295573445
PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1295578497

From prappo at openjdk.org  Wed Aug 16 10:08:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 16 Aug 2023 10:08:11 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <HwWO0Af0zY-sNOWqSPipVH75kKGnwGAcFSaVirfIeRo=.a25304cb-717b-4979-992a-35050b23d374@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
 <HwWO0Af0zY-sNOWqSPipVH75kKGnwGAcFSaVirfIeRo=.a25304cb-717b-4979-992a-35050b23d374@github.com>
Message-ID: <gj180G5Vp9RftUTu5XeAcrabNu6yAYE1WJCxgDDvTH8=.178aeaa1-963b-402b-a28d-13d4d03e500a@github.com>

On Tue, 15 Aug 2023 17:26:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> prototypical type

FWIW, that term is used multiple times in that package. Maybe it's worth defining and `{@index}`-ing, in a separate PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1295672902

From prappo at openjdk.org  Wed Aug 16 10:31:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 16 Aug 2023 10:31:11 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v3]
In-Reply-To: <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
Message-ID: <AOPtsNpce0HxYkdrZuCpDC4EnKsMJbZbFRuPw1JMhlY=.67100d5a-df2d-4675-8e96-5231f2a64615@github.com>

On Wed, 16 Aug 2023 04:59:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> 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 seven additional commits since the last revision:
> 
>  - Implement review feedback.
>  - Merge branch 'master' into JDK-8281169
>  - Iteration of spec update.
>  - Merge branch 'master' into JDK-8281169
>  - Checkpoint intermediate state.
>  - Merge branch 'master' into JDK-8281169
>  - JDK-8281169: Expand discussion of elements and types

src/java.compiler/share/classes/javax/lang/model/package-info.java line 81:

> 79:  * a {@code @DefinitelyNotNull} type annotation while the type of
> 80:  * the parameter is a {@code String} annotated with a {@code
> 81:  * @MightBeNull} type annotation. In a reflective API, since the set

> In a reflective API,

Nit: re-reading that bit made me pause for a moment and doubt that javax.lang.model is a reflective API, which I hope it is. We could help the reader by rephrasing that more assertively as "In a reflective API, such as this one," or dropping "In a reflective API" altogether.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1295695947

From mcimadamore at openjdk.org  Wed Aug 16 14:00:14 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Aug 2023 14:00:14 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v3]
In-Reply-To: <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
Message-ID: <IbE9qsQZ9WzFfXd_Y6lcoE3ZfDc6kv65MwqMsZsJHoo=.9a63260d-fa5b-448c-bfd5-c5211882d9f3@github.com>

On Wed, 16 Aug 2023 04:59:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> 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 seven additional commits since the last revision:
> 
>  - Implement review feedback.
>  - Merge branch 'master' into JDK-8281169
>  - Iteration of spec update.
>  - Merge branch 'master' into JDK-8281169
>  - Checkpoint intermediate state.
>  - Merge branch 'master' into JDK-8281169
>  - JDK-8281169: Expand discussion of elements and types

Javadoc text looks very good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15097#pullrequestreview-1580699923

From prappo at openjdk.org  Wed Aug 16 14:41:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 16 Aug 2023 14:41:15 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v3]
In-Reply-To: <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
Message-ID: <d2Vo8tOHDvSwJ_HyG8o7_MStFzUjbu0RjfkT9RWwMes=.36ccbffd-0832-458d-a468-cd0112a18429@github.com>

On Wed, 16 Aug 2023 04:59:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> 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 seven additional commits since the last revision:
> 
>  - Implement review feedback.
>  - Merge branch 'master' into JDK-8281169
>  - Iteration of spec update.
>  - Merge branch 'master' into JDK-8281169
>  - Checkpoint intermediate state.
>  - Merge branch 'master' into JDK-8281169
>  - JDK-8281169: Expand discussion of elements and types

src/java.compiler/share/classes/javax/lang/model/package-info.java line 86:

> 84:  * be represented by different objects to distinguish between these two
> 85:  * cases. The <em>definition</em> of {@code java.lang.String} itself
> 86:  * is annotated with neither of the type annotations in question.

Out of curiosity, how does this method from `Types` fit into this paragraph?

     * <p>Since annotations are only meta-data associated with a type,
     * the set of annotations on either argument is <em>not</em> taken
     * into account when computing whether or not two {@code
     * TypeMirror} objects are the same type. In particular, two
     * {@code TypeMirror} objects can have different annotations and
     * still be considered the same.
     *
     * @param t1  the first type
     * @param t2  the second type
     * @return {@code true} if and only if the two types are the same
     */
    boolean isSameType(TypeMirror t1, TypeMirror t2);

src/java.compiler/share/classes/javax/lang/model/package-info.java line 122:

> 120:  * the declaration. Otherwise, for a non-generic class or interface,
> 121:  * the prototypical type mirror corresponds to an unannotated use of
> 122:  * the type.)

Perhaps I'm not quite following it, but why juxtapose "default" parameterization with being unannotated? I assume, for a generic class or interface, the prototypical type is also unannotated, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1296012218
PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1296018763

From abimpoudis at openjdk.org  Wed Aug 16 15:01:27 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 16 Aug 2023 15:01:27 GMT
Subject: RFR: 8314423: Multiple patterns without unnamed variables
Message-ID: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>

This PR addresses both [JDK-8314423](https://bugs.openjdk.org/browse/JDK-8314423) and [JDK-8314216](https://bugs.openjdk.org/browse/JDK-8314216), since both are relevant to checks around the structure of switch in the relevant method in `Check`. Additionally a check was needed in `analyzePattern` to detect that when a case starts with a constant case label followed by a `,` or `->` is indeed a constant expression and not a pattern as previously signified.

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

Commit messages:
 - 8314423: Multiple patterns without unnamed variables

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

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

From jlahoda at openjdk.org  Wed Aug 16 15:12:11 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Aug 2023 15:12:11 GMT
Subject: RFR: 8314423: Multiple patterns without unnamed variables
In-Reply-To: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
References: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
Message-ID: <LhqPabS7Nu4sMtEZZ0swmU8k8Xrvh9VKuCrU7OKZu7s=.aab0edde-cef0-4cc7-8c28-7f3fc54b2bed@github.com>

On Wed, 16 Aug 2023 14:52:14 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR addresses both [JDK-8314423](https://bugs.openjdk.org/browse/JDK-8314423) and [JDK-8314216](https://bugs.openjdk.org/browse/JDK-8314216), since both are relevant to checks around the structure of switch in the relevant method in `Check`. Additionally a check was needed in `analyzePattern` to detect that when a case starts with a constant case label followed by a `,` or `->` is indeed a constant expression and not a pattern as previously signified.

Looks reasonable, with some comments.

test/langtools/tools/javac/T8314216.java line 20:

> 18: 
> 19:     public static void main(String[] args) {
> 20:         new Test().test("ddd");

Note `Test` is not in scope here (not declared), which is the cause of the `cant.resolve.location` error. Is there a reason to keep the `main` method here? Seems to me it should be fine to simply remove it?

test/langtools/tools/javac/T8314423.java line 4:

> 2:  * @test  /nodynamiccopyright/
> 3:  * @bug 8314423
> 4:  * @summary Multiple patterns without unnamed variables

Maybe use `@enablePreview` instead of `--enable-preview`?

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

PR Review: https://git.openjdk.org/jdk/pull/15310#pullrequestreview-1580855285
PR Review Comment: https://git.openjdk.org/jdk/pull/15310#discussion_r1296061208
PR Review Comment: https://git.openjdk.org/jdk/pull/15310#discussion_r1296061693

From abimpoudis at openjdk.org  Wed Aug 16 15:22:37 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 16 Aug 2023 15:22:37 GMT
Subject: RFR: 8314423: Multiple patterns without unnamed variables [v2]
In-Reply-To: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
References: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
Message-ID: <PbwLOMPpkwTNW36Ith-pUVZOL9QXcs5Y2ZMeOXsPSy4=.0b43e03e-3509-4bc1-98fb-ab68af46a1c1@github.com>

> This PR addresses both [JDK-8314423](https://bugs.openjdk.org/browse/JDK-8314423) and [JDK-8314216](https://bugs.openjdk.org/browse/JDK-8314216), since both are relevant to checks around the structure of switch in the relevant method in `Check`. Additionally a check was needed in `analyzePattern` to detect that when a case starts with a constant case label followed by a `,` or `->` is indeed a constant expression and not a pattern as previously signified.

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

  Cleanup of T8314216

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15310/files
  - new: https://git.openjdk.org/jdk/pull/15310/files/6fa8619b..07308ba2

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

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

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

From jlahoda at openjdk.org  Wed Aug 16 15:22:38 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Aug 2023 15:22:38 GMT
Subject: RFR: 8314423: Multiple patterns without unnamed variables [v2]
In-Reply-To: <PbwLOMPpkwTNW36Ith-pUVZOL9QXcs5Y2ZMeOXsPSy4=.0b43e03e-3509-4bc1-98fb-ab68af46a1c1@github.com>
References: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
 <PbwLOMPpkwTNW36Ith-pUVZOL9QXcs5Y2ZMeOXsPSy4=.0b43e03e-3509-4bc1-98fb-ab68af46a1c1@github.com>
Message-ID: <QUS8soOqS56GS_6uPpV4MOgZVV_liAAF22aPO35ydlQ=.df213746-dcf0-451f-ac5b-d70455dae264@github.com>

On Wed, 16 Aug 2023 15:17:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR addresses both [JDK-8314423](https://bugs.openjdk.org/browse/JDK-8314423) and [JDK-8314216](https://bugs.openjdk.org/browse/JDK-8314216), since both are relevant to checks around the structure of switch in the relevant method in `Check`. Additionally a check was needed in `analyzePattern` to detect that when a case starts with a constant case label followed by a `,` or `->` is indeed a constant expression and not a pattern as previously signified.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup of T8314216

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15310#pullrequestreview-1580870628

From abimpoudis at openjdk.org  Wed Aug 16 15:22:38 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 16 Aug 2023 15:22:38 GMT
Subject: RFR: 8314423: Multiple patterns without unnamed variables [v2]
In-Reply-To: <LhqPabS7Nu4sMtEZZ0swmU8k8Xrvh9VKuCrU7OKZu7s=.aab0edde-cef0-4cc7-8c28-7f3fc54b2bed@github.com>
References: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
 <LhqPabS7Nu4sMtEZZ0swmU8k8Xrvh9VKuCrU7OKZu7s=.aab0edde-cef0-4cc7-8c28-7f3fc54b2bed@github.com>
Message-ID: <lZMb-nb1RqVSE5wYFxC0k5vxx1YtV60lhW5-duQC9LY=.d1e29080-5aa1-4429-9601-35aaa1471a0d@github.com>

On Wed, 16 Aug 2023 15:08:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup of T8314216
>
> test/langtools/tools/javac/T8314216.java line 20:
> 
>> 18: 
>> 19:     public static void main(String[] args) {
>> 20:         new Test().test("ddd");
> 
> Note `Test` is not in scope here (not declared), which is the cause of the `cant.resolve.location` error. Is there a reason to keep the `main` method here? Seems to me it should be fine to simply remove it?

Thx!

> test/langtools/tools/javac/T8314423.java line 4:
> 
>> 2:  * @test  /nodynamiccopyright/
>> 3:  * @bug 8314423
>> 4:  * @summary Multiple patterns without unnamed variables
> 
> Maybe use `@enablePreview` instead of `--enable-preview`?

I would like to avoid the `@enablePreview` to be applied to both `@compile` commands. In the first I test that it will raise the error by checking the preview feature, and in the second that it will compile successfully. Isn't `@enablePreview` going to be applied to both?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15310#discussion_r1296066984
PR Review Comment: https://git.openjdk.org/jdk/pull/15310#discussion_r1296069300

From jlahoda at openjdk.org  Wed Aug 16 15:22:38 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Aug 2023 15:22:38 GMT
Subject: RFR: 8314423: Multiple patterns without unnamed variables [v2]
In-Reply-To: <lZMb-nb1RqVSE5wYFxC0k5vxx1YtV60lhW5-duQC9LY=.d1e29080-5aa1-4429-9601-35aaa1471a0d@github.com>
References: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
 <LhqPabS7Nu4sMtEZZ0swmU8k8Xrvh9VKuCrU7OKZu7s=.aab0edde-cef0-4cc7-8c28-7f3fc54b2bed@github.com>
 <lZMb-nb1RqVSE5wYFxC0k5vxx1YtV60lhW5-duQC9LY=.d1e29080-5aa1-4429-9601-35aaa1471a0d@github.com>
Message-ID: <0E4gMJEHuWFyeXtXWtjIabWKXL14i-qNu8DdUJ9XWpQ=.eb2fcb81-d6a1-4f4b-950a-44f7b72ce07e@github.com>

On Wed, 16 Aug 2023 15:14:36 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> test/langtools/tools/javac/T8314423.java line 4:
>> 
>>> 2:  * @test  /nodynamiccopyright/
>>> 3:  * @bug 8314423
>>> 4:  * @summary Multiple patterns without unnamed variables
>> 
>> Maybe use `@enablePreview` instead of `--enable-preview`?
>
> I would like to avoid the `@enablePreview` to be applied to both `@compile` commands. In the first I test that it will raise the error by checking the preview feature, and in the second that it will compile successfully. Isn't `@enablePreview` going to be applied to both?

Ah, sorry, I missed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15310#discussion_r1296071091

From darcy at openjdk.org  Wed Aug 16 16:23:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 16:23:12 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <gj180G5Vp9RftUTu5XeAcrabNu6yAYE1WJCxgDDvTH8=.178aeaa1-963b-402b-a28d-13d4d03e500a@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
 <HwWO0Af0zY-sNOWqSPipVH75kKGnwGAcFSaVirfIeRo=.a25304cb-717b-4979-992a-35050b23d374@github.com>
 <gj180G5Vp9RftUTu5XeAcrabNu6yAYE1WJCxgDDvTH8=.178aeaa1-963b-402b-a28d-13d4d03e500a@github.com>
Message-ID: <KNt3lIegP3RMLKn40y1AF3WFKqvDoamNL18dfVbzFDI=.1c017d85-32c1-491c-9bfb-f1a9c583acbc@github.com>

On Wed, 16 Aug 2023 10:05:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/package-info.java line 114:
>> 
>>> 112:  *
>>> 113:  * <p>All elements can be {@linkplain
>>> 114:  * javax.lang.model.element.Element#asType() mapped to} some type. For
>> 
>> I find this sentence not very clear. I'd phrase it more directly as "Class and interface elements map to..." but I think "prototypical type" is also part of the problem (what is it?). Perhaps it would be worth mentioning that this type has some interesting properties:
>> * if the element is a non-generic class, then the type is equal to a type mirror corresponding to the unannotated use of that type.
>> * if the element is a generic class, then the type is a parameterization of the class declaration, where the type arguments are the type variables of the declaring class/interface.
>
>> prototypical type
> 
> FWIW, that term is used multiple times in that package. Maybe it's worth defining and `{@index}`-ing, in a separate PR?

Yes, javax.lang.model has long used "prototypical type" -- I'll making the index entry, etc. in a follow-up changeset; good suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1296154077

From darcy at openjdk.org  Wed Aug 16 16:38:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 16:38:16 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v3]
In-Reply-To: <AOPtsNpce0HxYkdrZuCpDC4EnKsMJbZbFRuPw1JMhlY=.67100d5a-df2d-4675-8e96-5231f2a64615@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
 <AOPtsNpce0HxYkdrZuCpDC4EnKsMJbZbFRuPw1JMhlY=.67100d5a-df2d-4675-8e96-5231f2a64615@github.com>
Message-ID: <HfL4F9QJNQtxsPSP08wCTtfhMqNngayZX591fboeHaY=.57ec059c-f6e2-4133-bc7a-0feb5e6e08c4@github.com>

On Wed, 16 Aug 2023 10:27:40 GMT, Pavel Rappo <prappo 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 seven additional commits since the last revision:
>> 
>>  - Implement review feedback.
>>  - Merge branch 'master' into JDK-8281169
>>  - Iteration of spec update.
>>  - Merge branch 'master' into JDK-8281169
>>  - Checkpoint intermediate state.
>>  - Merge branch 'master' into JDK-8281169
>>  - JDK-8281169: Expand discussion of elements and types
>
> src/java.compiler/share/classes/javax/lang/model/package-info.java line 81:
> 
>> 79:  * a {@code @DefinitelyNotNull} type annotation while the type of
>> 80:  * the parameter is a {@code String} annotated with a {@code
>> 81:  * @MightBeNull} type annotation. In a reflective API, since the set
> 
>> In a reflective API,
> 
> Nit: re-reading that bit made me pause for a moment and doubt that javax.lang.model is a reflective API, which I hope it is. We could help the reader by rephrasing that more assertively as "In a reflective API, such as this one," or dropping "In a reflective API" altogether.

Will change the opening sentence to:

"Types and hierarchies of packages comprising a Java language model, a reflective API that models the declarations and types of the Java programming language."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1296170187

From darcy at openjdk.org  Wed Aug 16 16:43:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 16:43:09 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v3]
In-Reply-To: <HfL4F9QJNQtxsPSP08wCTtfhMqNngayZX591fboeHaY=.57ec059c-f6e2-4133-bc7a-0feb5e6e08c4@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
 <AOPtsNpce0HxYkdrZuCpDC4EnKsMJbZbFRuPw1JMhlY=.67100d5a-df2d-4675-8e96-5231f2a64615@github.com>
 <HfL4F9QJNQtxsPSP08wCTtfhMqNngayZX591fboeHaY=.57ec059c-f6e2-4133-bc7a-0feb5e6e08c4@github.com>
Message-ID: <amhr2y5Dq9m1SFIvjEtkZdk3PMFVvL46ya_GRAYl5Jo=.e797dcaa-315c-4751-8371-7cc0a2046ab4@github.com>

On Wed, 16 Aug 2023 16:35:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/package-info.java line 81:
>> 
>>> 79:  * a {@code @DefinitelyNotNull} type annotation while the type of
>>> 80:  * the parameter is a {@code String} annotated with a {@code
>>> 81:  * @MightBeNull} type annotation. In a reflective API, since the set
>> 
>>> In a reflective API,
>> 
>> Nit: re-reading that bit made me pause for a moment and doubt that javax.lang.model is a reflective API, which I hope it is. We could help the reader by rephrasing that more assertively as "In a reflective API, such as this one," or dropping "In a reflective API" altogether.
>
> Will change the opening sentence to:
> 
> "Types and hierarchies of packages comprising a Java language model, a reflective API that models the declarations and types of the Java programming language."

(The text was initially written when core reflection and javax.lang.model were both discussed.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1296175168

From darcy at openjdk.org  Wed Aug 16 16:52:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 16:52:46 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v4]
In-Reply-To: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
Message-ID: <BWPZLoQvgcLywpJW2AKeH_idE952TTTB-pow3K0mc4E=.fd4c3593-ca9f-4f3b-8820-e90f1a2d4c8d@github.com>

> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).

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/15097/files
  - new: https://git.openjdk.org/jdk/pull/15097/files/fe197d6c..1fd0e2da

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

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

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

From darcy at openjdk.org  Wed Aug 16 16:52:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 16:52:48 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v3]
In-Reply-To: <d2Vo8tOHDvSwJ_HyG8o7_MStFzUjbu0RjfkT9RWwMes=.36ccbffd-0832-458d-a468-cd0112a18429@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <7OIlKdquGSBqdWEMaByBD03LLvn4Jry1JxSpTLYu3K4=.5a487dd0-e635-4e51-9eb7-39d17d541051@github.com>
 <d2Vo8tOHDvSwJ_HyG8o7_MStFzUjbu0RjfkT9RWwMes=.36ccbffd-0832-458d-a468-cd0112a18429@github.com>
Message-ID: <wqMVPePoMeUoLsxBLF6Hz3M0a9yuUVcT-HLQKSKInm4=.def6e0a8-54bb-41ef-bdab-e290222bcd3e@github.com>

On Wed, 16 Aug 2023 14:38:25 GMT, Pavel Rappo <prappo 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 seven additional commits since the last revision:
>> 
>>  - Implement review feedback.
>>  - Merge branch 'master' into JDK-8281169
>>  - Iteration of spec update.
>>  - Merge branch 'master' into JDK-8281169
>>  - Checkpoint intermediate state.
>>  - Merge branch 'master' into JDK-8281169
>>  - JDK-8281169: Expand discussion of elements and types
>
> src/java.compiler/share/classes/javax/lang/model/package-info.java line 122:
> 
>> 120:  * the declaration. Otherwise, for a non-generic class or interface,
>> 121:  * the prototypical type mirror corresponds to an unannotated use of
>> 122:  * the type.)
> 
> Perhaps I'm not quite following it, but why juxtapose "default" parameterization with being unannotated? I assume, for a generic class or interface, the prototypical type is also unannotated, no?

I assume Maurizio suggested mentioning annotations given that they were discussed as one reason uses need separate objects.

Adding a note that the other case is unannotated as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1296180422

From prappo at openjdk.org  Wed Aug 16 17:17:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 16 Aug 2023 17:17:14 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v4]
In-Reply-To: <BWPZLoQvgcLywpJW2AKeH_idE952TTTB-pow3K0mc4E=.fd4c3593-ca9f-4f3b-8820-e90f1a2d4c8d@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BWPZLoQvgcLywpJW2AKeH_idE952TTTB-pow3K0mc4E=.fd4c3593-ca9f-4f3b-8820-e90f1a2d4c8d@github.com>
Message-ID: <Dotn44F8o34AIuDUClXldC38CdoTzaFVvLGrDA8wPbI=.a70ea1ea-8ea8-4195-8e7a-45caea5d9ac5@github.com>

On Wed, 16 Aug 2023 16:52:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

Marked as reviewed by prappo (Reviewer).

src/java.compiler/share/classes/javax/lang/model/package-info.java line 28:

> 26: /**
> 27:  * Types and hierarchies of packages comprising a {@index "Java language
> 28:  * model"}, a reflective API that models the declarations and types of the Java

That was a nice way of doing it!

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

PR Review: https://git.openjdk.org/jdk/pull/15097#pullrequestreview-1581085872
PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1296210918

From darcy at openjdk.org  Wed Aug 16 19:59:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 19:59:42 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v5]
In-Reply-To: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
Message-ID: <eTIrMFuGkNf-NySvBPFmRCUfHgSP2I42scAacTqbB7U=.13b32a22-112d-47ac-9963-1f73a37f20fe@github.com>

> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).

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

  Reflow paragraphs.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15097/files
  - new: https://git.openjdk.org/jdk/pull/15097/files/1fd0e2da..b94e2e96

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

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

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

From darcy at openjdk.org  Wed Aug 16 20:35:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Aug 2023 20:35:17 GMT
Subject: Integrated: JDK-8281169: Expand discussion of elements and types
In-Reply-To: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
Message-ID: <-5smdI92OQD4x7-7kSxQ_7BNLrldXcWfqYNh4rF7z_Q=.6f7294b5-85c3-44e0-bb5f-b1f716758394@github.com>

On Tue, 1 Aug 2023 05:00:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The goal is this change is to convey to the reader an accurate "vibe" for the dichotomy between elements and type in the javax.lang.model API rather than a primer on category theory (projection-embedding pairs, etc.).

This pull request has now been integrated.

Changeset: 0c3bc71d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c3bc71d24fa13a0b1e55541c01554cd5e124027
Stats:     89 lines in 3 files changed: 85 ins; 0 del; 4 mod

8281169: Expand discussion of elements and types

Reviewed-by: mcimadamore, prappo

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

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

From darcy at openjdk.org  Thu Aug 17 01:05:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 01:05:39 GMT
Subject: RFR: JDK-8281169: Expand discussion of elements and types [v2]
In-Reply-To: <KNt3lIegP3RMLKn40y1AF3WFKqvDoamNL18dfVbzFDI=.1c017d85-32c1-491c-9bfb-f1a9c583acbc@github.com>
References: <eRW7EneX3yjNhXaIcMW7vgHjLlEz1HjHtcqlQ806F4M=.5211c169-369c-4033-aa93-f390345fadd8@github.com>
 <BNuOCEsf7Z-DoL5IEHxn10zPF0iNpaqeasZ7cfB1r_4=.b2022d72-09bf-44f0-a709-097d3725171d@github.com>
 <HwWO0Af0zY-sNOWqSPipVH75kKGnwGAcFSaVirfIeRo=.a25304cb-717b-4979-992a-35050b23d374@github.com>
 <gj180G5Vp9RftUTu5XeAcrabNu6yAYE1WJCxgDDvTH8=.178aeaa1-963b-402b-a28d-13d4d03e500a@github.com>
 <KNt3lIegP3RMLKn40y1AF3WFKqvDoamNL18dfVbzFDI=.1c017d85-32c1-491c-9bfb-f1a9c583acbc@github.com>
Message-ID: <DLUk8k-4Cgr4IesPt7HWdW3Cc_NvkD1AExdthk68zkU=.20ba3e4d-c2f7-499e-ae98-639ea3b03b3a@github.com>

On Wed, 16 Aug 2023 16:20:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Yes, javax.lang.model has long used "prototypical type" -- I'll making the index entry, etc. in a follow-up changeset; good suggestion.

See https://github.com/openjdk/jdk/pull/15320

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15097#discussion_r1296571018

From darcy at openjdk.org  Thu Aug 17 01:08:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 01:08:40 GMT
Subject: RFR: JDK-8314477: Improve definition of "prototypical type"
Message-ID: <5qZOhC__kHL-cbvL20KVWIpox6WEN4WoBgE88x0tym4=.311a3673-1f89-4ec4-a0c3-aee842a79052@github.com>

Use an index tag to make the definition of "prototypical type" more findable.

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

Commit messages:
 - JDK-8314477: Improve definition of "prototypical type"

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

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

From abimpoudis at openjdk.org  Thu Aug 17 07:36:41 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 17 Aug 2023 07:36:41 GMT
Subject: Integrated: 8314423: Multiple patterns without unnamed variables
In-Reply-To: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
References: <yQUH32NXcybjWuCUyaGKI32hPc1Zi8ZLAP6RolJklAU=.1ff2a0e8-cd28-4255-8deb-f7e4194d5f95@github.com>
Message-ID: <L0nBkkIfn0nOXG9NRNAjv874OxHA9um7ID5auI7lJmQ=.81a8a7e4-9f9c-4018-954e-d136ce92d3d6@github.com>

On Wed, 16 Aug 2023 14:52:14 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR addresses both [JDK-8314423](https://bugs.openjdk.org/browse/JDK-8314423) and [JDK-8314216](https://bugs.openjdk.org/browse/JDK-8314216), since both are relevant to checks around the structure of switch in the relevant method in `Check`. Additionally a check was needed in `analyzePattern` to detect that when a case starts with a constant case label followed by a `,` or `->` is indeed a constant expression and not a pattern as previously signified.

This pull request has now been integrated.

Changeset: 43311930
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43311930107d1783b742adbe567e9bdbcb55775d
Stats:     63 lines in 6 files changed: 63 ins; 0 del; 0 mod

8314423: Multiple patterns without unnamed variables
8314216: Case enumConstant, pattern compilation fails

Reviewed-by: jlahoda

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

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

From prappo at openjdk.org  Thu Aug 17 09:02:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 17 Aug 2023 09:02:28 GMT
Subject: RFR: JDK-8314477: Improve definition of "prototypical type"
In-Reply-To: <5qZOhC__kHL-cbvL20KVWIpox6WEN4WoBgE88x0tym4=.311a3673-1f89-4ec4-a0c3-aee842a79052@github.com>
References: <5qZOhC__kHL-cbvL20KVWIpox6WEN4WoBgE88x0tym4=.311a3673-1f89-4ec4-a0c3-aee842a79052@github.com>
Message-ID: <dMz0j4AU-jtR7lsHBlWZEpC5gMu2Uo10vaX5iMW_4MM=.3670ef19-1d39-463f-8971-2c1f91cb70cd@github.com>

On Thu, 17 Aug 2023 01:02:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use an index tag to make the definition of "prototypical type" more findable.

Looks good; thanks for doing this.

---
I rarely, if ever, see the `<dfn>` element, so I had to read up on it.

[MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dfn#specifying_the_term_being_defined) lead me to think that the text being defined is only that of `<dfn>` or the immediately descending `<abbr>`. But, then I went to [WHATWG](https://html.spec.whatwg.org/multipage/text-level-semantics.html#defining-term) which reassured me that the "descendant text content" is also ok.

The reason why it's important is that on the HTML page, this:

    <dfn>{@index "prototypical type"}</dfn>

translates to this:

    <dfn><span id="prototypicaltype" class="search-tag-result">prototypical type</span></dfn>

Which means that the actual text, prototypical type, is neither within `<dfn>` nor within `<dfn><abbr>`.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15320#pullrequestreview-1582124501

From mcimadamore at openjdk.org  Thu Aug 17 11:29:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 17 Aug 2023 11:29:26 GMT
Subject: RFR: JDK-8314477: Improve definition of "prototypical type"
In-Reply-To: <5qZOhC__kHL-cbvL20KVWIpox6WEN4WoBgE88x0tym4=.311a3673-1f89-4ec4-a0c3-aee842a79052@github.com>
References: <5qZOhC__kHL-cbvL20KVWIpox6WEN4WoBgE88x0tym4=.311a3673-1f89-4ec4-a0c3-aee842a79052@github.com>
Message-ID: <aRhD6GRwkFTWhIy66zSVpdeAMLUgRk02rDWJwG_IG20=.d910e960-9aa3-4f82-8de8-1804e3fe64aa@github.com>

On Thu, 17 Aug 2023 01:02:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use an index tag to make the definition of "prototypical type" more findable.

src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java line 91:

> 89:     /**
> 90:      * Returns the type defined by this class or interface element,
> 91:      * returning the <dfn>{@index "prototypical type"}</dfn> for an element

Since we are here - another term the JLS uses for synthetic types that are given to some expression (for the purpose of some computation) is _notional type_ which might be easier on the eye.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15320#discussion_r1297086214

From maurizio.cimadamore at oracle.com  Thu Aug 17 14:11:00 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 17 Aug 2023 15:11:00 +0100
Subject: [External] : Re: Error examples page
In-Reply-To: <CA+NR86h6_wcBV4BxvPx6xQBWwbN1v5Gi_gbhykRFwO-U_KcPsg@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>
 <bbeec72f-04e1-709c-cb4e-e173f5b15f06@oracle.com>
 <CA+NR86gm4gcZ+1nhYmAY2orUEhiOxjqtACPZ-GgA22g9JzYAQA@mail.gmail.com>
 <7205be7f-9227-6578-1b76-a9db8afce2c9@oracle.com>
 <CA+NR86hwhV8FOw56gQj2d2WgT3Aq8MMVk2X715asoQJ_o-y_Rg@mail.gmail.com>
 <CA+NR86h6_wcBV4BxvPx6xQBWwbN1v5Gi_gbhykRFwO-U_KcPsg@mail.gmail.com>
Message-ID: <02acffff-9b96-cec6-9f64-09dc97fd92dd@oracle.com>

Hi Ethan,
thanks for taking the time to do this exploration on javac (but not 
only!) diagnostics.

As you have noted, javac does have its own idiomatic way to add "hints" 
to an error message - long ago we settled on the rule that the very 
first line of the error message should "stand out" and be 
self-contained. After all, that is the line that is most likely to be 
searched online. (as you notice, this rule is not followed everywhere, 
and that's a bug!)

After the first line, javac will typically (depending on formatter 
options) display the line at which the error was reported. After that, 
we have some indented space where we can provide more information. 
Surely, this is not structural (as in the approach you describe), but we 
have been using this framework to generate dioagnostics that are, in 
spirit, pretty close to the one you are aiming for.

For instance, around 2008, when we implemented the new formatter-based 
architecture for diagnostics, we had the following goals:

* explain what occurrences of types were about (e.g. T is a 
type-variable with bounds X, Y and Z - or I is an intersection type with 
components A, B and C) - this is done in the RichDiagnosticFormatter
* capture near-misses - this was particularly an issue with overload 
resolution, where javac just said "cannot apply method", but didn't say 
"why", or which alternative overloads were available
* drop package qualifier in unambiguous contexts - this is also done in 
the RichDiagnosticFormatter

When working on Project Lambda, it became clear that the "more helpful" 
diagnostics around overload resolution were backfiring. It was not 
unusual to get a pretty long error message, with nested diagnostics, and 
little clue as to what went wrong. So, as part of the Java 8 effort, we 
have tried to apply some heuristics to _rewrite_ some of the more 
complex diagnostics into simpler ones (by speculating e.g. on which 
overload candidate the user was likely to want to hear more about it). 
This helped, but I think it is telling that, when using in anger, some 
of the "improvements" listed above (such as listing all overload 
candidates), turned out to be liabilities.

All this to say that the problem of generating good diagnostics is 
rather tricky - and, most of all, a subjective one. Some developers 
prefer terse diagnostics (this is especially the case when working on a 
big build system). Other developers would prefer more help. But in a 
real language like Java, there is a delicate balance between help and 
"too much information". For instance, some of the stuff we did to spell 
out "this is a type variable", or "this is a union type", is good on one 
side, as developers can search for terms and learn what they are about - 
but on the other end, they expose developers to the type-system rabbit 
hole, which can be pretty deep. I'm sure that, with more complex error 
messages, developers will simply try to "make the compiler happy" rather 
than reading all the messages and try to understand as to why a type 
with 2 nested wildcard type arguments cannot be assigned to this other 
generic type.

Now, I'm sure that Rust gets its share of "complex error messages" when 
you start tinkering with lifetime variables and all that. But one might 
argue that stuff like that, in Rust, is for "advanced developers". For 
better or worse, that's not the case with Java generics (or other 
features leading to complex messages such as platform modules). That is, 
even a relatively casual user can trigger pretty complex error messages 
when using simple methods in the standard library:

```
jshell> (List<Object>)List.of(1, "");
|? Error:
|? incompatible types: 
java.util.List<java.lang.Object&java.io.Serializable&java.lang.Comparable<? 
extends java.lang.Object&java.io.Serializable&java.lang.Comparable<?>>> 
cannot be converted to java.util.List<java.lang.Object>
|? (List<Object>)List.of(1, "");
|??????????????? ^------------^
```

The distribution of errors you report is also interesting, and might 
suggest that perhaps (as it's often the case in this industry) focussing 
on specific fixes to specific error messages might provide a lot of 
relief for casual develpers with relatively minor effort. For instance, 
we know well that all parser errors are quite bad (recovering from 
parsing error is science in itself), and likely the ones developers will 
see first when interacting with the compiler. Then, "cannot find symbol" 
I think it's bad because it talks about "symbol" which is not a term 
that the Java developer understands (Java has fields, local variables, 
methods, classes, enums - but not "symbols"). I think it would improve 
things if the error message was more targeted (e.g. "no field foo in 
class Bar"). As to whether we should list near misses - given past 
experiences, I guess I'm a little biased against - but that's 
subjective. Anyway, even if we wanted to do all that, no big 
infrastructure change is needed - using diagnostic formatter, together 
with multi-line diagnostics (useful to show table of nested diagnostics, 
we use these for overload diagnostics) should be good enough to achieve 
decent results.

Cheers
Maurizio



On 15/08/2023 00:48, Ethan McCue wrote:
> Also coming out of some of the other discussions[1][2] I think there 
> is one table from a paper[3] that feels relevant to the discussion.
>
> | Compiler Error Message ? ? ? ? ? ? ? ?| n ? ? | % ? ? |
> |---------------------------------------|-------|-------|
> | cannot find symbol ? ? ? ? ? ? ? ? ? ?| 4,614 | 16.0% |
> | ?)? expected ? ? ? ? ? ? ? ? ? ? ? ? ?| 3,317 | 11.5% |
> | ?;? expected ? ? ? ? ? ? ? ? ? ? ? ? ?| 3,076 | 10.7% |
> | not a statement ? ? ? ? ? ? ? ? ? ? ? | 2,142 | 7.4% ?|
> | illegal start of expression ? ? ? ? ? | 1,825 | 6.3% ?|
> | reached end of file while parsing ? ? | 1,406 | 4.9% ?|
> | illegal start of type ? ? ? ? ? ? ? ? | 1,316 | 4.6% ?|
> | ?else? without ?if? ? ? ? ? ? ? ? ? ? | 1,141 | 4.0% ?|
> | bad operand types for binary operator | 1,138 | 3.9% ?|
> | <identifier> expected ? ? ? ? ? ? ? ? | 1,091 | 3.8% ?|
>
> This shows the frequency at which their sample of students ran into 
> different errors.[4]
>
>
>
> [1]: 
> https://www.reddit.com/r/programming/comments/15qzny5/better_java_compiler_error_messages/ 
> <https://urldefense.com/v3/__https://www.reddit.com/r/programming/comments/15qzny5/better_java_compiler_error_messages/__;!!ACWV5N9M2RV99hQ!OJ4RfE35tRDXZM0iDFEEndNd4Gz5aeGGI09BczVXBUmshIXcZPhj3s5z6c_maHzCNjOoFXUrWUJe4--MJ6p8Bvg$>
> [2]: 
> https://www.reddit.com/r/java/comments/15qzkh9/better_java_compiler_error_messages/ 
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/15qzkh9/better_java_compiler_error_messages/__;!!ACWV5N9M2RV99hQ!OJ4RfE35tRDXZM0iDFEEndNd4Gz5aeGGI09BczVXBUmshIXcZPhj3s5z6c_maHzCNjOoFXUrWUJe4--MOliwT-U$>
> [3]: 
> https://drive.google.com/file/d/1GUj-KQMzWhuWTk7ksAIgABKiGkHseHQL/view?usp=sharing 
> <https://urldefense.com/v3/__https://drive.google.com/file/d/1GUj-KQMzWhuWTk7ksAIgABKiGkHseHQL/view?usp=sharing__;!!ACWV5N9M2RV99hQ!OJ4RfE35tRDXZM0iDFEEndNd4Gz5aeGGI09BczVXBUmshIXcZPhj3s5z6c_maHzCNjOoFXUrWUJe4--MPxtS2C0$>
> [4]: I don't know whether this generalizes to the language as it will 
> exist in the future or whether that particular paper is reliable, but 
> it's a start.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230817/c90089c3/attachment-0001.htm>

From darcy at openjdk.org  Thu Aug 17 20:25:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 20:25:31 GMT
Subject: RFR: JDK-8314477: Improve definition of "prototypical type"
In-Reply-To: <aRhD6GRwkFTWhIy66zSVpdeAMLUgRk02rDWJwG_IG20=.d910e960-9aa3-4f82-8de8-1804e3fe64aa@github.com>
References: <5qZOhC__kHL-cbvL20KVWIpox6WEN4WoBgE88x0tym4=.311a3673-1f89-4ec4-a0c3-aee842a79052@github.com>
 <aRhD6GRwkFTWhIy66zSVpdeAMLUgRk02rDWJwG_IG20=.d910e960-9aa3-4f82-8de8-1804e3fe64aa@github.com>
Message-ID: <VkRquLoiijR7FgkU70it4gJD12sDP4_fWYY_OeRPIs0=.b9a6a939-6783-454e-9a81-987356d9d35b@github.com>

On Thu, 17 Aug 2023 11:27:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Use an index tag to make the definition of "prototypical type" more findable.
>
> src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java line 91:
> 
>> 89:     /**
>> 90:      * Returns the type defined by this class or interface element,
>> 91:      * returning the <dfn>{@index "prototypical type"}</dfn> for an element
> 
> Since we are here - another term the JLS uses for synthetic types that are given to some expression (for the purpose of some computation) is _notional type_ which might be easier on the eye.

Hmm. Okay, from searching through the JLS 20 pdf "notional type" looks to be introduced in 4.9 "Intersection Types". The term looks to be introduced in the JLS for Java SE 8.

JSR 269 has used "prototypical type" since its introduction, so for this changeset I plan to keep that terminology.

As future work, it could be helpful to take a pass over the javax.lang.model.* type discussion to see how it could better align with evolution of JLS terminology since the API was introduced.

A general discussion of denotable and non-denotable types might be helpful too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15320#discussion_r1297702409

From darcy at openjdk.org  Thu Aug 17 20:28:33 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 20:28:33 GMT
Subject: Integrated: JDK-8314477: Improve definition of "prototypical type"
In-Reply-To: <5qZOhC__kHL-cbvL20KVWIpox6WEN4WoBgE88x0tym4=.311a3673-1f89-4ec4-a0c3-aee842a79052@github.com>
References: <5qZOhC__kHL-cbvL20KVWIpox6WEN4WoBgE88x0tym4=.311a3673-1f89-4ec4-a0c3-aee842a79052@github.com>
Message-ID: <xalwNofM5f2Uy_M10B-3NfE8WIJtaf-e3W_exDoetCE=.35eee704-4542-4558-bdd0-8558b2d11550@github.com>

On Thu, 17 Aug 2023 01:02:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use an index tag to make the definition of "prototypical type" more findable.

This pull request has now been integrated.

Changeset: 6445314f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6445314fec25b85db32d9fb75c9c1b29e07f01cb
Stats:     13 lines in 2 files changed: 6 ins; 4 del; 3 mod

8314477: Improve definition of "prototypical type"

Reviewed-by: prappo

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

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

From cstein at openjdk.org  Fri Aug 18 09:53:48 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 18 Aug 2023 09:53:48 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
Message-ID: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>

Please review the change to update to using jtreg 7.3,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 change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda

This change set also fixes:
- https://bugs.openjdk.org/browse/JDK-8313902
- https://bugs.openjdk.org/browse/JDK-8313903

Testing: _tier1-tier5 pending..._

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

Commit messages:
 - Un-problem-list tests failing with jtreg 7.3
 - 8314495: Update to use jtreg 7.3.1

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

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

From dholmes at openjdk.org  Fri Aug 18 09:53:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Aug 2023 09:53:48 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <4iFRb_Qh7PqBCUiY84xDyDOK7GzCXKDCKyz6eBwIBZI=.387bf6ce-d2f2-481f-9a38-74f97629828d@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,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 change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: _tier1-tier5 pending..._

Looks good to me!

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1582016262

From erikj at openjdk.org  Fri Aug 18 12:16:28 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 18 Aug 2023 12:16:28 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <ve4sUGJ7RG5ZnxRBh7da6nx-MSdPm59lUj5R9RRk4PM=.2568d8c8-c125-4d0f-8a78-bf598f707728@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,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 change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: _tier1-tier5 pending..._

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1584457571

From iris at openjdk.org  Fri Aug 18 18:39:25 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 18 Aug 2023 18:39:25 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <3efOFjO6mEklYsdbGon5OWAsK7ffNDSd-lpSzMHnjCk=.264978af-605d-4943-ad17-e50dcb9b1416@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,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 change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: tier1-tier5 OK

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1585041001

From jpai at openjdk.org  Sun Aug 20 06:58:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 20 Aug 2023 06:58:36 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <nqvto-2duB9RBZ1r8JUgReinh6Ackgqmm5H8ocgb424=.d309d8d6-ff29-4979-a1ab-2e1a10ec51f1@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,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 change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: tier1-tier5 OK

Looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1585812406

From cstein at openjdk.org  Mon Aug 21 06:33:35 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 21 Aug 2023 06:33:35 GMT
Subject: Integrated: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <lpRwAzlEmkhq3uQVzIjyagG37nc9PZ67TI9xgeXUHdc=.29a625f6-e22b-4f1f-8c05-a31c4a1f9d97@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,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 change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: tier1-tier5 OK

This pull request has now been integrated.

Changeset: c50315de
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c50315de8f13d316a7de08be53716cd88fa801c4
Stats:     12 lines in 9 files changed: 0 ins; 3 del; 9 mod

8314495: Update to use jtreg 7.3.1

Reviewed-by: dholmes, erikj, iris, jpai

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

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

From jwaters at openjdk.org  Tue Aug 22 03:09:41 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Aug 2023 03:09:41 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
Message-ID: <dfLWo5rApcH_80dR15-QjtJHt_oXIpvuyOimzezdgDs=.0ff3dd7c-8582-4546-9e55-90d164bb6792@github.com>

On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Create and cache a single instance of the oft-used SuperThisChecker.
>  - Add unit test verifying super() can't appear inside a lambda.
>  - Use TreeInfo.isConstructor() for detecting constructors.
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

Is this all clear for sponsorship?

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1687346705

From liach at openjdk.org  Tue Aug 22 03:56:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Aug 2023 03:56:35 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
Message-ID: <AlfAhdlX5b-OhYqIu32-eSo1Eb_cIgbMSmciYIwR2_U=.3300557b-3b88-4eca-b0e4-fa4b4e01ffba@github.com>

On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Create and cache a single instance of the oft-used SuperThisChecker.
>  - Add unit test verifying super() can't appear inside a lambda.
>  - Use TreeInfo.isConstructor() for detecting constructors.
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

Just curious, is it worth adding a test case where we call `super` multiple times or in a control flow, like

public Example() {
    if (Utilities.condition()) super();
    super();
}

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1687376391

From jwaters at openjdk.org  Tue Aug 22 04:02:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Aug 2023 04:02:46 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
Message-ID: <6FRBjtyvfrUiQsRH4YUytfoCbCxHA-YY4yE-rqU0KT8=.707755ee-fb8e-436a-b13e-5eb1f7721c55@github.com>

On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Create and cache a single instance of the oft-used SuperThisChecker.
>  - Add unit test verifying super() can't appear inside a lambda.
>  - Use TreeInfo.isConstructor() for detecting constructors.
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

Marked as reviewed by jwaters (Committer).

Approving in good spirit, but will not sponsor until I get the green light

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

PR Review: https://git.openjdk.org/jdk/pull/13656#pullrequestreview-1588233521
PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1687380426

From prappo at openjdk.org  Tue Aug 22 08:50:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 08:50:07 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
Message-ID: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>

Please review this simple PR.

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

Commit messages:
 - Initial commit

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

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

From mr at openjdk.org  Tue Aug 22 12:28:29 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 22 Aug 2023 12:28:29 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

Removing `@revised` tags is not a substantive change, so I wouldn?t update the copyright year as you have in some of these files.

Otherwise, this looks fine.

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

Marked as reviewed by mr (Lead).

PR Review: https://git.openjdk.org/jdk/pull/15382#pullrequestreview-1589309922

From prappo at openjdk.org  Tue Aug 22 12:28:30 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 12:28:30 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
 <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>
Message-ID: <SDiBPiBgNy7goDvyA_QproyjabPlsLoKDVaK_LUXfME=.05456201-40e8-4e38-b544-c81f9491d21a@github.com>

On Tue, 22 Aug 2023 12:23:18 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> I wouldn?t update the copyright year as you have in some of these files.

I was taught to do it every time when I change a file. Would you like me to revert those changes to copyright years in this case?

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

PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688086627

From mr at openjdk.org  Tue Aug 22 12:40:27 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 22 Aug 2023 12:40:27 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <zt4wRlDz8gCkuOvuI-b_2CJ29LVQgsD4tUm7QhBNoHM=.e4306c1b-4a54-46ff-a76c-91418bdca95c@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

You can leave the copyright years as-is.

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

PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688104170

From prappo at openjdk.org  Tue Aug 22 13:05:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 13:05:38 GMT
Subject: Integrated: 8314738: Remove all occurrences of and support for
 @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <DoB0QHugB2TSmS92E-93jBcsldiwg0_Bhsiusb6oMwo=.4e630be5-9b9a-4d1f-9434-62dffa8900e7@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

This pull request has now been integrated.

Changeset: f39fc0aa
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f39fc0aa2de19332fa51af605ece0660891d8c7a
Stats:     124 lines in 28 files changed: 0 ins; 116 del; 8 mod

8314738: Remove all occurrences of and support for @revised

Reviewed-by: mr

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

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

From acobbs at openjdk.org  Tue Aug 22 14:08:18 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 22 Aug 2023 14:08:18 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <dfLWo5rApcH_80dR15-QjtJHt_oXIpvuyOimzezdgDs=.0ff3dd7c-8582-4546-9e55-90d164bb6792@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
 <dfLWo5rApcH_80dR15-QjtJHt_oXIpvuyOimzezdgDs=.0ff3dd7c-8582-4546-9e55-90d164bb6792@github.com>
Message-ID: <ad5M707wv34gnLbS7LnkK04nK9NqLKakGLuiexmWyJo=.ad191f99-5325-432e-a2b8-acff211bbf27@github.com>

On Tue, 22 Aug 2023 03:06:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Is this all clear for sponsorship?

Not sure if you're asking me or not, but from my perspective, yes - at least technically speaking.

> Just curious, is it worth adding a test case where we call super multiple times or in a control flow

Happy to add it if you like. That example fails two of the checks [here](https://github.com/archiecobbs/jdk/blob/e2f881373e8e01309b8d34802b4d13b4b8bf9efe/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java#L4043): (a) all `super()` invocations must be "top level", and (b) there can only be one `super()` statement.

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1688213639

From darcy at openjdk.org  Wed Aug 23 02:45:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Aug 2023 02:45:53 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody
Message-ID: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>

Trivial implementation to get feedback on the proposed API.

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

Commit messages:
 - Appease jcheck.
 - Merge in patch from Jan.
 - Merge branch 'master' into JDK-8312418
 - Merge branch 'master' into JDK-8312418
 - Correct test predicate.
 - Augment test.
 - appease jcheck
 - Add test; check-point implementation.
 - Merge branch 'master' into JDK-8312418
 - Merge branch 'master' into JDK-8312418
 - ... and 2 more: https://git.openjdk.org/jdk/compare/2eae13c6...3684d30a

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

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

From darcy at openjdk.org  Wed Aug 23 02:45:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Aug 2023 02:45:53 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody
In-Reply-To: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
Message-ID: <oEQDkR95aS5QFwA0xgxUg4PLDKWMzPR-t6rKnvqw71Y=.6d069e07-9ebe-44cd-b102-73471a4182fa@github.com>

On Wed, 19 Jul 2023 20:49:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Trivial implementation to get feedback on the proposed API.

Add code from @lahodaj and make the PR non-draft to continue the discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/14939#issuecomment-1689161012

From darcy at openjdk.org  Wed Aug 23 09:14:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Aug 2023 09:14:40 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v2]
In-Reply-To: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
Message-ID: <Se_XZQ8TS4kfQhPJ5Dxxp9rD2gb6Kne-tB5wO38iW-o=.b4f76bee-b65e-4587-89fd-1c7ba1f5e649@github.com>

> Trivial implementation to get feedback on the proposed API.

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

  Update printing processor.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14939/files
  - new: https://git.openjdk.org/jdk/pull/14939/files/3684d30a..c8eedff3

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

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

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

From prappo at openjdk.org  Wed Aug 23 10:11:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 23 Aug 2023 10:11:36 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v2]
In-Reply-To: <Se_XZQ8TS4kfQhPJ5Dxxp9rD2gb6Kne-tB5wO38iW-o=.b4f76bee-b65e-4587-89fd-1c7ba1f5e649@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <Se_XZQ8TS4kfQhPJ5Dxxp9rD2gb6Kne-tB5wO38iW-o=.b4f76bee-b65e-4587-89fd-1c7ba1f5e649@github.com>
Message-ID: <h0-Hukl_BIVgIa1hujVLlqtdEg5aCgQGlQ7gcyIqCWc=.21597a0b-8c90-42eb-8581-1d3f7ff4b1d6@github.com>

On Wed, 23 Aug 2023 09:14:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial implementation to get feedback on the proposed API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update printing processor.

Thanks for doing this; it looks like it also brings jdk.javadoc closer to fixing [JDK-8144631: No documentation is created for methods of enum constants' class bodies](https://bugs.openjdk.org/browse/JDK-8144631)

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 769:

> 767:      * The default implementation of this method returns {@code null}
> 768:      * if the argument is an {@code enum} constant and throws an
> 769:      * {@code IllegalArgumentException}  if it is not.

Nit:
Suggestion:

     * {@code IllegalArgumentException} if it is not.

src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 733:

> 731:     @Override @DefinedBy(Api.LANGUAGE_MODEL)
> 732:     public TypeElement getEnumConstantBody(VariableElement enumConstant) {
> 733:         if (enumConstant.getKind() == ElementKind.ENUM_CONSTANT) {

Inverting `if`-`else` (exception first) might be cleaner and can also save indentation if `else` is not used. But it's a matter of style.

test/langtools/tools/javac/processing/model/util/elements/TestGetEnumConstantBody.java line 73:

> 71:                     case ENUM_CONSTANT -> testEnumConstant(field, typeElt);
> 72:                     default            -> throw new RuntimeException("Unexpected field kind seen");
> 73:                     }

That's unusual indentation.

test/langtools/tools/javac/processing/model/util/elements/TestGetEnumConstantBody.java line 139:

> 137:         try {
> 138:             var typeElement = supplier.get();
> 139:             messager.printError(message, typeElement);

Testing for an expected exception is surprisingly subtle. Testing for an expected _unchecked_ exception is even more so.

If a test framework is not used, we should be very careful. Consider moving printError outside try-catch to exclude even the slightest possibility of false negative.

test/langtools/tools/javac/processing/model/util/elements/TestGetEnumConstantBody.java line 213:

> 211:     // Nested classes hosting a variety of different kinds of fields.
> 212: 
> 213:     private static enum Body {

I think it makes sense to expand testing, to make sure there are no surprises with constants that override or implement methods, as those are the important cases as per JLS 8.9.1, which you quote.

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

PR Review: https://git.openjdk.org/jdk/pull/14939#pullrequestreview-1591067681
PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1302685141
PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1302689705
PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1302709266
PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1302717119
PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1302796206

From vromero at openjdk.org  Wed Aug 23 14:04:23 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 23 Aug 2023 14:04:23 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v2]
In-Reply-To: <Se_XZQ8TS4kfQhPJ5Dxxp9rD2gb6Kne-tB5wO38iW-o=.b4f76bee-b65e-4587-89fd-1c7ba1f5e649@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <Se_XZQ8TS4kfQhPJ5Dxxp9rD2gb6Kne-tB5wO38iW-o=.b4f76bee-b65e-4587-89fd-1c7ba1f5e649@github.com>
Message-ID: <OnmATyXjiPbdz_Tgt5o9_7g_LrPZHD9R5I6WQ3XfRmU=.48b18013-db92-421e-a5d4-fc41b8c587b5@github.com>

On Wed, 23 Aug 2023 09:14:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial implementation to get feedback on the proposed API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update printing processor.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 772:

> 770:      *
> 771:      * @throws IllegalArgumentException if the argument is not an {@code enum} constant
> 772:      * @param enumConstant an enum constant

nice, my only comment is that the order selected in the javadoc seems to be at odds with the rest of the javadoc in this class. The common order I see is:

1. @implSpec
2. @param
3. @return
4. @throws

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1303072140

From darcy at openjdk.org  Wed Aug 23 21:05:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Aug 2023 21:05:23 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v2]
In-Reply-To: <Se_XZQ8TS4kfQhPJ5Dxxp9rD2gb6Kne-tB5wO38iW-o=.b4f76bee-b65e-4587-89fd-1c7ba1f5e649@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <Se_XZQ8TS4kfQhPJ5Dxxp9rD2gb6Kne-tB5wO38iW-o=.b4f76bee-b65e-4587-89fd-1c7ba1f5e649@github.com>
Message-ID: <kZRIMxiq7_eIG-qMyyujB-n7k128jPMBQyvrdu9WN-E=.bf5ca1d1-a81b-4ca6-b719-36ce09470800@github.com>

On Wed, 23 Aug 2023 09:14:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial implementation to get feedback on the proposed API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update printing processor.

A few explanatory notes on the changes in the printing processor. Consider an enum like


public enum BodyEnum {
    GOLGI(true) {
        public boolean isOrganelle() {return true;}
    },

    HEAVENLY(true) {
        public boolean isCelestial() {return true;}
    };

    private BodyEnum(boolean predicate) {
        this.predicate = predicate;
    }

    private boolean predicate;
    public static int field = 42;
    public void method() {return;}
}



which uses enum constants with bodies. If this enum class is printed from a class file, but not source code, the output is like:


public enum BodyEnum permits BodyEnum$1, BodyEnum$2 {

  GOLGI,
  HEAVENLY;

  private boolean predicate;
  public static int field;

  public static BodyEnum[] values();

  public static BodyEnum valueOf(java.lang.String arg0);

  private BodyEnum(boolean arg0);

  public void method();
}

This does reflect how javac currently lowers an enum to a class file, but the permits information is not really helpful and is better to be elided, as the extra check now does.

If one goes out of the way to explicitly request printing of the anonymous class used for an enum contanst, the output is similar to:


$ jdk-21/bin/javac -Xprint 'BodyEnum$1'
new BodyEnum(java.lang.String arg0,
  int arg1,
  boolean arg2) {

  public boolean isOrganelle();
}

While this is reasonable for a general anonymous class, it isn't helpful for an enum body and I think it is best to just have no output in this case.

Generally we haven't tested the exact printing processor output and I think it is best if we continue that policy here.

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

PR Comment: https://git.openjdk.org/jdk/pull/14939#issuecomment-1690634306

From darcy at openjdk.org  Wed Aug 23 21:24:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Aug 2023 21:24:40 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v3]
In-Reply-To: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
Message-ID: <-Mar0gCcuwweE5v0eIJDsxmFANLisOLPlzmItshSpRk=.247ad68f-130d-4ffa-9276-acad78ad8c18@github.com>

> Trivial implementation to get feedback on the proposed API.

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

  Change policy of default method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14939/files
  - new: https://git.openjdk.org/jdk/pull/14939/files/c8eedff3..41c2448f

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

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

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

From darcy at openjdk.org  Wed Aug 23 21:28:24 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Aug 2023 21:28:24 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v3]
In-Reply-To: <-Mar0gCcuwweE5v0eIJDsxmFANLisOLPlzmItshSpRk=.247ad68f-130d-4ffa-9276-acad78ad8c18@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <-Mar0gCcuwweE5v0eIJDsxmFANLisOLPlzmItshSpRk=.247ad68f-130d-4ffa-9276-acad78ad8c18@github.com>
Message-ID: <Hhl3xXI6SfWfa2EsUS1KO6M_WRCLC1F59lx9LN0VnLY=.0e52f62d-7473-4765-ac40-57e317f8b7ac@github.com>

On Wed, 23 Aug 2023 21:24:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial implementation to get feedback on the proposed API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change policy of default method.

To address some concerns raised off-list by @jonathan-gibbons, I modified the semantics of the default method to always throw some exception, either an IllegalArgumentException or an UnsupportedOperationException. This is (slightly) a more precise approximation to the "real" behavior of the method than always throwing UnsupportedOperationException.

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

PR Comment: https://git.openjdk.org/jdk/pull/14939#issuecomment-1690662049

From darcy at openjdk.org  Thu Aug 24 17:18:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 24 Aug 2023 17:18:14 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v4]
In-Reply-To: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
Message-ID: <BomW5xzY94oong2efxwFr6i7LM-RD3BriiP1aYSityg=.fbeda4d4-fa31-4e58-a0a0-ef8c7a88a69e@github.com>

> Trivial implementation to get feedback on the proposed API.

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

  Reorder javadoc tags.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14939/files
  - new: https://git.openjdk.org/jdk/pull/14939/files/41c2448f..8f69e477

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

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

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

From darcy at openjdk.org  Thu Aug 24 17:22:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 24 Aug 2023 17:22:28 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v2]
In-Reply-To: <OnmATyXjiPbdz_Tgt5o9_7g_LrPZHD9R5I6WQ3XfRmU=.48b18013-db92-421e-a5d4-fc41b8c587b5@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <Se_XZQ8TS4kfQhPJ5Dxxp9rD2gb6Kne-tB5wO38iW-o=.b4f76bee-b65e-4587-89fd-1c7ba1f5e649@github.com>
 <OnmATyXjiPbdz_Tgt5o9_7g_LrPZHD9R5I6WQ3XfRmU=.48b18013-db92-421e-a5d4-fc41b8c587b5@github.com>
Message-ID: <cWP3jjpgyxY4gsx7HRXJdq8aMl65FPAbgfPjWX9OCxk=.73dad657-0575-45ec-b264-60f8ade112e4@github.com>

On Wed, 23 Aug 2023 14:01:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update printing processor.
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 772:
> 
>> 770:      *
>> 771:      * @throws IllegalArgumentException if the argument is not an {@code enum} constant
>> 772:      * @param enumConstant an enum constant
> 
> nice, my only comment is that the order selected in the javadoc seems to be at odds with the rest of the javadoc in this class. The common order I see is:
> 
> 1. @implSpec
> 2. @param
> 3. @return
> 4. @throws

Tags reordered; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1304644457

From vromero at openjdk.org  Thu Aug 24 18:06:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Aug 2023 18:06:35 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v4]
In-Reply-To: <BomW5xzY94oong2efxwFr6i7LM-RD3BriiP1aYSityg=.fbeda4d4-fa31-4e58-a0a0-ef8c7a88a69e@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <BomW5xzY94oong2efxwFr6i7LM-RD3BriiP1aYSityg=.fbeda4d4-fa31-4e58-a0a0-ef8c7a88a69e@github.com>
Message-ID: <eUqIp_qMx2ADClBF1a5iDq-Gzp7ZiV_5N2TfUcDMeRE=.9ce80910-aa90-4328-b259-ea235a1d0b33@github.com>

On Thu, 24 Aug 2023 17:18:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial implementation to get feedback on the proposed API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorder javadoc tags.

test/langtools/tools/javac/processing/model/util/elements/TestGetEnumConstantBody.java line 64:

> 62: 
> 63:             for (TypeElement typeElt : ElementFilter.typesIn(typeRoot.getEnclosedElements()) ) {
> 64:                 System.out.println("Testing type " + typeElt);

should the `println` invocations be removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1304690653

From acobbs at openjdk.org  Thu Aug 24 18:12:04 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 24 Aug 2023 18:12:04 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v4]
In-Reply-To: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
Message-ID: <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>

> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
> 
> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
> 
> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
> 
> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
> 
> Changes:
> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
> * Add new `StringNameTable` implementation.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into JDK-8269957
 - Merge branch 'master' into JDK-8269957
 - Merge branch 'master' into JDK-8269957
 - Merge branch 'master' into JDK-8269957
 - Move equals() table check into common superclass.
 - Add Name.Table factory methods to Names class.
 - Add StringNameTable as a new (optional) Name.Table implementation.
 - Add a few more default method implementations to Name superclass.
 - Revert some unnecessary changes.
 - Merge branch 'master' into JDK-8269957
 - ... and 1 more: https://git.openjdk.org/jdk/compare/f2399546...e386ea3e

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

Changes: https://git.openjdk.org/jdk/pull/13282/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13282&range=03
  Stats: 834 lines in 11 files changed: 571 ins; 162 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/13282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13282/head:pull/13282

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

From darcy at openjdk.org  Thu Aug 24 20:08:49 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 24 Aug 2023 20:08:49 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v5]
In-Reply-To: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
Message-ID: <5WtmPFDVRuC5FispF983wCv3IHI78xyScZXBFV7MJcc=.a87e550b-2af3-4760-b272-fc2b531496be@github.com>

> Trivial implementation to get feedback on the proposed API.

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

  Refactor as suggested by jjg.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14939/files
  - new: https://git.openjdk.org/jdk/pull/14939/files/8f69e477..095eedb6

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

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

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

From prappo at openjdk.org  Thu Aug 24 22:19:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 24 Aug 2023 22:19:15 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v5]
In-Reply-To: <5WtmPFDVRuC5FispF983wCv3IHI78xyScZXBFV7MJcc=.a87e550b-2af3-4760-b272-fc2b531496be@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <5WtmPFDVRuC5FispF983wCv3IHI78xyScZXBFV7MJcc=.a87e550b-2af3-4760-b272-fc2b531496be@github.com>
Message-ID: <gxkLEC7SIFIok1wbc9ukVh0TBT_SGndY9GinkoDfc_g=.03b63d88-92b8-4345-ab9c-69637e2f37a4@github.com>

On Thu, 24 Aug 2023 20:08:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial implementation to get feedback on the proposed API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor as suggested by jjg.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 779:

> 777:     default TypeElement getEnumConstantBody(VariableElement enumConstant) {
> 778:         switch(enumConstant.getKind()) {
> 779:         case ENUM_CONSTANT -> throw new UnsupportedOperationException();

Hm... Most retrofitted methods in this API return null or false, not throw UnsupportedOperationException. The only other exception seems to be Elements.getFileObjectOf. Is this the new approach, or it just does make more sense for these two particular methods?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1304926293

From jjg at openjdk.org  Thu Aug 24 22:26:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 24 Aug 2023 22:26:17 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v5]
In-Reply-To: <gxkLEC7SIFIok1wbc9ukVh0TBT_SGndY9GinkoDfc_g=.03b63d88-92b8-4345-ab9c-69637e2f37a4@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <5WtmPFDVRuC5FispF983wCv3IHI78xyScZXBFV7MJcc=.a87e550b-2af3-4760-b272-fc2b531496be@github.com>
 <gxkLEC7SIFIok1wbc9ukVh0TBT_SGndY9GinkoDfc_g=.03b63d88-92b8-4345-ab9c-69637e2f37a4@github.com>
Message-ID: <PdonOh7f0rTjecKJwOUo-G20hA6Y2Ou5D6Qj-DvRrUU=.db3491a2-859c-4e66-9efa-aaad79f754a3@github.com>

On Thu, 24 Aug 2023 22:15:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor as suggested by jjg.
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 779:
> 
>> 777:     default TypeElement getEnumConstantBody(VariableElement enumConstant) {
>> 778:         switch(enumConstant.getKind()) {
>> 779:         case ENUM_CONSTANT -> throw new UnsupportedOperationException();
> 
> Hm... Most retrofitted methods in this API return null or false, not throw UnsupportedOperationException. The only other exception seems to be Elements.getFileObjectOf. Is this the new approach, or it just does make more sense for these two particular methods?

I think it depends whether a `null` result is permitted by the specification of the method.  For this method, while `null` would be the correct result most of the time, it is exactly the wrong result when it is most interesting, and so a non-exception result would be misleading.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1304931340

From prappo at openjdk.org  Thu Aug 24 22:36:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 24 Aug 2023 22:36:14 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v5]
In-Reply-To: <PdonOh7f0rTjecKJwOUo-G20hA6Y2Ou5D6Qj-DvRrUU=.db3491a2-859c-4e66-9efa-aaad79f754a3@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <5WtmPFDVRuC5FispF983wCv3IHI78xyScZXBFV7MJcc=.a87e550b-2af3-4760-b272-fc2b531496be@github.com>
 <gxkLEC7SIFIok1wbc9ukVh0TBT_SGndY9GinkoDfc_g=.03b63d88-92b8-4345-ab9c-69637e2f37a4@github.com>
 <PdonOh7f0rTjecKJwOUo-G20hA6Y2Ou5D6Qj-DvRrUU=.db3491a2-859c-4e66-9efa-aaad79f754a3@github.com>
Message-ID: <PR1VhsXkFrxzNPsqPCVkZf5HmUpGOnbTB4TBJFyb9hE=.7837d9ea-3fed-46c0-9c14-227fd1c27180@github.com>

On Thu, 24 Aug 2023 22:23:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 779:
>> 
>>> 777:     default TypeElement getEnumConstantBody(VariableElement enumConstant) {
>>> 778:         switch(enumConstant.getKind()) {
>>> 779:         case ENUM_CONSTANT -> throw new UnsupportedOperationException();
>> 
>> Hm... Most retrofitted methods in this API return null or false, not throw UnsupportedOperationException. The only other exception seems to be Elements.getFileObjectOf. Is this the new approach, or it just does make more sense for these two particular methods?
>
> I think it depends whether a `null` result is permitted by the specification of the method.  For this method, while `null` would be the correct result most of the time, it is exactly the wrong result when it is most interesting, and so a non-exception result would be misleading.

I see your point and agree with it: the `default` implementation will return `null` if called for an enum constant with the class body. That said, isn't, say, `Elements.getTypeElement(ModuleElement, CharSequence)` in a similar situation? But it returns `null`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1304937087

From josiahnoel at gmail.com  Fri Aug 25 05:04:57 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Fri, 25 Aug 2023 01:04:57 -0400
Subject: ModuleElement doesn't work with generated provides classes?
Message-ID: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>

Hello there,

I'm adding functionality to my annotation processor to check whether a
generated class is registered on a module-info.java. When I try to use
`ModuleElement#getDirectives`, I get the `requires` statements, but I
cannot get the `provides` statements I've written.

Is it possible to get this to work? Or does the fact that the classes are
generated totally prevent me from getting the provides statements?

-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230825/b307253e/attachment.htm>

From jjg at openjdk.org  Fri Aug 25 21:27:18 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 25 Aug 2023 21:27:18 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v4]
In-Reply-To: <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
Message-ID: <bo_nMeOI9mk5k2oBDAfmAtzljVi-cT0XwRlncu_T-OU=.631bc7f3-b758-4e9b-96aa-b61713d79464@github.com>

On Thu, 24 Aug 2023 18:12:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
>> 
>> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
>> 
>> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
>> 
>> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
>> 
>> Changes:
>> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
>> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
>> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
>> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
>> * Add new `StringNameTable` implementation.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Move equals() table check into common superclass.
>  - Add Name.Table factory methods to Names class.
>  - Add StringNameTable as a new (optional) Name.Table implementation.
>  - Add a few more default method implementations to Name superclass.
>  - Revert some unnecessary changes.
>  - Merge branch 'master' into JDK-8269957
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f2399546...e386ea3e

Verified javadoc tests all pass if StringNameTable is on by default in javadoc

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

PR Comment: https://git.openjdk.org/jdk/pull/13282#issuecomment-1693949440

From jjg at openjdk.org  Fri Aug 25 21:30:11 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 25 Aug 2023 21:30:11 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v4]
In-Reply-To: <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
Message-ID: <qedemweDNYUGvuKlW8Fpddq9_6tBXrxYdyK2F1ia10U=.e04b2e89-c20b-478e-a1a6-91dd8aaa560d@github.com>

On Thu, 24 Aug 2023 18:12:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
>> 
>> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
>> 
>> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
>> 
>> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
>> 
>> Changes:
>> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
>> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
>> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
>> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
>> * Add new `StringNameTable` implementation.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Move equals() table check into common superclass.
>  - Add Name.Table factory methods to Names class.
>  - Add StringNameTable as a new (optional) Name.Table implementation.
>  - Add a few more default method implementations to Name superclass.
>  - Revert some unnecessary changes.
>  - Merge branch 'master' into JDK-8269957
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f2399546...e386ea3e

Verified API documentation is unchanged if `StringNameTable` is on by default in javadoc

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

PR Comment: https://git.openjdk.org/jdk/pull/13282#issuecomment-1693954634

From josiahnoel at gmail.com  Fri Aug 25 22:25:59 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Fri, 25 Aug 2023 18:25:59 -0400
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
Message-ID: <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>

I was able to work around it by using Filer to directly load the
module-info.java file as a string and parse it.

On Fri, Aug 25, 2023 at 1:04?AM Josiah Noel <josiahnoel at gmail.com> wrote:

> Hello there,
>
> I'm adding functionality to my annotation processor to check whether a
> generated class is registered on a module-info.java. When I try to use
> `ModuleElement#getDirectives`, I get the `requires` statements, but I
> cannot get the `provides` statements I've written.
>
> Is it possible to get this to work? Or does the fact that the classes are
> generated totally prevent me from getting the provides statements?
>
> --
> Cheers, Josiah.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230825/5b4b7f7f/attachment-0001.htm>

From vromero at openjdk.org  Fri Aug 25 22:33:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Aug 2023 22:33:10 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v4]
In-Reply-To: <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
Message-ID: <DR8YKRGEEZcxfio8UrfVhFMNlURSQiVtvm0Gm7-BsGE=.e9631427-d6c0-49bf-b246-1c60fe6fc1a6@github.com>

On Thu, 24 Aug 2023 18:12:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
>> 
>> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
>> 
>> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
>> 
>> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
>> 
>> Changes:
>> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
>> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
>> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
>> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
>> * Add new `StringNameTable` implementation.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Move equals() table check into common superclass.
>  - Add Name.Table factory methods to Names class.
>  - Add StringNameTable as a new (optional) Name.Table implementation.
>  - Add a few more default method implementations to Name superclass.
>  - Revert some unnecessary changes.
>  - Merge branch 'master' into JDK-8269957
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f2399546...e386ea3e

src/jdk.compiler/share/classes/com/sun/tools/javac/util/StringNameTable.java line 51:

> 49: 
> 50:     public StringNameTable(Names names) {
> 51:         this(names, 8000);

did you mean: 0x8000?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13282#discussion_r1306193555

From acobbs at openjdk.org  Fri Aug 25 23:02:53 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 25 Aug 2023 23:02:53 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v5]
In-Reply-To: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
Message-ID: <7DH3WmvL1-HqeoiImU9ZXlZK7xaKjF8BU1YJHOOgDhk=.6913c79f-94bc-4668-8095-fda82412dc73@github.com>

> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
> 
> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
> 
> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
> 
> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
> 
> Changes:
> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
> * Add new `StringNameTable` implementation.

Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Fix copyright year.
 - Fix 8000 table size constant which was meant to be 0x8000.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13282/files
  - new: https://git.openjdk.org/jdk/pull/13282/files/e386ea3e..193d0666

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

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

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

From acobbs at openjdk.org  Fri Aug 25 23:02:58 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 25 Aug 2023 23:02:58 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v4]
In-Reply-To: <DR8YKRGEEZcxfio8UrfVhFMNlURSQiVtvm0Gm7-BsGE=.e9631427-d6c0-49bf-b246-1c60fe6fc1a6@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
 <DR8YKRGEEZcxfio8UrfVhFMNlURSQiVtvm0Gm7-BsGE=.e9631427-d6c0-49bf-b246-1c60fe6fc1a6@github.com>
Message-ID: <M8YxzNkRGq619kA8YfBu_WaZVCWVrZllEJYiVhlOV5E=.704c4fa7-661e-4a92-b542-67740a0b7f21@github.com>

On Fri, 25 Aug 2023 22:30:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' into JDK-8269957
>>  - Merge branch 'master' into JDK-8269957
>>  - Merge branch 'master' into JDK-8269957
>>  - Merge branch 'master' into JDK-8269957
>>  - Move equals() table check into common superclass.
>>  - Add Name.Table factory methods to Names class.
>>  - Add StringNameTable as a new (optional) Name.Table implementation.
>>  - Add a few more default method implementations to Name superclass.
>>  - Revert some unnecessary changes.
>>  - Merge branch 'master' into JDK-8269957
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f2399546...e386ea3e
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/StringNameTable.java line 51:
> 
>> 49: 
>> 50:     public StringNameTable(Names names) {
>> 51:         this(names, 8000);
> 
> did you mean: 0x8000?

Yes, thanks... was trying to cut & paste from `SharedNameTable()` but dropped the `0x` somehow. Fixed in 3c6d9145219.

> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Utf8NameTable.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1999, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> nit: copyright year should only be 2023

Thanks, fixed in 193d06662dd.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13282#discussion_r1306202448
PR Review Comment: https://git.openjdk.org/jdk/pull/13282#discussion_r1306202921

From vromero at openjdk.org  Fri Aug 25 23:03:00 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Aug 2023 23:03:00 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v4]
In-Reply-To: <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <e-FQQho9I0F26_2JjXE9t9_-MB7sTp0y-VmPDrE6kWg=.6697587f-1c1d-4a2b-aa00-f8370c827d93@github.com>
Message-ID: <chyQTMSIRHNzCW--KKe5JaJZFXHGOAZyRpKhXhuVSPw=.7cd480b7-6644-47a3-b62e-2d11cbdc4754@github.com>

On Thu, 24 Aug 2023 18:12:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
>> 
>> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
>> 
>> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
>> 
>> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
>> 
>> Changes:
>> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
>> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
>> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
>> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
>> * Add new `StringNameTable` implementation.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Merge branch 'master' into JDK-8269957
>  - Move equals() table check into common superclass.
>  - Add Name.Table factory methods to Names class.
>  - Add StringNameTable as a new (optional) Name.Table implementation.
>  - Add a few more default method implementations to Name superclass.
>  - Revert some unnecessary changes.
>  - Merge branch 'master' into JDK-8269957
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f2399546...e386ea3e

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Utf8NameTable.java line 2:

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

nit: copyright year should only be 2023

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13282#discussion_r1306201837

From joe.darcy at oracle.com  Fri Aug 25 23:15:31 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 25 Aug 2023 16:15:31 -0700
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
Message-ID: <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>

Hello,

 From your description, I'm not entirely clear of the compilation 
context you're working in. Note that by design the annotation processing 
API does not support the creation of module-info files via the Filer.

Cheers,

-Joe

On 8/25/2023 3:25 PM, Josiah Noel wrote:
> I was able to work around it by using Filer?to directly load the 
> module-info.java file as a string and parse it.
>
> On Fri, Aug 25, 2023 at 1:04?AM Josiah Noel <josiahnoel at gmail.com> wrote:
>
>     Hello there,
>
>     I'm adding functionality to my annotation processor to check
>     whether a generated?class is registered on a module-info.java.
>     When I try to use `ModuleElement#getDirectives`, I get the
>     `requires` statements, but I cannot get the `provides` statements
>     I've written.
>
>     Is it possible to get?this to work? Or does the fact that the
>     classes are generated totally prevent me from getting the provides
>     statements?
>
>     -- 
>     Cheers, Josiah.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230825/2726a67f/attachment.htm>

From josiahnoel at gmail.com  Fri Aug 25 23:41:58 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Fri, 25 Aug 2023 19:41:58 -0400
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
Message-ID: <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>

I mean reading an existing module-info via ModuleElement, not creating a
new one. The module-info I'm trying to read has generated classes in a
provided clause.

On Fri, Aug 25, 2023, 7:15 PM Joseph D. Darcy <joe.darcy at oracle.com> wrote:

> Hello,
>
> From your description, I'm not entirely clear of the compilation context
> you're working in. Note that by design the annotation processing API does
> not support the creation of module-info files via the Filer.
>
> Cheers,
>
> -Joe
> On 8/25/2023 3:25 PM, Josiah Noel wrote:
>
> I was able to work around it by using Filer to directly load the
> module-info.java file as a string and parse it.
>
> On Fri, Aug 25, 2023 at 1:04?AM Josiah Noel <josiahnoel at gmail.com> wrote:
>
>> Hello there,
>>
>> I'm adding functionality to my annotation processor to check whether a
>> generated class is registered on a module-info.java. When I try to use
>> `ModuleElement#getDirectives`, I get the `requires` statements, but I
>> cannot get the `provides` statements I've written.
>>
>> Is it possible to get this to work? Or does the fact that the classes are
>> generated totally prevent me from getting the provides statements?
>>
>> --
>> Cheers, Josiah.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230825/fd6dd232/attachment.htm>

From jonathan.gibbons at oracle.com  Fri Aug 25 23:46:05 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 25 Aug 2023 16:46:05 -0700
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
Message-ID: <d89a3282-9868-05a0-5601-000063394d03@oracle.com>

If I understand you correctly, it seems that this ought to work. But 
perception does not always match reality. It would help to have a toy 
test case.

-- Jon

On 8/25/23 4:41 PM, Josiah Noel wrote:
> I mean reading an existing module-info via ModuleElement, not creating 
> a new one. The module-info I'm trying to read has generated classes in 
> a provided clause.
>
> On Fri, Aug 25, 2023, 7:15 PM Joseph D. Darcy <joe.darcy at oracle.com> 
> wrote:
>
>     Hello,
>
>     From your description, I'm not entirely clear of the compilation
>     context you're working in. Note that by design the annotation
>     processing API does not support the creation of module-info files
>     via the Filer.
>
>     Cheers,
>
>     -Joe
>
>     On 8/25/2023 3:25 PM, Josiah Noel wrote:
>>     I was able to work around it by using Filer?to directly load the
>>     module-info.java file as a string and parse it.
>>
>>     On Fri, Aug 25, 2023 at 1:04?AM Josiah Noel
>>     <josiahnoel at gmail.com> wrote:
>>
>>         Hello there,
>>
>>         I'm adding functionality to my annotation processor to check
>>         whether a generated?class is registered on a
>>         module-info.java. When I try to use
>>         `ModuleElement#getDirectives`, I get the `requires`
>>         statements, but I cannot get the `provides` statements I've
>>         written.
>>
>>         Is it possible to get?this to work? Or does the fact that the
>>         classes are generated totally prevent me from getting the
>>         provides statements?
>>
>>         -- 
>>         Cheers, Josiah.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230825/1245b75e/attachment-0001.htm>

From joe.darcy at oracle.com  Sat Aug 26 00:07:46 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 25 Aug 2023 17:07:46 -0700
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <d89a3282-9868-05a0-5601-000063394d03@oracle.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <d89a3282-9868-05a0-5601-000063394d03@oracle.com>
Message-ID: <d7a2d4f9-132e-d033-e6c6-ee0bac47dc67@oracle.com>

Another relevant data point is if the module information could be 
retrieved from a module-info _source file_ but not a class file.

-Joe

On 8/25/2023 4:46 PM, Jonathan Gibbons wrote:
>
> If I understand you correctly, it seems that this ought to work. But 
> perception does not always match reality. It would help to have a toy 
> test case.
>
> -- Jon
>
> On 8/25/23 4:41 PM, Josiah Noel wrote:
>> I mean reading an existing module-info via ModuleElement, not 
>> creating a new one. The module-info I'm trying to read has generated 
>> classes in a provided clause.
>>
>> On Fri, Aug 25, 2023, 7:15 PM Joseph D. Darcy <joe.darcy at oracle.com> 
>> wrote:
>>
>>     Hello,
>>
>>     From your description, I'm not entirely clear of the compilation
>>     context you're working in. Note that by design the annotation
>>     processing API does not support the creation of module-info files
>>     via the Filer.
>>
>>     Cheers,
>>
>>     -Joe
>>
>>     On 8/25/2023 3:25 PM, Josiah Noel wrote:
>>>     I was able to work around it by using Filer?to directly load the
>>>     module-info.java file as a string and parse it.
>>>
>>>     On Fri, Aug 25, 2023 at 1:04?AM Josiah Noel
>>>     <josiahnoel at gmail.com> wrote:
>>>
>>>         Hello there,
>>>
>>>         I'm adding functionality to my annotation processor to check
>>>         whether a generated?class is registered on a
>>>         module-info.java. When I try to use
>>>         `ModuleElement#getDirectives`, I get the `requires`
>>>         statements, but I cannot get the `provides` statements I've
>>>         written.
>>>
>>>         Is it possible to get?this to work? Or does the fact that
>>>         the classes are generated totally prevent me from getting
>>>         the provides statements?
>>>
>>>         -- 
>>>         Cheers, Josiah.
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230825/6a921f20/attachment.htm>

From josiahnoel at gmail.com  Sat Aug 26 01:00:06 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Fri, 25 Aug 2023 21:00:06 -0400
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
Message-ID: <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>

Say I got this module

```

module nima.example {

requires io.avaje.http.client;

requires io.avaje.http.api;

provides io.avaje.http.client.HttpClient.GeneratedComponent with

com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;

}

```
and I generate com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent in
the last round of processing. When I get the module element during normal
processing and so much as call `ModuleElement#getDirectives` and do nothing
else, the processor will correctly generate, but compilation will still
fail.(if I take out the module-info from the project it works though) I'm
pretty sure it might have to do with the fact that GeneratedHttpComponent is
created in the last round. Even so, not sure why it fails the compilation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230825/10fc4660/attachment.htm>

From jjg at openjdk.org  Sat Aug 26 16:37:08 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 26 Aug 2023 16:37:08 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v5]
In-Reply-To: <7DH3WmvL1-HqeoiImU9ZXlZK7xaKjF8BU1YJHOOgDhk=.6913c79f-94bc-4668-8095-fda82412dc73@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <7DH3WmvL1-HqeoiImU9ZXlZK7xaKjF8BU1YJHOOgDhk=.6913c79f-94bc-4668-8095-fda82412dc73@github.com>
Message-ID: <DGFmFnbWOkUSyv4McN8HAv8msiDE26bCDd6SlNM-Qe4=.136a355e-0d35-43f6-bb7c-ea4da61163f7@github.com>

On Fri, 25 Aug 2023 23:02:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
>> 
>> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
>> 
>> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
>> 
>> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
>> 
>> Changes:
>> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
>> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
>> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
>> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
>> * Add new `StringNameTable` implementation.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix copyright year.
>  - Fix 8000 table size constant which was meant to be 0x8000.

CI job for all tier1 tests, with `StringNameTable` enabled by default, passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13282#issuecomment-1694405427

From jjg at openjdk.org  Sat Aug 26 16:42:11 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 26 Aug 2023 16:42:11 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v5]
In-Reply-To: <7DH3WmvL1-HqeoiImU9ZXlZK7xaKjF8BU1YJHOOgDhk=.6913c79f-94bc-4668-8095-fda82412dc73@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <7DH3WmvL1-HqeoiImU9ZXlZK7xaKjF8BU1YJHOOgDhk=.6913c79f-94bc-4668-8095-fda82412dc73@github.com>
Message-ID: <v0q1UWH5fyW9tSk5wJQ6npQbV-YpBZpVKfXYZqBRU2g=.da4803e2-fa55-4bb3-9116-efd6dc0a1bcf@github.com>

On Fri, 25 Aug 2023 23:02:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
>> 
>> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
>> 
>> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
>> 
>> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
>> 
>> Changes:
>> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
>> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
>> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
>> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
>> * Add new `StringNameTable` implementation.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix copyright year.
>  - Fix 8000 table size constant which was meant to be 0x8000.

The code passes javadoc tests and :tier1 tests with StringNameTable enabled.

I'll approve, but recommend we get Vicente's approval, as a javac dev, as well.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13282#pullrequestreview-1596949991

From acobbs at openjdk.org  Sat Aug 26 17:14:11 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 26 Aug 2023 17:14:11 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v5]
In-Reply-To: <v0q1UWH5fyW9tSk5wJQ6npQbV-YpBZpVKfXYZqBRU2g=.da4803e2-fa55-4bb3-9116-efd6dc0a1bcf@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <7DH3WmvL1-HqeoiImU9ZXlZK7xaKjF8BU1YJHOOgDhk=.6913c79f-94bc-4668-8095-fda82412dc73@github.com>
 <v0q1UWH5fyW9tSk5wJQ6npQbV-YpBZpVKfXYZqBRU2g=.da4803e2-fa55-4bb3-9116-efd6dc0a1bcf@github.com>
Message-ID: <GrwpSbjPUTS-iwPJA4NiuX14DiuHsr6ZV-q-KjCVRo0=.fb0bf98d-28c5-4c3c-9daf-b61ba2634a75@github.com>

On Sat, 26 Aug 2023 16:38:54 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I'll approve, but recommend we get Vicente's approval, as a javac dev, as well.

Thanks @jonathan-gibbons. I agree and will bump the required reviewer count.

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

PR Comment: https://git.openjdk.org/jdk/pull/13282#issuecomment-1694412860

From vromero at openjdk.org  Sat Aug 26 18:06:15 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 26 Aug 2023 18:06:15 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v5]
In-Reply-To: <7DH3WmvL1-HqeoiImU9ZXlZK7xaKjF8BU1YJHOOgDhk=.6913c79f-94bc-4668-8095-fda82412dc73@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <7DH3WmvL1-HqeoiImU9ZXlZK7xaKjF8BU1YJHOOgDhk=.6913c79f-94bc-4668-8095-fda82412dc73@github.com>
Message-ID: <hj3p0YS3SJZ6qr3IKKBZYmlcI0g6rsPc4scx3JYVV8c=.98a5f94f-6454-45b8-84f8-dd143c0ec829@github.com>

On Fri, 25 Aug 2023 23:02:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
>> 
>> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
>> 
>> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
>> 
>> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
>> 
>> Changes:
>> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
>> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
>> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
>> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
>> * Add new `StringNameTable` implementation.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix copyright year.
>  - Fix 8000 table size constant which was meant to be 0x8000.

looks good to me too, thanks for fixing this!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13282#pullrequestreview-1596969039

From josiahnoel at gmail.com  Sat Aug 26 20:04:02 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Sat, 26 Aug 2023 16:04:02 -0400
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
Message-ID: <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>

As requested, I have created a simple example to replicate this issue.
SentryMan/module-directive-bug:
showcase annotation processing bug (github.com)
<https://github.com/SentryMan/module-directive-bug/tree/master>

On Fri, Aug 25, 2023 at 9:00?PM Josiah Noel <josiahnoel at gmail.com> wrote:

> Say I got this module
>
> ```
>
> module nima.example {
>
> requires io.avaje.http.client;
>
> requires io.avaje.http.api;
>
> provides io.avaje.http.client.HttpClient.GeneratedComponent with
>
> com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;
>
> }
>
> ```
> and I generate com.jojo.helidon.api.client.httpclient.
> GeneratedHttpComponent in the last round of processing. When I get the
> module element during normal processing and so much as call
> `ModuleElement#getDirectives` and do nothing else, the processor will
> correctly generate, but compilation will still fail.(if I take out the
> module-info from the project it works though) I'm pretty sure it might have
> to do with the fact that GeneratedHttpComponent is created in the last
> round. Even so, not sure why it fails the compilation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230826/11ebb704/attachment-0001.htm>

From attila.kelemen85 at gmail.com  Sun Aug 27 12:25:39 2023
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Sun, 27 Aug 2023 14:25:39 +0200
Subject: Javac type inference issue
Message-ID: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>

Hi,

I'm never sure what type inference is supposed to work with or not, but I
have an example what I find strange that it does not compile successfully:

```
import java.util.*;

public class Test {
    private static <T> void arrayMethod(List<? super T>[] args) {
        listMethod(Arrays.asList(args));
    }

    private static <T> void listMethod(List<List<? super T>> list) {
    }
}
```

I have tried this with 11.0.20, 20.0.2 and 21 RC, and all fails with this:

>     listMethod(Arrays.asList(args));
>     ^
> required: List<List<? super T#1>>
> found:    List<List<? super T#2>>
> reason: inference variable T#3 has incompatible bounds
> equality constraints: List<? super CAP#1>
> lower bounds: List<? super T#2>
> where T#1,T#2,T#3 are type-variables:
> T#1 extends Object declared in method <T#1>listMethod(List<List<? super
T#1>>)
> T#2 extends Object declared in method <T#2>arrayMethod(List<? super
T#2>[])
> T#3 extends Object declared in method <T#3>asList(T#3...)
> where CAP#1 is a fresh type-variable:
> CAP#1 extends Object super: T#2 from capture of ? super T#2

Of course, if I explicitly specify the type argument for `Arrays.asList`,
then it compiles fine, but I fail to see why this should not work without
explicitly specifying the type arguments.

Thanks,
Attila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230827/e2d714bb/attachment.htm>

From forax at univ-mlv.fr  Sun Aug 27 12:38:41 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 27 Aug 2023 14:38:41 +0200 (CEST)
Subject: Javac type inference issue
In-Reply-To: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
References: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
Message-ID: <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>

> From: "attila kelemen85" <attila.kelemen85 at gmail.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, August 27, 2023 2:25:39 PM
> Subject: Javac type inference issue

> Hi,
> I'm never sure what type inference is supposed to work with or not, but I have
> an example what I find strange that it does not compile successfully:

> ```
> import java.util.*;

> public class Test {
> private static <T> void arrayMethod(List<? super T>[] args) {
> listMethod(Arrays.asList(args));
> }

> private static <T> void listMethod(List<List<? super T>> list) {
> }
> }
> ```

> I have tried this with 11.0.20, 20.0.2 and 21 RC, and all fails with this:

> > listMethod(Arrays.asList(args));
> > ^
> > required: List<List<? super T#1>>
> > found: List<List<? super T#2>>
> > reason: inference variable T#3 has incompatible bounds
> > equality constraints: List<? super CAP#1>
> > lower bounds: List<? super T#2>
> > where T#1,T#2,T#3 are type-variables:
> > T#1 extends Object declared in method <T#1>listMethod(List<List<? super T#1>>)
> > T#2 extends Object declared in method <T#2>arrayMethod(List<? super T#2>[])
> > T#3 extends Object declared in method <T#3>asList(T#3...)
> > where CAP#1 is a fresh type-variable:
> > CAP#1 extends Object super: T#2 from capture of ? super T#2

> Of course, if I explicitly specify the type argument for `Arrays.asList`, then
> it compiles fine, but I fail to see why this should not work without explicitly
> specifying the type arguments.

It's not a bug, it's how the capture works, a List<List<? super T>> is a List where each List can have a different type, but here you want a List of List with each list with the same type, 
it can be approximated by 

private static <T> void listMethod(List<? extends List<? super T>> list) { 
} 

but please, do not use an array of parametrized types List<? super T>[] in an API, because creating those are usually unsafe. 

> Thanks,
> Attila

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230827/de4d4dc7/attachment.htm>

From attila.kelemen85 at gmail.com  Sun Aug 27 12:49:38 2023
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Sun, 27 Aug 2023 14:49:38 +0200
Subject: Javac type inference issue
In-Reply-To: <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>
References: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
 <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAKDaPBerAUn6XpqKSoKtr906Lcti3aD6VJv+7+f+19mo793-_A@mail.gmail.com>

>
>
> It's not a bug, it's how the capture works, a List<List<? super T>> is a
> List where each List can have a different type, but here you want a List of
> List with each list with the same type,
> it can be approximated by
>
> private static <T> void listMethod(List<? extends List<? super T>> list) {
> }
>

I think you misunderstand R?mi. I know very well what `List<List<? super
T>>` is. And the code snippet I shared is logically correct in the sense
that an infinitely intelligent type inferer could figure out that it is
correct. In fact, if - in the above code - I write `Arrays.<List<? super
T>>asList(args)` instead of `Arrays.asList(args)`, then it compiles fine.
My question is why do I have to explicitly specify the type arguments, why
can't it be inferred.

Btw. If you change the `listMethod` argument to `List<? extends List<?
super T>> list` it won't compile either.


>
> but please, do not use an array of parametrized types List<? super T>[] in
> an API, because creating those are usually unsafe.
>

That is besides the point, I wrote this code to be as simple as possible.
If you need to know, then in the original code I came across this was using
varargs in a safe way (and to avoid further red herrings it was not done
with List).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230827/a05a8d71/attachment-0001.htm>

From forax at univ-mlv.fr  Sun Aug 27 13:37:50 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 27 Aug 2023 15:37:50 +0200 (CEST)
Subject: Javac type inference issue
In-Reply-To: <CAKDaPBerAUn6XpqKSoKtr906Lcti3aD6VJv+7+f+19mo793-_A@mail.gmail.com>
References: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
 <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBerAUn6XpqKSoKtr906Lcti3aD6VJv+7+f+19mo793-_A@mail.gmail.com>
Message-ID: <1194730356.19499088.1693143470669.JavaMail.zimbra@univ-eiffel.fr>

> From: "attila kelemen85" <attila.kelemen85 at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, August 27, 2023 2:49:38 PM
> Subject: Re: Javac type inference issue

>> It's not a bug, it's how the capture works, a List<List<? super T>> is a List
>> where each List can have a different type, but here you want a List of List
>> with each list with the same type,
>> it can be approximated by

>> private static <T> void listMethod(List<? extends List<? super T>> list) {
>> }

> I think you misunderstand R?mi. I know very well what `List<List<? super T>>`
> is. And the code snippet I shared is logically correct in the sense that an
> infinitely intelligent type inferer could figure out that it is correct. In
> fact, if - in the above code - I write `Arrays.<List<? super T>>asList(args)`
> instead of `Arrays.asList(args)`, then it compiles fine. My question is why do
> I have to explicitly specify the type arguments, why can't it be inferred.

In case of a capture, the inference does not try to replace the capture by its bound. It's a limitation of the inference which tend to choose the most speciifc type where here, it has to use a less specific type. 

> Btw. If you change the `listMethod` argument to `List<? extends List<? super T>>
> list` it won't compile either.

My bad, I should have written List<? super List<? super T>>. 

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230827/531c3569/attachment.htm>

From attila.kelemen85 at gmail.com  Sun Aug 27 14:06:16 2023
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Sun, 27 Aug 2023 16:06:16 +0200
Subject: Javac type inference issue
In-Reply-To: <1194730356.19499088.1693143470669.JavaMail.zimbra@univ-eiffel.fr>
References: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
 <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBerAUn6XpqKSoKtr906Lcti3aD6VJv+7+f+19mo793-_A@mail.gmail.com>
 <1194730356.19499088.1693143470669.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAKDaPBeQY=EWaCE2Cr_4+jEtOaGUmjW5cHG58x9qUzAq68QPDg@mail.gmail.com>

>
>
> In case of a capture, the inference does not try to replace the capture by
> its bound. It's a limitation of the inference which tend to choose the most
> speciifc type where here, it has to use a less specific type.
>
>
I don't quite understand the step by step "reasoning"  of the type inferer
here, because naively this is what I would do if I was employed as a full
time type inferer :). (I'm copying here my code again with some variable
renaming for easier reference) Suppose I'm a compiler, and I see this:

```
<T1> void arrayMethod(List<? super T1>[] args) {
    listMethod(Arrays.asList(args));
}
<T2> void listMethod(List<List<? super T2>> list) { }
```

1. I look at `arrayMethod` and see 2 type variables to infer. One for
`listMethod` (let's call it #L), and one for `Arrays.asList` (let's call it
#A).
2. The first thing I see is that `Arrays.asList` returns `List<#A>`, and it
is assigned to `List<List<? super #L>>`. This is easy to satisfy with #A =
List<? super #L> (and this is actually the only possibility).
3. Then I go the next part, and see that args is of course `List<? super
T1>[]` which must be assigned to `#A[]`, which is again easy to satisfy
with #A = List<? super T1> (which is the only possibility again).
4. So, now I have to satisfy all equalities `#A = List<? super #L>` and `#A
= List<? super T1>`, which implies that `List<? super #L> = List<? super
T1>`, which is easy to satisfy by the choice #L = T1 (again, this is the
only choice).
5. So, now I have resolved both variables:` #L = T1`, and `#A = List<?
super T1>`, and indeed I can validate that this choice will satisfy every
constraint.

I'm just puzzled here, because sometimes the type inferer can solve much
more difficult problems, and this seems trivial compared to those.



> My bad, I should have written List<? super List<? super T>>.
>
>
Surprisingly (to me), that would compile without explicitly specifying the
type arguments (though of course that is not a type declaration that is
acceptable for me). What surprises me here is that I would think that this
would make the job of the type inferer harder, since now it is more
difficult to find the correct types, since there are more options. Without
the outer "? super" the inferer would be forced to make the correct type
assignment (since there is always only one possibility). That is, when you
write `List<? super List<? super T>`, now you get another fresh type
variable to satisfy. Namely, you have to pick a type of `? super List<?
super T>`. While in the other case your only option for this was `List<?
super T>` (which is the only correct choice even in the `? super` variant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230827/4e2ed08b/attachment.htm>

From asotona at openjdk.org  Mon Aug 28 08:29:18 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Aug 2023 08:29:18 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
Message-ID: <81Lr7VBflCF9wpwW7lBp5rHbtxE-MC0EQyme_e2BkKA=.bd9a00b3-0dc4-4498-8843-67e20c8e6db9@github.com>

On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed code printing and ConstantPoolException reporting indoex
>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>  - throwing ConstantPoolException for invalid BSM entry index
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed JavapTask
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/11411#issuecomment-1695260560

From maurizio.cimadamore at oracle.com  Mon Aug 28 10:59:02 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 28 Aug 2023 11:59:02 +0100
Subject: Javac type inference issue
In-Reply-To: <CAKDaPBeQY=EWaCE2Cr_4+jEtOaGUmjW5cHG58x9qUzAq68QPDg@mail.gmail.com>
References: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
 <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBerAUn6XpqKSoKtr906Lcti3aD6VJv+7+f+19mo793-_A@mail.gmail.com>
 <1194730356.19499088.1693143470669.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBeQY=EWaCE2Cr_4+jEtOaGUmjW5cHG58x9qUzAq68QPDg@mail.gmail.com>
Message-ID: <0a9ab434-4874-a13f-bd49-715930b87155@oracle.com>

This does seem like an issue.

Note that similar code, w/o a method call works:

|List<List<? super T1>> res = Arrays.asList(args); |

I did some manual calculation of the bounds involved and I got to:

|List<? super T1> <: #A = List<? super #T2> |

Which seems solvable for:

|A = List<? super T2> T2 = T1 |

But the javac error message reveals a capture conversion is being 
applied somewhere:

|error: method listMethod in class Test cannot be applied to given 
types; List<List<? super T2>> res = listMethod(Arrays.asList(args)); ^ 
required: List<List<? super T2>> found: List<List<? super T1>> reason: 
inference variable T has incompatible bounds equality constraints: 
List<? super CAP#1> // <-------------------------- lower bounds: List<? 
super T1> |

Which seems odd - I would have understod if javac tried to capture 
?args? before passing to Arrays::asList - but that?s not what is 
happening here.

My feeling (confirmed by looking at the internals of the compiler) is 
that javac is applying incorporation to the above set of bounds - and 
running the following check:

|List<? super T1> <: List<? super #T2> |

The JLS here says that when running the this incorporation step, since 
both types are |? super X| wildcards we should just derive:

|#T2 <: T1 |

(e.g. no capture conversion applied).

But that?s not what happens in the compiler implementation (which does a 
straight subtyping check with capture conversion), hence the issue.

Maurizio

On 27/08/2023 15:06, Attila Kelemen wrote:

>
>     In case of a capture, the inference does not try to replace the
>     capture by its bound. It's a limitation of the inference which
>     tend to choose the most speciifc type where here, it has to use a
>     less specific type.
>
>
> I don't quite understand the step by step "reasoning"? of the type 
> inferer here, because naively?this is what I would do if I was 
> employed as a full time type inferer :). (I'm copying here my code 
> again with some variable renaming for easier reference) Suppose I'm a 
> compiler, and I see this:
>
> ```
> <T1> void arrayMethod(List<? super T1>[] args) {
> ? ? listMethod(Arrays.asList(args));
> }
> <T2> void listMethod(List<List<? super T2>> list) { }
> ```
>
> 1. I look at `arrayMethod` and see 2 type variables to infer. One for 
> `listMethod` (let's call it #L), and one for `Arrays.asList` (let's 
> call it #A).
> 2. The first thing I see is that `Arrays.asList` returns `List<#A>`, 
> and it is assigned to `List<List<? super #L>>`. This is easy to 
> satisfy with #A = List<? super #L> (and this is actually the only 
> possibility).
> 3. Then I go the next part, and see that args is of course `List<? 
> super T1>[]` which must be assigned to `#A[]`, which is again easy to 
> satisfy with #A = List<? super T1> (which is the only possibility again).
> 4. So, now I have to satisfy all equalities `#A = List<? super #L>` 
> and `#A = List<? super T1>`, which implies that `List<? super #L> = 
> List<? super T1>`, which is easy to satisfy by the choice #L = T1 
> (again, this is the only choice).
> 5. So, now I have resolved both variables:` #L = T1`, and `#A = List<? 
> super T1>`, and indeed I can validate that this choice will satisfy 
> every constraint.
>
> I'm just puzzled here, because sometimes the type inferer can solve 
> much more difficult problems, and this seems trivial compared to those.
>
>     My bad, I should have written List<? super List<? super T>>.
>
>
> Surprisingly (to me), that would compile without explicitly specifying 
> the type arguments (though of course that is not a type declaration 
> that is acceptable for me). What surprises me here is that I would 
> think that this would make the job of the type inferer harder, since 
> now it is more difficult to find the correct types, since there are 
> more options. Without the outer "? super" the inferer would be forced 
> to make the correct type assignment (since there is always only one 
> possibility). That is, when you write `List<? super List<? super T>`, 
> now you get another fresh type variable to satisfy. Namely, you have 
> to pick a type of `? super List<? super T>`. While in the other case 
> your only option for this was `List<? super T>` (which is the only 
> correct choice even in the `? super` variant.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/33b1a160/attachment-0001.htm>

From acobbs at openjdk.org  Mon Aug 28 14:52:27 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 28 Aug 2023 14:52:27 GMT
Subject: Integrated: 8269957: facilitate alternate impls of NameTable and Name
In-Reply-To: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
Message-ID: <ESz1Px3dNJ7bKpcW7LZXpNagSLrnJapE6TnKnvZhG2A=.be569045-7cb5-407f-970b-7df633ea125e@github.com>

On Sun, 2 Apr 2023 15:06:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
> 
> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
> 
> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
> 
> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag.  A simple performance test with this class enabled ([JavacNameTable.java.txt](https://github.com/openjdk/jdk/files/11602852/JavacNameTable.java.txt)) shows a 17% speedup.
> 
> Changes:
> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
> * Add new `StringNameTable` implementation.

This pull request has now been integrated.

Changeset: 11da15d1
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11da15d1429a7269a31667643365007c752b30e0
Stats:     834 lines in 11 files changed: 571 ins; 162 del; 101 mod

8269957: facilitate alternate impls of NameTable and Name

Reviewed-by: jjg, vromero

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

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

From jonathan.gibbons at oracle.com  Mon Aug 28 15:29:21 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 28 Aug 2023 08:29:21 -0700
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
 <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>
Message-ID: <447f1d85-4ece-0138-321b-3f3cec9f8b35@oracle.com>

The following error message seems relevant:

|/M:/Dev/module-directive-bug/blackbox-test-module/src/main/java/module-info.java:[6,41] 
the service implementation does not have a default constructor: 
io.avaje.modules.example.GeneratedProvider|

-- Jon


On 8/26/23 1:04 PM, Josiah Noel wrote:
> As requested, I have created a simple example to replicate this issue. 
> SentryMan/module-directive-bug: showcase annotation processing bug 
> (github.com) 
> <https://github.com/SentryMan/module-directive-bug/tree/master>
>
> On Fri, Aug 25, 2023 at 9:00?PM Josiah Noel <josiahnoel at gmail.com> wrote:
>
>     Say I got this module
>
>     ```
>
>     modulenima.example {
>
>     requiresio.avaje.http.client;
>
>     requiresio.avaje.http.api;
>
>     providesio.avaje.http.client.HttpClient.GeneratedComponentwith
>
>     com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;
>
>     }
>
>     ```
>     and I generate
>     com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent?in
>     the last round of processing. When I get the module element during
>     normal processing and so much as call
>     `ModuleElement#getDirectives` and do nothing else, the processor
>     will correctly generate, but compilation will still fail.(if I
>     take out the module-info from the project it works though) I'm
>     pretty sure it might have to do with the fact that
>     GeneratedHttpComponent?is created in the last round. Even so, not
>     sure why it fails the compilation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/d5428d97/attachment.htm>

From vromero at openjdk.org  Mon Aug 28 15:35:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Aug 2023 15:35:26 GMT
Subject: RFR: 8315116: fix minor issue in copyright header introduced by
 JDK-8269957 that is breaking the build
Message-ID: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>

The copyright header of new file: `src/jdk.compiler/share/classes/com/sun/tools/javac/util/Utf8NameTable.java` introduced by the fix for `JDK-8269957` is missing a `,` after the copyright year.

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

Commit messages:
 - 8315116: fix minor issue in copyright header introduced by JDK-8269957 that is breaking the build

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

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

From jjg at openjdk.org  Mon Aug 28 15:35:26 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 28 Aug 2023 15:35:26 GMT
Subject: RFR: 8315116: fix minor issue in copyright header introduced by
 JDK-8269957 that is breaking the build
In-Reply-To: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>
References: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>
Message-ID: <tJB9jnA8WEUvZaOpvIekG93vXFJKQUjDt0ms4PcXZOg=.7e9c6895-1088-41fb-83a8-2d770094592c@github.com>

On Mon, 28 Aug 2023 15:28:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The copyright header of new file: `src/jdk.compiler/share/classes/com/sun/tools/javac/util/Utf8NameTable.java` introduced by the fix for `JDK-8269957` is missing a `,` after the copyright year.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15450#pullrequestreview-1598538154

From josiahnoel at gmail.com  Mon Aug 28 15:35:31 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Mon, 28 Aug 2023 11:35:31 -0400
Subject: ModuleElement doesn't work with generated provides classes?
In-Reply-To: <447f1d85-4ece-0138-321b-3f3cec9f8b35@oracle.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
 <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>
 <447f1d85-4ece-0138-321b-3f3cec9f8b35@oracle.com>
Message-ID: <CAJ_t5Uab-kWtF+8Pyo=od-JDKYfxw4mHc4=unCJCFjRfQC_eog@mail.gmail.com>

Just tried explicitly adding a default constructor, but I still receive the
same error.

On Mon, Aug 28, 2023 at 11:29?AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> The following error message seems relevant:
>
> /M:/Dev/module-directive-bug/blackbox-test-module/src/main/java/module-info.java:[6,41] the service implementation does not have
> a default constructor: io.avaje.modules.example.GeneratedProvider
>
> -- Jon
>
>
> On 8/26/23 1:04 PM, Josiah Noel wrote:
>
> As requested, I have created a simple example to replicate this issue. SentryMan/module-directive-bug:
> showcase annotation processing bug (github.com)
> <https://github.com/SentryMan/module-directive-bug/tree/master>
>
> On Fri, Aug 25, 2023 at 9:00?PM Josiah Noel <josiahnoel at gmail.com> wrote:
>
>> Say I got this module
>>
>> ```
>>
>> module nima.example {
>>
>> requires io.avaje.http.client;
>>
>> requires io.avaje.http.api;
>>
>> provides io.avaje.http.client.HttpClient.GeneratedComponent with
>>
>> com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;
>>
>> }
>> ```
>> and I generate com.jojo.helidon.api.client.httpclient.
>> GeneratedHttpComponent in the last round of processing. When I get the
>> module element during normal processing and so much as call
>> `ModuleElement#getDirectives` and do nothing else, the processor will
>> correctly generate, but compilation will still fail.(if I take out the
>> module-info from the project it works though) I'm pretty sure it might have
>> to do with the fact that GeneratedHttpComponent is created in the last
>> round. Even so, not sure why it fails the compilation.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/df6caf64/attachment.htm>

From vromero at openjdk.org  Mon Aug 28 15:47:20 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Aug 2023 15:47:20 GMT
Subject: RFR: 8315116: fix minor issue in copyright header introduced by
 JDK-8269957 that is breaking the build
In-Reply-To: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>
References: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>
Message-ID: <LuZBpxTFirsCnOneSuBGQtu_ak4-hPs1CA9Pg5WHzYI=.330fdec6-cb3f-4af9-83ac-bbf3d7435654@github.com>

On Mon, 28 Aug 2023 15:28:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The copyright header of new file: `src/jdk.compiler/share/classes/com/sun/tools/javac/util/Utf8NameTable.java` introduced by the fix for `JDK-8269957` is missing a `,` after the copyright year.

thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/15450#issuecomment-1695922791

From vromero at openjdk.org  Mon Aug 28 15:47:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Aug 2023 15:47:21 GMT
Subject: Integrated: 8315116: fix minor issue in copyright header introduced by
 JDK-8269957 that is breaking the build
In-Reply-To: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>
References: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>
Message-ID: <WpmJQgBqFtF4C9lUUpEk8PYNBYfyVHJ1yCaQuf9k8tk=.1fb5d821-c8b7-4685-968a-5640e0442aa1@github.com>

On Mon, 28 Aug 2023 15:28:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The copyright header of new file: `src/jdk.compiler/share/classes/com/sun/tools/javac/util/Utf8NameTable.java` introduced by the fix for `JDK-8269957` is missing a `,` after the copyright year.

This pull request has now been integrated.

Changeset: acb24bf3
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acb24bf3540fafae7659d0b92f7696db7d70f55a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8315116: fix minor issue in copyright header introduced by JDK-8269957 that is breaking the build

Reviewed-by: jjg, dcubed

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

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

From dcubed at openjdk.org  Mon Aug 28 15:47:19 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 28 Aug 2023 15:47:19 GMT
Subject: RFR: 8315116: fix minor issue in copyright header introduced by
 JDK-8269957 that is breaking the build
In-Reply-To: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>
References: <qNyZtv3t0WIa0l4wfZlkrXsxQnoYHwVF99yBd2FzGF4=.d675e819-d822-48f2-a119-0023b91ff49f@github.com>
Message-ID: <Q3Giotj6GY4StUCwREbLtoc_UTOoL5mi8hn7UqLX08A=.6759da70-9156-4751-839e-c33a70f00f7b@github.com>

On Mon, 28 Aug 2023 15:28:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The copyright header of new file: `src/jdk.compiler/share/classes/com/sun/tools/javac/util/Utf8NameTable.java` introduced by the fix for `JDK-8269957` is missing a `,` after the copyright year.

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15450#pullrequestreview-1598558533

From jonathan.gibbons at oracle.com  Mon Aug 28 15:50:32 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 28 Aug 2023 08:50:32 -0700
Subject: [External] : Re: ModuleElement doesn't work with generated
 provides classes?
In-Reply-To: <CAJ_t5Uab-kWtF+8Pyo=od-JDKYfxw4mHc4=unCJCFjRfQC_eog@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
 <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>
 <447f1d85-4ece-0138-321b-3f3cec9f8b35@oracle.com>
 <CAJ_t5Uab-kWtF+8Pyo=od-JDKYfxw4mHc4=unCJCFjRfQC_eog@mail.gmail.com>
Message-ID: <c8de83e1-b542-df51-2ec3-9b1104a0f781@oracle.com>

I'll file a JBS issue to track this further.

-- Jon


On 8/28/23 8:35 AM, Josiah Noel wrote:
> Just tried explicitly adding a default constructor, but I still 
> receive the same error.
>
> On Mon, Aug 28, 2023 at 11:29?AM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>     The following error message seems relevant:
>
>     |/M:/Dev/module-directive-bug/blackbox-test-module/src/main/java/module-info.java:[6,41]
>     the service implementation does not have a default constructor:
>     io.avaje.modules.example.GeneratedProvider|
>
>     -- Jon
>
>
>     On 8/26/23 1:04 PM, Josiah Noel wrote:
>>     As requested, I have created a simple example to replicate this
>>     issue. SentryMan/module-directive-bug: showcase annotation
>>     processing bug (github.com)
>>     <https://urldefense.com/v3/__https://github.com/SentryMan/module-directive-bug/tree/master__;!!ACWV5N9M2RV99hQ!O3CMUWVsFHaaU7b9D1x_-4ByzBUrMMF0KeTPmtdnqOC1hRhhZCBO0dODJwf1rZsapQpTYmYktzo5W_0TwANTUZuu$>
>>
>>     On Fri, Aug 25, 2023 at 9:00?PM Josiah Noel
>>     <josiahnoel at gmail.com> wrote:
>>
>>         Say I got this module
>>
>>         ```
>>
>>         modulenima.example {
>>
>>         requiresio.avaje.http.client;
>>
>>         requiresio.avaje.http.api;
>>
>>         providesio.avaje.http.client.HttpClient.GeneratedComponentwith
>>
>>         com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;
>>
>>         }
>>
>>         ```
>>         and I generate
>>         com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent?in
>>         the last round of processing. When I get the module element
>>         during normal processing and so much as call
>>         `ModuleElement#getDirectives` and do nothing else, the
>>         processor will correctly generate, but compilation will still
>>         fail.(if I take out the module-info from the project it works
>>         though) I'm pretty sure it might have to do with the fact
>>         that GeneratedHttpComponent?is created in the last round.
>>         Even so, not sure why it fails the compilation.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/7ade9862/attachment.htm>

From jonathan.gibbons at oracle.com  Mon Aug 28 15:57:47 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 28 Aug 2023 08:57:47 -0700
Subject: [External] : Re: ModuleElement doesn't work with generated
 provides classes?
In-Reply-To: <c8de83e1-b542-df51-2ec3-9b1104a0f781@oracle.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
 <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>
 <447f1d85-4ece-0138-321b-3f3cec9f8b35@oracle.com>
 <CAJ_t5Uab-kWtF+8Pyo=od-JDKYfxw4mHc4=unCJCFjRfQC_eog@mail.gmail.com>
 <c8de83e1-b542-df51-2ec3-9b1104a0f781@oracle.com>
Message-ID: <19baec94-8b9a-5824-7887-5ff2534a8892@oracle.com>

https://bugs.openjdk.org/browse/JDK-8315125

-- Jon

On 8/28/23 8:50 AM, Jonathan Gibbons wrote:
>
> I'll file a JBS issue to track this further.
>
> -- Jon
>
>
> On 8/28/23 8:35 AM, Josiah Noel wrote:
>> Just tried explicitly adding a default constructor, but I still 
>> receive the same error.
>>
>> On Mon, Aug 28, 2023 at 11:29?AM Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com> wrote:
>>
>>     The following error message seems relevant:
>>
>>     |/M:/Dev/module-directive-bug/blackbox-test-module/src/main/java/module-info.java:[6,41]
>>     the service implementation does not have a default constructor:
>>     io.avaje.modules.example.GeneratedProvider|
>>
>>     -- Jon
>>
>>
>>     On 8/26/23 1:04 PM, Josiah Noel wrote:
>>>     As requested, I have created a simple example to replicate this
>>>     issue. SentryMan/module-directive-bug: showcase annotation
>>>     processing bug (github.com)
>>>     <https://urldefense.com/v3/__https://github.com/SentryMan/module-directive-bug/tree/master__;!!ACWV5N9M2RV99hQ!O3CMUWVsFHaaU7b9D1x_-4ByzBUrMMF0KeTPmtdnqOC1hRhhZCBO0dODJwf1rZsapQpTYmYktzo5W_0TwANTUZuu$>
>>>
>>>     On Fri, Aug 25, 2023 at 9:00?PM Josiah Noel
>>>     <josiahnoel at gmail.com> wrote:
>>>
>>>         Say I got this module
>>>
>>>         ```
>>>
>>>         modulenima.example {
>>>
>>>         requiresio.avaje.http.client;
>>>
>>>         requiresio.avaje.http.api;
>>>
>>>         providesio.avaje.http.client.HttpClient.GeneratedComponentwith
>>>
>>>         com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;
>>>
>>>         }
>>>
>>>         ```
>>>         and I generate
>>>         com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent?in
>>>         the last round of processing. When I get the module element
>>>         during normal processing and so much as call
>>>         `ModuleElement#getDirectives` and do nothing else, the
>>>         processor will correctly generate, but compilation will
>>>         still fail.(if I take out the module-info from the project
>>>         it works though) I'm pretty sure it might have to do with
>>>         the fact that GeneratedHttpComponent?is created in the last
>>>         round. Even so, not sure why it fails the compilation.
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/24976317/attachment-0001.htm>

From josiahnoel at gmail.com  Mon Aug 28 18:48:31 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Mon, 28 Aug 2023 14:48:31 -0400
Subject: [External] : Re: ModuleElement doesn't work with generated
 provides classes?
In-Reply-To: <19baec94-8b9a-5824-7887-5ff2534a8892@oracle.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
 <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>
 <447f1d85-4ece-0138-321b-3f3cec9f8b35@oracle.com>
 <CAJ_t5Uab-kWtF+8Pyo=od-JDKYfxw4mHc4=unCJCFjRfQC_eog@mail.gmail.com>
 <c8de83e1-b542-df51-2ec3-9b1104a0f781@oracle.com>
 <19baec94-8b9a-5824-7887-5ff2534a8892@oracle.com>
Message-ID: <CAJ_t5UY9wKV0NhSzdbv=yZK3UQ2uQ5isx03-dGNdUo1_FzDZRQ@mail.gmail.com>

I see it has been partially fixed in a later version, and that the problem
only occurs if the service impl is generated in the last round. I can
tolerate not being able to explicitly see the `provides` statements, but
it's still a problem if merely calling `ModuleElement.getDirectives` causes
compilation to fail if services are generated in the last round. Is there a
way that we can make the behavior the same except not failing compilation?
(Currently I can see the requires just fine but the compilation is doomed
to fail)

On Mon, Aug 28, 2023 at 2:05?PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> https://bugs.openjdk.org/browse/JDK-8315125
>
> -- Jon
> On 8/28/23 8:50 AM, Jonathan Gibbons wrote:
>
> I'll file a JBS issue to track this further.
>
> -- Jon
>
>
> On 8/28/23 8:35 AM, Josiah Noel wrote:
>
> Just tried explicitly adding a default constructor, but I still receive
> the same error.
>
> On Mon, Aug 28, 2023 at 11:29?AM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> The following error message seems relevant:
>>
>> /M:/Dev/module-directive-bug/blackbox-test-module/src/main/java/module-info.java:[6,41] the service implementation does not have
>> a default constructor: io.avaje.modules.example.GeneratedProvider
>>
>> -- Jon
>>
>>
>> On 8/26/23 1:04 PM, Josiah Noel wrote:
>>
>> As requested, I have created a simple example to replicate this issue. SentryMan/module-directive-bug:
>> showcase annotation processing bug (github.com)
>> <https://urldefense.com/v3/__https://github.com/SentryMan/module-directive-bug/tree/master__;!!ACWV5N9M2RV99hQ!O3CMUWVsFHaaU7b9D1x_-4ByzBUrMMF0KeTPmtdnqOC1hRhhZCBO0dODJwf1rZsapQpTYmYktzo5W_0TwANTUZuu$>
>>
>> On Fri, Aug 25, 2023 at 9:00?PM Josiah Noel <josiahnoel at gmail.com> wrote:
>>
>>> Say I got this module
>>>
>>> ```
>>>
>>> module nima.example {
>>>
>>> requires io.avaje.http.client;
>>>
>>> requires io.avaje.http.api;
>>>
>>> provides io.avaje.http.client.HttpClient.GeneratedComponent with
>>>
>>> com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;
>>>
>>> }
>>> ```
>>> and I generate com.jojo.helidon.api.client.httpclient.
>>> GeneratedHttpComponent in the last round of processing. When I get the
>>> module element during normal processing and so much as call
>>> `ModuleElement#getDirectives` and do nothing else, the processor will
>>> correctly generate, but compilation will still fail.(if I take out the
>>> module-info from the project it works though) I'm pretty sure it might have
>>> to do with the fact that GeneratedHttpComponent is created in the last
>>> round. Even so, not sure why it fails the compilation.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/d76fa415/attachment.htm>

From vicente.romero at oracle.com  Mon Aug 28 18:51:25 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 28 Aug 2023 14:51:25 -0400
Subject: Javac type inference issue
In-Reply-To: <0a9ab434-4874-a13f-bd49-715930b87155@oracle.com>
References: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
 <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBerAUn6XpqKSoKtr906Lcti3aD6VJv+7+f+19mo793-_A@mail.gmail.com>
 <1194730356.19499088.1693143470669.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBeQY=EWaCE2Cr_4+jEtOaGUmjW5cHG58x9qUzAq68QPDg@mail.gmail.com>
 <0a9ab434-4874-a13f-bd49-715930b87155@oracle.com>
Message-ID: <c865c6e1-672e-8a7f-2ecd-aac8539217f4@oracle.com>

very interesting issue, I agree that the compiler could do better here, 
this needs more research, I have been taking a look at the compiler 
internals, it could be that a structural type comparison could be needed 
here. In the mean time I have filed [1]

Thanks,
Vicente

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

On 8/28/23 06:59, Maurizio Cimadamore wrote:
>
> This does seem like an issue.
>
> Note that similar code, w/o a method call works:
>
> |List<List<? super T1>> res = Arrays.asList(args); |
>
> I did some manual calculation of the bounds involved and I got to:
>
> |List<? super T1> <: #A = List<? super #T2> |
>
> Which seems solvable for:
>
> |A = List<? super T2> T2 = T1 |
>
> But the javac error message reveals a capture conversion is being 
> applied somewhere:
>
> |error: method listMethod in class Test cannot be applied to given 
> types; List<List<? super T2>> res = listMethod(Arrays.asList(args)); ^ 
> required: List<List<? super T2>> found: List<List<? super T1>> reason: 
> inference variable T has incompatible bounds equality constraints: 
> List<? super CAP#1> // <-------------------------- lower bounds: 
> List<? super T1> |
>
> Which seems odd - I would have understod if javac tried to capture 
> ?args? before passing to Arrays::asList - but that?s not what is 
> happening here.
>
> My feeling (confirmed by looking at the internals of the compiler) is 
> that javac is applying incorporation to the above set of bounds - and 
> running the following check:
>
> |List<? super T1> <: List<? super #T2> |
>
> The JLS here says that when running the this incorporation step, since 
> both types are |? super X| wildcards we should just derive:
>
> |#T2 <: T1 |
>
> (e.g. no capture conversion applied).
>
> But that?s not what happens in the compiler implementation (which does 
> a straight subtyping check with capture conversion), hence the issue.
>
> Maurizio
>
> On 27/08/2023 15:06, Attila Kelemen wrote:
>
>>
>>     In case of a capture, the inference does not try to replace the
>>     capture by its bound. It's a limitation of the inference which
>>     tend to choose the most speciifc type where here, it has to use a
>>     less specific type.
>>
>>
>> I don't quite understand the step by step "reasoning"? of the type 
>> inferer here, because naively?this is what I would do if I was 
>> employed as a full time type inferer :). (I'm copying here my code 
>> again with some variable renaming for easier reference) Suppose I'm a 
>> compiler, and I see this:
>>
>> ```
>> <T1> void arrayMethod(List<? super T1>[] args) {
>> ? ? listMethod(Arrays.asList(args));
>> }
>> <T2> void listMethod(List<List<? super T2>> list) { }
>> ```
>>
>> 1. I look at `arrayMethod` and see 2 type variables to infer. One for 
>> `listMethod` (let's call it #L), and one for `Arrays.asList` (let's 
>> call it #A).
>> 2. The first thing I see is that `Arrays.asList` returns `List<#A>`, 
>> and it is assigned to `List<List<? super #L>>`. This is easy to 
>> satisfy with #A = List<? super #L> (and this is actually the only 
>> possibility).
>> 3. Then I go the next part, and see that args is of course `List<? 
>> super T1>[]` which must be assigned to `#A[]`, which is again easy to 
>> satisfy with #A = List<? super T1> (which is the only possibility again).
>> 4. So, now I have to satisfy all equalities `#A = List<? super #L>` 
>> and `#A = List<? super T1>`, which implies that `List<? super #L> = 
>> List<? super T1>`, which is easy to satisfy by the choice #L = T1 
>> (again, this is the only choice).
>> 5. So, now I have resolved both variables:` #L = T1`, and `#A = 
>> List<? super T1>`, and indeed I can validate that this choice will 
>> satisfy every constraint.
>>
>> I'm just puzzled here, because sometimes the type inferer can solve 
>> much more difficult problems, and this seems trivial compared to those.
>>
>>     My bad, I should have written List<? super List<? super T>>.
>>
>>
>> Surprisingly (to me), that would compile without explicitly 
>> specifying the type arguments (though of course that is not a type 
>> declaration that is acceptable for me). What surprises me here is 
>> that I would think that this would make the job of the type inferer 
>> harder, since now it is more difficult to find the correct types, 
>> since there are more options. Without the outer "? super" the inferer 
>> would be forced to make the correct type assignment (since there is 
>> always only one possibility). That is, when you write `List<? super 
>> List<? super T>`, now you get another fresh type variable to satisfy. 
>> Namely, you have to pick a type of `? super List<? super T>`. While 
>> in the other case your only option for this was `List<? super T>` 
>> (which is the only correct choice even in the `? super` variant.
> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/4afa6e08/attachment-0001.htm>

From darcy at openjdk.org  Mon Aug 28 19:58:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Aug 2023 19:58:51 GMT
Subject: RFR: JDK-8315137: Add explicit override
 RecordComponentElement.asType()
Message-ID: <ZfPwqpuuq_YLd7HxmDkVJXYmR7Zp5QDeuW9T03Sk39s=.2cafbf81-71fe-42e8-8bf2-d536d85cff0c@github.com>

No change in semantics, just adding more explicit information.

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

Commit messages:
 - JDK-8315137: Add explicit override RecordComponentElement.asType()

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

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

From attila.kelemen85 at gmail.com  Mon Aug 28 20:01:11 2023
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Mon, 28 Aug 2023 22:01:11 +0200
Subject: Javac type inference issue
In-Reply-To: <c865c6e1-672e-8a7f-2ecd-aac8539217f4@oracle.com>
References: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
 <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBerAUn6XpqKSoKtr906Lcti3aD6VJv+7+f+19mo793-_A@mail.gmail.com>
 <1194730356.19499088.1693143470669.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBeQY=EWaCE2Cr_4+jEtOaGUmjW5cHG58x9qUzAq68QPDg@mail.gmail.com>
 <0a9ab434-4874-a13f-bd49-715930b87155@oracle.com>
 <c865c6e1-672e-8a7f-2ecd-aac8539217f4@oracle.com>
Message-ID: <CAKDaPBdpZT4s9q_ZKT2qwHXPy52sR6T423Ea2=NZ38nY+MwMMg@mail.gmail.com>

What I find the most interesting about this issue is what R?mi showed. If
you change the argument type of listMethod from `List<List<? super T>>` to
`List<? super List<? super T>>`. then the type inferer can find the correct
type assignments. And this looks bizarre to me, because that just looks
like a straight up more difficult problem, yet it is demonstrably not so
for the compiler.

Vicente Romero <vicente.romero at oracle.com> ezt ?rta (id?pont: 2023. aug.
28., H, 20:56):

> very interesting issue, I agree that the compiler could do better here,
> this needs more research, I have been taking a look at the compiler
> internals, it could be that a structural type comparison could be needed
> here. In the mean time I have filed [1]
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.org/browse/JDK-8315134
>
> On 8/28/23 06:59, Maurizio Cimadamore wrote:
>
> This does seem like an issue.
>
> Note that similar code, w/o a method call works:
>
> List<List<? super T1>> res = Arrays.asList(args);
>
> I did some manual calculation of the bounds involved and I got to:
>
> List<? super T1> <: #A = List<? super #T2>
>
> Which seems solvable for:
>
> A = List<? super T2>
> T2 = T1
>
> But the javac error message reveals a capture conversion is being applied
> somewhere:
>
> error: method listMethod in class Test cannot be applied to given types;
> List<List<? super T2>> res = listMethod(Arrays.asList(args));
>                              ^
>   required: List<List<? super T2>>
>   found: List<List<? super T1>>
>   reason: inference variable T has incompatible bounds
>     equality constraints: List<? super CAP#1> // <--------------------------
>     lower bounds: List<? super T1>
>
> Which seems odd - I would have understod if javac tried to capture ?args?
> before passing to Arrays::asList - but that?s not what is happening here.
>
> My feeling (confirmed by looking at the internals of the compiler) is that
> javac is applying incorporation to the above set of bounds - and running
> the following check:
>
> List<? super T1> <: List<? super #T2>
>
> The JLS here says that when running the this incorporation step, since
> both types are ? super X wildcards we should just derive:
>
> #T2 <: T1
>
> (e.g. no capture conversion applied).
>
> But that?s not what happens in the compiler implementation (which does a
> straight subtyping check with capture conversion), hence the issue.
>
> Maurizio
>
> On 27/08/2023 15:06, Attila Kelemen wrote:
>
>
>> In case of a capture, the inference does not try to replace the capture
>> by its bound. It's a limitation of the inference which tend to choose the
>> most speciifc type where here, it has to use a less specific type.
>>
>>
> I don't quite understand the step by step "reasoning"  of the type inferer
> here, because naively this is what I would do if I was employed as a full
> time type inferer :). (I'm copying here my code again with some variable
> renaming for easier reference) Suppose I'm a compiler, and I see this:
>
> ```
> <T1> void arrayMethod(List<? super T1>[] args) {
>     listMethod(Arrays.asList(args));
> }
> <T2> void listMethod(List<List<? super T2>> list) { }
> ```
>
> 1. I look at `arrayMethod` and see 2 type variables to infer. One for
> `listMethod` (let's call it #L), and one for `Arrays.asList` (let's call it
> #A).
> 2. The first thing I see is that `Arrays.asList` returns `List<#A>`, and
> it is assigned to `List<List<? super #L>>`. This is easy to satisfy with #A
> = List<? super #L> (and this is actually the only possibility).
> 3. Then I go the next part, and see that args is of course `List<? super
> T1>[]` which must be assigned to `#A[]`, which is again easy to satisfy
> with #A = List<? super T1> (which is the only possibility again).
> 4. So, now I have to satisfy all equalities `#A = List<? super #L>` and
> `#A = List<? super T1>`, which implies that `List<? super #L> = List<?
> super T1>`, which is easy to satisfy by the choice #L = T1 (again, this is
> the only choice).
> 5. So, now I have resolved both variables:` #L = T1`, and `#A = List<?
> super T1>`, and indeed I can validate that this choice will satisfy every
> constraint.
>
> I'm just puzzled here, because sometimes the type inferer can solve much
> more difficult problems, and this seems trivial compared to those.
>
>
>
>> My bad, I should have written List<? super List<? super T>>.
>>
>>
> Surprisingly (to me), that would compile without explicitly specifying the
> type arguments (though of course that is not a type declaration that is
> acceptable for me). What surprises me here is that I would think that this
> would make the job of the type inferer harder, since now it is more
> difficult to find the correct types, since there are more options. Without
> the outer "? super" the inferer would be forced to make the correct type
> assignment (since there is always only one possibility). That is, when you
> write `List<? super List<? super T>`, now you get another fresh type
> variable to satisfy. Namely, you have to pick a type of `? super List<?
> super T>`. While in the other case your only option for this was `List<?
> super T>` (which is the only correct choice even in the `? super` variant.
>
> ?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/c5292690/attachment-0001.htm>

From darcy at openjdk.org  Mon Aug 28 20:33:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Aug 2023 20:33:47 GMT
Subject: RFR: JDK-8315137: Add explicit override
 RecordComponentElement.asType() [v2]
In-Reply-To: <ZfPwqpuuq_YLd7HxmDkVJXYmR7Zp5QDeuW9T03Sk39s=.2cafbf81-71fe-42e8-8bf2-d536d85cff0c@github.com>
References: <ZfPwqpuuq_YLd7HxmDkVJXYmR7Zp5QDeuW9T03Sk39s=.2cafbf81-71fe-42e8-8bf2-d536d85cff0c@github.com>
Message-ID: <9t5-Aaqc_HiWcLcHSIiXPmJZn6JY6c0fSMWXhRmjQlc=.0b745f79-d28e-4cc8-9ede-b25cee3662ef@github.com>

> No change in semantics, just adding more explicit information.

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

  Fix typo noticed during code review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15456/files
  - new: https://git.openjdk.org/jdk/pull/15456/files/dc309f55..397b2bb2

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

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

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

From jjg at openjdk.org  Mon Aug 28 20:33:48 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 28 Aug 2023 20:33:48 GMT
Subject: RFR: JDK-8315137: Add explicit override
 RecordComponentElement.asType() [v2]
In-Reply-To: <9t5-Aaqc_HiWcLcHSIiXPmJZn6JY6c0fSMWXhRmjQlc=.0b745f79-d28e-4cc8-9ede-b25cee3662ef@github.com>
References: <ZfPwqpuuq_YLd7HxmDkVJXYmR7Zp5QDeuW9T03Sk39s=.2cafbf81-71fe-42e8-8bf2-d536d85cff0c@github.com>
 <9t5-Aaqc_HiWcLcHSIiXPmJZn6JY6c0fSMWXhRmjQlc=.0b745f79-d28e-4cc8-9ede-b25cee3662ef@github.com>
Message-ID: <WiSHm2NehJYLBzUPVBJVa7q3bt-p_KT2LMwpuJMlKwQ=.860faea1-cc1b-4824-b251-99e0936ad6c7@github.com>

On Mon, 28 Aug 2023 20:29:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> No change in semantics, just adding more explicit information.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo noticed during code review.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15456#pullrequestreview-1599061644

From darcy at openjdk.org  Mon Aug 28 20:47:26 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Aug 2023 20:47:26 GMT
Subject: Integrated: JDK-8315137: Add explicit override
 RecordComponentElement.asType()
In-Reply-To: <ZfPwqpuuq_YLd7HxmDkVJXYmR7Zp5QDeuW9T03Sk39s=.2cafbf81-71fe-42e8-8bf2-d536d85cff0c@github.com>
References: <ZfPwqpuuq_YLd7HxmDkVJXYmR7Zp5QDeuW9T03Sk39s=.2cafbf81-71fe-42e8-8bf2-d536d85cff0c@github.com>
Message-ID: <yc2KCbZ8YQVpX4RYIdxIeiHTdgVLj0gxUaasobRux9Q=.62802de6-328f-4c33-8c86-86767ecb02af@github.com>

On Mon, 28 Aug 2023 19:50:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> No change in semantics, just adding more explicit information.

This pull request has now been integrated.

Changeset: 8e2a533d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e2a533df69d32c419d035068ac3964dd9f98b7b
Stats:     17 lines in 2 files changed: 16 ins; 0 del; 1 mod

8315137: Add explicit override RecordComponentElement.asType()

Reviewed-by: jjg

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

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

From vicente.romero at oracle.com  Mon Aug 28 23:57:14 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 28 Aug 2023 19:57:14 -0400
Subject: [External] : Re: Javac type inference issue
In-Reply-To: <CAKDaPBdpZT4s9q_ZKT2qwHXPy52sR6T423Ea2=NZ38nY+MwMMg@mail.gmail.com>
References: <CAKDaPBfE_1hyqYch8AG1DtVom2n2h0e9OGprcshQOVhYvAM2cg@mail.gmail.com>
 <1383635081.19486211.1693139921591.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBerAUn6XpqKSoKtr906Lcti3aD6VJv+7+f+19mo793-_A@mail.gmail.com>
 <1194730356.19499088.1693143470669.JavaMail.zimbra@univ-eiffel.fr>
 <CAKDaPBeQY=EWaCE2Cr_4+jEtOaGUmjW5cHG58x9qUzAq68QPDg@mail.gmail.com>
 <0a9ab434-4874-a13f-bd49-715930b87155@oracle.com>
 <c865c6e1-672e-8a7f-2ecd-aac8539217f4@oracle.com>
 <CAKDaPBdpZT4s9q_ZKT2qwHXPy52sR6T423Ea2=NZ38nY+MwMMg@mail.gmail.com>
Message-ID: <fc1f83fe-b485-35b9-b32c-b0c5cdf604cb@oracle.com>



On 8/28/23 16:01, Attila Kelemen wrote:
> What I find the most interesting about this issue is what R?mi showed. 
> If you change the argument type of listMethod from `List<List<? super 
> T>>` to `List<? super List<? super T>>`. then the type inferer can 
> find the correct type assignments. And this looks bizarre to me, 
> because that just looks like a straight up more difficult problem, yet 
> it is demonstrably not so for the compiler.

the compiler is basically doing an upfront capture conversion every time 
it does a subtyping test during inference, this produces the expected 
result for most type pairs but not for all as your test case proves,

Vicente

>
> Vicente Romero <vicente.romero at oracle.com> ezt ?rta (id?pont: 2023. 
> aug. 28., H, 20:56):
>
>     very interesting issue, I agree that the compiler could do better
>     here, this needs more research, I have been taking a look at the
>     compiler internals, it could be that a structural type comparison
>     could be needed here. In the mean time I have filed [1]
>
>     Thanks,
>     Vicente
>
>     [1] https://bugs.openjdk.org/browse/JDK-8315134
>
>     On 8/28/23 06:59, Maurizio Cimadamore wrote:
>>
>>     This does seem like an issue.
>>
>>     Note that similar code, w/o a method call works:
>>
>>     |List<List<? super T1>> res = Arrays.asList(args); |
>>
>>     I did some manual calculation of the bounds involved and I got to:
>>
>>     |List<? super T1> <: #A = List<? super #T2> |
>>
>>     Which seems solvable for:
>>
>>     |A = List<? super T2> T2 = T1 |
>>
>>     But the javac error message reveals a capture conversion is being
>>     applied somewhere:
>>
>>     |error: method listMethod in class Test cannot be applied to
>>     given types; List<List<? super T2>> res =
>>     listMethod(Arrays.asList(args)); ^ required: List<List<? super
>>     T2>> found: List<List<? super T1>> reason: inference variable T
>>     has incompatible bounds equality constraints: List<? super CAP#1>
>>     // <-------------------------- lower bounds: List<? super T1> |
>>
>>     Which seems odd - I would have understod if javac tried to
>>     capture ?args? before passing to Arrays::asList - but that?s not
>>     what is happening here.
>>
>>     My feeling (confirmed by looking at the internals of the
>>     compiler) is that javac is applying incorporation to the above
>>     set of bounds - and running the following check:
>>
>>     |List<? super T1> <: List<? super #T2> |
>>
>>     The JLS here says that when running the this incorporation step,
>>     since both types are |? super X| wildcards we should just derive:
>>
>>     |#T2 <: T1 |
>>
>>     (e.g. no capture conversion applied).
>>
>>     But that?s not what happens in the compiler implementation (which
>>     does a straight subtyping check with capture conversion), hence
>>     the issue.
>>
>>     Maurizio
>>
>>     On 27/08/2023 15:06, Attila Kelemen wrote:
>>
>>>
>>>         In case of a capture, the inference does not try to replace
>>>         the capture by its bound. It's a limitation of the inference
>>>         which tend to choose the most speciifc type where here, it
>>>         has to use a less specific type.
>>>
>>>
>>>     I don't quite understand the step by step "reasoning"? of the
>>>     type inferer here, because naively?this is what I would do if I
>>>     was employed as a full time type inferer :). (I'm copying here
>>>     my code again with some variable renaming for easier reference)
>>>     Suppose I'm a compiler, and I see this:
>>>
>>>     ```
>>>     <T1> void arrayMethod(List<? super T1>[] args) {
>>>     ? ? listMethod(Arrays.asList(args));
>>>     }
>>>     <T2> void listMethod(List<List<? super T2>> list) { }
>>>     ```
>>>
>>>     1. I look at `arrayMethod` and see 2 type variables to infer.
>>>     One for `listMethod` (let's call it #L), and one for
>>>     `Arrays.asList` (let's call it #A).
>>>     2. The first thing I see is that `Arrays.asList` returns
>>>     `List<#A>`, and it is assigned to `List<List<? super #L>>`. This
>>>     is easy to satisfy with #A = List<? super #L> (and this is
>>>     actually the only possibility).
>>>     3. Then I go the next part, and see that args is of course
>>>     `List<? super T1>[]` which must be assigned to `#A[]`, which is
>>>     again easy to satisfy with #A = List<? super T1> (which is the
>>>     only possibility again).
>>>     4. So, now I have to satisfy all equalities `#A = List<? super
>>>     #L>` and `#A = List<? super T1>`, which implies that `List<?
>>>     super #L> = List<? super T1>`, which is easy to satisfy by the
>>>     choice #L = T1 (again, this is the only choice).
>>>     5. So, now I have resolved both variables:` #L = T1`, and `#A =
>>>     List<? super T1>`, and indeed I can validate that this choice
>>>     will satisfy every constraint.
>>>
>>>     I'm just puzzled here, because sometimes the type inferer can
>>>     solve much more difficult problems, and this seems trivial
>>>     compared to those.
>>>
>>>         My bad, I should have written List<? super List<? super T>>.
>>>
>>>
>>>     Surprisingly (to me), that would compile without explicitly
>>>     specifying the type arguments (though of course that is not a
>>>     type declaration that is acceptable for me). What surprises me
>>>     here is that I would think that this would make the job of the
>>>     type inferer harder, since now it is more difficult to find the
>>>     correct types, since there are more options. Without the outer
>>>     "? super" the inferer would be forced to make the correct type
>>>     assignment (since there is always only one possibility). That
>>>     is, when you write `List<? super List<? super T>`, now you get
>>>     another fresh type variable to satisfy. Namely, you have to pick
>>>     a type of `? super List<? super T>`. While in the other case
>>>     your only option for this was `List<? super T>` (which is the
>>>     only correct choice even in the `? super` variant.
>>     ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230828/f96d8062/attachment-0001.htm>

From vromero at openjdk.org  Tue Aug 29 03:27:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 29 Aug 2023 03:27:49 GMT
Subject: RFR: 8315134: javac inference seems to be capturing types incorrectly
Message-ID: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>

this code:


import java.util.*;

public class Test {
    private static <T> void arrayMethod(List<? super T>[] args) {
        listMethod(Arrays.asList(args));
    }

    private static <T> void listMethod(List<List<? super T>> list) {}
}


is being rejected by the compiler. This code should be accepted according to the spec. The compiler is doing a capture conversion that is not mentioned in the spec while reducing subtyping constraints during type inference. This fix is syncing the compiler with the spec.

TIA

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

Commit messages:
 - 8315134: javac inference seems to be capturing types incorrectly

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

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

From mcimadamore at openjdk.org  Tue Aug 29 10:40:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Aug 2023 10:40:10 GMT
Subject: RFR: 8315134: javac inference seems to be capturing types
 incorrectly
In-Reply-To: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>
References: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>
Message-ID: <ec5ULNMrIyw7xUNuEwW-40v5DUVZf_AublVeJcImqQY=.b37c33bc-c2b0-4f2a-b5cd-a0f1c14a2e12@github.com>

On Tue, 29 Aug 2023 03:20:52 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this code:
> 
> 
> import java.util.*;
> 
> public class Test {
>     private static <T> void arrayMethod(List<? super T>[] args) {
>         listMethod(Arrays.asList(args));
>     }
> 
>     private static <T> void listMethod(List<List<? super T>> list) {}
> }
> 
> 
> is being rejected by the compiler. This code should be accepted according to the spec. The compiler is doing a capture conversion that is not mentioned in the spec while reducing subtyping constraints during type inference. This fix is syncing the compiler with the spec.
> 
> TIA

Note that this issue was already known:
https://bugs.openjdk.org/browse/JDK-8206142?jql=text%20~%20%22capture%20incorporation%22

IIRC we had some issues with that patch, or were concerned about compatibility impact. This is discussed in this thread:

https://mail.openjdk.org/pipermail/compiler-dev/2018-July/012217.html

Note that there's a related JLS issue that is still not resolved:
https://bugs.openjdk.org/browse/JDK-8016196

Applying capture is too strict (as this bug shows), but not applying capture could result in other problems. Consider a type declaration such as this:


Foo<X> extends Sup<Foo<X>>


Now, let's say you run the following subtyping test:


Foo<?> <: Sup<Foo<?>>


If you don't capture, when you "lift" `Foo` in the LHS to `Sup` what do you do? Do we just replace a wildcard for `X` in `Sup<Foo<X>>` ? If we do, we end up like this:


Sup<Foo<?>> <: Sup<Foo<?>>
-> true


But this is unsound.

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

PR Comment: https://git.openjdk.org/jdk/pull/15463#issuecomment-1697187102

From mcimadamore at openjdk.org  Tue Aug 29 10:43:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Aug 2023 10:43:10 GMT
Subject: RFR: 8315134: javac inference seems to be capturing types
 incorrectly
In-Reply-To: <ec5ULNMrIyw7xUNuEwW-40v5DUVZf_AublVeJcImqQY=.b37c33bc-c2b0-4f2a-b5cd-a0f1c14a2e12@github.com>
References: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>
 <ec5ULNMrIyw7xUNuEwW-40v5DUVZf_AublVeJcImqQY=.b37c33bc-c2b0-4f2a-b5cd-a0f1c14a2e12@github.com>
Message-ID: <kdf9XKZhAQLsMnzw4M4capSXa5s04egEh8BHQoB4jtI=.9fe5047b-c636-463a-93ba-31d4ee238339@github.com>

On Tue, 29 Aug 2023 10:37:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> But this is unsound.

A "more correct" solution would be to treat the supertype derivation as an inference problem - e.g. posit that given `Foo<?>` that is some supertype `Sup<Foo<alpha>>`, where `alpha` is an inference variable (likely with some `capture` constraints). But, needless to say, this requires a lot of spec (and compiler) work to get right.

Anyway, for the time being, as I suggested last time, I believe the best course of action is to do nothing, and treat this as a "known issue".

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

PR Comment: https://git.openjdk.org/jdk/pull/15463#issuecomment-1697191037

From acobbs at openjdk.org  Tue Aug 29 15:45:20 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 29 Aug 2023 15:45:20 GMT
Subject: RFR: 8268622: Performance issues in javac `Name` class
Message-ID: <aFRsuubILSfwcPChu3GtRnL2H-kRkQicJpml9M9HIQ4=.dfca4fd6-43bc-428b-855c-1f20e948ca1d@github.com>

Quoting [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622):
> The javadoc team has identified performance issues in the javac `Name` class, particularly when it is used via its `CharSequence` interface ([JDK-8263321](https://bugs.openjdk.org/browse/JDK-8263321)). The main issue there is that the `CharSequence` is specifically character-oriented, whereas the native form inside javac is a byte[] in modified-UTF8 form. Operations like `.length()` and `.charAt(int)` have "simple" but very inefficient implementations.

Thanks to [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) we now have the option to swap in a `String`-based `Name` table implementation in place of the current UTF-8-based one. This does in fact improve performance of the compiler.

This patch does two things:
* Make the `String`-based `Name` table implementation the default. The two other UTF-8-based implementations are still available via the flags `-XDuseUnsharedTable=true` and `-XDuseSharedTable=true` (the latter was the previous default). This results in a 19% speedup in my simple benchmark (see below).
* Adds a new flag `-XDinternStringTable=true`, which turns on `intern()`ing of the `String`s in the `String` table. This however is **not** the default because it results in lower performance (see below). But it's possible this could help in other scenarios so it's left in there for future testing purposes.

Here are results from the [JavacNameTable.java](https://github.com/openjdk/jdk/files/12466359/JavacNameTable.java.txt) benchmark.

Benchmark                             Mode  Cnt   Score   Error  Units
JavacNameTable.testSharedTable        avgt   25  54.145 ? 1.738  ms/op
JavacNameTable.testStringTable        avgt   25  45.305 ? 0.415  ms/op
JavacNameTable.testStringTableIntern  avgt   25  50.736 ? 0.245  ms/op
JavacNameTable.testUnsharedTable      avgt   25  59.877 ? 2.503  ms/op

To reiterate: `testSharedTable` reflects the previous default; `testStringTable` reflects the new default. The other two options are available via the flags `-XDinternStringTable=true` and `-XDuseUnsharedTable=true`.

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

Commit messages:
 - Change the default Name table implementation to StringNameTable.

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

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

From vromero at openjdk.org  Tue Aug 29 16:17:11 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 29 Aug 2023 16:17:11 GMT
Subject: RFR: 8315134: javac inference seems to be capturing types
 incorrectly
In-Reply-To: <kdf9XKZhAQLsMnzw4M4capSXa5s04egEh8BHQoB4jtI=.9fe5047b-c636-463a-93ba-31d4ee238339@github.com>
References: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>
 <ec5ULNMrIyw7xUNuEwW-40v5DUVZf_AublVeJcImqQY=.b37c33bc-c2b0-4f2a-b5cd-a0f1c14a2e12@github.com>
 <kdf9XKZhAQLsMnzw4M4capSXa5s04egEh8BHQoB4jtI=.9fe5047b-c636-463a-93ba-31d4ee238339@github.com>
Message-ID: <YqgOH3hf0Mnv9Pvz1py1TMCHk0zWHLu5A3htEvqtP1E=.458609d7-af5e-4141-8217-ea795210f15d@github.com>

On Tue, 29 Aug 2023 10:40:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > But this is unsound.
> 
> A "more correct" solution would be to treat the supertype derivation as an inference problem - e.g. posit that given `Foo<?>` that is some supertype `Sup<Foo<alpha>>`, where `alpha` is an inference variable (likely with some `capture` constraints). But, needless to say, this requires a lot of spec (and compiler) work to get right.
> 
> Anyway, for the time being, as I suggested last time, I believe the best course of action is to do nothing, and treat this as a "known issue".

Ok, I forgot about the previous discussion, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/15463#issuecomment-1697759246

From vromero at openjdk.org  Tue Aug 29 16:20:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 29 Aug 2023 16:20:22 GMT
Subject: RFR: 8315134: javac inference seems to be capturing types
 incorrectly
In-Reply-To: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>
References: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>
Message-ID: <K4xhhmDnqSD_y3e-UKuP5pNcYVSmo2N-bFAlQRPVF6w=.c9eb450c-3a66-4112-a687-2e2e8298b308@github.com>

On Tue, 29 Aug 2023 03:20:52 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this code:
> 
> 
> import java.util.*;
> 
> public class Test {
>     private static <T> void arrayMethod(List<? super T>[] args) {
>         listMethod(Arrays.asList(args));
>     }
> 
>     private static <T> void listMethod(List<List<? super T>> list) {}
> }
> 
> 
> is being rejected by the compiler. This code should be accepted according to the spec. The compiler is doing a capture conversion that is not mentioned in the spec while reducing subtyping constraints during type inference. This fix is syncing the compiler with the spec.
> 
> TIA

the issue is a duplicate of [JDK-8206142](https://bugs.openjdk.org/browse/JDK-8206142) at that instance we decided to wait for the related spec to be finished. Closing this PR as this is a known issue we won't fix for the time being

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

PR Comment: https://git.openjdk.org/jdk/pull/15463#issuecomment-1697764600

From vromero at openjdk.org  Tue Aug 29 16:20:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 29 Aug 2023 16:20:22 GMT
Subject: Withdrawn: 8315134: javac inference seems to be capturing types
 incorrectly
In-Reply-To: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>
References: <HbXrL-yFmFXcSp1sOh0NzsLmgI5xVYQnlsreSckE8jw=.41d1524b-4954-4451-95d5-f31d8bcd1a6d@github.com>
Message-ID: <YGZI3f6BtSpi5cqW_kkVQFhXJgwGOQXyD2py9mYIwso=.67f12635-2e82-4c16-8aa8-6981ac90c114@github.com>

On Tue, 29 Aug 2023 03:20:52 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this code:
> 
> 
> import java.util.*;
> 
> public class Test {
>     private static <T> void arrayMethod(List<? super T>[] args) {
>         listMethod(Arrays.asList(args));
>     }
> 
>     private static <T> void listMethod(List<List<? super T>> list) {}
> }
> 
> 
> is being rejected by the compiler. This code should be accepted according to the spec. The compiler is doing a capture conversion that is not mentioned in the spec while reducing subtyping constraints during type inference. This fix is syncing the compiler with the spec.
> 
> TIA

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.org  Wed Aug 30 00:32:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 30 Aug 2023 00:32:27 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo
Message-ID: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>

Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.

Full details in the JBS issue and comments.

There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.

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

Commit messages:
 - JDK-8315248: AssertionError in Name.compareTo

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

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

From vromero at openjdk.org  Wed Aug 30 02:15:13 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 30 Aug 2023 02:15:13 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo
In-Reply-To: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
Message-ID: <LWLHc5-Q99t1GU1suLtG4VDeEuOzs5bp2R2lBCFX7hQ=.212c7d12-bd92-4265-8036-5291a97edac0@github.com>

On Wed, 30 Aug 2023 00:25:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.
> 
> Full details in the JBS issue and comments.
> 
> There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.

looks good

test/langtools/tools/javac/nametable/TestNameTables.java line 87:

> 85: 
> 86:     /**
> 87:      * Tests operations using a single name tbale

typo: tbale

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15478#pullrequestreview-1601755951
PR Review Comment: https://git.openjdk.org/jdk/pull/15478#discussion_r1309536739

From acobbs at openjdk.org  Wed Aug 30 13:35:10 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 30 Aug 2023 13:35:10 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo
In-Reply-To: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
Message-ID: <IuD1nYSCWV3jYI0yxxW6bffwFrGk9i206nmstl1MDrc=.f30020d9-6148-4ec3-981f-d7e6d5509517@github.com>

On Wed, 30 Aug 2023 00:25:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.
> 
> Full details in the JBS issue and comments.
> 
> There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.

This definitely works. However, if a class `X` implements `Comparable`, by definition instances must be able to `compareTo()` themselves with any other instance of type `X` (even if `X` is an interface - so this is a pretty major imposition that any class or interface implementing `Comparable` imposes on all subtypes, present, past, and future).

In this case, it is `Name` that implements `Comparable`, and `Utf8NameTable.NameImpl`'s version of `compareTo()` is just as an overriding optimization of `Name.compareTo()`, which does in fact work in all cases.

So it seems like the "truly correct" thing to do here would be something like this:

// Utf8NameTable.NameImpl.compareTo()
@Override
public int compareTo(Name name0) {
    NameImpl name;
    try {
        name = (NameImpl)name0;
    } catch (ClassCastException e) {
        return super.compareTo(name0);
    }
    byte[] buf1 = getByteData();
    ...etc...

This probably doesn't matter in practice, but just wanted to point out the theoretical argument.

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

PR Comment: https://git.openjdk.org/jdk/pull/15478#issuecomment-1699184276

From jjg at openjdk.org  Wed Aug 30 15:15:08 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 30 Aug 2023 15:15:08 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo
In-Reply-To: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
Message-ID: <UyYqC_0jssvHJqFb6OsDwfQVIBTZOU-8nTFl0uRJWfg=.d208cc40-4242-4d1a-ad29-cc205b0292db@github.com>

On Wed, 30 Aug 2023 00:25:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.
> 
> Full details in the JBS issue and comments.
> 
> There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.

> This definitely works. However, if a class `X` implements `Comparable`, by definition instances must be able to `compareTo()` themselves with any other instance of type `X` (even if `X` is an interface - so this is a pretty major imposition that any class or interface implementing `Comparable` imposes on all subtypes, present, past, and future).
> 
> In this case, it is `Name` that implements `Comparable`, and `Utf8NameTable.NameImpl`'s version of `compareTo()` is just as an overriding optimization of `Name.compareTo()`, which does in fact work in all cases.
> 
> So it seems like the "truly correct" thing to do here would be something like this:
> 
> ```java
> // Utf8NameTable.NameImpl.compareTo()
> @Override
> public int compareTo(Name name0) {
>     NameImpl name;
>     try {
>         name = (NameImpl)name0;
>     } catch (ClassCastException e) {
>         return super.compareTo(name0);
>     }
>     byte[] buf1 = getByteData();
>     ...etc...
> ```
> 
> This probably doesn't matter in practice, but just wanted to point out the theoretical argument.

Noted; thanks. Since we're editing the code, I'll fix it.
It's notable that the test works with all combinations of `Name` but it is protected by the code in `CharSequence.compare`

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

PR Comment: https://git.openjdk.org/jdk/pull/15478#issuecomment-1699367173

From prappo at openjdk.org  Wed Aug 30 16:42:30 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 30 Aug 2023 16:42:30 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't recognize a
 tag
Message-ID: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>

This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.

Before:


MyClass.java:4: warning: no main description
 * @implSpite {@linkpain Object#hashCode}}
   ^
MyClass.java:4: error: unknown tag: implSpite
 * @implSpite {@linkpain Object#hashCode}}
   ^
MyClass.java:4: error: unknown tag: linkpain
 * @implSpite {@linkpain Object#hashCode}}
              ^
MyClass.java:5: error: unknown tag: danger
 * @danger
   ^


After:


 * @implSpite {@linkpain Object#hashCode}}
   ^
MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
 * @implSpite {@linkpain Object#hashCode}}
   ^
Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
 * @implSpite {@linkpain Object#hashCode}}
              ^
MyClass.java:5: error: unknown tag: danger
 * @danger
   ^


As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.

For details, see the actual change.

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

Commit messages:
 - Initial commit

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

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

From jjg at openjdk.org  Wed Aug 30 17:52:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 30 Aug 2023 17:52:55 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo [v2]
In-Reply-To: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
Message-ID: <hpT-svfvBKeXhQ2hKXf3AiMS0TTi1bMdt0H396vqYOY=.d639f450-e481-40f0-9da7-fd07477a525c@github.com>

> Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.
> 
> Full details in the JBS issue and comments.
> 
> There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15478/files
  - new: https://git.openjdk.org/jdk/pull/15478/files/54f4ea61..f016195f

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

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

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

From vromero at openjdk.org  Wed Aug 30 17:59:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 30 Aug 2023 17:59:26 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo [v2]
In-Reply-To: <hpT-svfvBKeXhQ2hKXf3AiMS0TTi1bMdt0H396vqYOY=.d639f450-e481-40f0-9da7-fd07477a525c@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
 <hpT-svfvBKeXhQ2hKXf3AiMS0TTi1bMdt0H396vqYOY=.d639f450-e481-40f0-9da7-fd07477a525c@github.com>
Message-ID: <4t9ABxzTf10T6z1GmEO2evh4c5sF89IcvbabnZyzhpw=.107202ea-7d29-4e1a-b461-fe7c1d8a44a1@github.com>

On Wed, 30 Aug 2023 17:52:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.
>> 
>> Full details in the JBS issue and comments.
>> 
>> There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

last changes look good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15478#pullrequestreview-1603231052

From jjg at openjdk.org  Wed Aug 30 18:02:26 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 30 Aug 2023 18:02:26 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo
In-Reply-To: <UyYqC_0jssvHJqFb6OsDwfQVIBTZOU-8nTFl0uRJWfg=.d208cc40-4242-4d1a-ad29-cc205b0292db@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
 <UyYqC_0jssvHJqFb6OsDwfQVIBTZOU-8nTFl0uRJWfg=.d208cc40-4242-4d1a-ad29-cc205b0292db@github.com>
Message-ID: <B8l_U7Ikxn4iPaKAJGkQThpiIKPbZTWWVkL-cyw0a_w=.b22501fc-daa9-4f01-b724-7165504e89d7@github.com>

On Wed, 30 Aug 2023 15:10:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>     NameImpl name;
>     try {
>         name = (NameImpl)name0;
>     } catch (ClassCastException e) {
>         return super.compareTo(name0);
>     }

See the updated code for a revised, more concise, suggestion using `instanceof` pattern.

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

PR Comment: https://git.openjdk.org/jdk/pull/15478#issuecomment-1699615531

From acobbs at openjdk.org  Wed Aug 30 18:05:25 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 30 Aug 2023 18:05:25 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo
In-Reply-To: <B8l_U7Ikxn4iPaKAJGkQThpiIKPbZTWWVkL-cyw0a_w=.b22501fc-daa9-4f01-b724-7165504e89d7@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
 <UyYqC_0jssvHJqFb6OsDwfQVIBTZOU-8nTFl0uRJWfg=.d208cc40-4242-4d1a-ad29-cc205b0292db@github.com>
 <B8l_U7Ikxn4iPaKAJGkQThpiIKPbZTWWVkL-cyw0a_w=.b22501fc-daa9-4f01-b724-7165504e89d7@github.com>
Message-ID: <gugDjoRlQhZe28zXf-m6zxXkD6PSnERGDFamU67I2s0=.88fd0201-7ca4-42ad-adc9-a2f8848a9a03@github.com>

On Wed, 30 Aug 2023 17:59:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> See the updated code for a revised, more concise, suggestion using instanceof pattern.

?

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

PR Comment: https://git.openjdk.org/jdk/pull/15478#issuecomment-1699618939

From jjg at openjdk.org  Wed Aug 30 21:55:31 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 30 Aug 2023 21:55:31 GMT
Subject: Integrated: JDK-8315248: AssertionError in Name.compareTo
In-Reply-To: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
Message-ID: <b6_4i8aOsXoqnq9YS29Rf0gsTyJ86Xrnunht24E3kro=.6151029c-5bd1-4c72-bb52-0d75e06982d6@github.com>

On Wed, 30 Aug 2023 00:25:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.
> 
> Full details in the JBS issue and comments.
> 
> There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.

This pull request has now been integrated.

Changeset: df5e6e5d
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df5e6e5d482e70b33612639b3c1c04eaa1ed361e
Stats:     158 lines in 2 files changed: 142 ins; 9 del; 7 mod

8315248: AssertionError in Name.compareTo

Reviewed-by: vromero

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

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

From duke at openjdk.org  Wed Aug 30 23:46:17 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 30 Aug 2023 23:46:17 GMT
Subject: RFR: JDK-8315248: AssertionError in Name.compareTo [v2]
In-Reply-To: <hpT-svfvBKeXhQ2hKXf3AiMS0TTi1bMdt0H396vqYOY=.d639f450-e481-40f0-9da7-fd07477a525c@github.com>
References: <J7FS-0A6HMDxh5lgtO47B4ijc9gwpxRWuCn79963kQM=.01ec2d06-af62-429f-a6f6-dba279695c6a@github.com>
 <hpT-svfvBKeXhQ2hKXf3AiMS0TTi1bMdt0H396vqYOY=.d639f450-e481-40f0-9da7-fd07477a525c@github.com>
Message-ID: <ubOnTza2_720RJKmferhEu_keGzHG5tpCgL8_9gM41s=.4683e895-5eaa-4bb9-8173-bcaf062708dd@github.com>

On Wed, 30 Aug 2023 17:52:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.
>> 
>> Full details in the JBS issue and comments.
>> 
>> There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Utf8NameTable.java line 116:

> 114:                 return Convert.utf2string(getByteData(), getByteOffset(), getByteLength(), Convert.Validation.NONE);
> 115:             } catch (InvalidUtfException e) {
> 116:                 throw new AssertionError("invalid UTF8 data", e);

Note?that this?can simply?use `throw?new?AssertionError(e)`, as?the?`AssertionError(Object)` constructor?calls `Throwable::initCause` when?the?`Object`?parameter is?a?`Throwable`:
https://github.com/openjdk/jdk/blob/3c8a6678feac8e3225bc1c44593a78d9e7c4d77c/src/java.base/share/classes/java/lang/AssertionError.java#L74-L78

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15478#discussion_r1310950231

From hannesw at openjdk.org  Thu Aug 31 09:07:01 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 31 Aug 2023 09:07:01 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag
In-Reply-To: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
Message-ID: <dLJjvTQynmY80yBDpvjMb5zFavQ3zjjx4lxcvbwTYvw=.de847fe5-c7e0-457d-aa34-91224a2f9443@github.com>

On Wed, 30 Aug 2023 16:34:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
> 
> Before:
> 
> 
> MyClass.java:4: warning: no main description
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: linkpain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> After:
> 
> 
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
> 
> For details, see the actual change.

I really like this feature, but my immediate reaction is to also worry about decreased readability caused by increased verbosity. Some ideas:

 - `the most similar tags are: ...` is quite long, and there are now 4 colon characters in that message line. Maybe the message could be something like `unknown tag implSpite, did you mean implSpec, implNote`?
 - The `Note: An unknown tag has been reported...` message after the first unrecognized tag is a bit disruptive. I'm not sure it is needed, and if we want it maybe it should be at the end of the output? I have an open JBS issue to [generate a final message if any invalid input was encountered](https://bugs.openjdk.org/browse/JDK-8296175), maybe this would also benefit from such handling?

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

PR Comment: https://git.openjdk.org/jdk/pull/15494#issuecomment-1700648869

From prappo at openjdk.org  Thu Aug 31 10:40:01 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 31 Aug 2023 10:40:01 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag
In-Reply-To: <dLJjvTQynmY80yBDpvjMb5zFavQ3zjjx4lxcvbwTYvw=.de847fe5-c7e0-457d-aa34-91224a2f9443@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
 <dLJjvTQynmY80yBDpvjMb5zFavQ3zjjx4lxcvbwTYvw=.de847fe5-c7e0-457d-aa34-91224a2f9443@github.com>
Message-ID: <vS8y_BNkmzL5GjnVoNfhxnk57p2FFAySdcScZMnujmo=.4f19c70f-e4fc-49c9-b8f2-a5d35f312b3f@github.com>

On Thu, 31 Aug 2023 09:04:29 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> I really like this feature, but my immediate reaction is to also worry about decreased readability caused by increased verbosity. Some ideas:
> 
> * `the most similar tags are: ...` is quite long, and there are now 4 colon characters in that message line. Maybe the message could be something like `unknown tag implSpite, did you mean implSpec, implNote?`?
> * The `Note: An unknown tag has been reported...` message after the first unrecognized tag is a bit disruptive. I'm not sure it is needed, and if we want it maybe it should be at the end of the output? I have an open JBS issue to [generate a final message if any invalid input was encountered](https://bugs.openjdk.org/browse/JDK-8296175), maybe this would also benefit from such handling?

We can shorten both messages, but we have to make sure that the error reads clear on its own and both error and "Note" read well when combined. In particular, "Note" shouldn't provide information the error has already provided.

An orthogonal way to shorten the error would be to remove the tag name: we already have a caret (`^`) pointing to that tag in source. That said, it's not just these errors that duplicate information this way, it's many other errors in DocLint and to a lesser extent in JavaDoc.  

On ordering of "Note". When I showed this change to @jonathan-gibbons offline, before making it a PR, I had "Note" in the trailing position, much like the JBS proposal you linked to. To me it was natural: that's what I see first in my terminal. However, Jon noted that it might be better if "Note" followed the first relevant error, because that's how bugs from compiler and similar tools are generally fixed: you fix the first error, which might have caused all the following errors. So, I repositioned "Note".

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

PR Comment: https://git.openjdk.org/jdk/pull/15494#issuecomment-1700791590

From abimpoudis at openjdk.org  Thu Aug 31 12:41:28 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 31 Aug 2023 12:41:28 GMT
Subject: RFR: 8314632: Intra-case dominance check fails in the presence of a
 guard
Message-ID: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>

Intra-case domination should be affected by the presence of a guard. A missing check in dominance ensures that requirement.

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

Commit messages:
 - 8314632: Intra-case dominance check fails in the presence of a guard

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

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

From jlahoda at openjdk.org  Thu Aug 31 14:34:20 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 31 Aug 2023 14:34:20 GMT
Subject: RFR: 8315452: Erroneous AST missing modifiers for partial input
Message-ID: <MwFsK7_HiGixnwbQDVdzAzLBWmjIc0nY4SmfxCFdiOU=.1360bc70-379d-46a7-8041-be30167e5e15@github.com>

Consider code like:

package test;
public


Before [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), this was producing an AST which included the package clause + an ErroneousTree, which contained the `public` as partial modifiers.

After [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), the `public` is no longer included in the AST, and hence it is invisible for tools that operate on the AST.

My proposal is to return the `public` back to the AST. Seems that the problem from [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671) can be solved by breaking out of the outter loop, instead of inner loop, as it was before [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), without affecting non-eof situations.

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

Commit messages:
 - 8315452: Erroneous AST missing modifiers for partial input

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

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

From vromero at openjdk.org  Thu Aug 31 15:55:59 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Aug 2023 15:55:59 GMT
Subject: RFR: 8314632: Intra-case dominance check fails in the presence of
 a guard
In-Reply-To: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
References: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
Message-ID: <FrC7OAZWjXGGsu0v_-Jfv5sVPbdHefa62ojFubjJWTI=.1a1e7d25-4bab-4a03-b746-00b8813c04f3@github.com>

On Thu, 31 Aug 2023 12:33:26 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Intra-case domination should be affected by the presence of a guard. A missing check in dominance ensures that requirement.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15515#pullrequestreview-1605090405

From jlahoda at openjdk.org  Thu Aug 31 16:07:03 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 31 Aug 2023 16:07:03 GMT
Subject: RFR: 8314632: Intra-case dominance check fails in the presence of
 a guard
In-Reply-To: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
References: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
Message-ID: <MH36TXoXnyqskdk0d7uNGzr2QBW3EUBmkn7GtpUTX7k=.712de423-a397-48b8-a150-b46717bd73c4@github.com>

On Thu, 31 Aug 2023 12:33:26 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Intra-case domination should be affected by the presence of a guard. A missing check in dominance ensures that requirement.

Overall, looks good to me, but please see the inline comment. Thanks!

test/langtools/tools/javac/patterns/T8314632.java line 23:

> 21:  * questions.
> 22:  */
> 23: /*

For tests with golden files, we typically don't use a license header, and use `/nodynamiccopyright/` after `@test`. This is because the line numbers are important, and the test would fail if the license header would change.

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

Changes requested by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15515#pullrequestreview-1605123935
PR Review Comment: https://git.openjdk.org/jdk/pull/15515#discussion_r1311863936

From jjg at openjdk.org  Thu Aug 31 23:10:44 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 31 Aug 2023 23:10:44 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag
In-Reply-To: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
Message-ID: <8_G5gpcVht07JAN_rgR2gNYrTJUtgmpsYKmLqsqlXJo=.7578edf6-119b-48e4-8e87-eb2dfd526433@github.com>

On Wed, 30 Aug 2023 16:34:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
> 
> Before:
> 
> 
> MyClass.java:4: warning: no main description
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: linkpain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> After:
> 
> 
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
> 
> For details, see the actual change.

I like the detection for misspellings.
I'm less convinced (at this time) by the helpful suggestion, but maybe it would eventually be OK when viewed in the context of a broader effort to give help hints, with some stylistic consistency as to their format.

I wonder if it would be interesting to treat helpful hints as a subcategory of notes so that all hints can be enabled or disabled with a single option. (i.e. we shouldn't change the distinction of `error`/`warning`/`note` but we might want to be able to identify "all hints", perhaps by a convention in the key name, etc.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 122:

> 120: doclet.UnknownTagWithHint={0} is an unknown tag; the most similar tags are: {1}
> 121: doclet.UnknownTagHelp=An unknown tag has been reported. Mistyped? \
> 122:   Forgot to add a custom tag or register a taglet?

This is a bit terse. I'd suggest to split it in two lines, the first containing a statement of fact. (`An unknown tag has been reported.`), and the second containing a more complete helpful sentence, such as "Did you mistype it, or forget to add a custom tag, or register a taglet?"

I know I suggested posting the message early, but if you post it at the end, it could be more of a summary, such as "5 different tags were reported 105 times; did you ..."

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 380:

> 378: 
> 379:     public static List<String> suggestSimilar(Collection<String> knownTags, String unknownTag) {
> 380:         final double MIN_SIMILARITY = 2.0 / 3;

Is there significance in `2.0 / 3` as compared to `0.667` etc

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 90:

> 88: dc.tag.unknown.with.hint = unknown tag: {0}; the most similar tags are: {1}
> 89: dc.tag.unknown.help = An unknown tag has been reported. Mistyped? \
> 90:   Forgot to add a custom tag or register a taglet?

Mild uugh at duplicate strings; maybe it's OK for now but is another reason to consolidate docent/javadoc behavior.

test/langtools/jdk/javadoc/doclet/testUknownTags/TestUnknownTags.java line 125:

> 123:                 package x;
> 124: 
> 125:                 /**

:-) I bet the spelling checker in the IDE loves this :-)

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

PR Review: https://git.openjdk.org/jdk/pull/15494#pullrequestreview-1605878689
PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1312362450
PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1312363282
PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1312365309
PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1312365775