From duke at openjdk.org  Mon Jan  1 17:12:59 2024
From: duke at openjdk.org (Romain Manni-Bucau)
Date: Mon, 1 Jan 2024 17:12:59 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
Message-ID: <wWXJ8ylVKFhTYvM_0xWk0m-4kCiEM25up1wPrEExU_E=.90d8f8ed-e14e-430f-ade9-c1e332f6ec94@github.com>

On Fri, 6 Oct 2023 21:55:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos.

Think there is some reasoning shortcut taken there.
The will to avoid to enable annotation processor when not needed is sane and I agree we regularly see apps enabling some of them without needing due to the dependency game/abuse.

That said it would be welcomed to take into account 3 points and not only postpone because the community kind of reject this shift - otherwise it will happen again in a few years:

1. Discovery is needed and enable a loose coupling between processor and applications (referencing the class is not great and couple the provider of the processor with all apps setup, this is undesired until a notion of alias is added to annot proc but not sure it is needed).
2. Warning undesired setup (enablement when not needed) is a good thing, if there is a too high cost (`ServiceLoader` one is not since any run will likely trigger a lot of `getResources` and it is fine, even just plain `ToolProvider` to get `javac`) then defaulting to a mode where run fails is better than disabling blindly (`-proc:failIfOverhead` - indeed a better name is welcomed). That said, due to javac code this is hardly explanable so it would better be "fail if explicitly enabled and unused, warn if unused and implicitly enabled" so pretty close to what we have for years and everyone was happy with but a bit stricter for future uses.
3. Annotation processing is a great Javac feature and I don't think it is an option to make it "hard"/verbose to setup (2 maven executions of compiler plugin for example which would make people using it even slower and harder to setup - incremental support is not trivial for people not understanding what happens under the hood).
4. Annotation processing is far to be dead, debatable probably but lombok, immutables, JPA, dagger, (google) auto, jmh, mapstruct, fusion, ... are good example of very living libraries with some serious user base (records don't solve all issues ;)).
5. Annotation processing is a neat way to solve the reflection challenges `native-image` (graalvm) brings.
6. If the generation is not part of the main compilation cycle it enforces to use 2 "load the model" cycle which is often slower (due to the model loading but also the fact it will not use javac internals to rely on a stable API so in terms of classloading it will be worse, in particular in modular systems like maven).
7. All the point about disabling it are security related but this is the wrong way to fix the security of the build for most builds (all using a dependency manager like ivy/gradle, maven/aether cause these builds will keep all the mentionned issues if they don't use the dependency validation which must be done at build level (by design it cant be done at javac level).

So overall the original statements should be (in)validated and if there is really an issue using `ServiceLoader` maybe switch to a better SPI option (better to request tools/producers to adjust than consumers) rather than disabling the discovery feature.

Side note: not great for users but acceptable if the will is really to disable the discovery, keeping the `full` flag could be an accepable compromise IMHO.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1873404178

From jlahoda at openjdk.org  Tue Jan  2 11:17:53 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 2 Jan 2024 11:17:53 GMT
Subject: Integrated: 8322159: ThisEscapeAnalyzer crashes for erroneous code
In-Reply-To: <jst9pel7lJIEd8c8-v5hnw5KwPN65_Vutrfim0xD7VM=.1a2d0f6d-26e2-4168-a167-1bc3a402f9e1@github.com>
References: <jst9pel7lJIEd8c8-v5hnw5KwPN65_Vutrfim0xD7VM=.1a2d0f6d-26e2-4168-a167-1bc3a402f9e1@github.com>
Message-ID: <Q9FZJnwFssFgKgpAqvym3hSO-S9rWtqdbKdY6bzrJXk=.781d5662-8958-4ce6-9c97-ffa91bc9996b@github.com>

On Fri, 15 Dec 2023 08:10:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When an unresolvable method is used in the code, the model is a bit strange (and not very easy to fix) - for method invocations, the symbol used is actually a `ClassSymbol` instead of `MethodSymbol`, and method references have fields like `kind` unfilled.
> 
> This is causing issues in ThisEscapeAnalyzer when there were unresolvable methods, and the analyzer is called (i.e. in practice when running with `-Xlint:this-escape -XDshould-stop.at=FLOW`, or similar):
>  - `visitApply` has a hardcoded cast to `MethodSymbol`. Seems the case in not really necessary, so the proposal is to remove it.
>  - `visitReference` crashes on an access to `JCMemberReference.kind`, as it is unfilled. The proposal is to skip the check if the method reference's type is errneous.

This pull request has now been integrated.

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

8322159: ThisEscapeAnalyzer crashes for erroneous code

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Tue Jan  2 12:37:58 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 2 Jan 2024 12:37:58 GMT
Subject: [jdk22] RFR: 8322159: ThisEscapeAnalyzer crashes for erroneous code
Message-ID: <W0kG7mO0T3nzSuq051cg0Ljx2uo2BMArDgVXgDje1kU=.8888df7d-9ae9-44ce-8121-434e9a758e5d@github.com>

Hi all,

This pull request contains a backport of commit [7455b1b5](https://github.com/openjdk/jdk/commit/7455b1b527568aff5b1c16a29fd80b05260c0fad) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 2 Jan 2024 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport 7455b1b527568aff5b1c16a29fd80b05260c0fad

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

PR: https://git.openjdk.org/jdk22/pull/26

From duke at openjdk.org  Tue Jan  2 14:40:57 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 2 Jan 2024 14:40:57 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v7]
In-Reply-To: <kYSgsC4nPB3FutKh6PkZX1NN9KM0P4_wJrIr6O76HCo=.2237db66-faad-4e68-9331-11d224b04efc@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <L0_Ei1bTc-gWLNiYIQRA8XPF6X4tLBhLbQ2fnzWUbNY=.dbab6e4a-2ba1-4ad2-88a0-3bbab11dcd84@github.com>
 <kYSgsC4nPB3FutKh6PkZX1NN9KM0P4_wJrIr6O76HCo=.2237db66-faad-4e68-9331-11d224b04efc@github.com>
Message-ID: <FQA62Gjq7_8ZZ77jemgSEDrWwejE9ZQM_qpnksBLnlY=.fe2818a2-7293-4260-9eaf-cbdf581f3a5e@github.com>

On Tue, 21 Feb 2023 17:06:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to Object.hashCode
>
> FYI, the PR has been withdrawn for now, pending additional design discussions.

Thank you so much for the work @jonathan-gibbons and @lahodaj (for the jshell part).

I can see the need for an universal solution allow to handle both Markdown and ASCIIDoc. However, offering Markdown would be a huge improvement compared to the existing solution (having to use HTML and IDE support took a long time to fix "trivial" things - e.g., proper HTML reformat https://youtrack.jetbrains.com/issue/IDEA-147601).

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

PR Comment: https://git.openjdk.org/jdk/pull/11701#issuecomment-1874106337

From jlahoda at openjdk.org  Tue Jan  2 15:05:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 2 Jan 2024 15:05:57 GMT
Subject: RFR: 8322003: JShell - Incorrect type inference in lists of records
 implementing interfaces
Message-ID: <itoHqy3lZW-6CYigYTX7vrywHxn5BOn0C6rqmRW0-vQ=.f27194a5-06a3-4f61-8115-f62b2803ac8e@github.com>

Consider JShell snippet like:

var v = List.of("", 0);


The type of `v` is along the lines of `List<Serializable&Comparable<? extends Serializable&Comparable<?>&java.lang.constant.Constable&java.lang.constant.ConstantDesc>&java.lang.constant.Constable&java.lang.constant.ConstantDesc>` - i.e. a List with an intersection type as a type argument.

The problem is that JShell compiles snippets separately in separate classes. And hence `v` is upgraded to a field. But, the field cannot have the above non-denotable type, so its type is demoted to `List<Serializable>`. When the field is read when a subsequent snippet is processed, JShell tries to reconstitute the type, but a type with an intersection type as a type argument cannot be parsed by the parser. As a consequence, continuing with the example above:

jshell> List<java.lang.constant.Constable> l = v;
|  Error:
|  incompatible types: java.util.List<java.io.Serializable> cannot be converted to java.util.List<java.lang.constant.Constable>
|  List<java.lang.constant.Constable> l = v;
|                                         ^


The proposed solution here is to enhance the parser used by JShell so that it can parse intersection types at any position. JShell then can reconstitute the type, and the above snippets work:

jshell> var v = List.of("", 0);
v ==> [, 0]

jshell> List<java.lang.constant.Constable> l = v;
l ==> [, 0]

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

Commit messages:
 - 8322003: JShell - Incorrect type inference in lists of records implementing interfaces

Changes: https://git.openjdk.org/jdk/pull/17223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17223&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322003
  Stats: 121 lines in 3 files changed: 87 ins; 11 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17223/head:pull/17223

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

From darcy at openjdk.org  Tue Jan  2 22:33:55 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Jan 2024 22:33:55 GMT
Subject: RFR: JDK-8322248: Fix inconsistent wording in ElementFilter.typesIn
Message-ID: <87cdXflxg25vKZKLqzzq8_ViaTRmQP1MaEage4_2t2U=.30478712-609f-40b1-a2db-e5ee9cb3d51d@github.com>

Correct small oversight made during the fix for

    JDK-8257638: Update usage of "type" terminology in javax.lang.model

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

Commit messages:
 - JDK-8322248: Fix inconsistent wording in ElementFilter.typesIn

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

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

From jjg at openjdk.org  Tue Jan  2 22:33:56 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 2 Jan 2024 22:33:56 GMT
Subject: RFR: JDK-8322248: Fix inconsistent wording in
 ElementFilter.typesIn
In-Reply-To: <87cdXflxg25vKZKLqzzq8_ViaTRmQP1MaEage4_2t2U=.30478712-609f-40b1-a2db-e5ee9cb3d51d@github.com>
References: <87cdXflxg25vKZKLqzzq8_ViaTRmQP1MaEage4_2t2U=.30478712-609f-40b1-a2db-e5ee9cb3d51d@github.com>
Message-ID: <0H1AEAl92b-7tN6HFqEtcNa7Qx9bbkyZ4XmnNlEx1eY=.3d8bbd94-fdfa-4116-af03-8ff896fd773d@github.com>

On Tue, 2 Jan 2024 22:28:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Correct small oversight made during the fix for
> 
>     JDK-8257638: Update usage of "type" terminology in javax.lang.model

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17231#pullrequestreview-1801170498

From iris at openjdk.org  Tue Jan  2 22:53:46 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 2 Jan 2024 22:53:46 GMT
Subject: RFR: JDK-8322248: Fix inconsistent wording in
 ElementFilter.typesIn
In-Reply-To: <87cdXflxg25vKZKLqzzq8_ViaTRmQP1MaEage4_2t2U=.30478712-609f-40b1-a2db-e5ee9cb3d51d@github.com>
References: <87cdXflxg25vKZKLqzzq8_ViaTRmQP1MaEage4_2t2U=.30478712-609f-40b1-a2db-e5ee9cb3d51d@github.com>
Message-ID: <llNsEqyyEHHk1Zi5vnAIRKxT6rV4FL9_Jrp-Vuvn0oo=.5a9904ca-7925-4943-9d28-4fe315973596@github.com>

On Tue, 2 Jan 2024 22:28:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Correct small oversight made during the fix for
> 
>     JDK-8257638: Update usage of "type" terminology in javax.lang.model

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17231#pullrequestreview-1801184493

From darcy at openjdk.org  Tue Jan  2 23:08:52 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Jan 2024 23:08:52 GMT
Subject: Integrated: JDK-8322248: Fix inconsistent wording in
 ElementFilter.typesIn
In-Reply-To: <87cdXflxg25vKZKLqzzq8_ViaTRmQP1MaEage4_2t2U=.30478712-609f-40b1-a2db-e5ee9cb3d51d@github.com>
References: <87cdXflxg25vKZKLqzzq8_ViaTRmQP1MaEage4_2t2U=.30478712-609f-40b1-a2db-e5ee9cb3d51d@github.com>
Message-ID: <N2kT1Ryb4vm0keT_LlO3Q0S1ePuzqMvtRojJkyY3RaM=.807b3c08-bde5-4cb2-abd3-d0ab79a1885f@github.com>

On Tue, 2 Jan 2024 22:28:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Correct small oversight made during the fix for
> 
>     JDK-8257638: Update usage of "type" terminology in javax.lang.model

This pull request has now been integrated.

Changeset: fcf8368e
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcf8368eb1945c440df8f38969849621b4fffc50
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8322248: Fix inconsistent wording in ElementFilter.typesIn

Reviewed-by: jjg, iris

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

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

From cushon at openjdk.org  Wed Jan  3 23:29:40 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 3 Jan 2024 23:29:40 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
Message-ID: <SmxFus18vupJDEKfNW0SqDIqOESjBluzzkVoBU-0sjI=.70449656-c489-40dd-9155-8deef51f1157@github.com>

On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> 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 three additional commits since the last revision:
> 
>  - Update visitor; all langtools regression tests pass.
>  - Merge branch 'master' into JDK-8042981
>  - JDK-8042981: Strip type annotations in Types' utility methods

I cleaned up the approach described in https://github.com/openjdk/jdk/pull/8984#issuecomment-1806211798 and have a draft with those changes applied on top of the work in this PR: https://github.com/openjdk/jdk/pull/17256. It passes the tests added in this PR, with the disabled cases re-enabled.

@jddarcy what do you think of that approach?

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

PR Comment: https://git.openjdk.org/jdk/pull/8984#issuecomment-1876104743

From jlahoda at openjdk.org  Fri Jan  5 12:46:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Jan 2024 12:46:25 GMT
Subject: [jdk22] Integrated: 8321582: yield <primitive-type>.class not parsed
 correctly.
In-Reply-To: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com>
References: <8h-h23rMlK-NCG04lFOcYNU5-w5noQBovgI-OXvZ1to=.981ddd89-be9c-4d2b-9f26-7dce664c9a60@github.com>
Message-ID: <E-Mb702zeaKJ55xT-Shfamq_bgcvV4dZQFgATwBCJoQ=.4655ff84-bff1-4a5c-9e97-25bddabc6e04@github.com>

On Mon, 11 Dec 2023 12:47:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ce8399fd](https://github.com/openjdk/jdk/commit/ce8399fd6071766114f5f201b6e44a7abdba9f5a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 11 Dec 2023 and was reviewed by Vicente Romero.
> 
> Thanks!

This pull request has now been integrated.

Changeset: bb0e203d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/bb0e203d134b35bb1078c3be10f7a6952f6c75bc
Stats:     29 lines in 2 files changed: 27 ins; 1 del; 1 mod

8321582: yield <primitive-type>.class not parsed correctly.

Reviewed-by: shade, vromero
Backport-of: ce8399fd6071766114f5f201b6e44a7abdba9f5a

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

PR: https://git.openjdk.org/jdk22/pull/6

From vromero at openjdk.org  Fri Jan  5 17:48:46 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Jan 2024 17:48:46 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations
Message-ID: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>

This is a very interesting issue. Given code like:

sealed interface Sealed {
    record R1() implements Sealed {}
    record R2() implements Sealed {}
}


As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.

TIA

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

Commit messages:
 - 8322477: order of subclasses in the permits clause can differ between compilations

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

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

From vromero at openjdk.org  Fri Jan  5 17:57:22 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Jan 2024 17:57:22 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations
In-Reply-To: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
Message-ID: <tQ0ezqbIM1KstY7KKrZnBgan0IEHBpGCVoJ7MVdok40=.8ce91c89-3137-47a6-abdd-4b1e12e10e68@github.com>

On Fri, 5 Jan 2024 17:42:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This is a very interesting issue. Given code like:
> 
> sealed interface Sealed {
>     record R1() implements Sealed {}
>     record R2() implements Sealed {}
> }
> 
> 
> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1307:

> 1305:         /** The classes, or interfaces, permitted to extend this class, or interface
> 1306:          */
> 1307:         private java.util.List<PermittedClassWithPos> permitted;

some of the changes come only because of the fact that this field is not private. We can keep it public and the code will be simpler but there could be erroneous uses of the field

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17284#discussion_r1443183930

From vromero at openjdk.org  Fri Jan  5 18:00:23 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Jan 2024 18:00:23 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations
In-Reply-To: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
Message-ID: <Vo66GwVb7sb_AQBncwO_KsIGPhxWr3V6p4TpDc6fqb8=.ae808a2a-d426-496b-b280-4bf36777a83a@github.com>

On Fri, 5 Jan 2024 17:42:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This is a very interesting issue. Given code like:
> 
> sealed interface Sealed {
>     record R1() implements Sealed {}
>     record R2() implements Sealed {}
> }
> 
> 
> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
> 
> TIA

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

> 5391:                     Set<Symbol> permittedTypes = new HashSet<>();
> 5392:                     boolean sealedInUnnamed = c.packge().modle == syms.unnamedModule || c.packge().modle == syms.noModule;
> 5393:                     for (Type subType : c.getPermittedSubclasses()) {

most changes here are due to the use of `getPermittedSubclasses`, which is a previously existing API, that returns a list of types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17284#discussion_r1443188628

From jlahoda at openjdk.org  Fri Jan  5 19:56:41 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Jan 2024 19:56:41 GMT
Subject: RFR: 8323057: Recoverable errors may be reported before unrecoverable
 errors when annotation processing is skipped
Message-ID: <y5JKBbYhNFeC86Gx_yyJmYJfD_Xm-JBJyIkB7TvE9tA=.9e0b8faa-e529-418d-a71f-97be22ef42d5@github.com>

When annotation processing is requested, some errors reported during enter may be resolved by the annotation processors. So, javac stashes the errors from enter aside. When an error that cannot be resolved by annotation processing is found in the stashed errors, the annotation processors all the errors will be printed.

This may be confusing if there's one important non-resolvable error, hidden among many errors that would be resolved by the annotation processors. The proposal herein is therefore to first print the not-recoverable errors, and only then the recoverable errors, when the errors are stashed away and then re-printed.

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

Commit messages:
 - 8323057: Recoverable errors may be reported before unrecoverable errors when annotation processing is skipped

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

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

From jlahoda at openjdk.org  Fri Jan  5 20:00:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Jan 2024 20:00:57 GMT
Subject: RFR: 8322003: JShell - Incorrect type inference in lists of
 records implementing interfaces [v2]
In-Reply-To: <itoHqy3lZW-6CYigYTX7vrywHxn5BOn0C6rqmRW0-vQ=.f27194a5-06a3-4f61-8115-f62b2803ac8e@github.com>
References: <itoHqy3lZW-6CYigYTX7vrywHxn5BOn0C6rqmRW0-vQ=.f27194a5-06a3-4f61-8115-f62b2803ac8e@github.com>
Message-ID: <wxsduivIWDUaBK1ctypuUhOKMvOEs35UpuEtT7-Z6Nc=.f56a6bbf-0810-4780-b2b6-265efe8cdce9@github.com>

> Consider JShell snippet like:
> 
> var v = List.of("", 0);
> 
> 
> The type of `v` is along the lines of `List<Serializable&Comparable<? extends Serializable&Comparable<?>&java.lang.constant.Constable&java.lang.constant.ConstantDesc>&java.lang.constant.Constable&java.lang.constant.ConstantDesc>` - i.e. a List with an intersection type as a type argument.
> 
> The problem is that JShell compiles snippets separately in separate classes. And hence `v` is upgraded to a field. But, the field cannot have the above non-denotable type, so its type is demoted to `List<Serializable>`. When the field is read when a subsequent snippet is processed, JShell tries to reconstitute the type, but a type with an intersection type as a type argument cannot be parsed by the parser. As a consequence, continuing with the example above:
> 
> jshell> List<java.lang.constant.Constable> l = v;
> |  Error:
> |  incompatible types: java.util.List<java.io.Serializable> cannot be converted to java.util.List<java.lang.constant.Constable>
> |  List<java.lang.constant.Constable> l = v;
> |                                         ^
> 
> 
> The proposed solution here is to enhance the parser used by JShell so that it can parse intersection types at any position. JShell then can reconstitute the type, and the above snippets work:
> 
> jshell> var v = List.of("", 0);
> v ==> [, 0]
> 
> jshell> List<java.lang.constant.Constable> l = v;
> l ==> [, 0]

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8322003
 - 8322003: JShell - Incorrect type inference in lists of records implementing interfaces

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

Changes: https://git.openjdk.org/jdk/pull/17223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17223&range=01
  Stats: 121 lines in 3 files changed: 87 ins; 11 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17223/head:pull/17223

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

From cushon at google.com  Fri Jan  5 20:56:51 2024
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 5 Jan 2024 12:56:51 -0800
Subject: diagnostics for non-applicable type annotations
Message-ID: <CAL4QsgvWtaqG-9SarR8eut07tsmq0RRXAbK-JDd0FxApB+wPLA@mail.gmail.com>

Hello,

JDK-8043226 is a long-standing bug about the diagnostics for non-applicable
type annotations. This is an example of a current diagnostic:

test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38:
error: scoping construct cannot be annotated with type-use annotation: @TA
    @TA Outer.SInner osi;
             ^
Users troubleshooting these diagnostics sometimes find them hard to
resolve, because it isn't intuitive which location is an
admissible location for the annotation. Additionally, the 'scoping
construct' language was used in JSR-308 discussions, but didn't end up in
the final version of the specification.

I think it would be helpful to users for the diagnostic to mention where a
type annotation would be admissible, for example something like:

test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38:
error: type annotations are not admissible at this location: @TA
    @TA Outer.SInner osi;
             ^
  (to annotate a qualified type, write Outer. at TA SInner)

I have a PR to implement the revised diagnostic here:
https://github.com/openjdk/jdk/pull/16592

Do you think the revised diagnostics are an improvement? Are there any
suggestions for language that would be better? Any feedback on the idea is
welcome.

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240105/13a8f540/attachment.htm>

From vromero at openjdk.org  Fri Jan  5 21:01:24 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Jan 2024 21:01:24 GMT
Subject: RFR: 8322003: JShell - Incorrect type inference in lists of
 records implementing interfaces [v2]
In-Reply-To: <wxsduivIWDUaBK1ctypuUhOKMvOEs35UpuEtT7-Z6Nc=.f56a6bbf-0810-4780-b2b6-265efe8cdce9@github.com>
References: <itoHqy3lZW-6CYigYTX7vrywHxn5BOn0C6rqmRW0-vQ=.f27194a5-06a3-4f61-8115-f62b2803ac8e@github.com>
 <wxsduivIWDUaBK1ctypuUhOKMvOEs35UpuEtT7-Z6Nc=.f56a6bbf-0810-4780-b2b6-265efe8cdce9@github.com>
Message-ID: <j6-tPGjstrk6-0WliS86yKH_Y1PrtYEiY8DpfX07oZA=.ae1ab59c-1940-4e61-99dc-884c277e48ff@github.com>

On Fri, 5 Jan 2024 20:00:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider JShell snippet like:
>> 
>> var v = List.of("", 0);
>> 
>> 
>> The type of `v` is along the lines of `List<Serializable&Comparable<? extends Serializable&Comparable<?>&java.lang.constant.Constable&java.lang.constant.ConstantDesc>&java.lang.constant.Constable&java.lang.constant.ConstantDesc>` - i.e. a List with an intersection type as a type argument.
>> 
>> The problem is that JShell compiles snippets separately in separate classes. And hence `v` is upgraded to a field. But, the field cannot have the above non-denotable type, so its type is demoted to `List<Serializable>`. When the field is read when a subsequent snippet is processed, JShell tries to reconstitute the type, but a type with an intersection type as a type argument cannot be parsed by the parser. As a consequence, continuing with the example above:
>> 
>> jshell> List<java.lang.constant.Constable> l = v;
>> |  Error:
>> |  incompatible types: java.util.List<java.io.Serializable> cannot be converted to java.util.List<java.lang.constant.Constable>
>> |  List<java.lang.constant.Constable> l = v;
>> |                                         ^
>> 
>> 
>> The proposed solution here is to enhance the parser used by JShell so that it can parse intersection types at any position. JShell then can reconstitute the type, and the above snippets work:
>> 
>> jshell> var v = List.of("", 0);
>> v ==> [, 0]
>> 
>> jshell> List<java.lang.constant.Constable> l = v;
>> l ==> [, 0]
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8322003
>  - 8322003: JShell - Incorrect type inference in lists of records implementing interfaces

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17223#pullrequestreview-1806836651

From cushon at openjdk.org  Fri Jan  5 21:15:21 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 5 Jan 2024 21:15:21 GMT
Subject: RFR: 8043226: Better diagnostics for non-applicable type
 annotations
In-Reply-To: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
References: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
Message-ID: <cls9YhbGraTJOC464ZuuG9KeZMRxnuWnf1pwc9w9JCo=.8cf42cc0-8a7f-454a-9226-498600c46be2@github.com>

On Fri, 10 Nov 2023 01:21:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi,
> 
> Please consider this improvement to diagnostics on inadmissable type annotations.
> 
> [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug.
> 
> I have some notes on details of the proposed changes below.
> 
> ---
> 
> Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. 
> 
> As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2.
> 
> This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names.
> 
> Before:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA
>     @TA Outer.SInner osi;
>              ^
> 
> 
> After:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA
>     @TA Outer.SInner osi;
>              ^
>   (to annotate a qualified type, write Outer. at TA SInner)
> 
> 
> ---
> 
> Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`.
> 
> This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location.
> 
> This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l...

Please keep this open

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

PR Comment: https://git.openjdk.org/jdk/pull/16592#issuecomment-1879261789

From tschatzl at openjdk.org  Mon Jan  8 13:28:29 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 8 Jan 2024 13:28:29 GMT
Subject: RFR: 8323181: JavadocHelperTest.java OOMEs with Parallel GC and ZGC
Message-ID: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>

Hi all,

  please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.

The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.

Testing: local testing

Hth,
  Thomas

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

Commit messages:
 - increase max heap size to let the test pass

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

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

From prappo at openjdk.org  Mon Jan  8 13:49:31 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 8 Jan 2024 13:49:31 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v5]
In-Reply-To: <5D_gyGHDR52UTLCcFnUNSWYXjYgcy3jYnffOXZ70xsg=.e1389d08-c9ae-481f-9c53-1ccd1e389102@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5D_gyGHDR52UTLCcFnUNSWYXjYgcy3jYnffOXZ70xsg=.e1389d08-c9ae-481f-9c53-1ccd1e389102@github.com>
Message-ID: <-A138lUTDM768TSi4KH0VYzBEoEDUOnADjSCL_RRgKA=.ab4b9b97-47a8-474a-bc64-4b461988bbe4@github.com>

On Wed, 15 Nov 2023 18:58:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

@jonathan-gibbons, please sync this PR with mainline. As for Skara bots, this comment will hopefully deter them for another 4 weeks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-1881040100

From jlahoda at openjdk.org  Mon Jan  8 14:12:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 8 Jan 2024 14:12:30 GMT
Subject: Integrated: 8322003: JShell - Incorrect type inference in lists of
 records implementing interfaces
In-Reply-To: <itoHqy3lZW-6CYigYTX7vrywHxn5BOn0C6rqmRW0-vQ=.f27194a5-06a3-4f61-8115-f62b2803ac8e@github.com>
References: <itoHqy3lZW-6CYigYTX7vrywHxn5BOn0C6rqmRW0-vQ=.f27194a5-06a3-4f61-8115-f62b2803ac8e@github.com>
Message-ID: <FUmTlUnPNQLy1cuGEgs6zSqLzx-PZAuxJPUu_XeZQxc=.a69fe543-0bae-4db1-85fc-03dcf0cfa88f@github.com>

On Tue, 2 Jan 2024 15:00:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider JShell snippet like:
> 
> var v = List.of("", 0);
> 
> 
> The type of `v` is along the lines of `List<Serializable&Comparable<? extends Serializable&Comparable<?>&java.lang.constant.Constable&java.lang.constant.ConstantDesc>&java.lang.constant.Constable&java.lang.constant.ConstantDesc>` - i.e. a List with an intersection type as a type argument.
> 
> The problem is that JShell compiles snippets separately in separate classes. And hence `v` is upgraded to a field. But, the field cannot have the above non-denotable type, so its type is demoted to `List<Serializable>`. When the field is read when a subsequent snippet is processed, JShell tries to reconstitute the type, but a type with an intersection type as a type argument cannot be parsed by the parser. As a consequence, continuing with the example above:
> 
> jshell> List<java.lang.constant.Constable> l = v;
> |  Error:
> |  incompatible types: java.util.List<java.io.Serializable> cannot be converted to java.util.List<java.lang.constant.Constable>
> |  List<java.lang.constant.Constable> l = v;
> |                                         ^
> 
> 
> The proposed solution here is to enhance the parser used by JShell so that it can parse intersection types at any position. JShell then can reconstitute the type, and the above snippets work:
> 
> jshell> var v = List.of("", 0);
> v ==> [, 0]
> 
> jshell> List<java.lang.constant.Constable> l = v;
> l ==> [, 0]

This pull request has now been integrated.

Changeset: 57a65fe4
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57a65fe436a3617d64bbf0b02d4c7f7c2551448f
Stats:     121 lines in 3 files changed: 87 ins; 11 del; 23 mod

8322003: JShell - Incorrect type inference in lists of records implementing interfaces

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Mon Jan  8 14:27:47 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 8 Jan 2024 14:27:47 GMT
Subject: [jdk22] RFR: 8322003: JShell - Incorrect type inference in lists of
 records implementing interfaces
Message-ID: <unDiUeYUhMebrhby6sinjdgfHWys9rvLZfsPyxCxMf4=.88b1b6fa-dc97-4718-9a95-0c7e9eaacb9b@github.com>

Hi all,

This pull request contains a backport of commit [57a65fe4](https://github.com/openjdk/jdk/commit/57a65fe436a3617d64bbf0b02d4c7f7c2551448f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 8 Jan 2024 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport 57a65fe436a3617d64bbf0b02d4c7f7c2551448f

Changes: https://git.openjdk.org/jdk22/pull/40/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=40&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322003
  Stats: 121 lines in 3 files changed: 87 ins; 11 del; 23 mod
  Patch: https://git.openjdk.org/jdk22/pull/40.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/40/head:pull/40

PR: https://git.openjdk.org/jdk22/pull/40

From wmdietl at openjdk.org  Mon Jan  8 17:01:26 2024
From: wmdietl at openjdk.org (Werner Dietl)
Date: Mon, 8 Jan 2024 17:01:26 GMT
Subject: RFR: 8043226: Better diagnostics for non-applicable type
 annotations
In-Reply-To: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
References: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
Message-ID: <g4JQG_1P43fBd1ciutOlmaJC_5Ux8yU1PnidZq0yNcQ=.3b22d8dc-e94b-4686-bb0b-0e7beb9dbcda@github.com>

On Fri, 10 Nov 2023 01:21:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi,
> 
> Please consider this improvement to diagnostics on inadmissable type annotations.
> 
> [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug.
> 
> I have some notes on details of the proposed changes below.
> 
> ---
> 
> Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. 
> 
> As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2.
> 
> This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names.
> 
> Before:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA
>     @TA Outer.SInner osi;
>              ^
> 
> 
> After:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA
>     @TA Outer.SInner osi;
>              ^
>   (to annotate a qualified type, write Outer. at TA SInner)
> 
> 
> ---
> 
> Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`.
> 
> This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location.
> 
> This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l...

Thanks for working on this! Improving the compiler error messages is a very important task.
I'm not a reviewer, so just some comments from going through the code (I didn't compile and run it yet).

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

> 5272:                 attribTree(tree.underlyingType, env, new ResultInfo(KindSelector.TYP_PCK, Type.noType));
> 5273:         if (underlyingType.hasTag(PACKAGE)) {
> 5274:             // Type annotations are not admissible on packages, but we handle packages here to be to

Suggestion:

            // Type annotations are not admissible on packages, but we handle packages here to

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3233:

> 3231: # 0: fragment, 1: symbol, 2: type
> 3232: compiler.err.type.annotation.inadmissible=\
> 3233:     type annotations are not admissible at this location: {0}\n\

Suggestion:

compiler.err.type.annotation.not.applicable=\
    type annotations are not applicable at this location: {0}\n\


I don't know whether there are concrete guidelines for this or whether "admissible" is what the JLS uses for this.
Looking at other annotation-related error messages in this file, most use "applicable" and "not applicable" (one key uses `inapplicable`, but the message still uses `not applicable`).
There are no other uses of `admissible` in this file.
There is also `annotation.not.valid.for.type` which uses `annotation not valid for an element of type {0}`, which could be another option.

Also, not not sure whether it would be `are not applicable *at* this location`, `are not applicable *on* this location`, or something else.

test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out line 1:

> 1: CantAnnotatePackages.java:14:18: compiler.err.type.annotation.inadmissible: (compiler.misc.type.annotation.1: @TA), java.lang, @TA java.lang.Object

In this output, isn't `java.lang` the `1: symbol` and `@TA java.lang.Object` the `2: type` in the error message?
Won't the `to annotate a qualified type, write {1}.{2}` then output `java.lang. at TA java.lang.Object`, which isn't what we would want.
Am I parsing this incorrectly?

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

PR Review: https://git.openjdk.org/jdk/pull/16592#pullrequestreview-1809460770
PR Review Comment: https://git.openjdk.org/jdk/pull/16592#discussion_r1444890016
PR Review Comment: https://git.openjdk.org/jdk/pull/16592#discussion_r1444978083
PR Review Comment: https://git.openjdk.org/jdk/pull/16592#discussion_r1445001491

From cushon at openjdk.org  Mon Jan  8 19:12:34 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 8 Jan 2024 19:12:34 GMT
Subject: RFR: 8043226: Better diagnostics for non-applicable type
 annotations [v2]
In-Reply-To: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
References: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
Message-ID: <4ymqDKx7z9VqfAjr93Dx7tVCUnJDoz_1TIY4oarSkoc=.26f92336-85b6-4549-a4a1-cb1d5a424d78@github.com>

> Hi,
> 
> Please consider this improvement to diagnostics on inadmissable type annotations.
> 
> [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug.
> 
> I have some notes on details of the proposed changes below.
> 
> ---
> 
> Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. 
> 
> As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2.
> 
> This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names.
> 
> Before:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA
>     @TA Outer.SInner osi;
>              ^
> 
> 
> After:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA
>     @TA Outer.SInner osi;
>              ^
>   (to annotate a qualified type, write Outer. at TA SInner)
> 
> 
> ---
> 
> Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`.
> 
> This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location.
> 
> This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
  
  Co-authored-by: Werner Dietl <wdietl at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16592/files
  - new: https://git.openjdk.org/jdk/pull/16592/files/55c15c9b..568eb387

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

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

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

From cushon at openjdk.org  Mon Jan  8 19:20:24 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 8 Jan 2024 19:20:24 GMT
Subject: RFR: 8043226: Better diagnostics for non-applicable type
 annotations [v2]
In-Reply-To: <g4JQG_1P43fBd1ciutOlmaJC_5Ux8yU1PnidZq0yNcQ=.3b22d8dc-e94b-4686-bb0b-0e7beb9dbcda@github.com>
References: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
 <g4JQG_1P43fBd1ciutOlmaJC_5Ux8yU1PnidZq0yNcQ=.3b22d8dc-e94b-4686-bb0b-0e7beb9dbcda@github.com>
Message-ID: <FnCAF4yfx_co8ObItAVMaYEqmDkzKl74IhWSECkTgMc=.2b902373-42a9-485a-a0fd-d25f53dea685@github.com>

On Mon, 8 Jan 2024 16:36:44 GMT, Werner Dietl <wmdietl at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>>   
>>   Co-authored-by: Werner Dietl <wdietl at gmail.com>
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3233:
> 
>> 3231: # 0: fragment, 1: symbol, 2: type
>> 3232: compiler.err.type.annotation.inadmissible=\
>> 3233:     type annotations are not admissible at this location: {0}\n\
> 
> Suggestion:
> 
> compiler.err.type.annotation.not.applicable=\
>     type annotations are not applicable at this location: {0}\n\
> 
> 
> I don't know whether there are concrete guidelines for this or whether "admissible" is what the JLS uses for this.
> Looking at other annotation-related error messages in this file, most use "applicable" and "not applicable" (one key uses `inapplicable`, but the message still uses `not applicable`).
> There are no other uses of `admissible` in this file.
> There is also `annotation.not.valid.for.type` which uses `annotation not valid for an element of type {0}`, which could be another option.
> 
> Also, not not sure whether it would be `are not applicable *at* this location`, `are not applicable *on* this location`, or something else.

Thanks, I'm very open to changing the language here. I was using 'admissible' because it is used in [JVMS 4.7.20](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.20) and [JLS 9.7.4](https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.7.4) to describe where type annotations are allowed on nested types.

> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out line 1:
> 
>> 1: CantAnnotatePackages.java:14:18: compiler.err.type.annotation.inadmissible: (compiler.misc.type.annotation.1: @TA), java.lang, @TA java.lang.Object
> 
> In this output, isn't `java.lang` the `1: symbol` and `@TA java.lang.Object` the `2: type` in the error message?
> Won't the `to annotate a qualified type, write {1}.{2}` then output `java.lang. at TA java.lang.Object`, which isn't what we would want.
> Am I parsing this incorrectly?

I think you're parsing the arguments correctly, but when the arguments are formatted for the output the type is printed using its simple name, so we end up with:


test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java:14: error: type annotations are not admissible at this location: @TA
    @TA java.lang.Object of1;
                 ^
  (to annotate a qualified type, write java.lang. at TA Object)
  ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16592#discussion_r1445204346
PR Review Comment: https://git.openjdk.org/jdk/pull/16592#discussion_r1445221432

From jjg at openjdk.org  Mon Jan  8 21:26:50 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 8 Jan 2024 21:26:50 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Address review comments
 - Fix whitespace
 - Improve handling of embedded inline taglets
 - Customize support for Markdown headings
 - JDK-8298405: Support Markdown in Documentation Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/39cdd2bb..50bb105d

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

  Stats: 837199 lines in 5369 files changed: 205028 ins; 545552 del; 86619 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From ayang at openjdk.org  Tue Jan  9 06:15:22 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 9 Jan 2024 06:15:22 GMT
Subject: RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
Message-ID: <Qir1xOG8DFrslVfYDNrFuD7zE-1QJm0_kspAjmXXVrg=.c1c87d96-d76a-4e8c-aae9-dc47b675a708@github.com>

On Mon, 8 Jan 2024 13:23:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
> 
> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
> 
> Testing: local testing
> 
> Hth,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17304#pullrequestreview-1810462707

From aboldtch at openjdk.org  Tue Jan  9 07:47:21 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 9 Jan 2024 07:47:21 GMT
Subject: RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
Message-ID: <fAAeMZdJQCP8BU4beWpSsOnIACJHvr6ssmQfj_qkSCc=.51c24e4c-43f8-4eac-a0ec-0032d62023c0@github.com>

On Mon, 8 Jan 2024 13:23:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
> 
> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
> 
> Testing: local testing
> 
> Hth,
>   Thomas

Looked at this issue earlier this week as well. This seem like the appropriate solution.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17304#pullrequestreview-1810564101

From pbielicki at gmail.com  Tue Jan  9 08:48:06 2024
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Tue, 9 Jan 2024 09:48:06 +0100
Subject: [private] Re: [External] : Re: [Bug] javac gives
 non-deterministic output (for sealed interface with records)
In-Reply-To: <f5e8277e-355f-4ad3-b977-036ab2d8f528@oracle.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <b28ea522-3467-407c-b230-bafc0fe5bef6@oracle.com>
 <CAMvdueBPKS6gAL30NwimojuPm89AdxnyGoNzfLj0OvCGops9ng@mail.gmail.com>
 <CAMvdueCh6E-6gDnRmBp+Tw0Aa5DZ4ESp-wxS6esPbCNHUXF47Q@mail.gmail.com>
 <CAMvdueB2EuRnCcmm+OwLiGk0SRgJWboHr60ToY0RrvRZBo42Cg@mail.gmail.com>
 <2e0d46a5-add6-4c98-b359-f8a4a4a6f1e2@oracle.com>
 <CAMvdueDrZKX-C+BWHMQZiROk9758AUuB3nSypxYRjcOnOPeO9w@mail.gmail.com>
 <32306a3d-1376-4ec8-850b-f78eae103f1f@oracle.com>
 <f5cbda02-5e09-4654-a154-a87a4167ee14@oracle.com>
 <CAMvdueCcvYW0AqjopkARAkhumbWjpATjjbQ=7xYtv7MUijY80A@mail.gmail.com>
 <c60aed74-3648-4767-bb48-7ccf4eaa0577@oracle.com>
 <CAMvdueD=aoSOeuHudAo2nXCDODPoBwcUUsfnr3rfLLwvaM_aOQ@mail.gmail.com>
 <f54edd21-db84-4529-b75c-af493b5046c5@oracle.com>
 <CAMvdueDeVVvMqOCMsLLMxGog5anCb7y4JYm99584kD_dKKUeRQ@mail.gmail.com>
 <8c26af0d-b0c5-410f-8db7-96e209707c90@oracle.com>
 <CAMvdueB8epAEr1scqCiXs-xAC--0zxW2NAeQDBb12uew_t7gKA@mail.gmail.com>
 <f5e8277e-355f-4ad3-b977-036ab2d8f528@oracle.com>
Message-ID: <CAMvdueCSdLeVmVa=drMxBOhm0M8-c5iugtnTcuRXUmedo_NJBQ@mail.gmail.com>

Hey Vicente,

My fellow Gradle JVM Platform engineer (Octavia Togami) created a
reproducer: https://github.com/octylFractal/javac-permitted-ordering-bug
Her first analysis was: "Looking at the stacktraces, it appears that when
it's ordered properly, the subclasses of the sealed type are visited as
part of their parent; but when it's ordered incorrectly, they're visited as
part of resolving the type of a variable somewhere else."
Eventually she says: "This is not in any way a Gradle bug. It has to do
with ordering of other files that use the sealed type and its subclasses."

Can you please verify this on your end and update the JIRA ticket with the
latest findings?

Thanks,
Przemek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240109/68786149/attachment-0001.htm>

From tschatzl at openjdk.org  Tue Jan  9 13:41:24 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 9 Jan 2024 13:41:24 GMT
Subject: RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <fAAeMZdJQCP8BU4beWpSsOnIACJHvr6ssmQfj_qkSCc=.51c24e4c-43f8-4eac-a0ec-0032d62023c0@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
 <fAAeMZdJQCP8BU4beWpSsOnIACJHvr6ssmQfj_qkSCc=.51c24e4c-43f8-4eac-a0ec-0032d62023c0@github.com>
Message-ID: <EVmNPMtfuEaeQWdkErlokrsmw6nMckLNkwhZXzwLcX8=.25cb8817-79e1-4a98-a83f-df46815b762f@github.com>

On Tue, 9 Jan 2024 07:44:50 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
>> 
>> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
>> 
>> Testing: local testing
>> 
>> Hth,
>>   Thomas
>
> Looked at this issue earlier this week as well. This seem like the appropriate solution.

Thanks @xmas92 @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/17304#issuecomment-1883067543

From tschatzl at openjdk.org  Tue Jan  9 13:51:36 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 9 Jan 2024 13:51:36 GMT
Subject: Integrated: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
Message-ID: <aO7zrO5C9R_tVr07_dqgy7ktWEJARjXSnxqJQ_m-2mA=.9650d04d-ba3c-40a6-8fe7-740ca74dc692@github.com>

On Mon, 8 Jan 2024 13:23:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
> 
> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
> 
> Testing: local testing
> 
> Hth,
>   Thomas

This pull request has now been integrated.

Changeset: 52c7ff1d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52c7ff1d81940d6d0d1e3dd7ad0447c80708161c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8322330: JavadocHelperTest.java OOMEs with Parallel GC and ZGC

Reviewed-by: ayang, aboldtch

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

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

From prappo at openjdk.org  Tue Jan  9 14:35:33 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 9 Jan 2024 14:35:33 GMT
Subject: RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
Message-ID: <f-Iw6V8IKvo3N92GBr6XXUyGdECPWgQzB8_i0FgfjTY=.e6a65930-6f1f-4cd3-b702-1b45a1c4940e@github.com>

On Mon, 8 Jan 2024 13:23:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
> 
> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
> 
> Testing: local testing
> 
> Hth,
>   Thomas

I have a few questions on this PR. Firstly, general: how come this PR hasn't been reviewed by jshell people? I appreciate that the change is about GCs, but generally a PR should be reviewed by experts in all areas that that PR touches. Secondly, is that correct that the Skara bot [applied] the "javadoc" label but not "kulla" to a test that belongs to jshell? (CC'ing @jonathan-gibbons and @lahodaj.) To be clear, I see the respective [rules] in place, but I wonder if they are correct.

[applied]: https://github.com/openjdk/jdk/pull/17304#issuecomment-1881003029
[rules]: https://github.com/openjdk/skara/blob/ef8238c35070094e979a13ad872d105f883f3881/config/mailinglist/rules/jdk.json#L457-L474

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

PR Comment: https://git.openjdk.org/jdk/pull/17304#issuecomment-1883157740

From vicente.romero at oracle.com  Tue Jan  9 16:04:52 2024
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 9 Jan 2024 11:04:52 -0500
Subject: [private] Re: [External] : Re: [Bug] javac gives
 non-deterministic output (for sealed interface with records)
In-Reply-To: <CAMvdueCSdLeVmVa=drMxBOhm0M8-c5iugtnTcuRXUmedo_NJBQ@mail.gmail.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <CAMvdueCh6E-6gDnRmBp+Tw0Aa5DZ4ESp-wxS6esPbCNHUXF47Q@mail.gmail.com>
 <CAMvdueB2EuRnCcmm+OwLiGk0SRgJWboHr60ToY0RrvRZBo42Cg@mail.gmail.com>
 <2e0d46a5-add6-4c98-b359-f8a4a4a6f1e2@oracle.com>
 <CAMvdueDrZKX-C+BWHMQZiROk9758AUuB3nSypxYRjcOnOPeO9w@mail.gmail.com>
 <32306a3d-1376-4ec8-850b-f78eae103f1f@oracle.com>
 <f5cbda02-5e09-4654-a154-a87a4167ee14@oracle.com>
 <CAMvdueCcvYW0AqjopkARAkhumbWjpATjjbQ=7xYtv7MUijY80A@mail.gmail.com>
 <c60aed74-3648-4767-bb48-7ccf4eaa0577@oracle.com>
 <CAMvdueD=aoSOeuHudAo2nXCDODPoBwcUUsfnr3rfLLwvaM_aOQ@mail.gmail.com>
 <f54edd21-db84-4529-b75c-af493b5046c5@oracle.com>
 <CAMvdueDeVVvMqOCMsLLMxGog5anCb7y4JYm99584kD_dKKUeRQ@mail.gmail.com>
 <8c26af0d-b0c5-410f-8db7-96e209707c90@oracle.com>
 <CAMvdueB8epAEr1scqCiXs-xAC--0zxW2NAeQDBb12uew_t7gKA@mail.gmail.com>
 <f5e8277e-355f-4ad3-b977-036ab2d8f528@oracle.com>
 <CAMvdueCSdLeVmVa=drMxBOhm0M8-c5iugtnTcuRXUmedo_NJBQ@mail.gmail.com>
Message-ID: <f76187b4-d814-4c62-a3b5-773e47acd0e9@oracle.com>

Hi Przemek,

this is pretty good, thanks for the reproducer. I will update the bug entry,

Thanks,
Vicente

On 1/9/24 03:48, Przemek Bielicki wrote:
> Hey Vicente,
>
> My fellow Gradle JVM Platform engineer (Octavia Togami) created a 
> reproducer: 
> https://github.com/octylFractal/javac-permitted-ordering-bug 
> <https://urldefense.com/v3/__https://github.com/octylFractal/javac-permitted-ordering-bug__;!!ACWV5N9M2RV99hQ!OuIjNEls9z95A5Eq458IZEjWn1nlxh3v2_wq3jYrPj61R62YNl6fUCJ_-Docq9rmUcpTVMWgk3iQLhvjhTxyZA$>
> Her first analysis was: "Looking at the stacktraces, it appears that 
> when it's ordered properly, the subclasses of the sealed type are 
> visited as part of their parent; but when it's ordered incorrectly, 
> they're visited as part of resolving the type of a variable somewhere 
> else."
> Eventually she says: "This is not in any way a Gradle bug. It has to 
> do with ordering of other files that use the sealed type and its 
> subclasses."
>
> Can you please verify this on your end and update the JIRA ticket with 
> the latest findings?
>
> Thanks,
> Przemek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240109/37a653a8/attachment-0001.htm>

From tschatzl at openjdk.org  Tue Jan  9 16:14:31 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 9 Jan 2024 16:14:31 GMT
Subject: RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <f-Iw6V8IKvo3N92GBr6XXUyGdECPWgQzB8_i0FgfjTY=.e6a65930-6f1f-4cd3-b702-1b45a1c4940e@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
 <f-Iw6V8IKvo3N92GBr6XXUyGdECPWgQzB8_i0FgfjTY=.e6a65930-6f1f-4cd3-b702-1b45a1c4940e@github.com>
Message-ID: <jTNlrLs6ip2MKexOowstcdoINR8juyxi19UKQbbKm0k=.845ccda6-4e18-4029-b135-1d87339dae44@github.com>

On Tue, 9 Jan 2024 14:32:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I have a few questions on this PR. Firstly, general: how come this PR hasn't been reviewed by jshell people? I appreciate that the change is about GCs, but generally a PR should be reviewed by experts in all areas that that PR touches.

There are multiple reasons why I thought that it is fine to integrate without further reviews, some of them are:
* This is a test change that only modifies the runtime environment of the test to allow GCs to handle the load. This has been evaluated and verified that the live data set is too large for some collectors to handle. I.e. the PR changes no jshell/javadoc or test code at all.
* The problem is well understood - too much live data used by the test due to other changes. There did not seem to be a memory leak or something either while looking at the logs (I did not mention this in the description, but I checked).
* The CR has also explicitly been moved to the GC team to handle (from the javadoc component).
* The duplicate CR  [JDK-8318025](https://bugs.openjdk.org/browse/JDK-8318025) is three months old now, with an explicit comment by experts in that area that this is likely a heap capacity issue, which the evaluation confirmed.
* The risk that the fix is wrong or worsens the situation (new test failures) is minimal imho.
* Formally the 24h rule so that everyone can participate has been observed.

It is unfortunate that the "kulla" label has not been applied which caused some people to miss the PR (apparently this label explicitly notifies you(?) jshell experts), so apologies for missing that.

However this (and the integration due to above reasons) does not mean that the discussion about the change is done with this integration, and obviously it can still be commented on, re-evaluated and changed as needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17304#issuecomment-1883345570

From jlahoda at openjdk.org  Tue Jan  9 16:18:32 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Jan 2024 16:18:32 GMT
Subject: RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
Message-ID: <TheBK5j1_x_5u4ZOTvt7PInq9-DtuVP_UqD56xJHwkI=.d8ca4215-a6bb-4db9-aca1-3879f794c7d4@github.com>

On Mon, 8 Jan 2024 13:23:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
> 
> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
> 
> Testing: local testing
> 
> Hth,
>   Thomas

FWIW - I don't mind the change. I think it is more for the GC people if they are fine with some GC requiring more memory than others, or if they want to investigate further. The validity of the javadoc-related test is not affected by this, I think.

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

PR Comment: https://git.openjdk.org/jdk/pull/17304#issuecomment-1883352387

From cpovirk at google.com  Tue Jan  9 16:26:29 2024
From: cpovirk at google.com (Chris Povirk)
Date: Tue, 9 Jan 2024 11:26:29 -0500
Subject: diagnostics for non-applicable type annotations
In-Reply-To: <CAL4QsgvWtaqG-9SarR8eut07tsmq0RRXAbK-JDd0FxApB+wPLA@mail.gmail.com>
References: <CAL4QsgvWtaqG-9SarR8eut07tsmq0RRXAbK-JDd0FxApB+wPLA@mail.gmail.com>
Message-ID: <CAEvq2noJ05eQNnHVoGVv80WXMcB7jL3FQp3qm1SubYO+THj6kg@mail.gmail.com>

Thanks, Liam.

We've found the current error messages to be a source of confusion: While
the average user doesn't use type-use annotations, those users who do use
them seem to hit this pretty frequently. We have our own FAQ entry about it
in our internal documentation, and I also refer people to the Checker
Framework's documentation
<https://checkerframework.org/manual/#common-problems-non-typechecking>,
which gives advice similar to that implemented by Liam's PR. I would expect
for that page and this Stack Overflow answer
<https://stackoverflow.com/a/21385939/28465> to get more traffic as
type-use annotations grow in popularity, as we're aiming for them to do as
part of our work on JSpecify nullness. The error-message changes could save
users a trip to those docs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240109/0a265779/attachment.htm>

From tschatzl at openjdk.org  Tue Jan  9 17:23:40 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 9 Jan 2024 17:23:40 GMT
Subject: [jdk22] RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC
 and ZGC
Message-ID: <NtlV8pyVB-05f0dHz2CuiyDoUPqD0ojVA56VJUFDuaE=.384bc7f3-2de0-4249-9736-dbbee8171884@github.com>

Hi all,

  This pull request contains a backport of commit [52c7ff1d](https://github.com/openjdk/jdk/commit/52c7ff1d81940d6d0d1e3dd7ad0447c80708161c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

  The commit being backported was authored by Thomas Schatzl on 9 Jan 2024 and was reviewed by Albert Mingkun Yang and Axel Boldt-Christmas.

This is a clean backport.

Thanks!
  Thomas

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

Commit messages:
 - Backport 52c7ff1d81940d6d0d1e3dd7ad0447c80708161c

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

PR: https://git.openjdk.org/jdk22/pull/44

From jjg at openjdk.org  Tue Jan  9 21:42:31 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 9 Jan 2024 21:42:31 GMT
Subject: RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <TheBK5j1_x_5u4ZOTvt7PInq9-DtuVP_UqD56xJHwkI=.d8ca4215-a6bb-4db9-aca1-3879f794c7d4@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
 <TheBK5j1_x_5u4ZOTvt7PInq9-DtuVP_UqD56xJHwkI=.d8ca4215-a6bb-4db9-aca1-3879f794c7d4@github.com>
Message-ID: <soOPKsr5OGD6WF6zYFeGIFIQasOVO27WGVw8pM0vmGE=.c0831627-f4f3-4348-a7d4-7bd4802264aa@github.com>

On Tue, 9 Jan 2024 16:15:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
>> 
>> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
>> 
>> Testing: local testing
>> 
>> Hth,
>>   Thomas
>
> FWIW - I don't mind the change. I think it is more for the GC people if they are fine with some GC requiring more memory than others, or if they want to investigate further. The validity of the javadoc-related test is not affected by this, I think.

1. _No `kulla` label_: that's an issue that should be investigated and fixed.  For my part, I saw the PR but assumed that @lahodaj would address it, as the engineer primarily responsible for the test.

2. While I read and accept @lahodaj 's comment that he is OK with the fix, in general it should _not_ be assumed that the solution to all out-of-memory errors is to provide more memory.   At least in part, it should be examined to see why the test is running out of memory, even if the proximate cause is to change the GC.

There is a history that I would now consider an anti-pattern of LangTools tests running on monotonically increasing data sets. I know, because I wrote some of them, back in the day.  The (anti-)pattern is to run a test on all available data files, for some value of "available" which is typically "all source files (in the `src` directory) or "all test files" (such as in the `test/langtools` directory. While the practice will for-sure lead to monotonically increasing run times, we could/should make sure that it doesn't lead to monotonically increasing memory requirements.  There have been (Oracle-internal) discussions about managing the "size" of tests, whether that is time-size or memory-size, and this test is another candidate for those discussions. (@jddarcy)

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

PR Comment: https://git.openjdk.org/jdk/pull/17304#issuecomment-1883841560

From vromero at openjdk.org  Tue Jan  9 22:10:23 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 9 Jan 2024 22:10:23 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations
In-Reply-To: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
Message-ID: <TexwoDz-GBCO6QqU-41ZPXcMh4hOchmdc9I4ycGyitQ=.db27f226-8e33-43ee-a6ab-4ac3b5960708@github.com>

On Fri, 5 Jan 2024 17:42:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This is a very interesting issue. Given code like:
> 
> sealed interface Sealed {
>     record R1() implements Sealed {}
>     record R2() implements Sealed {}
> }
> 
> 
> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
> 
> TIA

at the end the swap in the permits clause order can be boiled down to symbol completions that were triggered "before" expected by a call to Symbol::flags but, even if this was the right solution it is not future-proofed as a future change can include a call to Symbol::flags that can alter the expected order of the permits clause. This is why I think that relying on the original positions in the source code as the key for sorting the elements in the permits clause is a most. For example the patch below fixes the issue with current master, but as mentioned above this is not a good solution looking forward:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index 342ccb26798..9a939ef44db 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -4441,7 +4441,7 @@ public void visitSelect(JCFieldAccess tree) {
         if (isType(sitesym)) {
             if (sym.name != names._this && sym.name != names._super) {
                 // Check if type-qualified fields or methods are static (JLS)
-                if ((sym.flags() & STATIC) == 0 &&
+                if ((sym.flags_field & STATIC) == 0 &&
                     sym.name != names._super &&
                     (sym.kind == VAR || sym.kind == MTH)) {
                     rs.accessBase(rs.new StaticError(sym),
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
index f9b228203d4..76a71ed97dc 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
@@ -3814,7 +3814,7 @@ void checkDeprecated(Supplier<DiagnosticPosition> pos, final Symbol other, final
     }
 
     void checkSunAPI(final DiagnosticPosition pos, final Symbol s) {
-        if ((s.flags() & PROPRIETARY) != 0) {
+        if ((s.flags_field & PROPRIETARY) != 0) {
             deferredLintHandler.report(() -> {
                 log.mandatoryWarning(pos, Warnings.SunProprietary(s));
             });
@@ -3828,8 +3828,8 @@ void checkProfile(final DiagnosticPosition pos, final Symbol s) {
     }
 
     void checkPreview(DiagnosticPosition pos, Symbol other, Symbol s) {
-        if ((s.flags() & PREVIEW_API) != 0 && !preview.participatesInPreview(syms, other, s) && !disablePreviewCheck) {
-            if ((s.flags() & PREVIEW_REFLECTIVE) == 0) {
+        if ((s.flags_field & PREVIEW_API) != 0 && !preview.participatesInPreview(syms, other, s) && !disablePreviewCheck) {
+            if ((s.flags_field & PREVIEW_REFLECTIVE) == 0) {
                 if (!preview.isEnabled()) {
                     log.error(pos, Errors.IsPreview(s));
                 } else {
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
index 3980f03713d..f8b2614306b 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
@@ -415,7 +415,7 @@ public boolean isAccessible(Env<AttrContext> env, Type site, Symbol sym, boolean
             return true;
         }
 
-        switch ((short)(sym.flags() & AccessFlags)) {
+        switch ((short)(sym.flags_field & AccessFlags)) {
         case PRIVATE:
             return
                 (env.enclClass.sym == sym.owner // fast special case

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

PR Comment: https://git.openjdk.org/jdk/pull/17284#issuecomment-1883876588

From vromero at openjdk.org  Wed Jan 10 03:33:48 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 10 Jan 2024 03:33:48 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations [v2]
In-Reply-To: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
Message-ID: <-MmyJ813OIq7gT3PEQ47iv1tlm3N2Lcr_wgughcBtKQ=.9e25f8e6-d912-42fe-846d-2a8d08367e1e@github.com>

> This is a very interesting issue. Given code like:
> 
> sealed interface Sealed {
>     record R1() implements Sealed {}
>     record R2() implements Sealed {}
> }
> 
> 
> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  adding regression test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17284/files
  - new: https://git.openjdk.org/jdk/pull/17284/files/29702777..637f4241

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

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

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

From vromero at openjdk.org  Wed Jan 10 03:48:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 10 Jan 2024 03:48:42 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations [v3]
In-Reply-To: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
Message-ID: <EPb-RfRaI8CvQxrRcgDSVUgBqhein-fcLB4C2wx4pRw=.a1f01c26-e843-4f28-b114-149f8c8a48d4@github.com>

> This is a very interesting issue. Given code like:
> 
> sealed interface Sealed {
>     record R1() implements Sealed {}
>     record R2() implements Sealed {}
> }
> 
> 
> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  updating regression test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17284/files
  - new: https://git.openjdk.org/jdk/pull/17284/files/637f4241..20ff11bc

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

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

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

From tschatzl at openjdk.org  Wed Jan 10 09:33:33 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 10 Jan 2024 09:33:33 GMT
Subject: RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and
 ZGC
In-Reply-To: <TheBK5j1_x_5u4ZOTvt7PInq9-DtuVP_UqD56xJHwkI=.d8ca4215-a6bb-4db9-aca1-3879f794c7d4@github.com>
References: <wNBxgUUHmRvTmfnaOFfC0QSmZZA6_dHeKfo6jZvEZpc=.d7558c32-f9d3-4e17-9729-19ce1ace9eb9@github.com>
 <TheBK5j1_x_5u4ZOTvt7PInq9-DtuVP_UqD56xJHwkI=.d8ca4215-a6bb-4db9-aca1-3879f794c7d4@github.com>
Message-ID: <GksRVo1UQlXGD5NmYAK6wMSoS9w7pVdMoXWJ_0jz4Zw=.0c34b412-412c-4505-9e2b-67c7fd6d0b59@github.com>

On Tue, 9 Jan 2024 16:15:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
>> 
>> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
>> 
>> Testing: local testing
>> 
>> Hth,
>>   Thomas
>
> FWIW - I don't mind the change. I think it is more for the GC people if they are fine with some GC requiring more memory than others, or if they want to investigate further. The validity of the javadoc-related test is not affected by this, I think.

>From @lahodaj:

> FWIW - I don't mind the change. I think it is more for the GC people if they are fine with some GC requiring more memory than others, or if they want to investigate further. 

For garbage collection algorithms it is no different to other memory management algorithms to require different amount of slack to operate efficiently or at all.
A very, very old rule of thumb mentions like 30% of total heap capacity should be live set size for optimal operation (there can be huge variances depending on allocation rate and absolute heap capacity). This is a bit low imho, but at 85%+ (>660/768M) there is a large risk that one or the other algorithm just bails out. (To be clear, e.g. Parallel GC and GenZGC can probably be configured to require less, but that would make the change unnecessarily tied to it).

>The validity of the javadoc-related test is not affected by this, I think.

No.

>From @jonathan-gibbons :
> There is a history that I would now consider an anti-pattern of LangTools tests running on monotonically increasing data sets. [...] While the practice will for-sure lead to monotonically increasing run times, we could/should make sure that it doesn't lead to monotonically increasing memory requirements. 

There is also the possibility that this test has never been run with anything but the default collector before (and/or the problem with other collectors never been reported previously), that is, G1, which has very little minimum intrinsic requirements to limp along (jshell has been introduced in java 9, which is incidentally the version when G1 got to be the default collector). The test file has been introduced in 9, but parts of the test only later.

The test also seems to access src.zip ("all java files") which is not fixed, but not sure if it ever e.g. builds a javadoc model of the whole sources in memory. I think not afaict after a very brief look.

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

PR Comment: https://git.openjdk.org/jdk/pull/17304#issuecomment-1884485705

From jlahoda at openjdk.org  Wed Jan 10 16:36:24 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Jan 2024 16:36:24 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations [v3]
In-Reply-To: <EPb-RfRaI8CvQxrRcgDSVUgBqhein-fcLB4C2wx4pRw=.a1f01c26-e843-4f28-b114-149f8c8a48d4@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
 <EPb-RfRaI8CvQxrRcgDSVUgBqhein-fcLB4C2wx4pRw=.a1f01c26-e843-4f28-b114-149f8c8a48d4@github.com>
Message-ID: <U70hFiovw3Zpqq3LexiyeHja15hhfoX7ANgjkh97UlI=.2ac56563-1b0d-4457-add1-205f86e4a0ec@github.com>

On Wed, 10 Jan 2024 03:48:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This is a very interesting issue. Given code like:
>> 
>> sealed interface Sealed {
>>     record R1() implements Sealed {}
>>     record R2() implements Sealed {}
>> }
>> 
>> 
>> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating regression test

While it might be nicer to have the order implied, I can see that's not really easy to achieve in case of arbitrary order of completion. So, this looks OK to me. One suggestion for consideration slightly simplify the code. No re-review needed if the suggestion is accepted.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1334:

> 1332: 
> 1333:         public void addPermittedSubclass(ClassSymbol csym, int pos) {
> 1334:             if (isPermittedExplicit) {

If I understand it properly, the codepaths to add implicitly and explicitly declared permitted subclasses are completely different. And when the permitted subclasses are explicit, the `addPermittedSubclass` won't be called.

For consideration: just using `Assert.check(!isPermittedExplicit)`, drop the if.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17284#pullrequestreview-1813636466
PR Review Comment: https://git.openjdk.org/jdk/pull/17284#discussion_r1447632286

From prappo at openjdk.org  Wed Jan 10 16:58:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 10 Jan 2024 16:58:35 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <Y0EAERMlyTDnVQ8gB_V0Bcf_rLtaCY9yGTlxEV8dj74=.f69372bf-e3a2-4e90-babb-47d5d35b798c@github.com>

On Wed, 8 Nov 2023 15:57:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> test/langtools/tools/javac/doctree/DocCommentTester.java line 1012:
> 
>> 1010: //            }
>> 1011: //            return null;
>> 1012: //        }
> 
> Debugging leftover?

If you want to leave it for debugging you can make it private and uncomment.

> test/langtools/tools/javac/doctree/MarkdownTest.java line 555:
> 
>> 553: //  block tags: empty
>> 554: //]
>> 555: //*/
> 
> Just to clarify: it is supposed to be commented out, right? If uncommented, this test fails with a slightly different error.

Please update the DocComment printout in that commented out test: the actual content is different. It would be nice if the test were passing at least at the moment of its initial commit.

Here's what I see locally:


Expect:
DocComment[DOC_COMMENT, pos:0
  firstSentence: 1
    Summary[SUMMARY, pos:4
      summary: 1
        Erroneous[ERRONEOUS, pos:14, prefPos:37
          code: compiler.err.dc.unterminated.inline.tag
          body: abc_`|_def}|_rest_`more`
        ]
    ]
  body: empty
  block tags: empty
]

Found:
DocComment[DOC_COMMENT, pos:0
  firstSentence: 1
    Summary[SUMMARY, pos:1
      summary: 1
        Erroneous[ERRONEOUS, pos:11, prefPos:32
          code: compiler.err.dc.unterminated.inline.tag
          body: abc_`|def}|rest_`more`
        ]
    ]
  body: empty
  block tags: empty
]

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1447662029
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1447659363

From wxiao at openjdk.org  Wed Jan 10 17:07:31 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 10 Jan 2024 17:07:31 GMT
Subject: [jdk22] RFR: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
Message-ID: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>

Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
It is a clean backport.

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

Commit messages:
 - Backport 8ae309ebacd6947bbad2ef168ca13702e1cba099

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

PR: https://git.openjdk.org/jdk22/pull/55

From vromero at openjdk.org  Wed Jan 10 17:27:39 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 10 Jan 2024 17:27:39 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations [v4]
In-Reply-To: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
Message-ID: <XoZOHAd5CoRk9oYjkU9__Cplm61rHF-12XKMnzSbB3w=.4933cf4d-c8e6-43ea-a2ef-e2517fcae0d5@github.com>

> This is a very interesting issue. Given code like:
> 
> sealed interface Sealed {
>     record R1() implements Sealed {}
>     record R2() implements Sealed {}
> }
> 
> 
> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17284/files
  - new: https://git.openjdk.org/jdk/pull/17284/files/20ff11bc..b9703e8c

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

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

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

From vromero at openjdk.org  Wed Jan 10 17:27:43 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 10 Jan 2024 17:27:43 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations [v3]
In-Reply-To: <U70hFiovw3Zpqq3LexiyeHja15hhfoX7ANgjkh97UlI=.2ac56563-1b0d-4457-add1-205f86e4a0ec@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
 <EPb-RfRaI8CvQxrRcgDSVUgBqhein-fcLB4C2wx4pRw=.a1f01c26-e843-4f28-b114-149f8c8a48d4@github.com>
 <U70hFiovw3Zpqq3LexiyeHja15hhfoX7ANgjkh97UlI=.2ac56563-1b0d-4457-add1-205f86e4a0ec@github.com>
Message-ID: <4ybO9uUr9qItqIZBihetOcFCkfOjAf3oKhw9m4qUNfs=.5d860245-a78a-4bc3-81e1-05e48a826146@github.com>

On Wed, 10 Jan 2024 16:32:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updating regression test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1334:
> 
>> 1332: 
>> 1333:         public void addPermittedSubclass(ClassSymbol csym, int pos) {
>> 1334:             if (isPermittedExplicit) {
> 
> If I understand it properly, the codepaths to add implicitly and explicitly declared permitted subclasses are completely different. And when the permitted subclasses are explicit, the `addPermittedSubclass` won't be called.
> 
> For consideration: just using `Assert.check(!isPermittedExplicit)`, drop the if.

sure will do, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17284#discussion_r1447693614

From liach at openjdk.org  Wed Jan 10 17:35:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Jan 2024 17:35:22 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations [v4]
In-Reply-To: <XoZOHAd5CoRk9oYjkU9__Cplm61rHF-12XKMnzSbB3w=.4933cf4d-c8e6-43ea-a2ef-e2517fcae0d5@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
 <XoZOHAd5CoRk9oYjkU9__Cplm61rHF-12XKMnzSbB3w=.4933cf4d-c8e6-43ea-a2ef-e2517fcae0d5@github.com>
Message-ID: <E6hnhEpyhiK58U4RbvRsWiUZackAqI_i1IM2dRVpQc0=.29d7d0d8-6e50-40ff-9334-eaa8a596f8e6@github.com>

On Wed, 10 Jan 2024 17:27:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This is a very interesting issue. Given code like:
>> 
>> sealed interface Sealed {
>>     record R1() implements Sealed {}
>>     record R2() implements Sealed {}
>> }
>> 
>> 
>> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1360:

> 1358:             permitted.clear();
> 1359:             for (Symbol csym : permittedSubs) {
> 1360:                 permitted.add(new PermittedClassWithPos(csym, 0));

If we have multiple `0` positions in the list, a future `addPermittedSubclass` call may not produce a deterministic list if it's called with pos `0`, as that's how `Arrays.binarySearch` behaves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17284#discussion_r1447712012

From wxiao at openjdk.org  Wed Jan 10 17:48:30 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 10 Jan 2024 17:48:30 GMT
Subject: [jdk22] RFR: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
Message-ID: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>

Better Error Handling for Jar Tool When Processing Non-existent Files. <br>

It needs to be backported to JDK22.

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

Commit messages:
 - Backport 8ae309ebacd6947bbad2ef168ca13702e1cba099

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

PR: https://git.openjdk.org/jdk22/pull/56

From wxiao at openjdk.org  Wed Jan 10 17:49:26 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 10 Jan 2024 17:49:26 GMT
Subject: [jdk22] Withdrawn: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>
References: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>
Message-ID: <ptqyOlhc28L4kXBNqCIBLRk4_l3wzwAsQjV7Z6Rw4PQ=.e290d458-3703-43ab-a28b-fbaab5366fb3@github.com>

On Wed, 10 Jan 2024 17:02:03 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
> It is a clean backport.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk22/pull/55

From wxiao at openjdk.org  Wed Jan 10 17:49:25 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 10 Jan 2024 17:49:25 GMT
Subject: [jdk22] RFR: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>
References: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>
Message-ID: <avU6U_TpsH21nXELI7l_4cozCKhM-8wIw__jRnWW0qw=.0eed0aa3-75ac-4675-ab9c-358c2176e200@github.com>

On Wed, 10 Jan 2024 17:02:03 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
> It is a clean backport.

Use this PR instead https://github.com/openjdk/jdk22/pull/56.

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

PR Comment: https://git.openjdk.org/jdk22/pull/55#issuecomment-1885333004

From vromero at openjdk.org  Wed Jan 10 17:55:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 10 Jan 2024 17:55:31 GMT
Subject: RFR: 8322477: order of subclasses in the permits clause can differ
 between compilations [v4]
In-Reply-To: <E6hnhEpyhiK58U4RbvRsWiUZackAqI_i1IM2dRVpQc0=.29d7d0d8-6e50-40ff-9334-eaa8a596f8e6@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
 <XoZOHAd5CoRk9oYjkU9__Cplm61rHF-12XKMnzSbB3w=.4933cf4d-c8e6-43ea-a2ef-e2517fcae0d5@github.com>
 <E6hnhEpyhiK58U4RbvRsWiUZackAqI_i1IM2dRVpQc0=.29d7d0d8-6e50-40ff-9334-eaa8a596f8e6@github.com>
Message-ID: <uNXdk5IPj6k9M0qxVT4jmMzIZAvuhwAzX-Ff9dUPM9g=.3a954831-b794-406e-a23f-fedf05460dff@github.com>

On Wed, 10 Jan 2024 17:32:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1360:
> 
>> 1358:             permitted.clear();
>> 1359:             for (Symbol csym : permittedSubs) {
>> 1360:                 permitted.add(new PermittedClassWithPos(csym, 0));
> 
> If we have multiple `0` positions in the list, a future `addPermittedSubclass` call may not produce a deterministic list if it's called with pos `0`, as that's how `Arrays.binarySearch` behaves.

right but as Jan mentioned we will be calling either `addPermittedSubclass` or `setPermittedSubclasses` not both. We need to set a default position value if none is provided, `0` is a good option or `-1`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17284#discussion_r1447730402

From vromero at openjdk.org  Wed Jan 10 17:55:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 10 Jan 2024 17:55:33 GMT
Subject: Integrated: 8322477: order of subclasses in the permits clause can
 differ between compilations
In-Reply-To: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
References: <Pt5Ra1VE4LBlXtB8fIKMwfZxCPNOAUnhDTZaWPoM2F0=.3e077e1b-2718-4a30-8ecb-b6f40700f968@github.com>
Message-ID: <akf3ACdp4xqgRQi6Cach9zOyG8qUaBhzbHNutEPR92A=.35f2fa57-9ebf-4dd8-b5bf-59215d4b9e3a@github.com>

On Fri, 5 Jan 2024 17:42:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This is a very interesting issue. Given code like:
> 
> sealed interface Sealed {
>     record R1() implements Sealed {}
>     record R2() implements Sealed {}
> }
> 
> 
> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
> 
> TIA

This pull request has now been integrated.

Changeset: 5ba69e17
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ba69e17340cf44194c080a38219c6e150418fcf
Stats:     107 lines in 9 files changed: 68 ins; 1 del; 38 mod

8322477: order of subclasses in the permits clause can differ between compilations

Reviewed-by: jlahoda

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

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

From vicente.romero at oracle.com  Wed Jan 10 18:02:19 2024
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 10 Jan 2024 13:02:19 -0500
Subject: [private] Re: [External] : Re: [Bug] javac gives
 non-deterministic output (for sealed interface with records)
In-Reply-To: <f76187b4-d814-4c62-a3b5-773e47acd0e9@oracle.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <CAMvdueB2EuRnCcmm+OwLiGk0SRgJWboHr60ToY0RrvRZBo42Cg@mail.gmail.com>
 <2e0d46a5-add6-4c98-b359-f8a4a4a6f1e2@oracle.com>
 <CAMvdueDrZKX-C+BWHMQZiROk9758AUuB3nSypxYRjcOnOPeO9w@mail.gmail.com>
 <32306a3d-1376-4ec8-850b-f78eae103f1f@oracle.com>
 <f5cbda02-5e09-4654-a154-a87a4167ee14@oracle.com>
 <CAMvdueCcvYW0AqjopkARAkhumbWjpATjjbQ=7xYtv7MUijY80A@mail.gmail.com>
 <c60aed74-3648-4767-bb48-7ccf4eaa0577@oracle.com>
 <CAMvdueD=aoSOeuHudAo2nXCDODPoBwcUUsfnr3rfLLwvaM_aOQ@mail.gmail.com>
 <f54edd21-db84-4529-b75c-af493b5046c5@oracle.com>
 <CAMvdueDeVVvMqOCMsLLMxGog5anCb7y4JYm99584kD_dKKUeRQ@mail.gmail.com>
 <8c26af0d-b0c5-410f-8db7-96e209707c90@oracle.com>
 <CAMvdueB8epAEr1scqCiXs-xAC--0zxW2NAeQDBb12uew_t7gKA@mail.gmail.com>
 <f5e8277e-355f-4ad3-b977-036ab2d8f528@oracle.com>
 <CAMvdueCSdLeVmVa=drMxBOhm0M8-c5iugtnTcuRXUmedo_NJBQ@mail.gmail.com>
 <f76187b4-d814-4c62-a3b5-773e47acd0e9@oracle.com>
Message-ID: <5d93c106-00d9-4342-a103-7ac4082bb4d4@oracle.com>

Hi Przemek,

The fix to the issue you reported [1] has been integrated in our master 
repo. Thanks a lot for all the help tracking this very interesting issue 
down,

Thanks,
Vicente

[1] https://bugs.openjdk.org/browse/JDK-8322477
[2] https://github.com/openjdk/jdk

On 1/9/24 11:04, Vicente Romero wrote:
> Hi Przemek,
>
> this is pretty good, thanks for the reproducer. I will update the bug 
> entry,
>
> Thanks,
> Vicente
>
> On 1/9/24 03:48, Przemek Bielicki wrote:
>> Hey Vicente,
>>
>> My fellow Gradle JVM Platform engineer (Octavia Togami) created a 
>> reproducer: 
>> https://github.com/octylFractal/javac-permitted-ordering-bug 
>> <https://urldefense.com/v3/__https://github.com/octylFractal/javac-permitted-ordering-bug__;!!ACWV5N9M2RV99hQ!OuIjNEls9z95A5Eq458IZEjWn1nlxh3v2_wq3jYrPj61R62YNl6fUCJ_-Docq9rmUcpTVMWgk3iQLhvjhTxyZA$>
>> Her first analysis was: "Looking at the stacktraces, it appears that 
>> when it's ordered properly, the subclasses of the sealed type are 
>> visited as part of their parent; but when it's ordered incorrectly, 
>> they're visited as part of resolving the type of a variable somewhere 
>> else."
>> Eventually she says: "This is not in any way a Gradle bug. It has to 
>> do with ordering of other files that use the sealed type and its 
>> subclasses."
>>
>> Can you please verify this on your end and update the JIRA ticket 
>> with the latest findings?
>>
>> Thanks,
>> Przemek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240110/81334edf/attachment-0001.htm>

From pbielicki at gmail.com  Thu Jan 11 08:23:01 2024
From: pbielicki at gmail.com (Przemek Bielicki)
Date: Thu, 11 Jan 2024 09:23:01 +0100
Subject: [private] Re: [External] : Re: [Bug] javac gives
 non-deterministic output (for sealed interface with records)
In-Reply-To: <5d93c106-00d9-4342-a103-7ac4082bb4d4@oracle.com>
References: <CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com>
 <CAMvdueB2EuRnCcmm+OwLiGk0SRgJWboHr60ToY0RrvRZBo42Cg@mail.gmail.com>
 <2e0d46a5-add6-4c98-b359-f8a4a4a6f1e2@oracle.com>
 <CAMvdueDrZKX-C+BWHMQZiROk9758AUuB3nSypxYRjcOnOPeO9w@mail.gmail.com>
 <32306a3d-1376-4ec8-850b-f78eae103f1f@oracle.com>
 <f5cbda02-5e09-4654-a154-a87a4167ee14@oracle.com>
 <CAMvdueCcvYW0AqjopkARAkhumbWjpATjjbQ=7xYtv7MUijY80A@mail.gmail.com>
 <c60aed74-3648-4767-bb48-7ccf4eaa0577@oracle.com>
 <CAMvdueD=aoSOeuHudAo2nXCDODPoBwcUUsfnr3rfLLwvaM_aOQ@mail.gmail.com>
 <f54edd21-db84-4529-b75c-af493b5046c5@oracle.com>
 <CAMvdueDeVVvMqOCMsLLMxGog5anCb7y4JYm99584kD_dKKUeRQ@mail.gmail.com>
 <8c26af0d-b0c5-410f-8db7-96e209707c90@oracle.com>
 <CAMvdueB8epAEr1scqCiXs-xAC--0zxW2NAeQDBb12uew_t7gKA@mail.gmail.com>
 <f5e8277e-355f-4ad3-b977-036ab2d8f528@oracle.com>
 <CAMvdueCSdLeVmVa=drMxBOhm0M8-c5iugtnTcuRXUmedo_NJBQ@mail.gmail.com>
 <f76187b4-d814-4c62-a3b5-773e47acd0e9@oracle.com>
 <5d93c106-00d9-4342-a103-7ac4082bb4d4@oracle.com>
Message-ID: <CAMvdueDzve4c1HrzCEphMB0BqcBnyyiHunhU7nSNzEW1EXU9yA@mail.gmail.com>

Hi Vicente,

This is great news! Will this fix be backported to earlier JDK versions? If
so, then until which version? Ideally I would expect this fix to be a part
of JDK 11.

Cheers,
Przemek

On Wed, Jan 10, 2024 at 7:02?PM Vicente Romero <vicente.romero at oracle.com>
wrote:

> Hi Przemek,
>
> The fix to the issue you reported [1] has been integrated in our master
> repo. Thanks a lot for all the help tracking this very interesting issue
> down,
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.org/browse/JDK-8322477
> [2] https://github.com/openjdk/jdk
>
> On 1/9/24 11:04, Vicente Romero wrote:
>
> Hi Przemek,
>
> this is pretty good, thanks for the reproducer. I will update the bug
> entry,
>
> Thanks,
> Vicente
>
> On 1/9/24 03:48, Przemek Bielicki wrote:
>
> Hey Vicente,
>
> My fellow Gradle JVM Platform engineer (Octavia Togami) created a
> reproducer: https://github.com/octylFractal/javac-permitted-ordering-bug
> <https://urldefense.com/v3/__https://github.com/octylFractal/javac-permitted-ordering-bug__;!!ACWV5N9M2RV99hQ!OuIjNEls9z95A5Eq458IZEjWn1nlxh3v2_wq3jYrPj61R62YNl6fUCJ_-Docq9rmUcpTVMWgk3iQLhvjhTxyZA$>
> Her first analysis was: "Looking at the stacktraces, it appears that when
> it's ordered properly, the subclasses of the sealed type are visited as
> part of their parent; but when it's ordered incorrectly, they're visited as
> part of resolving the type of a variable somewhere else."
> Eventually she says: "This is not in any way a Gradle bug. It has to do
> with ordering of other files that use the sealed type and its subclasses."
>
> Can you please verify this on your end and update the JIRA ticket with the
> latest findings?
>
> Thanks,
> Przemek
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240111/2fa32db6/attachment.htm>

From abimpoudis at openjdk.org  Thu Jan 11 11:51:30 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 11 Jan 2024 11:51:30 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v38]
In-Reply-To: <3JvLQvkIPnCIy1JtnD6hKyVg2GvDUDvUqog8R7gbGJc=.21d55c1c-1476-4eea-8720-5424eda66678@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <3JvLQvkIPnCIy1JtnD6hKyVg2GvDUDvUqog8R7gbGJc=.21d55c1c-1476-4eea-8720-5424eda66678@github.com>
Message-ID: <vhA8S4Czyp6I1yFT8qb3Hgi_KStSLTygVN7mpxGWpJo=.e5d27f96-7874-4315-b77a-85090edbc55c@github.com>

On Thu, 14 Dec 2023 11:04:09 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Cleanup
>  - Merge branch 'master' into primitive-patterns
>  - Remove trailing spaces
>  - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns
>  - Fixed switch in the cases of unboxing and widening
>  - Merge branch 'JDK-8319220' into primitive-patterns
>  - Merge branch 'master' into JDK-8319220
>  - reflecting review comment: fixing letter case.
>  - Reflecting review feedback.
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/d2ba3b1e...a03fea7c

Keep open ???

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1886978935

From jpai at openjdk.org  Thu Jan 11 12:01:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Jan 2024 12:01:28 GMT
Subject: [jdk22] RFR: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>
References: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>
Message-ID: <x5Hf4lpIYjBa8KFCSqVx9DzkrcnUEKzoutck0BIrGfA=.84642aaa-ee2e-4cdd-9da0-f85f629f1331@github.com>

On Wed, 10 Jan 2024 17:42:21 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
> 
> It needs to be backported to JDK22.

Clean backport of a P3 bug fix.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/56#pullrequestreview-1815371942

From wxiao at openjdk.org  Thu Jan 11 12:19:29 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Thu, 11 Jan 2024 12:19:29 GMT
Subject: [jdk22] Integrated: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>
References: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>
Message-ID: <yQaueagMVIvdR7giUl0JyTtO9jPR2ASBz-l3Lnn-sK8=.2a72d9b6-bc5f-48c4-a046-28e8accb1893@github.com>

On Wed, 10 Jan 2024 17:42:21 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
> 
> It needs to be backported to JDK22.

This pull request has now been integrated.

Changeset: 3daa936f
Author:    Weibing Xiao <wxiao at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/3daa936f2da4da853e0cbe8dcb081e3a7509734f
Stats:     86 lines in 2 files changed: 84 ins; 0 del; 2 mod

8318971: Better Error Handling for Jar Tool When Processing Non-existent Files

Reviewed-by: jpai
Backport-of: 8ae309ebacd6947bbad2ef168ca13702e1cba099

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

PR: https://git.openjdk.org/jdk22/pull/56

From prappo at openjdk.org  Thu Jan 11 15:05:26 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 11 Jan 2024 15:05:26 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <ag2dtvCzHnO2BJ1nv1d1c9I-zq4mz898SbOFC7ucmGQ=.0103ad58-bf4b-428f-a44d-d9b537954ba1@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <0ZVcM3Dh7buB7gX0Fznz29_x1I6gWJjPsao2vxVOuus=.49fe643e-a1e1-45c4-a7b5-6161721a1649@github.com>
 <ag2dtvCzHnO2BJ1nv1d1c9I-zq4mz898SbOFC7ucmGQ=.0103ad58-bf4b-428f-a44d-d9b537954ba1@github.com>
Message-ID: <YTwMGeCC_bbsCL9AczaN0lzD3yEjMZnTQB2CLQ1Thak=.35ce13fc-b522-4e6e-8cd7-6d7f7280aaee@github.com>

On Wed, 15 Nov 2023 00:21:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> the output with the break iterator is now the same as the default simple iterator

I can confirm that. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1448993923

From prappo at openjdk.org  Thu Jan 11 15:10:29 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 11 Jan 2024 15:10:29 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <3N5guZn5SiRlcjZrWQt0JbqUMJr79EcQ999JpVtx8-k=.cf3f71c3-4fcb-4958-b673-76b6b9797cd5@github.com>

On Wed, 8 Nov 2023 16:24:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> test/langtools/tools/javac/classfiles/attributes/deprecated/DeprecatedTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8042261 8298405
> 
> This comment is not for this line, but for two compiler tests for `@deprecated` javadoc tag. It seemed quite contextual place to put it.
> 
> Did I miss it, or you are planning to add a javadoc test that verifies that `@deprecated` appearing in a `///` comment has no [special meaning] it has in classic `/** */` comments?
> 
> [special meaning]: https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java#L1639-L1653

Ping. I do believe that it's important to have such a test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1449001056

From prappo at openjdk.org  Thu Jan 11 15:38:23 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 11 Jan 2024 15:38:23 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v2]
In-Reply-To: <0xaWRD1add432FW4NF8dhU3gi3q6BzPbhdnSMWKs2CY=.6ed27293-a889-4802-8e3f-e9f5d0a030e2@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vwdVQznmh6zobqCK-FAgF2lm-OXjsBw3uzrNGz2RBU4=.561f8895-fb52-4a9c-b67b-7279435abdc4@github.com>
 <f6GZy-khspCeJNrtdfOofvHDNHAnS05sIifH0P8kTrs=.d13e1487-accf-468f-9894-84df4b862640@github.com>
 <FdSxw9wT96YfeOcMM7N3uJZlcM9_c0GRzLpVCXSLdZE=.9cc8914d-b6c6-405a-9a8d-731deda75272@github.com>
 <0xaWRD1add432FW4NF8dhU3gi3q6BzPbhdnSMWKs2CY=.6ed27293-a889-4802-8e3f-e9f5d0a030e2@github.com>
Message-ID: <oOjXFBl9kz1qSTVAjZ0qPTJFWwtB7pUeOWeeogvF0A4=.ba1a8d40-63c3-4d1b-ba64-00ceb9914524@github.com>

On Wed, 15 Nov 2023 18:48:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hmm.   teeny-tiny "yes", dominated by a big "BUT".
>> 
>> There is no easy simple direct support for Markdown in user-defined taglets, since there is no way to know the syntactic form of user-defined tags. We might be able to do something for user-defined tags given on the command line (with `-tag`) but in general we should be wary and think carefully about putting any headings inside any block tag, because block tags get converted to HTML definition lists.
>> 
>> ---
>> 
>> Separately, generally speaking, the Markdown headings in any doc comment should start at level 1 and increase from there. An offset will be added during translation to give the correct heading level in the overall page. There is a guard in the code (but no warning as yet) if you "overflow" heading level 6.  For example, if you go overboard and use `#### my heading` in the comment for a method (where the offset for headings is 3), it will (currently) max out at level 6.  Generating warnings for questionable Markdown is somewhat against the spirit of Markdown. It would seem a bit weird to warn against an obscure case like overflowing headings when the general policy for real errors is no message and just show the literal text.
>
> Update: 
> Markdown in tags defined by the user on the command-line works pretty much as expected: not great, but not bad.
> 
> Headings in user-defined tags work, but are semantically questionable, since the tags are generated inside a definition list (which itself is maybe questionable, these days.). There is (currently) no special accommodation for the "virtual heading" in the presentation of the block tag.
> 
> Headings, sections, HTML 5, Markdown and taglets are a complicated mess, and probably better discussed and tracked in JBS.

Understood. FWIW, here are a few examples of headings in user-defined tags in JDK:

https://github.com/openjdk/jdk/blob/a6785e4d633908596ddb6de6d2eeab1c9ebdf2c3/src/java.base/share/classes/java/math/BigDecimal.java#L229-L239

https://github.com/openjdk/jdk/blob/ddbbd36e4b064b9e7433f0a55973d72cd6dbc0d3/src/java.xml/share/classes/module-info.java#L402-L420

https://github.com/openjdk/jdk/blob/6f6486e97743eadfb20b4175e1b4b2b05b59a17a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#L1089-L1093

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1449039906

From vromero at openjdk.org  Thu Jan 11 18:06:25 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Jan 2024 18:06:25 GMT
Subject: [jdk22] RFR: 8322003: JShell - Incorrect type inference in lists
 of records implementing interfaces
In-Reply-To: <unDiUeYUhMebrhby6sinjdgfHWys9rvLZfsPyxCxMf4=.88b1b6fa-dc97-4718-9a95-0c7e9eaacb9b@github.com>
References: <unDiUeYUhMebrhby6sinjdgfHWys9rvLZfsPyxCxMf4=.88b1b6fa-dc97-4718-9a95-0c7e9eaacb9b@github.com>
Message-ID: <vLht1Fq0AAMwzXm7TbXTxzN-UjUJ9imjSwHVhfnDP-I=.b8cff230-5e21-4421-baa8-f7cb5a35a322@github.com>

On Mon, 8 Jan 2024 14:21:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [57a65fe4](https://github.com/openjdk/jdk/commit/57a65fe436a3617d64bbf0b02d4c7f7c2551448f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 8 Jan 2024 and was reviewed by Vicente Romero.
> 
> Thanks!

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/40#pullrequestreview-1816186760

From vromero at openjdk.org  Thu Jan 11 18:41:24 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Jan 2024 18:41:24 GMT
Subject: RFR: 8323057: Recoverable errors may be reported before
 unrecoverable errors when annotation processing is skipped
In-Reply-To: <y5JKBbYhNFeC86Gx_yyJmYJfD_Xm-JBJyIkB7TvE9tA=.9e0b8faa-e529-418d-a71f-97be22ef42d5@github.com>
References: <y5JKBbYhNFeC86Gx_yyJmYJfD_Xm-JBJyIkB7TvE9tA=.9e0b8faa-e529-418d-a71f-97be22ef42d5@github.com>
Message-ID: <BaqA98lF5FON9UFe3ZrQo3sBDAzAJs1XcHECjjcwQOc=.10ec28eb-1f3a-4dbb-9e86-5806c23cb3f4@github.com>

On Fri, 5 Jan 2024 19:51:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When annotation processing is requested, some errors reported during enter may be resolved by the annotation processors. So, javac stashes the errors from enter aside. When an error that cannot be resolved by annotation processing is found in the stashed errors, the annotation processors all the errors will be printed.
> 
> This may be confusing if there's one important non-resolvable error, hidden among many errors that would be resolved by the annotation processors. The proposal herein is therefore to first print the not-recoverable errors, and only then the recoverable errors, when the errors are stashed away and then re-printed.

looks good, minor suggestion, there is no need for a re-review

test/langtools/tools/javac/processing/errors/TestErrorOrder.java line 69:

> 67:         Path src = outerBase.resolve("src");
> 68:         tb.writeJavaFiles(src,
> 69:                           "package t;\n" +

please consider using text blocks

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17286#pullrequestreview-1816278586
PR Review Comment: https://git.openjdk.org/jdk/pull/17286#discussion_r1449255942

From darcy at openjdk.org  Thu Jan 11 19:31:32 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 11 Jan 2024 19:31:32 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v3]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <Mc3XxUDvAG2mp-kSeO77IV1jVZTYcVsxWkKCZIDBLIU=.c80c3915-ae81-4a34-8dd4-a8b4ed010bf3@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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:

 - Merge branch 'master' into JDK-8042981
 - Intermediate commit; add stripAnnotations method.
 - Merge branch 'master' into JDK-8042981
 - Merge branch 'master' into JDK-8042981
 - Update visitor; all langtools regression tests pass.
 - Merge branch 'master' into JDK-8042981
 - JDK-8042981: Strip type annotations in Types' utility methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/0dacb981..61cf9717

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

  Stats: 2480805 lines in 22680 files changed: 1276520 ins; 922281 del; 282004 mod
  Patch: https://git.openjdk.org/jdk/pull/8984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8984/head:pull/8984

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

From darcy at openjdk.org  Fri Jan 12 00:13:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Jan 2024 00:13:04 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v4]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <8Y9bRg1fmwtK_bixYBf8pk80bhh3yVpKyEnZTi6k4mY=.050ec663-77b1-4407-a5d6-7c8b5a12e6b3@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Add changes from Liam.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/61cf9717..78d4c299

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

  Stats: 73 lines in 4 files changed: 13 ins; 37 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/8984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8984/head:pull/8984

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

From darcy at openjdk.org  Fri Jan 12 07:27:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Jan 2024 07:27:26 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v5]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <9mAqXAAjAmhg90Yf_7fuGFridDdRXJ78q1vlJx50T9c=.d0eb9c81-6cbf-4459-b36c-18058722bb50@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Update implementation and tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/78d4c299..e9200876

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

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

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

From darcy at openjdk.org  Fri Jan 12 07:32:33 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Jan 2024 07:32:33 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <SmxFus18vupJDEKfNW0SqDIqOESjBluzzkVoBU-0sjI=.70449656-c489-40dd-9155-8deef51f1157@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <SmxFus18vupJDEKfNW0SqDIqOESjBluzzkVoBU-0sjI=.70449656-c489-40dd-9155-8deef51f1157@github.com>
Message-ID: <HKQnlDrLOlKHBTQe_v4BNXl8bOo6k7Bepq5ECJCrfDQ=.45e38475-0722-4916-846f-8c7b8610367b@github.com>

On Wed, 3 Jan 2024 23:26:22 GMT, Liam Miller-Cushon <cushon 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 three additional commits since the last revision:
>> 
>>  - Update visitor; all langtools regression tests pass.
>>  - Merge branch 'master' into JDK-8042981
>>  - JDK-8042981: Strip type annotations in Types' utility methods
>
> I cleaned up the approach described in https://github.com/openjdk/jdk/pull/8984#issuecomment-1806211798 and have a draft with those changes applied on top of the work in this PR: https://github.com/openjdk/jdk/pull/17256. It passes the tests added in this PR, with the disabled cases re-enabled.
> 
> @jddarcy what do you think of that approach?

After adding some code from @cushon to get past a roadblock, the PR is back on track. Thanks @cushon!

Please (re)review the API and implementation changes.

The testing seems to have uncovered a bug where the methods

getAnnotation(Class<A> annotationType)
getAnnotationsByType(Class<A> annotationType) getAnnotationsByType(Class<A> annotationType)

when called on a TypeMirror always return an empty result even when annotations are present. Commenting out the overrides in Type and using the code from AnnoConstruct seems to fix this and all regression tests pass. I can file a separate bug for that issue however and remove the portions of TestAnnotationStripping that would fail without that fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/8984#issuecomment-1888564131

From jlahoda at openjdk.org  Fri Jan 12 10:04:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 12 Jan 2024 10:04:22 GMT
Subject: [jdk22] Integrated: 8322003: JShell - Incorrect type inference in
 lists of records implementing interfaces
In-Reply-To: <unDiUeYUhMebrhby6sinjdgfHWys9rvLZfsPyxCxMf4=.88b1b6fa-dc97-4718-9a95-0c7e9eaacb9b@github.com>
References: <unDiUeYUhMebrhby6sinjdgfHWys9rvLZfsPyxCxMf4=.88b1b6fa-dc97-4718-9a95-0c7e9eaacb9b@github.com>
Message-ID: <jF78TRaABhn3him63Wu6ZI15ccX-wtLYDXqGZXHzlic=.2242d702-4d6b-4b08-9a4c-10c21b392cc7@github.com>

On Mon, 8 Jan 2024 14:21:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [57a65fe4](https://github.com/openjdk/jdk/commit/57a65fe436a3617d64bbf0b02d4c7f7c2551448f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 8 Jan 2024 and was reviewed by Vicente Romero.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 07a8911c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/07a8911ce8d6c0e791544c0fd38e04d9a5ca2cd5
Stats:     121 lines in 3 files changed: 87 ins; 11 del; 23 mod

8322003: JShell - Incorrect type inference in lists of records implementing interfaces

Reviewed-by: vromero
Backport-of: 57a65fe436a3617d64bbf0b02d4c7f7c2551448f

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

PR: https://git.openjdk.org/jdk22/pull/40

From prappo at openjdk.org  Fri Jan 12 12:39:27 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 12 Jan 2024 12:39:27 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
Message-ID: <hL9JteagRGnCieZjoYUuDU9wdyr9w4RrHGxDCQgS2Ts=.809da3ed-6515-4f2e-b56e-bd9d632810f7@github.com>

On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

On CommonMark.

* `jdk.internal.md` contains 133 files, the vast majority of which are from commonmark-java 0.21.0. According to https://github.com/commonmark/commonmark-java/releases 0.21.0 is the latest/current release; good.

  Questions:

  * Did we take the tagged commit or mainline at some point after the tagged commit? If it's the latter, we need to take the tagged version.

  * What's the difference between those commonmark-java files in this PR and official commonmark-java? In other words, how do we adapt them? It would be nice to have a description of the procedure or a script to update those files.

* `jdk.internal.md` exports packages to `jdk.jshell`. A question for @lahodaj, who maintains `jdk.jshell`: when do we need to create a new PR similar to that withdrawn https://github.com/openjdk/jdk/pull/11936?

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 2:

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

It's surprising to see 2005.

src/jdk.internal.md/share/classes/module-info.java line 29:

> 27:  * Internal support for Markdown.
> 28:  *
> 29:  * @since 22

Suggestion:

 * @since 23

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

PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1818084469
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450342017
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450347103

From cushon at openjdk.org  Fri Jan 12 20:34:26 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 12 Jan 2024 20:34:26 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v5]
In-Reply-To: <9mAqXAAjAmhg90Yf_7fuGFridDdRXJ78q1vlJx50T9c=.d0eb9c81-6cbf-4459-b36c-18058722bb50@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <9mAqXAAjAmhg90Yf_7fuGFridDdRXJ78q1vlJx50T9c=.d0eb9c81-6cbf-4459-b36c-18058722bb50@github.com>
Message-ID: <SsjkE1hqUyFTuqsaFlVavv7ShxYJfgV6_MT-JGlKd8s=.1b9760df-eab0-4da1-a03b-9f697a54a515@github.com>

On Fri, 12 Jan 2024 07:27:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update implementation and tests.

Thanks!

re: `TypeMirror #TypeMirror#getAnnotation*(Class)`, I agree that's a bug, and also that it probably warrants a separate issue.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 429:

> 427:     }
> 428:     //where
> 429:         private static final TypeMapping<Void> stripMetadata = new StructuralTypeMapping<Void>() {

It might be worth adding an implementation comment here to note that the visitor only needs to handle are the ones where 'contained' types can be annotated, which are the cases described by JVMS 4.7.20.2: classes (for type parameters and enclosing types), wildcards, and arrays.

test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 140:

> 138:     }
> 139: 
> 140:     void checkEmptyAnnotations(AnnotatedConstruct ac) {

I think it would be valuable to expand the assertion to visit contained types, and assert that none of the contained types have annotations:


diff --git a/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java b/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
index c627f41ba0b..8bb3c7cd3a8 100644
--- a/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
+++ b/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
@@ -82,10 +82,10 @@ public boolean process(Set<? extends TypeElement> annotations,
 
                 System.err.print("\tgetArrayType()");
                 ArrayType arrayType = typeUtils.getArrayType(returnType);
-                checkEmptyAnnotations(arrayType);
                 /*
                  * "Annotations on the component type are preserved."
                  */
+                checkEmptyAnnotations((AnnotatedConstruct) arrayType);
                 checkEqualTypeAndAnnotations(returnType, arrayType.getComponentType());
 
                 if (!returnType.getKind().isPrimitive()) {
@@ -93,10 +93,14 @@ public boolean process(Set<? extends TypeElement> annotations,
                      * "Annotations on the bounds are preserved."
                      */
                     WildcardType wcType;
-                    checkEmptyAnnotations(wcType = typeUtils.getWildcardType(returnType, null));
+                    System.err.print("\tgetWildcardType(returnType, null)");
+                    wcType = typeUtils.getWildcardType(returnType, null);
+                    checkEmptyAnnotations((AnnotatedConstruct) wcType);
                     checkEqualTypeAndAnnotations(returnType, wcType.getExtendsBound());
 
-                    checkEmptyAnnotations(wcType = typeUtils.getWildcardType(null,       returnType));
+                    System.err.print("\tgetWildcardType(null, returnType)");
+                    wcType = typeUtils.getWildcardType(null, returnType);
+                    checkEmptyAnnotations((AnnotatedConstruct) wcType);
                     checkEqualTypeAndAnnotations(returnType, wcType.getSuperBound());
                 }
 
@@ -158,6 +162,54 @@ void checkEmptyAnnotations(AnnotatedConstruct ac) {
         }
     }
 
+    void checkEmptyAnnotations(TypeMirror ac) {
+        System.err.println("\t" + ac);
+        if (ac == null) {
+            return;
+        }
+        new SimpleTypeVisitor14<Void, Void>() {
+            @Override
+            protected Void defaultAction(TypeMirror t, Void o) {
+                checkEmptyAnnotations((AnnotatedConstruct) t);
+                return null;
+            }
+
+            @Override
+            public Void visitArray(ArrayType t, Void o) {
+                scan(t.getComponentType());
+                return super.visitArray(t, o);
+            }
+
+            @Override
+            public Void visitDeclared(DeclaredType t, Void o) {
+                scan(t.getEnclosingType());
+                t.getTypeArguments().stream().forEach(this::scan);
+                return super.visitDeclared(t, o);
+            }
+
+            @Override
+            public Void visitTypeVariable(TypeVariable t, Void o) {
+                // the bounds correspond to the type variable declaration, not its use
+                // scan(t.getUpperBound());
+                // scan(t.getLowerBound());
+                return super.visitTypeVariable(t, o);
+            }
+
+            @Override
+            public Void visitWildcard(WildcardType t, Void o) {
+                scan(t.getExtendsBound());
+                scan(t.getSuperBound());
+                return super.visitWildcard(t, o);
+            }
+
+            private void scan(TypeMirror t) {
+                if (t != null) {
+                    visit(t);
+                }
+            }
+        }.visit(ac);
+    }
+
     void checkEqualTypeAndAnnotations(TypeMirror tm1, TypeMirror tm2) {
         if (!typeUtils.isSameType(tm1, tm2)) {
             failures++;

test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 189:

> 187:     public static  String @TestTypeAnnotation("foo5")[]  foo5() {return null;}
> 188: 
> 189:     public static  java.util. @TestTypeAnnotation("foo6") Set < @TestTypeAnnotation("foo7") String> foo6() {return null;}

Consider adding a case for type variable usages:


public static <@TestTypeAnnotation("foo8") T extends @TestTypeAnnotation("foo9") String> @TestTypeAnnotation("foo10") T foo8() {return null;}


This one raises a couple of questions about type annotations associated with the declaration of the type variable. I think probably only the annotations on the use of the type var need to be stripped, not the declaration.

Currently this causes failures for the assertion that `asElement()` has no annotations, because the annotations are only stripped from the type corresponding to the use of the type variable, not from the corresponding declaration.

Similarly `TypeVariable#getUpperBound` would report annotations.

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

PR Review: https://git.openjdk.org/jdk/pull/8984#pullrequestreview-1818788534
PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1450775093
PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1450896707
PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1450895756

From darcy at openjdk.org  Fri Jan 12 20:46:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Jan 2024 20:46:26 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v5]
In-Reply-To: <SsjkE1hqUyFTuqsaFlVavv7ShxYJfgV6_MT-JGlKd8s=.1b9760df-eab0-4da1-a03b-9f697a54a515@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <9mAqXAAjAmhg90Yf_7fuGFridDdRXJ78q1vlJx50T9c=.d0eb9c81-6cbf-4459-b36c-18058722bb50@github.com>
 <SsjkE1hqUyFTuqsaFlVavv7ShxYJfgV6_MT-JGlKd8s=.1b9760df-eab0-4da1-a03b-9f697a54a515@github.com>
Message-ID: <XQPSBmTJ0YNe6ix3-cY05u2Yij3Z3kAuUZh-kp199GI=.f55809f2-0333-4977-9f8d-0653a3866d27@github.com>

On Fri, 12 Jan 2024 20:31:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Thanks!
> 
> re: `TypeMirror #TypeMirror#getAnnotation*(Class)`, I agree that's a bug, and also that it probably warrants a separate issue.

Filed JDK-8323684: TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results.

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

PR Comment: https://git.openjdk.org/jdk/pull/8984#issuecomment-1889925740

From darcy at openjdk.org  Sat Jan 13 01:33:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 13 Jan 2024 01:33:21 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v6]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <tBjXSSPNbmltKGbQODgFLWzX9qe7yg2nDj0wWqQpt3g=.631c2220-9535-4288-8849-0e30c5b82b33@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

 - Merge branch 'master' into JDK-8042981
 - Update implementation and tests.
 - Add changes from Liam.
 - Merge branch 'master' into JDK-8042981
 - Intermediate commit; add stripAnnotations method.
 - Merge branch 'master' into JDK-8042981
 - Merge branch 'master' into JDK-8042981
 - Update visitor; all langtools regression tests pass.
 - Merge branch 'master' into JDK-8042981
 - JDK-8042981: Strip type annotations in Types' utility methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/e9200876..342b091f

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

  Stats: 11303 lines in 313 files changed: 6324 ins; 3810 del; 1169 mod
  Patch: https://git.openjdk.org/jdk/pull/8984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8984/head:pull/8984

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

From darcy at openjdk.org  Sat Jan 13 01:36:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 13 Jan 2024 01:36:49 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v7]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <aSS36VMmdn3avZKAfsUVqs6vT6PBH3RpKm5P7LfLiHc=.db5ee3de-8b2f-4e05-a79f-1350760f1a11@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Revert changes that will be done under JDK-8323684.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/342b091f..e389818d

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

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

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

From darcy at openjdk.org  Sat Jan 13 02:00:25 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 13 Jan 2024 02:00:25 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v5]
In-Reply-To: <XQPSBmTJ0YNe6ix3-cY05u2Yij3Z3kAuUZh-kp199GI=.f55809f2-0333-4977-9f8d-0653a3866d27@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <9mAqXAAjAmhg90Yf_7fuGFridDdRXJ78q1vlJx50T9c=.d0eb9c81-6cbf-4459-b36c-18058722bb50@github.com>
 <SsjkE1hqUyFTuqsaFlVavv7ShxYJfgV6_MT-JGlKd8s=.1b9760df-eab0-4da1-a03b-9f697a54a515@github.com>
 <XQPSBmTJ0YNe6ix3-cY05u2Yij3Z3kAuUZh-kp199GI=.f55809f2-0333-4977-9f8d-0653a3866d27@github.com>
Message-ID: <HPMbCkWNR570_zwgea7BGfyxpdCsfUnTp0nRPEVTVtI=.1df7a01f-1433-417f-887b-9f8683fcb2d1@github.com>

On Fri, 12 Jan 2024 20:43:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Thanks!
> > re: `TypeMirror #TypeMirror#getAnnotation*(Class)`, I agree that's a bug, and also that it probably warrants a separate issue.
> 
> Filed JDK-8323684: TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results.

Review of that fix will occur under https://github.com/openjdk/jdk/pull/17410

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

PR Comment: https://git.openjdk.org/jdk/pull/8984#issuecomment-1890248448

From attila.kelemen85 at gmail.com  Sat Jan 13 12:38:06 2024
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Sat, 13 Jan 2024 13:38:06 +0100
Subject: ? extend T[] is not considered an array
Message-ID: <CAKDaPBc2ZnGWpuy2WTFZHe7H2ZHqr0+OUj=WAwtwMqWZuv2F7A@mail.gmail.com>

Hi,

I have not found anything in JLS specifically mentioning this. So, I'm not
sure if it is intentional, but the following code does not compile (in any
versions of Java I have tried):

```
interface ForEachable<T> {
  void forEach(Consumer<? super T> consumer);
}

List<String> wrongMethod(ForEachable<? extends String[]> arrays) {
  var result = new ArrayList<String>();
  arrays.forEach(array -> result.add(array[0]));
  return result;
}
```

or in an even simpler example:

```
String first(Supplier<? extends String[]> supplier) {
  return supplier.get()[0];
}
```

The compiler complains about `array[0]` that `array` is not an array. While
I get that the compiler cannot assume that there is no subtype of
`String[]`, but even if there was one, I would expect it to be an
array, and be indexable.

An obvious workaround is to assign `array` to a new local variable, but it
is awkward to do.

Is this behavior a bug, or something required by the JLS?

Thanks,
Attila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240113/dfcf267f/attachment.htm>

From liach at openjdk.org  Sun Jan 14 16:33:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 14 Jan 2024 16:33:36 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type
Message-ID: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>

API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html

Additional questions:
1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

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

Commit messages:
 - redundant line
 - Fix a test in langtools, copyright year
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - Implementation cleanup, test update
 - Merge branch 'master' into fix/typearg-model
 - Formatting
 - Nuke signatureString and fix test fialure from bad cast
 - Adjust the type arg model to better represent the embodied type

Changes: https://git.openjdk.org/jdk/pull/16517/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323707
  Stats: 130 lines in 6 files changed: 46 ins; 32 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/16517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16517/head:pull/16517

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

From duke at openjdk.org  Sun Jan 14 16:33:37 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 14 Jan 2024 16:33:37 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type
In-Reply-To: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
Message-ID: <_yj_29oiqHBjdbwOPy8MC4uPQBScN5FpsG-Ah_QTW-g=.db327b2e-9f22-4804-973f-3e631ce8e782@github.com>

On Mon, 6 Nov 2023 07:30:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
> 
> Additional questions:
> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

src/java.base/share/classes/jdk/internal/classfile/Signature.java line 252:

> 250:         public static TypeArg.Bounded bounded(Bounded.WildcardIndicator wildcard, RefTypeSig boundType) {
> 251:             return new SignaturesImpl.TypeArgImpl(wildcard, boundType);
> 252:         }

Suggestion:

        public static TypeArg.Bounded bounded(Bounded.WildcardIndicator wildcard, RefTypeSig boundType) {
            requireNonNull(wildcard);
            requireNonNull(boundType);
            return new SignaturesImpl.TypeArgImpl(wildcard, boundType);
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1405426776

From duke at openjdk.org  Mon Jan 15 02:33:21 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 15 Jan 2024 02:33:21 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type
In-Reply-To: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
Message-ID: <ucgottWGuHTVA_NdHh2ihwUieoQBMknwHLfQetEqyB8=.1bfca408-a3ee-47ad-90eb-ac2d14b128ad@github.com>

On Mon, 6 Nov 2023 07:30:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
> 
> Additional questions:
> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

src/java.base/share/classes/java/lang/classfile/Signature.java line 219:

> 217:                  * no wildcard (empty), an exact type
> 218:                  */
> 219:                 DEFAULT,

I?m?personally in?favour of?naming this?`NONE`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1451876203

From prappo at openjdk.org  Mon Jan 15 14:04:44 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 15 Jan 2024 14:04:44 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
Message-ID: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>

On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

Here's another batch of comments. Please update `@since 22` to `@since 23` throughout this PR.

src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 257:

> 255:      *
> 256:      * @implSpec Visits the provided {@code RawTextTree} node
> 257:      * by calling {@code visitOther(node, p)}.

Nit: for consistency with the rest of the file, reorder `@param`-`@return` block with the `@implSpec` tag:

Suggestion:

     *
     * @implSpec Visits the provided {@code RawTextTree} node
     * by calling {@code visitOther(node, p)}.
     *
     * @param node the node being visited
     * @param p a parameter value
     * @return a result value

src/jdk.compiler/share/classes/com/sun/source/doctree/RawTextTree.java line 40:

> 38:  * @apiNote
> 39:  * This class may be used to represent tree nodes containing
> 40:  * {@linkplain DocTree.Kind#MARKDOWN Markdown} text.

This means that there is one-to-many relationship between `RawTextTree` and `DocTree.KIND`. This in turn perpetuates the pattern of checking the kind followed by casting as opposed to more modern `instanceof` pattern matching. There's nothing wrong with it per se, however I wonder what the rationale is for leaving this part of the API open-ended. Is it to support other types of raw text in the future?

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 299:

> 297:      * @param code the code
> 298:      * @return a {@code RawTextTree} object
> 299:      * @throws IllegalArgumentException if the kind is not a recognized kind for raw text

This method's implementation also throws `NullPointerException` if kind is null, which is unusual for these methods. You can either add `@throws`, or workaround it by using `String.valueOf(kind)` instead of `kind.toString()` down in the implementation.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 303:

> 301:      * @since 22
> 302:      */
> 303:     RawTextTree newRawTextTree(DocTree.Kind kind, String code) throws IllegalArgumentException;

It's unusual for a JDK method to declare a runtime exception.

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 97:

> 95:      */
> 96:     public enum CommentKind {
> 97:         /** The style of comments whose lines are prefixed by{@code ///}. */

Suggestion:

        /** The style of comments whose lines are prefixed by {@code ///}. */

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 104:

> 102: 
> 103:     /**
> 104:      * {@return the style of the documentation comment associated with a tree node.}

Period is redundant:
Suggestion:

     * {@return the style of the documentation comment associated with a tree node}

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 111:

> 109:      * @since 22
> 110:      */
> 111:     public abstract CommentKind getDocCommentKind(TreePath path);

This method's specification says nothing about `null` that the implementation can return.

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 157:

> 155:      * @param fileObject the content container
> 156:      * @return the doc comment tree
> 157:      * @throws IllegalArgumentException if the file type is not supported

It seems like this exception could've been thrown before, it's just that you have documented it for the first time. This might be important for CSR.

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 182:

> 180:      * @return the doc comment tree
> 181:      * @throws IOException if an exception occurs
> 182:      * @throws IllegalArgumentException if the file type is not supported

Ditto on this newly documented exception.

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 193:

> 191:      *
> 192:      * Supported file types are HTML files and Markdown files.
> 193:      * Future releases may support additional file types.

Good catch on this missing statement, which is present in other similar methods.

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 297:

> 295: 
> 296:     /**
> 297:      * A functional interface to transform a {@code DocCommentTree}.

Re: functional interface

If you mean it, annotate it with `@FunctionalInterface`. If you don't, simply remove that phrase.

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 309:

> 307:      * The standard implementation of this interface supports an extended form
> 308:      * of reference links in Markdown comments, such that if the label for a
> 309:      * reference link is undefined and matches a reference to a program

Suggestion:

     * reference link is undefined and resembles a reference to a program

src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 329:

> 327:          * Transforms a documentation comment tree.
> 328:          *
> 329:          * @param trees an instance of the {@link Trees} utility interface.

Suggestion:

         * @param trees an instance of the {@link Trees} utility interface

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 992:

> 990: 
> 991:     private static boolean isMarkdownFile(FileObject fo) {
> 992:         return fo.getName().endsWith(".md");

I wonder why you decided to (re)implement those methods using file extension matching. Is it because we don't want to introduce anything Markdown-related to this method that was used to implement `isHtmlFile` previously?
 https://github.com/openjdk/jdk/blob/8eb4e7e07e9211aabcb0f22696e9c572dac7a59f/src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java#L489-L498

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 1080:

> 1078:             }
> 1079: 
> 1080:             private String info(FileObject fo) {

This does not seem to be used; is it for debugging? If so, add your `// DEBUG` comment.

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 1156:

> 1154: 
> 1155:     /**
> 1156:      * {@return the {@linkplain ParserFactory} parser factory}.

Suggestion:

     * {@return the {@linkplain ParserFactory} parser factory}

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 89:

> 87:         POSTAMBLE,
> 88:         /** The rich-text content of an inline documentation comment tag. */
> 89:         INLINE

Do we also need to say something about `.md` files here?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 130:

> 128: 
> 129:     /**
> 130:      * Create a parser for a documentation comment.

Suggestion:

     * Creates a parser for a documentation comment.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 201:

> 199:                 }
> 200:                 newline = true;
> 201:             }

I can see clean LF and CRLF, but no FF; was the latter intentional?

In any case, we should double-check the generated test output to see if there's anything unexpected.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 215:

> 213:                  case '\n', '\r' -> {
> 214:                      return newString(bp, p);
> 215:                  }

Hm... this does not seem to be consistent with `newline` in `nextChar`; should it be consistent?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 241:

> 239:      * <li>{@code PREAMBLE}: the appearance of {@code <body>} (or {@code <main>}),
> 240:      *      as determined by {@link #isEndPreamble()}
> 241:      * <li>{@code BODY}: the beginning of a block tag, or when readung from

Suggestion:

     * <li>{@code BODY}: the beginning of a block tag, or when reading from

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 249:

> 247:      *
> 248:      *
> 249:      *

Suggestion:

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1000:

> 998:      * <li>cdata: {@code <![CDATA[ ... ]]>}
> 999:      * </ul>
> 1000:      *  or

Dangling "or".

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1065:

> 1063: 
> 1064:                     if (accept('/')) { // (Spec. 3.7)
> 1065:                         if (accept('/')) { // Markdown comment

I believe that some of the changes in `com/sun/tools/javac/parser` were contributed by @JimLaskey. If so, don't forget to add him as a co-author: `/contributor add jlaskey`.

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

PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1818383901
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1451611443
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450636952
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452278438
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450595553
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450524385
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450644783
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450706952
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450697324
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450708532
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450712757
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450721951
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450716256
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450724201
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450753241
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450756727
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450759909
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452387246
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452310521
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452316008
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452319517
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452329926
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452327712
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452322576
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450780454

From shade at openjdk.org  Mon Jan 15 16:13:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Jan 2024 16:13:34 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots
Message-ID: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>

Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 

Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.


% make test TEST=all

Test selection 'all', will run:
* jtreg:test/hotspot/jtreg:all
* jtreg:test/jdk:all
* jtreg:test/langtools:all
* jtreg:test/jaxp:all
* jtreg:test/lib-test:all

(...about 6 hours later...)

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
   jtreg:test/langtools:all                           4469  4469     0     0   
   jtreg:test/jaxp:all                                 513   513     0     0   
   jtreg:test/lib-test:all                              32    32     0     0   
==============================
TEST FAILURE

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

Commit messages:
 - Fix

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

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

From dholmes at openjdk.org  Mon Jan 15 22:41:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Jan 2024 22:41:24 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots
In-Reply-To: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
Message-ID: <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>

On Mon, 15 Jan 2024 11:05:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
> 
> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
> 
> 
> % make test TEST=all
> 
> Test selection 'all', will run:
> * jtreg:test/hotspot/jtreg:all
> * jtreg:test/jdk:all
> * jtreg:test/langtools:all
> * jtreg:test/jaxp:all
> * jtreg:test/lib-test:all
> 
> (...about 6 hours later...)
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>    jtreg:test/langtools:all                           4469  4469     0     0   
>    jtreg:test/jaxp:all                                 513   513     0     0   
>    jtreg:test/lib-test:all                              32    32     0     0   
> ==============================
> TEST FAILURE

Okay - change is harmless with no ongoing maintenance cost.

test/jdk/TEST.groups line 28:

> 26: #
> 27: 
> 28: all = \

Why no `jdk_all` definition in this case?

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17422#pullrequestreview-1822313872
PR Review Comment: https://git.openjdk.org/jdk/pull/17422#discussion_r1452781088

From shade at openjdk.org  Tue Jan 16 08:54:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Jan 2024 08:54:46 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v2]
In-Reply-To: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
Message-ID: <WdUxPU8N87YRubi9_SNLdaAhG0RgqvAIl4mBy9uDXqY=.efcd4142-847b-45fd-824c-813ae70e1a40@github.com>

> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
> 
> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
> 
> 
> % make test TEST=all
> 
> Test selection 'all', will run:
> * jtreg:test/hotspot/jtreg:all
> * jtreg:test/jdk:all
> * jtreg:test/langtools:all
> * jtreg:test/jaxp:all
> * jtreg:test/lib-test:all
> 
> (...about 6 hours later...)
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>    jtreg:test/langtools:all                           4469  4469     0     0   
>    jtreg:test/jaxp:all                                 513   513     0     0   
>    jtreg:test/lib-test:all                              32    32     0     0   
> ==============================
> TEST FAILURE

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  jdk_all and lib_test_all groups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17422/files
  - new: https://git.openjdk.org/jdk/pull/17422/files/7f6797b6..78f5f9bd

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

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

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

From shade at openjdk.org  Tue Jan 16 08:54:49 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Jan 2024 08:54:49 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v2]
In-Reply-To: <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>
Message-ID: <vSyIXgmJRL8Xw7gn1lxXF73UE0pjBuK36HfbQz_0_ws=.8c1243c2-f89e-4d4b-a5cb-942462f5124e@github.com>

On Mon, 15 Jan 2024 22:37:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jdk_all and lib_test_all groups
>
> test/jdk/TEST.groups line 28:
> 
>> 26: #
>> 27: 
>> 28: all = \
> 
> Why no `jdk_all` definition in this case?

Tried not to introduce new `*_all` groups here. `jdk_all` would be the same as `jdk:all`, TBH. But we still can do it for symmetry reasons, see new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17422#discussion_r1453098855

From alanb at openjdk.org  Tue Jan 16 08:54:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 08:54:49 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v2]
In-Reply-To: <vSyIXgmJRL8Xw7gn1lxXF73UE0pjBuK36HfbQz_0_ws=.8c1243c2-f89e-4d4b-a5cb-942462f5124e@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>
 <vSyIXgmJRL8Xw7gn1lxXF73UE0pjBuK36HfbQz_0_ws=.8c1243c2-f89e-4d4b-a5cb-942462f5124e@github.com>
Message-ID: <y9XkWwGo69xwDvQRpigZgw1O7FPSDvZcdxBsR40-lVA=.11eb8a35-d1c9-4685-8078-525b8adbc45e@github.com>

On Tue, 16 Jan 2024 08:47:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/jdk/TEST.groups line 28:
>> 
>>> 26: #
>>> 27: 
>>> 28: all = \
>> 
>> Why no `jdk_all` definition in this case?
>
> Tried not to introduce new `*_all` groups here. `jdk_all` would be the same as `jdk:all`, TBH. But we still can do it for symmetry reasons, see new commit.

"all" looks okay but the comment "Catch-all" suggests something else, shouldn't be "All tests"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17422#discussion_r1453103766

From shade at openjdk.org  Tue Jan 16 09:01:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Jan 2024 09:01:35 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
Message-ID: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>

> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
> 
> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
> 
> 
> % make test TEST=all
> 
> Test selection 'all', will run:
> * jtreg:test/hotspot/jtreg:all
> * jtreg:test/jdk:all
> * jtreg:test/langtools:all
> * jtreg:test/jaxp:all
> * jtreg:test/lib-test:all
> 
> (...about 6 hours later...)
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>    jtreg:test/langtools:all                           4469  4469     0     0   
>    jtreg:test/jaxp:all                                 513   513     0     0   
>    jtreg:test/lib-test:all                              32    32     0     0   
> ==============================
> TEST FAILURE

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Catch-all -> All tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17422/files
  - new: https://git.openjdk.org/jdk/pull/17422/files/78f5f9bd..def2f39b

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

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

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

From shade at openjdk.org  Tue Jan 16 09:01:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Jan 2024 09:01:36 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <y9XkWwGo69xwDvQRpigZgw1O7FPSDvZcdxBsR40-lVA=.11eb8a35-d1c9-4685-8078-525b8adbc45e@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>
 <vSyIXgmJRL8Xw7gn1lxXF73UE0pjBuK36HfbQz_0_ws=.8c1243c2-f89e-4d4b-a5cb-942462f5124e@github.com>
 <y9XkWwGo69xwDvQRpigZgw1O7FPSDvZcdxBsR40-lVA=.11eb8a35-d1c9-4685-8078-525b8adbc45e@github.com>
Message-ID: <MqemqHpjlMv17bxzrzR2lwyWYJvyk7FdQV4sRRdYWkQ=.780a562a-2608-4f9c-a431-52c2a6166c78@github.com>

On Tue, 16 Jan 2024 08:52:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tried not to introduce new `*_all` groups here. `jdk_all` would be the same as `jdk:all`, TBH. But we still can do it for symmetry reasons, see new commit.
>
> "all" looks okay but the comment "Catch-all" suggests something else, shouldn't be "All tests"?

Yeah, we can do "All tests" instead. See new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17422#discussion_r1453113607

From alanb at openjdk.org  Tue Jan 16 09:39:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 09:39:19 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <LWiyL3eeLdiiLvoHRwisxmcEmE4r3i1g0TE1bUFGL0c=.5b11d56b-0805-4067-8fc0-880ef86a5db8@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17422#pullrequestreview-1822902993

From ayang at openjdk.org  Tue Jan 16 10:06:24 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 16 Jan 2024 10:06:24 GMT
Subject: [jdk22] RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel
 GC and ZGC
In-Reply-To: <NtlV8pyVB-05f0dHz2CuiyDoUPqD0ojVA56VJUFDuaE=.384bc7f3-2de0-4249-9736-dbbee8171884@github.com>
References: <NtlV8pyVB-05f0dHz2CuiyDoUPqD0ojVA56VJUFDuaE=.384bc7f3-2de0-4249-9736-dbbee8171884@github.com>
Message-ID: <4-Tjk5uDuLNswWZ9eMu1fYiJkqyVnizGB6HRm1Egs18=.fc302351-36f5-4d85-a486-65032336ca16@github.com>

On Tue, 9 Jan 2024 13:58:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   This pull request contains a backport of commit [52c7ff1d](https://github.com/openjdk/jdk/commit/52c7ff1d81940d6d0d1e3dd7ad0447c80708161c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>   The commit being backported was authored by Thomas Schatzl on 9 Jan 2024 and was reviewed by Albert Mingkun Yang and Axel Boldt-Christmas.
> 
> This is a clean backport.
> 
> Thanks!
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/44#pullrequestreview-1822961062

From sjohanss at openjdk.org  Tue Jan 16 11:01:23 2024
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 16 Jan 2024 11:01:23 GMT
Subject: [jdk22] RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel
 GC and ZGC
In-Reply-To: <NtlV8pyVB-05f0dHz2CuiyDoUPqD0ojVA56VJUFDuaE=.384bc7f3-2de0-4249-9736-dbbee8171884@github.com>
References: <NtlV8pyVB-05f0dHz2CuiyDoUPqD0ojVA56VJUFDuaE=.384bc7f3-2de0-4249-9736-dbbee8171884@github.com>
Message-ID: <Vbedfgct-5T4cw1Rkq3Gec069FfXb3OSK8Uu8yjxlYI=.e07297d4-1c58-4ee6-a5cf-02a5edb373d1@github.com>

On Tue, 9 Jan 2024 13:58:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   This pull request contains a backport of commit [52c7ff1d](https://github.com/openjdk/jdk/commit/52c7ff1d81940d6d0d1e3dd7ad0447c80708161c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>   The commit being backported was authored by Thomas Schatzl on 9 Jan 2024 and was reviewed by Albert Mingkun Yang and Axel Boldt-Christmas.
> 
> This is a clean backport.
> 
> Thanks!
>   Thomas

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/44#pullrequestreview-1823066466

From tschatzl at openjdk.org  Tue Jan 16 11:37:21 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 16 Jan 2024 11:37:21 GMT
Subject: [jdk22] RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel
 GC and ZGC
In-Reply-To: <Vbedfgct-5T4cw1Rkq3Gec069FfXb3OSK8Uu8yjxlYI=.e07297d4-1c58-4ee6-a5cf-02a5edb373d1@github.com>
References: <NtlV8pyVB-05f0dHz2CuiyDoUPqD0ojVA56VJUFDuaE=.384bc7f3-2de0-4249-9736-dbbee8171884@github.com>
 <Vbedfgct-5T4cw1Rkq3Gec069FfXb3OSK8Uu8yjxlYI=.e07297d4-1c58-4ee6-a5cf-02a5edb373d1@github.com>
Message-ID: <lJPNsKy3YJLcrSSAxcSImA3P_BNcOinfsTLlEyuMzxA=.02b891cf-f667-46ff-adff-a5bca8f1a0a4@github.com>

On Tue, 16 Jan 2024 10:58:21 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Hi all,
>> 
>>   This pull request contains a backport of commit [52c7ff1d](https://github.com/openjdk/jdk/commit/52c7ff1d81940d6d0d1e3dd7ad0447c80708161c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>>   The commit being backported was authored by Thomas Schatzl on 9 Jan 2024 and was reviewed by Albert Mingkun Yang and Axel Boldt-Christmas.
>> 
>> This is a clean backport.
>> 
>> Thanks!
>>   Thomas
>
> Marked as reviewed by sjohanss (Reviewer).

Thanks @kstefanj @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk22/pull/44#issuecomment-1893563887

From tschatzl at openjdk.org  Tue Jan 16 11:37:22 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 16 Jan 2024 11:37:22 GMT
Subject: [jdk22] Integrated: 8322330: JavadocHelperTest.java OOMEs with
 Parallel GC and ZGC
In-Reply-To: <NtlV8pyVB-05f0dHz2CuiyDoUPqD0ojVA56VJUFDuaE=.384bc7f3-2de0-4249-9736-dbbee8171884@github.com>
References: <NtlV8pyVB-05f0dHz2CuiyDoUPqD0ojVA56VJUFDuaE=.384bc7f3-2de0-4249-9736-dbbee8171884@github.com>
Message-ID: <vZtWwGqjYOyj2t8ZyMo_qPVJHLvtmu55mUUd9b-9rxs=.06908b4b-39d1-42c3-8c4b-979974d45418@github.com>

On Tue, 9 Jan 2024 13:58:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   This pull request contains a backport of commit [52c7ff1d](https://github.com/openjdk/jdk/commit/52c7ff1d81940d6d0d1e3dd7ad0447c80708161c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>   The commit being backported was authored by Thomas Schatzl on 9 Jan 2024 and was reviewed by Albert Mingkun Yang and Axel Boldt-Christmas.
> 
> This is a clean backport.
> 
> Thanks!
>   Thomas

This pull request has now been integrated.

Changeset: bb43aae6
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/bb43aae61fefea1e50f619f5a81d3242e13b04e9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8322330: JavadocHelperTest.java OOMEs with Parallel GC and ZGC

Reviewed-by: ayang, sjohanss
Backport-of: 52c7ff1d81940d6d0d1e3dd7ad0447c80708161c

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

PR: https://git.openjdk.org/jdk22/pull/44

From darcy at openjdk.org  Tue Jan 16 20:50:25 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Jan 2024 20:50:25 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results
Message-ID: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>

Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.

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

Commit messages:
 - Appease jcheck.
 - Add regression tests.
 - JDK-8323684: TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results

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

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

From darcy at openjdk.org  Tue Jan 16 20:50:25 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Jan 2024 20:50:25 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results
In-Reply-To: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
Message-ID: <HvNW0U0NpdIG4pfvhLsL0-SXR3RkxO8vhtrPVkFdloA=.2b56814e-93ff-42db-a05d-1747444fe2ed@github.com>

On Fri, 12 Jan 2024 22:29:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.

> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.
> ### Progress
> 
>     * [ ]  Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> 
>     * [x]  Change must not contain extraneous whitespace
> 
>     * [x]  Commit message must refer to an issue
> 
> 
> ### Issue
> 
>     * [JDK-8323684](https://bugs.openjdk.org/browse/JDK-8323684): TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results (**Bug** - P4)
> 
> 
> ### Reviewing
> Using `git`
> Using Skara CLI tools
> Using diff file

The regression tests changes as written check both declaration and type annotations. Given that the type annotation code is shared for all kinds of types, the testing on one shape of type should be adequate from a regression testing perspective.

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

PR Comment: https://git.openjdk.org/jdk/pull/17410#issuecomment-1894486674

From darcy at openjdk.org  Tue Jan 16 21:03:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Jan 2024 21:03:54 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results
In-Reply-To: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
Message-ID: <pk1OyYntqOPH6aYXGQRuyRcPmWYci0J2Uagh9wiQIqg=.f1f17218-8241-4ea4-80d1-5c85bc72da2f@github.com>

On Fri, 12 Jan 2024 22:29:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.

CSR up for review: https://bugs.openjdk.org/browse/JDK-8323837

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

PR Comment: https://git.openjdk.org/jdk/pull/17410#issuecomment-1894505040

From darcy at openjdk.org  Tue Jan 16 22:01:58 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Jan 2024 22:01:58 GMT
Subject: RFR: JDK-8323839: Expand use of Messager convenience methods in
 langtools regression tests
Message-ID: <BoLvJndvTU0s7-poCSjOgtXxNBck8N50LdFXzVFDk_E=.4352e719-97e6-492e-a07a-bdf2a224b24a@github.com>

Simple refactoring. Remaining uses of "printMessage" are against Trees (where there are no corresponding convenience methods) or for calls to printMessage where there is not an appropriate convenience method overload, etc.

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

Commit messages:
 - JDK-8323839: Expand use of Messager convenience methods in langtools regression tests

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

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

From jjg at openjdk.org  Tue Jan 16 22:08:51 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Jan 2024 22:08:51 GMT
Subject: RFR: JDK-8323839: Expand use of Messager convenience methods in
 langtools regression tests
In-Reply-To: <BoLvJndvTU0s7-poCSjOgtXxNBck8N50LdFXzVFDk_E=.4352e719-97e6-492e-a07a-bdf2a224b24a@github.com>
References: <BoLvJndvTU0s7-poCSjOgtXxNBck8N50LdFXzVFDk_E=.4352e719-97e6-492e-a07a-bdf2a224b24a@github.com>
Message-ID: <HUL9asVlLEINmXmXiAOfbKF-6uX1zp-P6o7OtOsvk4A=.1164b558-a906-49ac-9bec-6677fb678ca0@github.com>

On Tue, 16 Jan 2024 21:53:27 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple refactoring. Remaining uses of "printMessage" are against Trees (where there are no corresponding convenience methods) or for calls to printMessage where there is not an appropriate convenience method overload, etc.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17454#pullrequestreview-1825333755

From jjg at openjdk.org  Wed Jan 17 00:16:55 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 17 Jan 2024 00:16:55 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v2]
In-Reply-To: <oOjXFBl9kz1qSTVAjZ0qPTJFWwtB7pUeOWeeogvF0A4=.ba1a8d40-63c3-4d1b-ba64-00ceb9914524@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vwdVQznmh6zobqCK-FAgF2lm-OXjsBw3uzrNGz2RBU4=.561f8895-fb52-4a9c-b67b-7279435abdc4@github.com>
 <f6GZy-khspCeJNrtdfOofvHDNHAnS05sIifH0P8kTrs=.d13e1487-accf-468f-9894-84df4b862640@github.com>
 <FdSxw9wT96YfeOcMM7N3uJZlcM9_c0GRzLpVCXSLdZE=.9cc8914d-b6c6-405a-9a8d-731deda75272@github.com>
 <0xaWRD1add432FW4NF8dhU3gi3q6BzPbhdnSMWKs2CY=.6ed27293-a889-4802-8e3f-e9f5d0a030e2@github.com>
 <oOjXFBl9kz1qSTVAjZ0qPTJFWwtB7pUeOWeeogvF0A4=.ba1a8d40-63c3-4d1b-ba64-00ceb9914524@github.com>
Message-ID: <T1KLSyGfObQ4z3a-4QgUjT04p89uCkArdpLdDLqEQMc=.e601055e-ac61-4b8e-a183-9bcca3403796@github.com>

On Thu, 11 Jan 2024 15:35:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Update: 
>> Markdown in tags defined by the user on the command-line works pretty much as expected: not great, but not bad.
>> 
>> Headings in user-defined tags work, but are semantically questionable, since the tags are generated inside a definition list (which itself is maybe questionable, these days.). There is (currently) no special accommodation for the "virtual heading" in the presentation of the block tag.
>> 
>> Headings, sections, HTML 5, Markdown and taglets are a complicated mess, and probably better discussed and tracked in JBS.
>
> Understood. FWIW, here are a few examples of headings in user-defined tags in JDK:
> 
> https://github.com/openjdk/jdk/blob/a6785e4d633908596ddb6de6d2eeab1c9ebdf2c3/src/java.base/share/classes/java/math/BigDecimal.java#L229-L239
> 
> https://github.com/openjdk/jdk/blob/ddbbd36e4b064b9e7433f0a55973d72cd6dbc0d3/src/java.xml/share/classes/module-info.java#L402-L420
> 
> https://github.com/openjdk/jdk/blob/6f6486e97743eadfb20b4175e1b4b2b05b59a17a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#L1089-L1093

Thanks for the examples.

Stylistically, they are maybe questionable.  But we can make sure that something sensible happens, and deal with stylistic issues later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1454239539

From jjg at openjdk.org  Wed Jan 17 00:27:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 17 Jan 2024 00:27:58 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <w8lQxY5brSRBfHvIQq-Qb12dg5HdAKbkfR_5tJIPjkY=.ae66d225-f916-4719-be19-03372eaf8b23@github.com>

On Fri, 12 Jan 2024 15:55:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/RawTextTree.java line 40:
> 
>> 38:  * @apiNote
>> 39:  * This class may be used to represent tree nodes containing
>> 40:  * {@linkplain DocTree.Kind#MARKDOWN Markdown} text.
> 
> This means that there is one-to-many relationship between `RawTextTree` and `DocTree.KIND`. This in turn perpetuates the pattern of checking the kind followed by casting as opposed to more modern `instanceof` pattern matching. There's nothing wrong with it per se, however I wonder what the rationale is for leaving this part of the API open-ended. Is it to support other types of raw text in the future?

Yes, the thinking was to allow it to be open-ended.

In this case, while I think we should specify the ability to use `instanceof`-style checks with this API, I do not think it would be necessary ... there is no need for a subtype for `MarkdownTree`, nor would I expect there to be one for any other kind of raw text.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 89:
> 
>> 87:         POSTAMBLE,
>> 88:         /** The rich-text content of an inline documentation comment tag. */
>> 89:         INLINE
> 
> Do we also need to say something about `.md` files here?

Probably, yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1454249356
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1454250904

From darcy at openjdk.org  Wed Jan 17 00:31:57 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Jan 2024 00:31:57 GMT
Subject: Integrated: JDK-8323839: Expand use of Messager convenience methods in
 langtools regression tests
In-Reply-To: <BoLvJndvTU0s7-poCSjOgtXxNBck8N50LdFXzVFDk_E=.4352e719-97e6-492e-a07a-bdf2a224b24a@github.com>
References: <BoLvJndvTU0s7-poCSjOgtXxNBck8N50LdFXzVFDk_E=.4352e719-97e6-492e-a07a-bdf2a224b24a@github.com>
Message-ID: <YA-k1_yK0apzLWXbaDOG5Rh16gbh9gnMPJehoetfppY=.f39325d3-9bf2-4390-8b45-ab72a413ec8f@github.com>

On Tue, 16 Jan 2024 21:53:27 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple refactoring. Remaining uses of "printMessage" are against Trees (where there are no corresponding convenience methods) or for calls to printMessage where there is not an appropriate convenience method overload, etc.

This pull request has now been integrated.

Changeset: d8b63370
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8b63370f301e6f2d2a43d997b9372f08dfcd2b4
Stats:     9 lines in 5 files changed: 0 ins; 0 del; 9 mod

8323839: Expand use of Messager convenience methods in langtools regression tests

Reviewed-by: jjg

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

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

From shade at openjdk.org  Wed Jan 17 12:12:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Jan 2024 12:12:52 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <gP8SIC8S4GydxFfWZrZJLl-eI8n3tHluDYh7AIjSH2o=.50fb00c7-4556-4dc5-a879-012e7fe80764@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Any other reviews needed for this? Nominally, this changes the test groups in langtools, so maybe @lahodaj or @biboudis want to take a look. For jaxp, @JoeWang-Java, maybe?

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

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1895680732

From abimpoudis at openjdk.org  Wed Jan 17 15:55:43 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 17 Jan 2024 15:55:43 GMT
Subject: RFR: 8323502: javac crash with wrongly typed method block in Flow
Message-ID: <C6MfeaWcvPaWuJdzxoUoxLAEGiq6tUizTO--GuzJpN0=.5d007893-e548-438b-b006-3bc5137b4b55@github.com>

The observation is that the `tree.target` of the RHS's `yield` was not set properly to point at the outer switch. As a result, the assertion was hit in `clearPendingExits` with a wrong set of pending exits.

The cause was that the `tree` was not attributed since `visitSwitchExpression` was short-circuited to `return;` and `visitYield` was never setting the `target`. As a result, `resolveJump` was not actually resolving the jump correctly.

thx @lahodaj for the help!

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

Commit messages:
 - 8323502: javac crash with wrongly typed method block in Flow

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

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

From joehw at openjdk.org  Wed Jan 17 17:41:52 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 17 Jan 2024 17:41:52 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <xTE2qH2lnlJxT7UYzz_pH6FSaHQFQRB1RVZ8FNmRO_w=.12a9d246-7171-43b4-a4eb-977fdd146cfa@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Thanks for the reminder. The new alias is nice, easier to run all tier tests. I often run xml-only as well that includes jaxp_all plus a small set of jaxp tests in jdk_all (test/jdk/javax/xml/jaxp). But that's just me, jdk_all already covers those tests.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17422#pullrequestreview-1827838226

From darcy at openjdk.org  Thu Jan 18 00:13:22 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 00:13:22 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v2]
In-Reply-To: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
Message-ID: <iEptyTMf6ymhFADY63P_pZrd0O4exDHhwhALju-ebmM=.ef2d715d-8d37-44d1-a228-b466d28f6d41@github.com>

> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8323684
 - Appease jcheck.
 - Add regression tests.
 - JDK-8323684: TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17410/files
  - new: https://git.openjdk.org/jdk/pull/17410/files/284fea38..37711749

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

  Stats: 6778 lines in 149 files changed: 2586 ins; 3769 del; 423 mod
  Patch: https://git.openjdk.org/jdk/pull/17410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17410/head:pull/17410

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

From jjg at openjdk.org  Thu Jan 18 00:13:25 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Jan 2024 00:13:25 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v2]
In-Reply-To: <iEptyTMf6ymhFADY63P_pZrd0O4exDHhwhALju-ebmM=.ef2d715d-8d37-44d1-a228-b466d28f6d41@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <iEptyTMf6ymhFADY63P_pZrd0O4exDHhwhALju-ebmM=.ef2d715d-8d37-44d1-a228-b466d28f6d41@github.com>
Message-ID: <eWztIWV1oyT1UWLpO9qB3ds3MGL58tn4PlYVTGc26_E=.e00a9649-b825-4aa4-8560-4e4be875e355@github.com>

On Thu, 18 Jan 2024 00:09:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8323684
>  - Appease jcheck.
>  - Add regression tests.
>  - JDK-8323684: TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results

test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java line 92:

> 90:     PrintWriter out;
> 91:     boolean verbose = true;
> 92:     static Map<String, Class<? extends Annotation>> nameToAnnotation;

this looks questionable ... a mutable static field

test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java line 115:

> 113:                           new NameToAnnotationEntry("BasicAnnoTests.TB",   BasicAnnoTests.TB.class),
> 114:                           new NameToAnnotationEntry("BasicAnnoTests.TC",   BasicAnnoTests.TC.class),
> 115:                           new NameToAnnotationEntry("BasicAnnoTests.TCs",  BasicAnnoTests.TCs.class));

You could maybe simplify this by obtaining the name from the class parameter.

test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java line 318:

> 316:     /**
> 317:      * Verify that an annotation mirror returned by
> 318:      * getAnnotatinMirrors() has a matching annotation from

spelling typo: getAnnotatinMirrors

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456639799
PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456644682
PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456640756

From darcy at openjdk.org  Thu Jan 18 00:13:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 00:13:26 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v2]
In-Reply-To: <eWztIWV1oyT1UWLpO9qB3ds3MGL58tn4PlYVTGc26_E=.e00a9649-b825-4aa4-8560-4e4be875e355@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <iEptyTMf6ymhFADY63P_pZrd0O4exDHhwhALju-ebmM=.ef2d715d-8d37-44d1-a228-b466d28f6d41@github.com>
 <eWztIWV1oyT1UWLpO9qB3ds3MGL58tn4PlYVTGc26_E=.e00a9649-b825-4aa4-8560-4e4be875e355@github.com>
Message-ID: <kKuZTGFvD2hxzzJgUUOhRYPv5TMjHVPwIUhSh6UYu7U=.9098c10f-b1e9-4c80-bee5-af054c4fdc5e@github.com>

On Thu, 18 Jan 2024 00:01:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8323684
>>  - Appease jcheck.
>>  - Add regression tests.
>>  - JDK-8323684: TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results
>
> test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java line 92:
> 
>> 90:     PrintWriter out;
>> 91:     boolean verbose = true;
>> 92:     static Map<String, Class<? extends Annotation>> nameToAnnotation;
> 
> this looks questionable ... a mutable static field

Good point -- the mapping should be static given the method it is used in are static; I'll change to a static final. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456641403

From jjg at openjdk.org  Thu Jan 18 00:13:27 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Jan 2024 00:13:27 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v2]
In-Reply-To: <kKuZTGFvD2hxzzJgUUOhRYPv5TMjHVPwIUhSh6UYu7U=.9098c10f-b1e9-4c80-bee5-af054c4fdc5e@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <iEptyTMf6ymhFADY63P_pZrd0O4exDHhwhALju-ebmM=.ef2d715d-8d37-44d1-a228-b466d28f6d41@github.com>
 <eWztIWV1oyT1UWLpO9qB3ds3MGL58tn4PlYVTGc26_E=.e00a9649-b825-4aa4-8560-4e4be875e355@github.com>
 <kKuZTGFvD2hxzzJgUUOhRYPv5TMjHVPwIUhSh6UYu7U=.9098c10f-b1e9-4c80-bee5-af054c4fdc5e@github.com>
Message-ID: <lqQM88QOb2h8A--3xOE4zrnDwW6NruCbeiPu2qNItKI=.24cf6bd2-6f86-41bf-af60-6734051aaf24@github.com>

On Thu, 18 Jan 2024 00:03:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java line 92:
>> 
>>> 90:     PrintWriter out;
>>> 91:     boolean verbose = true;
>>> 92:     static Map<String, Class<? extends Annotation>> nameToAnnotation;
>> 
>> this looks questionable ... a mutable static field
>
> Good point -- the mapping should be static given the method it is used in are static; I'll change to a static final. Thanks.

is it possible to make this static final with an initializer?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456643600

From darcy at openjdk.org  Thu Jan 18 00:34:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 00:34:21 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v3]
In-Reply-To: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
Message-ID: <1cQBV_wn68b5NA_eCsBvI8gsK6gP8OcnKDpMHubwGgk=.70b8d284-8675-448f-98d6-10ecda0f1d16@github.com>

> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.

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

  Implement review feedback on regression test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17410/files
  - new: https://git.openjdk.org/jdk/pull/17410/files/37711749..9717a54c

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

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

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

From darcy at openjdk.org  Thu Jan 18 00:34:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 00:34:24 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v3]
In-Reply-To: <eWztIWV1oyT1UWLpO9qB3ds3MGL58tn4PlYVTGc26_E=.e00a9649-b825-4aa4-8560-4e4be875e355@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <iEptyTMf6ymhFADY63P_pZrd0O4exDHhwhALju-ebmM=.ef2d715d-8d37-44d1-a228-b466d28f6d41@github.com>
 <eWztIWV1oyT1UWLpO9qB3ds3MGL58tn4PlYVTGc26_E=.e00a9649-b825-4aa4-8560-4e4be875e355@github.com>
Message-ID: <99zKYcqHIDWkHgxOp2kURAGx4tKdIsraKnPa5yM-m-E=.cfaecdf7-b1ca-45c0-b506-16d369b6db83@github.com>

On Thu, 18 Jan 2024 00:09:46 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review feedback on regression test.
>
> test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java line 115:
> 
>> 113:                           new NameToAnnotationEntry("BasicAnnoTests.TB",   BasicAnnoTests.TB.class),
>> 114:                           new NameToAnnotationEntry("BasicAnnoTests.TC",   BasicAnnoTests.TC.class),
>> 115:                           new NameToAnnotationEntry("BasicAnnoTests.TCs",  BasicAnnoTests.TCs.class));
> 
> You could maybe simplify this by obtaining the name from the class parameter.

Might be a case a premature optimization, but I wanted to avoid the repeated reflective operations here.

> test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java line 318:
> 
>> 316:     /**
>> 317:      * Verify that an annotation mirror returned by
>> 318:      * getAnnotatinMirrors() has a matching annotation from
> 
> spelling typo: getAnnotatinMirrors

Fixed; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456669422
PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456669060

From darcy at openjdk.org  Thu Jan 18 00:55:20 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 00:55:20 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v3]
In-Reply-To: <1cQBV_wn68b5NA_eCsBvI8gsK6gP8OcnKDpMHubwGgk=.70b8d284-8675-448f-98d6-10ecda0f1d16@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <1cQBV_wn68b5NA_eCsBvI8gsK6gP8OcnKDpMHubwGgk=.70b8d284-8675-448f-98d6-10ecda0f1d16@github.com>
Message-ID: <YzbFdlgQvQsLHfevLYrUF5t6MjWkgoz95iFVFv8j5EA=.4c8b133e-8565-4af6-bd35-415274509f0a@github.com>

On Thu, 18 Jan 2024 00:34:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback on regression test.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java line 53:

> 51:  * or deletion without notice.</b></p>
> 52:  */
> 53: public abstract sealed class AnnoConstruct implements AnnotatedConstruct

@lahodaj or @vicente-romero-oracle , any thoughts on using sealed/non-sealed in javac in this way?

If I don't here back from you on this point, I'll revert use of sealed/non-sealed before pushing. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456684651

From jjg at openjdk.org  Thu Jan 18 01:04:15 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Jan 2024 01:04:15 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v3]
In-Reply-To: <1cQBV_wn68b5NA_eCsBvI8gsK6gP8OcnKDpMHubwGgk=.70b8d284-8675-448f-98d6-10ecda0f1d16@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <1cQBV_wn68b5NA_eCsBvI8gsK6gP8OcnKDpMHubwGgk=.70b8d284-8675-448f-98d6-10ecda0f1d16@github.com>
Message-ID: <vzazBEKSxTlZ_ecIysthggg0QEhvgDlZ4XGSBLXUU5E=.3b398651-d85d-48a1-9350-a4e66812f7b2@github.com>

On Thu, 18 Jan 2024 00:34:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback on regression test.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17410#pullrequestreview-1828510208

From jjg at openjdk.org  Thu Jan 18 01:04:17 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Jan 2024 01:04:17 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v3]
In-Reply-To: <YzbFdlgQvQsLHfevLYrUF5t6MjWkgoz95iFVFv8j5EA=.4c8b133e-8565-4af6-bd35-415274509f0a@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <1cQBV_wn68b5NA_eCsBvI8gsK6gP8OcnKDpMHubwGgk=.70b8d284-8675-448f-98d6-10ecda0f1d16@github.com>
 <YzbFdlgQvQsLHfevLYrUF5t6MjWkgoz95iFVFv8j5EA=.4c8b133e-8565-4af6-bd35-415274509f0a@github.com>
Message-ID: <EMVn5ZV5_hGXHhS4WenPxasoikxyvANsz59pQkDTOzE=.028cb6e5-9620-40ef-9ce4-e27f9bc0c8b0@github.com>

On Thu, 18 Jan 2024 00:52:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review feedback on regression test.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java line 53:
> 
>> 51:  * or deletion without notice.</b></p>
>> 52:  */
>> 53: public abstract sealed class AnnoConstruct implements AnnotatedConstruct
> 
> @lahodaj or @vicente-romero-oracle , any thoughts on using sealed/non-sealed in javac in this way?
> 
> If I don't here back from you on this point, I'll revert use of sealed/non-sealed before pushing. Thanks.

With my `javadoc` hat on, I would hope that `Element` is never `sealed`. But that's a separate issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456690099

From jjg at openjdk.org  Thu Jan 18 01:04:19 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Jan 2024 01:04:19 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v3]
In-Reply-To: <99zKYcqHIDWkHgxOp2kURAGx4tKdIsraKnPa5yM-m-E=.cfaecdf7-b1ca-45c0-b506-16d369b6db83@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <iEptyTMf6ymhFADY63P_pZrd0O4exDHhwhALju-ebmM=.ef2d715d-8d37-44d1-a228-b466d28f6d41@github.com>
 <eWztIWV1oyT1UWLpO9qB3ds3MGL58tn4PlYVTGc26_E=.e00a9649-b825-4aa4-8560-4e4be875e355@github.com>
 <99zKYcqHIDWkHgxOp2kURAGx4tKdIsraKnPa5yM-m-E=.cfaecdf7-b1ca-45c0-b506-16d369b6db83@github.com>
Message-ID: <0Haah60uuHjXrJ4q82Du08HBLP9CKiooMqDbxFvMrco=.66f21161-ff62-4bae-affd-068a2b2d4c76@github.com>

On Thu, 18 Jan 2024 00:30:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java line 115:
>> 
>>> 113:                           new NameToAnnotationEntry("BasicAnnoTests.TB",   BasicAnnoTests.TB.class),
>>> 114:                           new NameToAnnotationEntry("BasicAnnoTests.TC",   BasicAnnoTests.TC.class),
>>> 115:                           new NameToAnnotationEntry("BasicAnnoTests.TCs",  BasicAnnoTests.TCs.class));
>> 
>> You could maybe simplify this by obtaining the name from the class parameter.
>
> Might be a case a premature optimization, but I wanted to avoid the repeated reflective operations here.

Yeah, the map isn't bad in itself, I just have a knee-jerk reaction to mutable static fields ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456689039

From darcy at openjdk.org  Thu Jan 18 01:22:18 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 01:22:18 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v3]
In-Reply-To: <EMVn5ZV5_hGXHhS4WenPxasoikxyvANsz59pQkDTOzE=.028cb6e5-9620-40ef-9ce4-e27f9bc0c8b0@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <1cQBV_wn68b5NA_eCsBvI8gsK6gP8OcnKDpMHubwGgk=.70b8d284-8675-448f-98d6-10ecda0f1d16@github.com>
 <YzbFdlgQvQsLHfevLYrUF5t6MjWkgoz95iFVFv8j5EA=.4c8b133e-8565-4af6-bd35-415274509f0a@github.com>
 <EMVn5ZV5_hGXHhS4WenPxasoikxyvANsz59pQkDTOzE=.028cb6e5-9620-40ef-9ce4-e27f9bc0c8b0@github.com>
Message-ID: <EdhKSNHBxqyFa5oRTX86d6XUGXtlxjcR2iheSE8wq-8=.053fb247-b7c9-45b6-a305-f88f93461114@github.com>

On Thu, 18 Jan 2024 01:01:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java line 53:
>> 
>>> 51:  * or deletion without notice.</b></p>
>>> 52:  */
>>> 53: public abstract sealed class AnnoConstruct implements AnnotatedConstruct
>> 
>> @lahodaj or @vicente-romero-oracle , any thoughts on using sealed/non-sealed in javac in this way?
>> 
>> If I don't here back from you on this point, I'll revert use of sealed/non-sealed before pushing. Thanks.
>
> With my `javadoc` hat on, I would hope that `Element` is never `sealed`. But that's a separate issue.

If we had sealed types when JSR 269 was in development, there are at least a few places in the API I would have liked to use them, in particular to seal javax.lang.model.UnknownEntityException to only have in-API subclasses.

Given that the javax.lang.model.{element, type} packages were intended to allow multiple independent implementations, the root interfaces like element couldn't be sealed while achieving that goal.

Inside javac, Type and Symbol could also be declared to be sealed rather than non-sealed, possibly at the cost of listed out all the subclasses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456700924

From jlahoda at openjdk.org  Thu Jan 18 11:09:21 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Jan 2024 11:09:21 GMT
Subject: RFR: 8323657: Compilation of snippet results in VerifyError at runtime
 with --release 9 (and above)
Message-ID: <8J6pCJK0dp-jErumOx3a8Ht-KdGJassMr4ZV9Th1DTo=.2090fe6d-a51c-41b0-a095-d1bf7c60b6f8@github.com>

Consider code like:

public class Test {
    public static void main(String... args) {
        System.err.println((test() ? null : null) + "");
    }
    private static boolean test() {
        System.err.println("test called!");
        return true;
    }
}


This should print:

test called!
null


but it prints:

$ java /tmp/Test.java
null


The correct semantics can be achieved by using `--source 8`:

$ java --source 8 /tmp/Test.java
test called!
null


Or `-XDstringConcat=inline` when compiling.

The reason is that when `StringConcat.IndyConstants` converts String concatenation parameters, it will short-circuit any expressions whose type is BOT (i.e. basically the `null` type). But, in this case, the expression that has the BOT type is a complex expression with a side-effect, so short-circuiting it leads to a broken semantics.

My proposal is to "short-circuit" only `null` literals, and generate other expressions normally. There may be some corner cases where we'd generate the expression unnecessarily (if it does not have any side-effect), but looking for side-effects seems unnecessarily complex and fragile given I'd expect non-trivial expressions with the BOT type are very rare. (The only case which comes to mind is exactly the above one - a conditional expressions, whose both result values are `null`.)

Please note that when the expression is incorrectly short-circuited, it may lead to various other effects - the original bug report shows a case where the resulting code does not pass the verification.

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

Commit messages:
 - 8323657: Compilation of snippet results in VerifyError at runtime with --release 9 (and above)

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

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

From asotona at openjdk.org  Thu Jan 18 15:06:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 18 Jan 2024 15:06:19 GMT
Subject: [jdk22] Withdrawn: 8288989: Make tests not depend on the source code
In-Reply-To: <wO9J-09LSt_Y5E-k61I-y5yV8YM66zkhdXAumfKFpF4=.5ee5a321-e91d-4371-9322-97f6bf8b3236@github.com>
References: <wO9J-09LSt_Y5E-k61I-y5yV8YM66zkhdXAumfKFpF4=.5ee5a321-e91d-4371-9322-97f6bf8b3236@github.com>
Message-ID: <o9s9k0faNQf8sjvQ_rGpJN7qfsnSE6wIEWJG0hOUT1c=.963167e1-bd80-4061-a64e-3a91630749f3@github.com>

On Thu, 14 Dec 2023 11:50:26 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 8288989: Make tests not depend on the source code

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk22/pull/13

From darcy at openjdk.org  Thu Jan 18 19:01:32 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 19:01:32 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v4]
In-Reply-To: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
Message-ID: <C_7jQTp3NoiqpV58I-lDcsBMWxcOk4Je76m6tbhTj5U=.c91afc44-62cb-44f0-9db5-82e8cdc8e50a@github.com>

> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.

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

  Remove sealed/non-sealed changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17410/files
  - new: https://git.openjdk.org/jdk/pull/17410/files/9717a54c..25f4f150

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

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

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

From darcy at openjdk.org  Thu Jan 18 19:07:29 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 19:07:29 GMT
Subject: RFR: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results [v3]
In-Reply-To: <EdhKSNHBxqyFa5oRTX86d6XUGXtlxjcR2iheSE8wq-8=.053fb247-b7c9-45b6-a305-f88f93461114@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
 <1cQBV_wn68b5NA_eCsBvI8gsK6gP8OcnKDpMHubwGgk=.70b8d284-8675-448f-98d6-10ecda0f1d16@github.com>
 <YzbFdlgQvQsLHfevLYrUF5t6MjWkgoz95iFVFv8j5EA=.4c8b133e-8565-4af6-bd35-415274509f0a@github.com>
 <EMVn5ZV5_hGXHhS4WenPxasoikxyvANsz59pQkDTOzE=.028cb6e5-9620-40ef-9ce4-e27f9bc0c8b0@github.com>
 <EdhKSNHBxqyFa5oRTX86d6XUGXtlxjcR2iheSE8wq-8=.053fb247-b7c9-45b6-a305-f88f93461114@github.com>
Message-ID: <5nKu9m-rf81QVY23ztvum-w6hGh3rFwDHWJqFxicp9A=.bf8f727d-ae48-4491-ada8-d940d18c1b71@github.com>

On Thu, 18 Jan 2024 01:19:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With my `javadoc` hat on, I would hope that `Element` is never `sealed`. But that's a separate issue.
>
> If we had sealed types when JSR 269 was in development, there are at least a few places in the API I would have liked to use them, in particular to seal javax.lang.model.UnknownEntityException to only have in-API subclasses.
> 
> Given that the javax.lang.model.{element, type} packages were intended to allow multiple independent implementations, the root interfaces like element couldn't be sealed while achieving that goal.
> 
> Inside javac, Type and Symbol could also be declared to be sealed rather than non-sealed, possibly at the cost of listed out all the subclasses.

> @lahodaj or @vicente-romero-oracle , any thoughts on using sealed/non-sealed in javac in this way?
> 
> If I don't here back from you on this point, I'll revert use of sealed/non-sealed before pushing. Thanks.

Reverted sealed/non-sealed changes to get the rest of the fix in and filed JDK-8324167: Use sealed/non-sealed in javac implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1457867646

From darcy at openjdk.org  Thu Jan 18 19:07:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 19:07:31 GMT
Subject: Integrated: JDK-8323684: TypeMirror.{getAnnotationsByType,
 getAnnotation} return uninformative results
In-Reply-To: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
References: <k-4Vg-9qN_Lp9HcC7bx7kTescryw5FvyKESWSrwsUJE=.c753a4cf-352c-4cbe-967f-b5f264c03bc3@github.com>
Message-ID: <82NX8S0SiCNEDZhFB5jJz2_V4ZnOMBuR1uD69dQo_MI=.879fc4ab-7198-4f17-9e51-087e3baf3c7b@github.com>

On Fri, 12 Jan 2024 22:29:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Initial implementation to make TypeMirror.{getAnnotationsByType, getAnnotation} functional; tests to follow.

This pull request has now been integrated.

Changeset: a6c0b107
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6c0b10704311c94c179136b13a4dcc244e8011f
Stats:     146 lines in 2 files changed: 128 ins; 14 del; 4 mod

8323684: TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results

Reviewed-by: jjg

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

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

From darcy at openjdk.org  Thu Jan 18 20:38:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 20:38:31 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v8]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <Awdi5xpvaxPbMyNWhUHMBygd0003PCOjC-hIDUgXTaQ=.1786a28f-86d0-4e34-9fd7-900efab4d950@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8042981
 - Revert changes that will be done under JDK-8323684.
 - Merge branch 'master' into JDK-8042981
 - Update implementation and tests.
 - Add changes from Liam.
 - Merge branch 'master' into JDK-8042981
 - Intermediate commit; add stripAnnotations method.
 - Merge branch 'master' into JDK-8042981
 - Merge branch 'master' into JDK-8042981
 - Update visitor; all langtools regression tests pass.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/81df265e...72b9333a

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

Changes: https://git.openjdk.org/jdk/pull/8984/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8984&range=07
  Stats: 317 lines in 5 files changed: 306 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/8984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8984/head:pull/8984

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

From darcy at openjdk.org  Thu Jan 18 20:42:29 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 20:42:29 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v9]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <S2EgEcoG6RPQacMoPsJhUgy41x3MP83rD4w3O-KoKgc=.d83fc3ad-b447-489c-920f-c83e5dc76184@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Update regression test for fix of JDK-8323684.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/72b9333a..48990299

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

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

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

From darcy at openjdk.org  Fri Jan 19 06:28:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Jan 2024 06:28:24 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v10]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <wWMY82ublOXBU2x-M4n97_thhRmQA-qa8Z2TEWaMgQ8=.f88a5982-133b-495b-b3bf-db6c0c2555e6@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Augment tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/48990299..2ad7f7ec

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

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

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

From prappo at openjdk.org  Fri Jan 19 10:55:36 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Jan 2024 10:55:36 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
Message-ID: <nbcVtqGbWdIttK2ojm2XDkxSXRC1fTgZur491Oza2EQ=.926f9b67-95b2-4eaf-abca-d42e78c251b4@github.com>

On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

Jon, please sync this PR with mainline to resolve conflicts.

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

PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-1900181880

From acobbs at openjdk.org  Fri Jan 19 15:38:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 19 Jan 2024 15:38:39 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v2]
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <PrHxn0WbDa4e5c2FFUe6P8HcqS_6BhJcFcFr1J38VkE=.f96581b9-76e7-460e-b9eb-b49bc701d683@github.com>

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

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

 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Javadoc++
 - Merge branch 'master' into JDK-8317376
 - Several improvements to the 'this' escape analyzer.
   
   - Track direct, indirect, and outer references for all Ref types.
   - Keep type information about all references to improve tracking precision.
   - Track enhanced for() invocations of iterator(), hasNext(), and next().
   - Don't report an escape of a non-public outer instances as a leak.
   - Fix omitted tracking of references from newly instantiated instances.
   - Fix omitted tracking of leaks via lambda return values.
   - Remove unneccesary suppressions of this-escape lint warning.

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

Changes: https://git.openjdk.org/jdk/pull/16208/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16208&range=01
  Stats: 871 lines in 20 files changed: 513 ins; 148 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/16208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208

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

From prappo at openjdk.org  Fri Jan 19 17:53:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Jan 2024 17:53:38 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <flR9QGfiaBhXqoK_j0z67KC8aSbVgmV15-ZGGU1Nfog=.a06bc2dc-7e1c-4586-af4a-80ddfa0cd753@github.com>

On Fri, 12 Jan 2024 17:47:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 992:
> 
>> 990: 
>> 991:     private static boolean isMarkdownFile(FileObject fo) {
>> 992:         return fo.getName().endsWith(".md");
> 
> I wonder why you decided to (re)implement those methods using file extension matching. Is it because we don't want to introduce anything Markdown-related to this method that was used to implement `isHtmlFile` previously?
>  https://github.com/openjdk/jdk/blob/8eb4e7e07e9211aabcb0f22696e9c572dac7a59f/src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java#L489-L498

Musing on this more.

Can/should we, without introducing probably unwelcome `Kind.MD` to `javax.tools.JavaFileObject.Kind`, teach javac to recognise `package.md` similarly to how it recognises legacy `package.html`? If we are aiming for Markdown to be a drop in replacement for traditional javadoc comments, we might want to go the extra mile.

I'm pleased to see that Markdown `-overview` files work just fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1459349927

From prappo at openjdk.org  Fri Jan 19 17:53:43 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Jan 2024 17:53:43 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
Message-ID: <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>

On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 259:

> 257:         LineKind lineKind = textKind == DocTree.Kind.MARKDOWN ? peekLineKind() : null;
> 258: 
> 259:         if (DEBUG) System.err.println("starting content " + showPos(bp) + " " + newline);

Debug output is useful. I wonder if we should consider https://openjdk.org/jeps/264.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1295:

> 1293:             switch (ch) {
> 1294:                 case ' ' -> indent++;
> 1295:                 case '\t' -> indent = 4;

Shouldn't it be like this or it does not matter?
 ```suggestion
                 case '\t' -> indent += 4;

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1336:

> 1334:                     switch (initialLineKind) {
> 1335:                         case CODE_FENCE -> {
> 1336:                             if (lineKind == LineKind.CODE_FENCE && ch == term && count(ch) == count) {

https://spec.commonmark.org/0.30/#example-124 shows that the closing fence may be longer than the opening one: consider `count(ch) >= count`.

That said, I note that on my experiment the resulting output was identical with or without the change I ask you to consider. Perhaps I haven't yet understood how the parsing works.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1377:

> 1375:          * @see <a href="https://spec.commonmark.org/0.30/#atx-headings">ATX Headings</a>
> 1376:          */
> 1377:         ATX_HEADER(Pattern.compile("#{1,6}( .*|$)")),

Nothing wrong here, I just didn't know that an ATX header "opening sequence of # characters" can be followed by the end of line". Interesting.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1421:

> 1419:             case '#', '=', '-', '+', '_', '`', '~' -> {
> 1420:                 String line = peekLine();
> 1421:                 for (LineKind lk : LineKind.values()) {

Nothing wrong here, just noting that this is one more way one can depend on an enum constant order. Change it, and a peeked line kind might change too (e.g. `OTHER` matches everything.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1458858629
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452560905
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452650328
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452629053
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1452632699

From darcy at openjdk.org  Fri Jan 19 18:19:35 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Jan 2024 18:19:35 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v5]
In-Reply-To: <SsjkE1hqUyFTuqsaFlVavv7ShxYJfgV6_MT-JGlKd8s=.1b9760df-eab0-4da1-a03b-9f697a54a515@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <9mAqXAAjAmhg90Yf_7fuGFridDdRXJ78q1vlJx50T9c=.d0eb9c81-6cbf-4459-b36c-18058722bb50@github.com>
 <SsjkE1hqUyFTuqsaFlVavv7ShxYJfgV6_MT-JGlKd8s=.1b9760df-eab0-4da1-a03b-9f697a54a515@github.com>
Message-ID: <YUIChEWroXELFp4YAW6W8YeYLj5rgvXH-qHLIqBq46U=.e5067da6-e5e4-447a-99e9-3d36cbc2f37d@github.com>

On Fri, 12 Jan 2024 20:28:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update implementation and tests.
>
> test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 140:
> 
>> 138:     }
>> 139: 
>> 140:     void checkEmptyAnnotations(AnnotatedConstruct ac) {
> 
> I think it would be valuable to expand the assertion to visit contained types, and assert that none of the contained types have annotations:
> 
> 
> diff --git a/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java b/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
> index c627f41ba0b..8bb3c7cd3a8 100644
> --- a/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
> +++ b/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
> @@ -82,10 +82,10 @@ public boolean process(Set<? extends TypeElement> annotations,
>  
>                  System.err.print("\tgetArrayType()");
>                  ArrayType arrayType = typeUtils.getArrayType(returnType);
> -                checkEmptyAnnotations(arrayType);
>                  /*
>                   * "Annotations on the component type are preserved."
>                   */
> +                checkEmptyAnnotations((AnnotatedConstruct) arrayType);
>                  checkEqualTypeAndAnnotations(returnType, arrayType.getComponentType());
>  
>                  if (!returnType.getKind().isPrimitive()) {
> @@ -93,10 +93,14 @@ public boolean process(Set<? extends TypeElement> annotations,
>                       * "Annotations on the bounds are preserved."
>                       */
>                      WildcardType wcType;
> -                    checkEmptyAnnotations(wcType = typeUtils.getWildcardType(returnType, null));
> +                    System.err.print("\tgetWildcardType(returnType, null)");
> +                    wcType = typeUtils.getWildcardType(returnType, null);
> +                    checkEmptyAnnotations((AnnotatedConstruct) wcType);
>                      checkEqualTypeAndAnnotations(returnType, wcType.getExtendsBound());
>  
> -                    checkEmptyAnnotations(wcType = typeUtils.getWildcardType(null,       returnType));
> +                    System.err.print("\tgetWildcardType(null, returnType)");
> +                    wcType = typeUtils.getWildcardType(null, returnType);
> +                    checkEmptyAnnotations((AnnotatedConstruct) wcType);
>                      checkEqualTypeAndAnnotations(returnType, wcType.getSuperBound());
>                  }
>  
> @@ -158,6 +162,54 @@ void checkEmptyAnnotations(AnnotatedConstruct ac) {
>          }
>      }
>  
> +    void ch...

> I think it would be valuable to expand the assertion to visit contained types, and assert that none of the contained types have annotations:
> 
> ```diff
> diff --git a/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java b/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
> index c627f41ba0b..8bb3c7cd3a8 100644
> --- a/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
> +++ b/test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java
> @@ -82,10 +82,10 @@ public boolean process(Set<? extends TypeElement> annotations,
>  
>                  System.err.print("\tgetArrayType()");
>                  ArrayType arrayType = typeUtils.getArrayType(returnType);
> -                checkEmptyAnnotations(arrayType);
>                  /*
>                   * "Annotations on the component type are preserved."
>                   */
> +                checkEmptyAnnotations((AnnotatedConstruct) arrayType);
>                  checkEqualTypeAndAnnotations(returnType, arrayType.getComponentType());
>  
>                  if (!returnType.getKind().isPrimitive()) {
> @@ -93,10 +93,14 @@ public boolean process(Set<? extends TypeElement> annotations,
>                       * "Annotations on the bounds are preserved."
>                       */
>                      WildcardType wcType;
> -                    checkEmptyAnnotations(wcType = typeUtils.getWildcardType(returnType, null));
> +                    System.err.print("\tgetWildcardType(returnType, null)");
> +                    wcType = typeUtils.getWildcardType(returnType, null);
> +                    checkEmptyAnnotations((AnnotatedConstruct) wcType);
>                      checkEqualTypeAndAnnotations(returnType, wcType.getExtendsBound());
>  
> -                    checkEmptyAnnotations(wcType = typeUtils.getWildcardType(null,       returnType));
> +                    System.err.print("\tgetWildcardType(null, returnType)");
> +                    wcType = typeUtils.getWildcardType(null, returnType);
> +                    checkEmptyAnnotations((AnnotatedConstruct) wcType);
>                      checkEqualTypeAndAnnotations(returnType, wcType.getSuperBound());
>                  }
>  
> @@ -158,6 +162,54 @@ void checkEmptyAnnotations(AnnotatedConstruct ac) {
>          }
>      }
>  
> +    void checkEmptyAnnotations(TypeMirror ac) {
> +        System.err.println("\t" + ac);
> +        if (ac == null) {
> +            return;
> +        }
> +        new SimpleTypeVisitor14<Void, Void>() {
> +            @Override
> +            protected Void defaultAction(TypeMirror t, Void o) {
> +                checkEmptyAnnotations((AnnotatedConstruct) t);
> +                return null;
> +            }
> +
> +            @Override
> +            public Void visitArray(ArrayType t, Void o) {
> +                scan(t.getComponentType());
> +                return super.visitArray(t, o);
> +            }
> +
> +            @Override
> +            public Void visitDeclared(DeclaredType t, Void o) {
> +                scan(t.getEnclosingType());
> +                t.getTypeArguments().stream().forEach(this::scan);
> +                return super.visitDeclared(t, o);
> +            }
> +
> +            @Override
> +            public Void visitTypeVariable(TypeVariable t, Void o) {
> +                // the bounds correspond to the type variable declaration, not its use
> +                // scan(t.getUpperBound());
> +                // scan(t.getLowerBound());
> +                return super.visitTypeVariable(t, o);
> +            }
> +
> +            @Override
> +            public Void visitWildcard(WildcardType t, Void o) {
> +                scan(t.getExtendsBound());
> +                scan(t.getSuperBound());
> +                return super.visitWildcard(t, o);
> +            }
> +
> +            private void scan(TypeMirror t) {
> +                if (t != null) {
> +                    visit(t);
> +                }
> +            }
> +        }.visit(ac);
> +    }
> +
>      void checkEqualTypeAndAnnotations(TypeMirror tm1, TypeMirror tm2) {
>          if (!typeUtils.isSameType(tm1, tm2)) {
>              failures++;
> ```

I've added a variation of the new code to the PR. The checks I added are in line with the properties discussed by the API changes in Types. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1459485081

From jjg at openjdk.org  Fri Jan 19 18:37:48 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Jan 2024 18:37:48 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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

 - Merge with upstream/master
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Address review comments
 - Fix whitespace
 - Improve handling of embedded inline taglets
 - Customize support for Markdown headings
 - JDK-8298405: Support Markdown in Documentation Comments

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=06
  Stats: 21334 lines in 191 files changed: 20679 ins; 266 del; 389 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From cushon at openjdk.org  Fri Jan 19 23:05:43 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 19 Jan 2024 23:05:43 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v10]
In-Reply-To: <wWMY82ublOXBU2x-M4n97_thhRmQA-qa8Z2TEWaMgQ8=.f88a5982-133b-495b-b3bf-db6c0c2555e6@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <wWMY82ublOXBU2x-M4n97_thhRmQA-qa8Z2TEWaMgQ8=.f88a5982-133b-495b-b3bf-db6c0c2555e6@github.com>
Message-ID: <KJCFzyYbRIaN1pB7DFMKv1z0AH-8twKZ2TiS-yN210Y=.5d86d5f3-33f3-4917-81b7-951d42a6d6c5@github.com>

On Fri, 19 Jan 2024 06:28:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Augment tests.

This looks good to me

test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 148:

> 146:         else {
> 147:             // Previously, was likely getting by-catch of annotations
> 148:             // on element declartions, can likely just print the size

typo: `s/declartions/declarations`

And per the explanation in this comment, I think the commented-out case for `jdk.internal.ValueBased` can be removed if the test passes without it

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

Marked as reviewed by cushon (Committer).

PR Review: https://git.openjdk.org/jdk/pull/8984#pullrequestreview-1833537216
PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1459617560

From darcy at openjdk.org  Sat Jan 20 00:07:45 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 20 Jan 2024 00:07:45 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v11]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <mNa0JlfQLC6a82h5De8iVKHJLGAXpgSAA4U331P74sw=.32e45507-0230-428f-b28c-8d5329392616@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Clean up regression test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/2ad7f7ec..bacbd1dd

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

  Stats: 53 lines in 1 file changed: 36 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/8984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8984/head:pull/8984

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

From darcy at openjdk.org  Sat Jan 20 00:11:30 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 20 Jan 2024 00:11:30 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v10]
In-Reply-To: <KJCFzyYbRIaN1pB7DFMKv1z0AH-8twKZ2TiS-yN210Y=.5d86d5f3-33f3-4917-81b7-951d42a6d6c5@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <wWMY82ublOXBU2x-M4n97_thhRmQA-qa8Z2TEWaMgQ8=.f88a5982-133b-495b-b3bf-db6c0c2555e6@github.com>
 <KJCFzyYbRIaN1pB7DFMKv1z0AH-8twKZ2TiS-yN210Y=.5d86d5f3-33f3-4917-81b7-951d42a6d6c5@github.com>
Message-ID: <rHwBFbrnq4QjcfG2fgwTZqTRQFJ-Zn2Wy9mdhMyJ0HM=.d6a84b71-5d20-4e0c-bc36-f8d74fe16c61@github.com>

On Fri, 19 Jan 2024 19:30:01 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Augment tests.
>
> test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 148:
> 
>> 146:         else {
>> 147:             // Previously, was likely getting by-catch of annotations
>> 148:             // on element declartions, can likely just print the size
> 
> typo: `s/declartions/declarations`
> 
> And per the explanation in this comment, I think the commented-out case for `jdk.internal.ValueBased` can be removed if the test passes without it

Pushed this and some other regression test cleanups/augmentations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1460035752

From vromero at openjdk.org  Sat Jan 20 02:19:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 20 Jan 2024 02:19:26 GMT
Subject: RFR: 8323657: Compilation of snippet results in VerifyError at
 runtime with --release 9 (and above)
In-Reply-To: <8J6pCJK0dp-jErumOx3a8Ht-KdGJassMr4ZV9Th1DTo=.2090fe6d-a51c-41b0-a095-d1bf7c60b6f8@github.com>
References: <8J6pCJK0dp-jErumOx3a8Ht-KdGJassMr4ZV9Th1DTo=.2090fe6d-a51c-41b0-a095-d1bf7c60b6f8@github.com>
Message-ID: <LPwqeuqe_jF_wWUhb_N1W5yq4K-Jf9IC-ifaIO9y8NM=.698feb20-821f-431b-bf68-0ee8f6f9772c@github.com>

On Thu, 18 Jan 2024 10:57:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Test {
>     public static void main(String... args) {
>         System.err.println((test() ? null : null) + "");
>     }
>     private static boolean test() {
>         System.err.println("test called!");
>         return true;
>     }
> }
> 
> 
> This should print:
> 
> test called!
> null
> 
> 
> but it prints:
> 
> $ java /tmp/Test.java
> null
> 
> 
> The correct semantics can be achieved by using `--source 8`:
> 
> $ java --source 8 /tmp/Test.java
> test called!
> null
> 
> 
> Or `-XDstringConcat=inline` when compiling.
> 
> The reason is that when `StringConcat.IndyConstants` converts String concatenation parameters, it will short-circuit any expressions whose type is BOT (i.e. basically the `null` type). But, in this case, the expression that has the BOT type is a complex expression with a side-effect, so short-circuiting it leads to a broken semantics.
> 
> My proposal is to "short-circuit" only `null` literals, and generate other expressions normally. There may be some corner cases where we'd generate the expression unnecessarily (if it does not have any side-effect), but looking for side-effects seems unnecessarily complex and fragile given I'd expect non-trivial expressions with the BOT type are very rare. (The only case which comes to mind is exactly the above one - a conditional expressions, whose both result values are `null`.)
> 
> Please note that when the expression is incorrectly short-circuited, it may lead to various other effects - the original bug report shows a case where the resulting code does not pass the verification.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17483#pullrequestreview-1834333082

From darcy at openjdk.org  Sat Jan 20 21:59:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 20 Jan 2024 21:59:46 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v12]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <p9moEkFegHofc-Tcqv_JAR7Zgej1Yl_4kHNccFfZrL4=.ddad4f5a-003f-45db-95a0-8b05e30f83f3@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Make make of stripAnnotations more explicit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/bacbd1dd..450ae6b2

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

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

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

From darcy at openjdk.org  Sat Jan 20 22:16:29 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 20 Jan 2024 22:16:29 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v12]
In-Reply-To: <p9moEkFegHofc-Tcqv_JAR7Zgej1Yl_4kHNccFfZrL4=.ddad4f5a-003f-45db-95a0-8b05e30f83f3@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <p9moEkFegHofc-Tcqv_JAR7Zgej1Yl_4kHNccFfZrL4=.ddad4f5a-003f-45db-95a0-8b05e30f83f3@github.com>
Message-ID: <CHLouC6KiRt-vqzq7Hm-PqkNpwlE1pn2DTP9bM572wo=.b9d9e002-dc60-442b-b4e0-a81d9853de62@github.com>

On Sat, 20 Jan 2024 21:59:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make make of stripAnnotations more explicit.

CSR https://bugs.openjdk.org/browse/JDK-8323620 updated with latest specification.

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

PR Comment: https://git.openjdk.org/jdk/pull/8984#issuecomment-1902277340

From abimpoudis at openjdk.org  Mon Jan 22 09:41:50 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 Jan 2024 09:41:50 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v39]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <tIMzgb8MpIXtlaYUmDKBNDD2Pb-l4Bortd9LLIIfCX0=.d09d1b72-4068-42f0-a5a5-56a89417a59b@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits:

 - Update copyright year, javadoc, JDK version
 - Merge branch 'master' into primitive-patterns
 - Merge branch 'master' into primitive-patterns
 - Cleanup
 - Merge branch 'master' into primitive-patterns
 - Remove trailing spaces
 - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns
 - Fixed switch in the cases of unboxing and widening
 - Merge branch 'JDK-8319220' into primitive-patterns
 - Merge branch 'master' into JDK-8319220
 - ... and 46 more: https://git.openjdk.org/jdk/compare/9049402a...676af9de

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

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=38
  Stats: 3281 lines in 41 files changed: 3000 ins; 110 del; 171 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

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

From abimpoudis at openjdk.org  Mon Jan 22 10:48:05 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 Jan 2024 10:48:05 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v40]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <3q3UXhPplqk5X8E0rnHuEyUFY-HiAIQSYPgBJeIXzEE=.bcc70cff-e2da-471b-abea-7ed23d168e18@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

 - Update ExactConversionsSupport Javadoc and JDK version
 - Revert "Update copyright year, javadoc, JDK version"
   
   This reverts commit 676af9de90d946f64f34762a6df94dbd91bce41b.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/676af9de..ed61d5fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=38-39

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

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

From jlahoda at openjdk.org  Mon Jan 22 10:58:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 Jan 2024 10:58:35 GMT
Subject: Integrated: 8323057: Recoverable errors may be reported before
 unrecoverable errors when annotation processing is skipped
In-Reply-To: <y5JKBbYhNFeC86Gx_yyJmYJfD_Xm-JBJyIkB7TvE9tA=.9e0b8faa-e529-418d-a71f-97be22ef42d5@github.com>
References: <y5JKBbYhNFeC86Gx_yyJmYJfD_Xm-JBJyIkB7TvE9tA=.9e0b8faa-e529-418d-a71f-97be22ef42d5@github.com>
Message-ID: <BaCz03KMcfQSLvqo6UDP26uy0z7SMdJBXEvUmdsinNQ=.cb3cb475-7eb6-4d7a-b391-e16b5db84d7f@github.com>

On Fri, 5 Jan 2024 19:51:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When annotation processing is requested, some errors reported during enter may be resolved by the annotation processors. So, javac stashes the errors from enter aside. When an error that cannot be resolved by annotation processing is found in the stashed errors, the annotation processors all the errors will be printed.
> 
> This may be confusing if there's one important non-resolvable error, hidden among many errors that would be resolved by the annotation processors. The proposal herein is therefore to first print the not-recoverable errors, and only then the recoverable errors, when the errors are stashed away and then re-printed.

This pull request has now been integrated.

Changeset: 72f19902
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72f199024d58b53a1dff2f79dd2050ae0044e809
Stats:     152 lines in 4 files changed: 134 ins; 11 del; 7 mod

8323057: Recoverable errors may be reported before unrecoverable errors when annotation processing is skipped

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Mon Jan 22 13:09:36 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 Jan 2024 13:09:36 GMT
Subject: Integrated: 8323657: Compilation of snippet results in VerifyError at
 runtime with --release 9 (and above)
In-Reply-To: <8J6pCJK0dp-jErumOx3a8Ht-KdGJassMr4ZV9Th1DTo=.2090fe6d-a51c-41b0-a095-d1bf7c60b6f8@github.com>
References: <8J6pCJK0dp-jErumOx3a8Ht-KdGJassMr4ZV9Th1DTo=.2090fe6d-a51c-41b0-a095-d1bf7c60b6f8@github.com>
Message-ID: <wVqVny7MhwmslAZ8RaZLlppYw2CGaznh4zmaBUJjZYw=.0a3035ad-ba4a-41a2-b05c-b489bbb17d06@github.com>

On Thu, 18 Jan 2024 10:57:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Test {
>     public static void main(String... args) {
>         System.err.println((test() ? null : null) + "");
>     }
>     private static boolean test() {
>         System.err.println("test called!");
>         return true;
>     }
> }
> 
> 
> This should print:
> 
> test called!
> null
> 
> 
> but it prints:
> 
> $ java /tmp/Test.java
> null
> 
> 
> The correct semantics can be achieved by using `--source 8`:
> 
> $ java --source 8 /tmp/Test.java
> test called!
> null
> 
> 
> Or `-XDstringConcat=inline` when compiling.
> 
> The reason is that when `StringConcat.IndyConstants` converts String concatenation parameters, it will short-circuit any expressions whose type is BOT (i.e. basically the `null` type). But, in this case, the expression that has the BOT type is a complex expression with a side-effect, so short-circuiting it leads to a broken semantics.
> 
> My proposal is to "short-circuit" only `null` literals, and generate other expressions normally. There may be some corner cases where we'd generate the expression unnecessarily (if it does not have any side-effect), but looking for side-effects seems unnecessarily complex and fragile given I'd expect non-trivial expressions with the BOT type are very rare. (The only case which comes to mind is exactly the above one - a conditional expressions, whose both result values are `null`.)
> 
> Please note that when the expression is incorrectly short-circuited, it may lead to various other effects - the original bug report shows a case where the resulting code does not pass the verification.

This pull request has now been integrated.

Changeset: c9cacfb2
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9cacfb25d1f15c879c961d2965a63c9fe4d9fa7
Stats:     65 lines in 2 files changed: 64 ins; 0 del; 1 mod

8323657: Compilation of snippet results in VerifyError at runtime with --release 9 (and above)

Reviewed-by: vromero

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

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

From hannesw at openjdk.org  Mon Jan 22 15:17:28 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 22 Jan 2024 15:17:28 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>
 <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
Message-ID: <6iTfL0RE9jqees8i6HOUWCHjdCwDkeXZRnWdUHAv_Ec=.c687ed6a-a072-4b4b-8575-a7c3629c26a6@github.com>

On Wed, 13 Dec 2023 10:44:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Should this issue have a CSR for the behavioral change?
>
>> Should this issue have a CSR for the behavioral change?
> 
> My understanding of the issue is that the lookup of explicit-class member references in enclosing classes was an unintended consequence of doing the same for classless references from within nested classes. So I consider this a bug fix, not a feature change (even though it unfortunately changes javadoc to become stricter in what it accepts).
> 
> Actually, the feature of extending member reference lookup to enclosing classes is not specified in the taglet spec, which only says this:
> 
>> When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity.
> 
> This could be extended to include enclosing classes, but this is existing behaviour, not changed by this issue.

> @hns would you be able to create a linked bug to track that lookup order issue?

I filed an issue for it here: https://bugs.openjdk.org/browse/JDK-8324320

Ping: since most of the discussion in this PR was off-topic, could somebody please review the actual change?

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1904218001

From prappo at openjdk.org  Mon Jan 22 15:23:32 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 22 Jan 2024 15:23:32 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
Message-ID: <I0BbMD-6I5O4K4R6gXHMjY5vyXu3feVLon7uhad5TjE=.20d7c871-e30f-48bf-836a-ade60ca65597@github.com>

On Tue, 12 Dec 2023 12:42:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location).
>
> Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8164094
>  - Additional test
>  - JDK-8164094: javadoc allows to create a @link to a non-existent method

Marked as reviewed by prappo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17069#pullrequestreview-1836726468

From abimpoudis at openjdk.org  Mon Jan 22 18:42:56 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 Jan 2024 18:42:56 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v41]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:

 - Improve Javadoc of ExactConversionsSupport
 - Merge branch 'master' into primitive-patterns
 - Update ExactConversionsSupport Javadoc and JDK version
 - Revert "Update copyright year, javadoc, JDK version"
   
   This reverts commit 676af9de90d946f64f34762a6df94dbd91bce41b.
 - Update copyright year, javadoc, JDK version
 - Merge branch 'master' into primitive-patterns
 - Merge branch 'master' into primitive-patterns
 - Cleanup
 - Merge branch 'master' into primitive-patterns
 - Remove trailing spaces
 - ... and 50 more: https://git.openjdk.org/jdk/compare/c9cacfb2...50cb9832

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

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=40
  Stats: 3272 lines in 41 files changed: 3008 ins; 110 del; 154 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

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

From darcy at openjdk.org  Mon Jan 22 21:57:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 Jan 2024 21:57:36 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility methods
Message-ID: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>

Incremental improvements and clarifications in the specification of Types.

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

Commit messages:
 - JDK-8175386: Clarify exception behavior of Types utility methods

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

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

From darcy at openjdk.org  Mon Jan 22 21:57:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 Jan 2024 21:57:37 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods
In-Reply-To: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
Message-ID: <Vm5-eLhthqQbpQZ9FGsmbvIZqBj6lSEPAe_RGwdhMf0=.26a07b98-701f-49dc-b7d8-2c3a2e9e8adf@github.com>

On Mon, 22 Jan 2024 21:51:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Incremental improvements and clarifications in the specification of Types.

More extensive improvements and testing may be done subsequently under JDK-8055219.

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

PR Comment: https://git.openjdk.org/jdk/pull/17523#issuecomment-1904885634

From prappo at openjdk.org  Mon Jan 22 23:05:33 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 22 Jan 2024 23:05:33 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
Message-ID: <CFjtWK1WETf8v3nN5x1eSCWSJns0-IuLzNgat6U422g=.f0017a35-2118-4769-9f19-de6f950e0acc@github.com>

On Fri, 19 Jan 2024 18:37:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge with upstream/master
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 271:

> 269: //                        if (textStart == -1) {
> 270: //                            textStart = bp;
> 271: //                        }

What's up with that?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1333:

> 1331:                     lineKind = (ch == '\n' || ch == '\r') ? LineKind.BLANK
> 1332:                             : (indent <= 3) ? peekLineKind()
> 1333:                             : LineKind.OTHER;

Nested ternary-s are hard to read. Nested if-s are bulky. Sigh.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1377:

> 1375:          * @see <a href="https://spec.commonmark.org/0.30/#atx-headings">ATX Headings</a>
> 1376:          */
> 1377:         ATX_HEADER(Pattern.compile("#{1,6}( .*|$)")),

Actually, I wonder how accurate those regexes should match spec. Given the definition [^*] of an ATX header and the fact that we always match the complete (not find inside) a line, which by definition should not have line terminators, shouldn't it be like this?

    #{1,6}([ \t]+.*)?

[^*]: The opening sequence of # characters must be followed by spaces or tabs, or by the end of line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1462039425
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1462213698
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1462148038

From cstein at openjdk.org  Tue Jan 23 07:11:37 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 23 Jan 2024 07:11:37 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
Message-ID: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>

Please review this fix to make the multi-file source-code launcher find classes with `$` in names, including names of packages, names of compliation units, and also names of enclosed types.

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

Commit messages:
 - 8323815: Source launcher should find classes with $ in names

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

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

From jlahoda at openjdk.org  Tue Jan 23 11:45:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 23 Jan 2024 11:45:28 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <zWTW573x0Oeknlv1bUsm-fL3AkdrAc2GnavlMwc1LKA=.55ba1805-0f6b-4c5c-b4d6-a7b42a9c4ee3@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

I have nothing against it, but I don't think I know enough about details of jtreg configuration to provide approval. OTOH, I personally don't see a strong need for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1905864727

From duke at openjdk.org  Tue Jan 23 15:32:27 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 23 Jan 2024 15:32:27 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
In-Reply-To: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
Message-ID: <Pq4ojU1Of4ZkQwCTrrdSpZuEhJH5X57SKsK-d1OV1ao=.652307ca-7a73-4e37-b6c1-bd1f71aed351@github.com>

On Tue, 23 Jan 2024 07:06:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to make the multi-file source-code launcher find classes with `$` in names, including names of packages, names of compliation units, and also names of enclosed types.
> 
> Tested tier1-3

test/langtools/tools/javac/launcher/MultiFileSourceLauncherTests.java line 89:

> 87:                     """);
> 88:         var pq = Files.createDirectories(base.resolve("p/q"));
> 89:         Files.writeString(pq.resolve("Unit$123.java"),

Maybe?keep both?tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17526#discussion_r1463458479

From prappo at openjdk.org  Tue Jan 23 15:37:40 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 23 Jan 2024 15:37:40 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
Message-ID: <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>

On Fri, 19 Jan 2024 18:37:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge with upstream/master
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 225:

> 223:         while (ch == ' ' && bp < buflen) {
> 224:             nextChar();
> 225:         }

Why do we specifically care about `\s` symbols here rather than about broader whitespace?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1165:

> 1163:     }
> 1164: 
> 1165: 

Please delete this blank line.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1315:

> 1313:     }
> 1314: 
> 1315:     void skipLine() {

Like `peekLike()`, this method also does not seem to be consistent with `newline` in `nextChar()`.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1382:

> 1380:          *  @see <a href="https://spec.commonmark.org/0.30/#setext-headings">Setext Headings</a>
> 1381:          */
> 1382:         SETEXT_UNDERLINE(Pattern.compile("[=-]+[ \t]*")),

This should be more accurate:
Suggestion:

        SETEXT_UNDERLINE(Pattern.compile("=+|-+[ \t]*")),

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1388:

> 1386:          * @see <a href="https://spec.commonmark.org/0.30/#thematic-breaks">Thematic Break</a>
> 1387:          */
> 1388:         THEMATIC_BREAK(Pattern.compile("((\\+[ \t]*+){3,})|((-[ \t]*+){3,})|((_[ \t]*+){3,})")),

Suggestion:

        /**
         * Thematic break: a line of * - _ interspersed with optional spaces and tabs
         * @see <a href="https://spec.commonmark.org/0.30/#thematic-breaks">Thematic Break</a>
         */
        THEMATIC_BREAK(Pattern.compile("((\*[ \t]*+){3,})|((-[ \t]*+){3,})|((_[ \t]*+){3,})")),

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1396:

> 1394:          * @see <a href="https://spec.commonmark.org/0.30/#code-fence">Code Fence</a>
> 1395:          */
> 1396:         CODE_FENCE(Pattern.compile("(`{3,}[^`]*+)|(~{3,}.*+)")),

Why are this and the previous patterns possessive (`+`), while others aren't?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1419:

> 1417:     LineKind peekLineKind() {
> 1418:         switch (ch) {
> 1419:             case '#', '=', '-', '+', '_', '`', '~' -> {

This change is to match that of `THEMATIC_BREAK`:
Suggestion:

            case '#', '=', '-', '*', '_', '`', '~' -> {

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1065:

> 1063: 
> 1064:                     if (accept('/')) { // (Spec. 3.7)
> 1065:                         if (accept('/')) { // Markdown comment

Here and elsewhere in this file: do we need to mention Markdown?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1553:

> 1551: 
> 1552:         /**
> 1553:          * Determine how much indent to remove from markdown comment.

Suggestion:

         * Determine how much indent to remove from Markdown comment.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1585:

> 1583:          */
> 1584:         UnicodeReader trimMarkdownComment(UnicodeReader line, int indent) {
> 1585:             int pos = line.position();

Unused.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ParserFactory.java line 30:

> 28: import java.util.Locale;
> 29: 
> 30: import com.sun.source.util.DocTrees;

Unused.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 35:

> 33: import com.sun.source.doctree.*;
> 34: import com.sun.source.doctree.AttributeTree.ValueKind;
> 35: import com.sun.source.util.DocTreeScanner;

Unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463169245
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463155900
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463252506
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463181845
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463202143
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463237327
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463239667
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463422663
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463422992
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463424623
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463437420
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1463441675

From cstein at openjdk.org  Tue Jan 23 15:41:33 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 23 Jan 2024 15:41:33 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
In-Reply-To: <Pq4ojU1Of4ZkQwCTrrdSpZuEhJH5X57SKsK-d1OV1ao=.652307ca-7a73-4e37-b6c1-bd1f71aed351@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
 <Pq4ojU1Of4ZkQwCTrrdSpZuEhJH5X57SKsK-d1OV1ao=.652307ca-7a73-4e37-b6c1-bd1f71aed351@github.com>
Message-ID: <UszGKecLEjNRYoOOevf-0UPzHjW-iQFDr7TuWNT1G8M=.097b1d38-73fa-4e2b-a6a0-c8ff619c9cd3@github.com>

On Tue, 23 Jan 2024 15:30:14 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Please review this fix to make the multi-file source-code launcher find classes with `$` in names, including names of packages, names of compliation units, and also names of enclosed types.
>> 
>> Tested tier1-3
>
> test/langtools/tools/javac/launcher/MultiFileSourceLauncherTests.java line 89:
> 
>> 87:                     """);
>> 88:         var pq = Files.createDirectories(base.resolve("p/q"));
>> 89:         Files.writeString(pq.resolve("Unit$123.java"),
> 
> Maybe?keep both?tests?

There are plenty tests for canonically named compilation units, thus that wouldn't carry much extra worth.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17526#discussion_r1463479105

From shade at openjdk.org  Tue Jan 23 15:43:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 15:43:35 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <d_XnS-9KYUYwtoQSTrDB3aNXhjMR67MpLEWIvGdFjzU=.bab81b99-de68-40fd-91fb-06990c185fe1@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

All right, thanks! @lmesnik, I realized I forgot to ask if you had objections to this.

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

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1906338893

From lmesnik at openjdk.org  Tue Jan 23 16:59:28 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 23 Jan 2024 16:59:28 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <VJuphjAXu0SBIWM9eypa7SLpzUP8SCElmkXBxyCl9kY=.e25ed17d-4b66-41ea-aeb8-1243e2a384fd@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17422#pullrequestreview-1839361504

From shade at openjdk.org  Tue Jan 23 17:06:38 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 17:06:38 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <CQUy1H5or0ZNkZzri_7qizVClqCPPtmlbRDWb5nYL48=.b82ae3cc-598b-4133-a875-4d837808b21e@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Thank you all!

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

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1906520760

From shade at openjdk.org  Tue Jan 23 17:06:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 17:06:40 GMT
Subject: Integrated: 8323515: Create test alias "all" for all test roots
In-Reply-To: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
Message-ID: <P2qIBvCejrqrp5pu68twbbsQMrY67dqP2Oir7WMREro=.9cf6c992-8622-4100-a623-0d75f62b44d6@github.com>

On Mon, 15 Jan 2024 11:05:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
> 
> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
> 
> 
> % make test TEST=all
> 
> Test selection 'all', will run:
> * jtreg:test/hotspot/jtreg:all
> * jtreg:test/jdk:all
> * jtreg:test/langtools:all
> * jtreg:test/jaxp:all
> * jtreg:test/lib-test:all
> 
> (...about 6 hours later...)
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>    jtreg:test/langtools:all                           4469  4469     0     0   
>    jtreg:test/jaxp:all                                 513   513     0     0   
>    jtreg:test/lib-test:all                              32    32     0     0   
> ==============================
> TEST FAILURE

This pull request has now been integrated.

Changeset: 8b9bf758
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b9bf758801400e4491326cd4c90fc117b9d97e1
Stats:     49 lines in 5 files changed: 42 ins; 5 del; 2 mod

8323515: Create test alias "all" for all test roots

Reviewed-by: dholmes, alanb, joehw, lmesnik

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

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

From jjg at openjdk.org  Wed Jan 24 00:03:39 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Jan 2024 00:03:39 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <la7NSChfspXEzKCeWhj7AMdNsi-tZfph0hH0IIN3JCA=.118b1131-33c1-48e0-9fa3-abb960667831@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <la7NSChfspXEzKCeWhj7AMdNsi-tZfph0hH0IIN3JCA=.118b1131-33c1-48e0-9fa3-abb960667831@github.com>
Message-ID: <w5k9EPyNvdAWZLaZub0Ps-Ek_iYnUK32kqUhZ0hdPLw=.e74b4cf9-bc1e-42bc-957e-89bf0008cb11@github.com>

On Thu, 22 Sep 2022 16:50:45 GMT, Liam Miller-Cushon <cushon 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 three additional commits since the last revision:
>> 
>>  - Update visitor; all langtools regression tests pass.
>>  - Merge branch 'master' into JDK-8042981
>>  - JDK-8042981: Strip type annotations in Types' utility methods
>
> src/java.compiler/share/classes/javax/lang/model/util/Types.java line 40:
> 
>> 38:  * Where a method returns a type mirror or a collection of type
>> 39:  * mirrors, any type mirrors represent types with no type annotations,
>> 40:  * unless otherwise indicated.
> 
> I'm seeing `erasure` preserve type annotations on the array type (but not its component) after this change: `erasure(@A int @B []) = int @B []`. (Here's the [repro](https://gist.github.com/cushon/e0a59cc291c3b83204b9139addb01340).)
> 
> Is that deliberate, or is this still work in progress?

@jdarcy ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464130816

From cushon at openjdk.org  Wed Jan 24 00:03:40 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 24 Jan 2024 00:03:40 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <w5k9EPyNvdAWZLaZub0Ps-Ek_iYnUK32kqUhZ0hdPLw=.e74b4cf9-bc1e-42bc-957e-89bf0008cb11@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <la7NSChfspXEzKCeWhj7AMdNsi-tZfph0hH0IIN3JCA=.118b1131-33c1-48e0-9fa3-abb960667831@github.com>
 <w5k9EPyNvdAWZLaZub0Ps-Ek_iYnUK32kqUhZ0hdPLw=.e74b4cf9-bc1e-42bc-957e-89bf0008cb11@github.com>
Message-ID: <Mf_mgjeQ9wjdacYvt_2NJdgs35g51G5BZmWwmZDLtfs=.5d2a05d8-bd43-4ddc-bf3b-4c3219c41afc@github.com>

On Tue, 23 Jan 2024 23:55:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/Types.java line 40:
>> 
>>> 38:  * Where a method returns a type mirror or a collection of type
>>> 39:  * mirrors, any type mirrors represent types with no type annotations,
>>> 40:  * unless otherwise indicated.
>> 
>> I'm seeing `erasure` preserve type annotations on the array type (but not its component) after this change: `erasure(@A int @B []) = int @B []`. (Here's the [repro](https://gist.github.com/cushon/e0a59cc291c3b83204b9139addb01340).)
>> 
>> Is that deliberate, or is this still work in progress?
>
> @jdarcy ?

(This comment is obsolete, it was on a much earlier version of the PR, and these issues have been addressed. The latest version correct handles removing annotations from contained types. There's some discussion about the issues with the earlier approach in https://github.com/openjdk/jdk/pull/8984#issuecomment-1806211798)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464132270

From jjg at openjdk.org  Wed Jan 24 00:03:42 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Jan 2024 00:03:42 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <WB_wJoKBzr1Hnv-XoXro27d6cRNaDb5bw0dPLf_o-18=.c2090a07-7357-4335-927c-20a73aa52b3f@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <WB_wJoKBzr1Hnv-XoXro27d6cRNaDb5bw0dPLf_o-18=.c2090a07-7357-4335-927c-20a73aa52b3f@github.com>
Message-ID: <fSkwqrH3W-2kfhUjGC3tetU2Pcv4sPr7xR6DoSXBuGw=.9989d620-b712-4ac8-8a2f-389ebebfa171@github.com>

On Wed, 21 Sep 2022 11:21:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Update visitor; all langtools regression tests pass.
>>  - Merge branch 'master' into JDK-8042981
>>  - JDK-8042981: Strip type annotations in Types' utility methods
>
> src/java.compiler/share/classes/javax/lang/model/util/Types.java line 241:
> 
>> 239:      * @param extendsBound  the extends (upper) bound, or {@code null} if none
>> 240:      * @param superBound    the super (lower) bound, or {@code null} if none
>> 241:      * @throws IllegalArgumentException if bounds are not valid
> 
> Should annotation also be preserved (and also documented to be preserved) for `getDeclaredType`?

@jddarcy ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464131446

From jjg at openjdk.org  Wed Jan 24 00:03:45 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Jan 2024 00:03:45 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v12]
In-Reply-To: <p9moEkFegHofc-Tcqv_JAR7Zgej1Yl_4kHNccFfZrL4=.ddad4f5a-003f-45db-95a0-8b05e30f83f3@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <p9moEkFegHofc-Tcqv_JAR7Zgej1Yl_4kHNccFfZrL4=.ddad4f5a-003f-45db-95a0-8b05e30f83f3@github.com>
Message-ID: <xQjtgJygRTHOyWb23ZABwW73UxtbpWmSKFwkM-8qMJc=.46578692-0ea3-48cc-b667-b1d6e2908273@github.com>

On Sat, 20 Jan 2024 21:59:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make make of stripAnnotations more explicit.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 431:

> 429:         /**
> 430:          * Note: this visitor only needs to handle cases where 'contained'
> 431:          * types can be annotated. These cases are described ing JVMS

typo: `ing`

test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 145:

> 143:         try {
> 144:             var result = vacuousTypes.stripAnnotations(tm);
> 145:             messager.printError("Unexpected non-exceptional result returned" +  result);

maybe need a space at the end of the string, to separate "returned" from `result`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464131301
PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464133221

From jjg at openjdk.org  Wed Jan 24 00:07:31 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Jan 2024 00:07:31 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <Mf_mgjeQ9wjdacYvt_2NJdgs35g51G5BZmWwmZDLtfs=.5d2a05d8-bd43-4ddc-bf3b-4c3219c41afc@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <la7NSChfspXEzKCeWhj7AMdNsi-tZfph0hH0IIN3JCA=.118b1131-33c1-48e0-9fa3-abb960667831@github.com>
 <w5k9EPyNvdAWZLaZub0Ps-Ek_iYnUK32kqUhZ0hdPLw=.e74b4cf9-bc1e-42bc-957e-89bf0008cb11@github.com>
 <Mf_mgjeQ9wjdacYvt_2NJdgs35g51G5BZmWwmZDLtfs=.5d2a05d8-bd43-4ddc-bf3b-4c3219c41afc@github.com>
Message-ID: <YB820LWYoiB6uLItCMH1FjbuYlG0u5n8Q_I8fmGkVm8=.a0532759-866d-4282-bae5-c49c437500b0@github.com>

On Tue, 23 Jan 2024 23:58:32 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> @jdarcy ?
>
> (This comment is obsolete, it was on a much earlier version of the PR, and these issues have been addressed. The latest version correct handles removing annotations from contained types. There's some discussion about the issues with the earlier approach in https://github.com/openjdk/jdk/pull/8984#issuecomment-1806211798)

> (This comment is obsolete, it was on a much earlier version of the PR, and these issues have been addressed. The latest version correct handles removing annotations from contained types. There's some discussion about the issues with the earlier approach in [#8984 (comment)](https://github.com/openjdk/jdk/pull/8984#issuecomment-1806211798))

Thanks, I guess I was confused by the different forms of the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464135431

From jjg at openjdk.org  Wed Jan 24 00:14:27 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Jan 2024 00:14:27 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods
In-Reply-To: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
Message-ID: <DaJtb6f5mFmP6lXvDOLp0cfQGmuMIM49CyXN9Ec35ww=.64172e47-2cff-4304-b627-443b63710d18@github.com>

On Mon, 22 Jan 2024 21:51:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Incremental improvements and clarifications in the specification of Types.

Fix duplicate entry

src/java.compiler/share/classes/javax/lang/model/util/Types.java line 46:

> 44:  * {@linkplain TypeKind#PACKAGE packages} and {@linkplain
> 45:  * TypeKind#MODULE modules} are generally out of scope for these
> 46:  * methods.

Do you want to better specify the behavior for the "out of scope" types, such as _Unless otherwise specified, `IllegalArgumenntException` will be thrown when a method is called with an inappropriate argument._

src/java.compiler/share/classes/javax/lang/model/util/Types.java line 252:

> 250:      * @param componentType  the component type
> 251:      * @throws IllegalArgumentException if the component type is not valid for
> 252:      *          an array, including executable, package, module, executable, and wildcard types

duplicate `executable`

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

Changes requested by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17523#pullrequestreview-1840154314
PR Review Comment: https://git.openjdk.org/jdk/pull/17523#discussion_r1464139144
PR Review Comment: https://git.openjdk.org/jdk/pull/17523#discussion_r1464139289

From darcy at openjdk.org  Wed Jan 24 01:03:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 01:03:37 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods [v2]
In-Reply-To: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
Message-ID: <fkEaQ4tsC6Xywar6ES2akUuyRYrBmbIVyRTpkp3qSTw=.cc1d99e0-b704-42d8-954a-cb82733db219@github.com>

> Incremental improvements and clarifications in the specification of Types.

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

  Fix typo found in code review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17523/files
  - new: https://git.openjdk.org/jdk/pull/17523/files/bdd28dc1..1f327589

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

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

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

From darcy at openjdk.org  Wed Jan 24 01:03:39 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 01:03:39 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods [v2]
In-Reply-To: <DaJtb6f5mFmP6lXvDOLp0cfQGmuMIM49CyXN9Ec35ww=.64172e47-2cff-4304-b627-443b63710d18@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
 <DaJtb6f5mFmP6lXvDOLp0cfQGmuMIM49CyXN9Ec35ww=.64172e47-2cff-4304-b627-443b63710d18@github.com>
Message-ID: <SpI2dioBeNODPn6gDP3TyqpUiq9tpbvjTQhB0UcDFec=.241d2f06-8ab2-4e80-a95c-3aae61985318@github.com>

On Wed, 24 Jan 2024 00:11:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo found in code review.
>
> src/java.compiler/share/classes/javax/lang/model/util/Types.java line 252:
> 
>> 250:      * @param componentType  the component type
>> 251:      * @throws IllegalArgumentException if the component type is not valid for
>> 252:      *          an array, including executable, package, module, executable, and wildcard types
> 
> duplicate `executable`

Fixed; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17523#discussion_r1464173043

From darcy at openjdk.org  Wed Jan 24 01:12:39 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 01:12:39 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods [v3]
In-Reply-To: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
Message-ID: <hRkrylYC97XHg_vYyNiHqff-R1XgFo827V8JITMQCNA=.fd7d71e5-9f5c-4c4b-9375-f6924f3ec6fc@github.com>

> Incremental improvements and clarifications in the specification of Types.

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/17523/files
  - new: https://git.openjdk.org/jdk/pull/17523/files/1f327589..9aa3b2fa

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

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

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

From darcy at openjdk.org  Wed Jan 24 01:12:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 01:12:40 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods [v3]
In-Reply-To: <DaJtb6f5mFmP6lXvDOLp0cfQGmuMIM49CyXN9Ec35ww=.64172e47-2cff-4304-b627-443b63710d18@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
 <DaJtb6f5mFmP6lXvDOLp0cfQGmuMIM49CyXN9Ec35ww=.64172e47-2cff-4304-b627-443b63710d18@github.com>
Message-ID: <85ae2sVlZcOy8LnOUMW0pA6pi-0koXlBcTBeHeMgNso=.5e3d3d3a-e739-47ae-ac3d-76a51a4ec984@github.com>

On Wed, 24 Jan 2024 00:11:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review feedback.
>
> src/java.compiler/share/classes/javax/lang/model/util/Types.java line 46:
> 
>> 44:  * {@linkplain TypeKind#PACKAGE packages} and {@linkplain
>> 45:  * TypeKind#MODULE modules} are generally out of scope for these
>> 46:  * methods.
> 
> Do you want to better specify the behavior for the "out of scope" types, such as _Unless otherwise specified, `IllegalArgumenntException` will be thrown when a method is called with an inappropriate argument._

Good suggestion; blanket statement added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17523#discussion_r1464179932

From darcy at openjdk.org  Wed Jan 24 01:28:30 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 01:28:30 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <fSkwqrH3W-2kfhUjGC3tetU2Pcv4sPr7xR6DoSXBuGw=.9989d620-b712-4ac8-8a2f-389ebebfa171@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <WB_wJoKBzr1Hnv-XoXro27d6cRNaDb5bw0dPLf_o-18=.c2090a07-7357-4335-927c-20a73aa52b3f@github.com>
 <fSkwqrH3W-2kfhUjGC3tetU2Pcv4sPr7xR6DoSXBuGw=.9989d620-b712-4ac8-8a2f-389ebebfa171@github.com>
Message-ID: <7COyJ1b5X_1Z6ZlMJ-LaG8jxOlY6n9qwNWJ8Ry0uvFY=.72cd939d-b535-4114-a312-a70342cd8b6e@github.com>

On Tue, 23 Jan 2024 23:56:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/Types.java line 241:
>> 
>>> 239:      * @param extendsBound  the extends (upper) bound, or {@code null} if none
>>> 240:      * @param superBound    the super (lower) bound, or {@code null} if none
>>> 241:      * @throws IllegalArgumentException if bounds are not valid
>> 
>> Should annotation also be preserved (and also documented to be preserved) for `getDeclaredType`?
>
> @jddarcy ?

I don't think it is preserved in that case as much as a lookup/construction process is done based on the TypeElement, etc.

So I think leaving the annotation behavior unspecified is okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464190452

From darcy at openjdk.org  Wed Jan 24 01:34:43 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 01:34:43 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v13]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <hr6n596A7ddIhr0R9ZmLx7r8HKKdoDDRx0MN5sDa4Tw=.a751ac52-874f-40c1-b7e1-11de33887034@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Fix issue found in code review.
 - Fix typo found in code review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/450ae6b2..0003be28

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

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

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

From darcy at openjdk.org  Wed Jan 24 01:34:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 01:34:46 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v12]
In-Reply-To: <xQjtgJygRTHOyWb23ZABwW73UxtbpWmSKFwkM-8qMJc=.46578692-0ea3-48cc-b667-b1d6e2908273@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <p9moEkFegHofc-Tcqv_JAR7Zgej1Yl_4kHNccFfZrL4=.ddad4f5a-003f-45db-95a0-8b05e30f83f3@github.com>
 <xQjtgJygRTHOyWb23ZABwW73UxtbpWmSKFwkM-8qMJc=.46578692-0ea3-48cc-b667-b1d6e2908273@github.com>
Message-ID: <q5BJDN3hHZlVaaxVhcuzRCe6VDygTXTUkV2SbUHr9ho=.b4781d49-a45c-4d69-a9c9-d97a47840379@github.com>

On Tue, 23 Jan 2024 23:56:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make make of stripAnnotations more explicit.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 431:
> 
>> 429:         /**
>> 430:          * Note: this visitor only needs to handle cases where 'contained'
>> 431:          * types can be annotated. These cases are described ing JVMS
> 
> typo: `ing`

Fixed.

> test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java line 145:
> 
>> 143:         try {
>> 144:             var result = vacuousTypes.stripAnnotations(tm);
>> 145:             messager.printError("Unexpected non-exceptional result returned" +  result);
> 
> maybe need a space at the end of the string, to separate "returned" from `result`

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464192117
PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1464193353

From vromero at openjdk.org  Wed Jan 24 04:00:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 04:00:37 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v41]
In-Reply-To: <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
Message-ID: <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>

On Mon, 22 Jan 2024 18:42:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
> 
>  - Improve Javadoc of ExactConversionsSupport
>  - Merge branch 'master' into primitive-patterns
>  - Update ExactConversionsSupport Javadoc and JDK version
>  - Revert "Update copyright year, javadoc, JDK version"
>    
>    This reverts commit 676af9de90d946f64f34762a6df94dbd91bce41b.
>  - Update copyright year, javadoc, JDK version
>  - Merge branch 'master' into primitive-patterns
>  - Merge branch 'master' into primitive-patterns
>  - Cleanup
>  - Merge branch 'master' into primitive-patterns
>  - Remove trailing spaces
>  - ... and 50 more: https://git.openjdk.org/jdk/compare/c9cacfb2...50cb9832

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 72:

> 70:     private static final Object SENTINEL = new Object();
> 71:     private static final MethodHandles.Lookup LOOKUP = MethodHandles.lookup();
> 72:     private static final boolean previewEnabled = true;

not sure about the use of this constant, do we really need it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464262036

From darcy at openjdk.org  Wed Jan 24 06:08:44 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 06:08:44 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v14]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <vbaiokJvzM0jMuE_PF_ofvdwoZvHQH3jBM-LIdp1Eks=.ca0d4b26-36b3-4f88-b0d2-74adae6ed219@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Better describe intentions of stripAnnotations method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/0003be28..aa9154b2

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

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

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

From jlahoda at openjdk.org  Wed Jan 24 08:18:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 24 Jan 2024 08:18:27 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
In-Reply-To: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
Message-ID: <PMwGWL3wbZyAWUnmKALFUwunO95rCyjv-kc6hi0OZ1I=.e2f13083-e1c9-43cb-b9b6-f6c487f84f11@github.com>

On Tue, 23 Jan 2024 07:06:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to make the multi-file source-code launcher find classes with `$` in names, including names of packages, names of compliation units, and also names of enclosed types.
> 
> Tested tier1-3

I think the code is OK, but I'd suggest to add a few more tests to help ensure the behavior is kept even in case the code is modified.

test/langtools/tools/javac/launcher/MultiFileSourceLauncherTests.java line 78:

> 76:                       public static void main(String... args) throws Exception {
> 77:                         System.out.println(Class.forName("World$Core"));
> 78:                         System.out.println(Class.forName("p.q.Unit$123$Fir$t$$econd"));

I think I would suggest two more tests:
- one that would (in a separate run) lookup `p.q.Unit$123$Fir$t` (to ensure the search is broad enough)
- one with a package name with `$`.

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

PR Review: https://git.openjdk.org/jdk/pull/17526#pullrequestreview-1840696005
PR Review Comment: https://git.openjdk.org/jdk/pull/17526#discussion_r1464477154

From jlahoda at openjdk.org  Wed Jan 24 10:29:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 24 Jan 2024 10:29:35 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v41]
In-Reply-To: <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
 <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>
Message-ID: <01zQgnrUk9UigmTRH4Zijckme2pKW4gUsKMzhlGorsc=.2bb5c607-644b-457d-b8d6-e1f9b6a84025@github.com>

On Wed, 24 Jan 2024 03:47:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
>> 
>>  - Improve Javadoc of ExactConversionsSupport
>>  - Merge branch 'master' into primitive-patterns
>>  - Update ExactConversionsSupport Javadoc and JDK version
>>  - Revert "Update copyright year, javadoc, JDK version"
>>    
>>    This reverts commit 676af9de90d946f64f34762a6df94dbd91bce41b.
>>  - Update copyright year, javadoc, JDK version
>>  - Merge branch 'master' into primitive-patterns
>>  - Merge branch 'master' into primitive-patterns
>>  - Cleanup
>>  - Merge branch 'master' into primitive-patterns
>>  - Remove trailing spaces
>>  - ... and 50 more: https://git.openjdk.org/jdk/compare/c9cacfb2...50cb9832
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 72:
> 
>> 70:     private static final Object SENTINEL = new Object();
>> 71:     private static final MethodHandles.Lookup LOOKUP = MethodHandles.lookup();
>> 72:     private static final boolean previewEnabled = true;
> 
> not sure about the use of this constant, do we really need it?

Uh, I think this is a good catch.

I am not completely sure what the policy is, but here we are enhancing a non-preview method with some preview-based behavior. I would feel better if the method would refuse to work in the preview way when preview is not enabled. I.e. my opinion is that this should either be initialized to `jdk.internal.misc.PreviewFeatures.isEnabled()`, or `jdk.internal.misc.PreviewFeatures.ensureEnabled()` should be used appropriately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464693259

From abimpoudis at openjdk.org  Wed Jan 24 11:53:52 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 11:53:52 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Set previewEnabled properly in SwitchBootstraps

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/50cb9832..663c7a54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=40-41

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

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

From abimpoudis at openjdk.org  Wed Jan 24 11:53:54 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 11:53:54 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v41]
In-Reply-To: <01zQgnrUk9UigmTRH4Zijckme2pKW4gUsKMzhlGorsc=.2bb5c607-644b-457d-b8d6-e1f9b6a84025@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
 <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>
 <01zQgnrUk9UigmTRH4Zijckme2pKW4gUsKMzhlGorsc=.2bb5c607-644b-457d-b8d6-e1f9b6a84025@github.com>
Message-ID: <BHwX3HCGZZiil_8ZBdwP0gcd5zJySeF_I4US6t245qE=.8c39683f-24cc-4d55-a2f8-a65c045984a1@github.com>

On Wed, 24 Jan 2024 10:26:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 72:
>> 
>>> 70:     private static final Object SENTINEL = new Object();
>>> 71:     private static final MethodHandles.Lookup LOOKUP = MethodHandles.lookup();
>>> 72:     private static final boolean previewEnabled = true;
>> 
>> not sure about the use of this constant, do we really need it?
>
> Uh, I think this is a good catch.
> 
> I am not completely sure what the policy is, but here we are enhancing a non-preview method with some preview-based behavior. I would feel better if the method would refuse to work in the preview way when preview is not enabled. I.e. my opinion is that this should either be initialized to `jdk.internal.misc.PreviewFeatures.isEnabled()`, or `jdk.internal.misc.PreviewFeatures.ensureEnabled()` should be used appropriately.

Used the `jdk.internal.misc.PreviewFeatures.isEnabled()` and remove an erroneous check in `typeSwitch`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464801847

From mcimadamore at openjdk.org  Wed Jan 24 12:25:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 12:25:34 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
Message-ID: <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>

On Wed, 24 Jan 2024 11:53:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set previewEnabled properly in SwitchBootstraps

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5046:

> 5044: 
> 5045:         if (target.isPrimitive()) {
> 5046:             return (source.isReference() && isSubtype(source, target)) ||

I'm a bit confused here - in here we have:
* `target.isPrimitive()`
* `source.isReference()`

So, isn't it the case that `isSubtype(source, target)` is always false?

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

> 1922:     }
> 1923:     // where
> 1924:     static final Set<TypeTag> nonIntegralPrimitiveTypes = Set.of(

This feels like a method on TypeTag?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464835145
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464836721

From sundar at openjdk.org  Wed Jan 24 12:32:30 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 24 Jan 2024 12:32:30 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
In-Reply-To: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
Message-ID: <vKquhPU6NdC8ZVKBkZFkmY6g7s7wCccBgVESqbt3EYI=.27a6dc06-92c8-4f0e-9bfd-10c24c08b8ce@github.com>

On Tue, 23 Jan 2024 07:06:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to make the multi-file source-code launcher find classes with `$` in names, including names of packages, names of compliation units, and also names of enclosed types.
> 
> Tested tier1-3

Marked as reviewed by sundar (Reviewer).

LGTM

I tested the fix with jextract samples (jextract generates $ in names). All source mode + mixed .class + .java mode both work fine as expected.

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

PR Review: https://git.openjdk.org/jdk/pull/17526#pullrequestreview-1841262743
PR Comment: https://git.openjdk.org/jdk/pull/17526#issuecomment-1908031020

From mcimadamore at openjdk.org  Wed Jan 24 12:34:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 12:34:35 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
Message-ID: <CviCTLebzieKrzLbh8QJKnL0QjSYeMdH_CdYjID1IvE=.54868a77-acb2-471f-b173-d1caae1c2ff4@github.com>

On Wed, 24 Jan 2024 11:53:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set previewEnabled properly in SwitchBootstraps

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

> 4145:         }
> 4146:         if (clazztype.isPrimitive()) {
> 4147:             preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);

So, if I have a primitive instanceof, I get two preview warnings, one for the expression, and one for the pattern type? Shouldn't one be enough?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464846948

From mcimadamore at openjdk.org  Wed Jan 24 12:17:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 12:17:38 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
Message-ID: <_hlWjNWAiPgvNTpwVWsBKURLCwySlIt5GoWiWKTJLRs=.3f069a48-2a82-408a-ba40-84d2b75b8ed3@github.com>

On Wed, 24 Jan 2024 11:53:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set previewEnabled properly in SwitchBootstraps

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 34:

> 32:  * may be used, for example, by Java compiler implementations to implement
> 33:  * checks for {@code instanceof} and pattern matching runtime implementations.
> 34:  * Unconditionally exact testing conversions do not require a corresponding

"... do not require a corresponding action at runtime" ... and, for this reason, method corresponding to these conversions are omitted here

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 37:

> 35:  * action at run time.
> 36:  * <p>
> 37:  * The run time conversion checks examine whether loss of information would

You provide examples for runtime conversions - it would be useful, before this para, to also have examples of an inexact conversion, an exact conversion and an unconditionally exact conversion (before diving into the details of how the runtime check is performed for floating points).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464828250
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464826696

From mcimadamore at openjdk.org  Wed Jan 24 12:43:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 12:43:36 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
Message-ID: <7L1Al1Y3JbKk3Xw624IOvM1ESmoRmmzkHRPbs-Wy4J0=.f9d0acee-0f06-41ea-889e-a035208d38aa@github.com>

On Wed, 24 Jan 2024 11:53:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set previewEnabled properly in SwitchBootstraps

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2962:

> 2960:      * More rewritings:
> 2961:      *
> 2962:      * - If the `instanceof` check is unconditionally exact rewrite to true.

Note: the same effect can be obtained, w/o rewriting (and perhaps more simply) by detecting the case of an unconditionally exact "instanceof" test, and giving the instanceof expression a constant boolean type (with value "true"). This can be done in Attr. Then, `Gen` will shortcircuit the expression, as required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464857684

From abimpoudis at openjdk.org  Wed Jan 24 14:58:55 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 14:58:55 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v43]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <kXlMFWjJh-MpZK9t-ca721LvRPPuhHsALOLkFQOddIg=.18978963-7202-4794-bd1a-f35ea41190f8@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Check the range of the new types of switch through TypeTag.isInSuperClassesOf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/663c7a54..9b7fb7fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=41-42

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

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

From abimpoudis at openjdk.org  Wed Jan 24 14:58:57 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 14:58:57 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v41]
In-Reply-To: <BHwX3HCGZZiil_8ZBdwP0gcd5zJySeF_I4US6t245qE=.8c39683f-24cc-4d55-a2f8-a65c045984a1@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
 <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>
 <01zQgnrUk9UigmTRH4Zijckme2pKW4gUsKMzhlGorsc=.2bb5c607-644b-457d-b8d6-e1f9b6a84025@github.com>
 <BHwX3HCGZZiil_8ZBdwP0gcd5zJySeF_I4US6t245qE=.8c39683f-24cc-4d55-a2f8-a65c045984a1@github.com>
Message-ID: <rYWNwhm54Xz-PhP2Txy7bGtUIwv9Q2PeIE1C7QgJlM4=.e2234b03-ce1d-4bb4-8c23-42a51a12c640@github.com>

On Wed, 24 Jan 2024 11:50:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Uh, I think this is a good catch.
>> 
>> I am not completely sure what the policy is, but here we are enhancing a non-preview method with some preview-based behavior. I would feel better if the method would refuse to work in the preview way when preview is not enabled. I.e. my opinion is that this should either be initialized to `jdk.internal.misc.PreviewFeatures.isEnabled()`, or `jdk.internal.misc.PreviewFeatures.ensureEnabled()` should be used appropriately.
>
> Used the `jdk.internal.misc.PreviewFeatures.isEnabled()` and remove an erroneous check in `typeSwitch`.

Addressed in https://github.com/openjdk/jdk/pull/15638/commits/663c7a54cec9ffd6ca468080f4d084e5fa4c9c3d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465039116

From abimpoudis at openjdk.org  Wed Jan 24 14:59:01 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 14:59:01 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v42]
In-Reply-To: <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
 <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
Message-ID: <2d_xzWvSpAAcu_RvESs8LipQDSvPL5A5N12t2VL6FMo=.b16e42ce-632a-4b1f-a7ab-a417ea39f86d@github.com>

On Wed, 24 Jan 2024 12:22:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set previewEnabled properly in SwitchBootstraps
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1924:
> 
>> 1922:     }
>> 1923:     // where
>> 1924:     static final Set<TypeTag> nonIntegralPrimitiveTypes = Set.of(
> 
> This feels like a method on TypeTag?

Addressed in https://github.com/openjdk/jdk/pull/15638/commits/9b7fb7fcdd2b393425267313622970ba709c645e

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4147:
> 
>> 4145:         }
>> 4146:         if (clazztype.isPrimitive()) {
>> 4147:             preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);
> 
> So, if I have a primitive instanceof, I get two preview warnings, one for the expression, and one for the pattern type? Shouldn't one be enough?

Meaning the `compiler.err.preview.feature.disabled.plural: (compiler.misc.feature.primitive.patterns)` error due to the two `if (clazztype.isPrimitive()) { preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);` ifs? Isn't it better to keep both, for better error reporting regarding the position? (i.e., which position do we report?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465034738
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465033188

From abimpoudis at openjdk.org  Wed Jan 24 15:26:54 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 15:26:54 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

 - Enhance Javadoc of ExactConversionsSupport (2)
 - Enhance Javadoc of ExactConversionsSupport

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/9b7fb7fc..aa9b2fcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=42-43

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

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

From abimpoudis at openjdk.org  Wed Jan 24 15:26:57 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 15:26:57 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v42]
In-Reply-To: <_hlWjNWAiPgvNTpwVWsBKURLCwySlIt5GoWiWKTJLRs=.3f069a48-2a82-408a-ba40-84d2b75b8ed3@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
 <_hlWjNWAiPgvNTpwVWsBKURLCwySlIt5GoWiWKTJLRs=.3f069a48-2a82-408a-ba40-84d2b75b8ed3@github.com>
Message-ID: <PXVNqX_5PEyNV1i_a5nAcALwty35cqU0mU3cZx1pUCc=.943eddb2-0902-4bd6-bad0-9020d0f83db8@github.com>

On Wed, 24 Jan 2024 12:13:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set previewEnabled properly in SwitchBootstraps
>
> src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 37:
> 
>> 35:  * action at run time.
>> 36:  * <p>
>> 37:  * The run time conversion checks examine whether loss of information would
> 
> You provide examples for runtime conversions - it would be useful, before this para, to also have examples of an inexact conversion, an exact conversion and an unconditionally exact conversion (before diving into the details of how the runtime check is performed for floating points).

Addressed in https://github.com/openjdk/jdk/pull/15638/commits/5e48ea253bb7d8ae6fcc15a1ae7adb30475ff4ac 

Good point!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465080703

From jiefu at openjdk.org  Wed Jan 24 15:27:42 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 24 Jan 2024 15:27:42 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <CQUy1H5or0ZNkZzri_7qizVClqCPPtmlbRDWb5nYL48=.b82ae3cc-598b-4133-a875-4d837808b21e@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
 <CQUy1H5or0ZNkZzri_7qizVClqCPPtmlbRDWb5nYL48=.b82ae3cc-598b-4133-a875-4d837808b21e@github.com>
Message-ID: <CrDmWxnBRkCblGtgiPpOf09jOKzhHU1WDRKqm0UaA8k=.229ca15f-a9e5-49d9-a5dd-30b18f6e2222@github.com>

On Tue, 23 Jan 2024 17:03:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Catch-all -> All tests
>
> Thank you all!

Hi @shipilev , plese see https://github.com/openjdk/jdk/pull/17558 .
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1908355476

From cstein at openjdk.org  Wed Jan 24 15:33:53 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Jan 2024 15:33:53 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
 [v2]
In-Reply-To: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
Message-ID: <BaKww-p0L1lxA26uJkhtPBOMTzNANpQDdVLTi6OA9lo=.17c325f9-c191-485f-a299-8bb1686985ae@github.com>

> Please review this fix to make the multi-file source-code launcher find classes with `$` in names, including names of packages, names of compliation units, and also names of enclosed types.
> 
> Tested tier1-3

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Include more intere'$'ting compilation units

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17526/files
  - new: https://git.openjdk.org/jdk/pull/17526/files/a8f92b90..38482e16

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

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

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

From cstein at openjdk.org  Wed Jan 24 15:33:56 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Jan 2024 15:33:56 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
 [v2]
In-Reply-To: <PMwGWL3wbZyAWUnmKALFUwunO95rCyjv-kc6hi0OZ1I=.e2f13083-e1c9-43cb-b9b6-f6c487f84f11@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
 <PMwGWL3wbZyAWUnmKALFUwunO95rCyjv-kc6hi0OZ1I=.e2f13083-e1c9-43cb-b9b6-f6c487f84f11@github.com>
Message-ID: <cKR58VwshCjcq-Jn08J5c09BLv-DDpIBcQX26EikV-c=.ede2fcf0-d923-4664-a706-55661d213746@github.com>

On Wed, 24 Jan 2024 08:01:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Include more intere'$'ting compilation units
>
> test/langtools/tools/javac/launcher/MultiFileSourceLauncherTests.java line 78:
> 
>> 76:                       public static void main(String... args) throws Exception {
>> 77:                         System.out.println(Class.forName("World$Core"));
>> 78:                         System.out.println(Class.forName("p.q.Unit$123$Fir$t$$econd"));
> 
> I think I would suggest two more tests:
> - one that would (in a separate run) lookup `p.q.Unit$123$Fir$t` (to ensure the search is broad enough)
> - one with a package name with `$`.

Added both tests a suggested.

The first is not test in the separate run, but a separate top-level compilation unit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17526#discussion_r1465095187

From cstein at openjdk.org  Wed Jan 24 15:33:58 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Jan 2024 15:33:58 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
 [v2]
In-Reply-To: <UszGKecLEjNRYoOOevf-0UPzHjW-iQFDr7TuWNT1G8M=.097b1d38-73fa-4e2b-a6a0-c8ff619c9cd3@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
 <Pq4ojU1Of4ZkQwCTrrdSpZuEhJH5X57SKsK-d1OV1ao=.652307ca-7a73-4e37-b6c1-bd1f71aed351@github.com>
 <UszGKecLEjNRYoOOevf-0UPzHjW-iQFDr7TuWNT1G8M=.097b1d38-73fa-4e2b-a6a0-c8ff619c9cd3@github.com>
Message-ID: <V-_b1m3O-bYpnw-fo-P-sLlyLiI8lsy-jsDbfs44AbM=.efdfae7b-66b8-4c3a-9215-c01866a30603@github.com>

On Tue, 23 Jan 2024 15:38:31 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> test/langtools/tools/javac/launcher/MultiFileSourceLauncherTests.java line 89:
>> 
>>> 87:                     """);
>>> 88:         var pq = Files.createDirectories(base.resolve("p/q"));
>>> 89:         Files.writeString(pq.resolve("Unit$123.java"),
>> 
>> Maybe?keep both?tests?
>
> There are plenty tests for canonically named compilation units, thus that wouldn't carry much extra worth.

Re-added the original test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17526#discussion_r1465095914

From vromero at openjdk.org  Wed Jan 24 15:37:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 15:37:38 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
Message-ID: <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>

On Wed, 24 Jan 2024 15:26:54 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Enhance Javadoc of ExactConversionsSupport (2)
>  - Enhance Javadoc of ExactConversionsSupport

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 461:

> 459:                                     // Object o = ...
> 460:                                     // o instanceof Wrapped(float)
> 461:                                     cb.aload(0);

probably just a matter of style so up to you, but I don't like the mixing of low level code generation here with higher level logic. I would prefer to see the code generation be extracted if possible to helper methods and or a separate helper class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465102870

From vromero at openjdk.org  Wed Jan 24 15:40:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 15:40:37 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
Message-ID: <98Xa1dqszc0IzREHFRDihwUi8_Y-NZ0i47NP-4pcfGc=.fbff61cf-f0ec-49e2-910f-19baa8c68565@github.com>

On Wed, 24 Jan 2024 15:26:54 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Enhance Javadoc of ExactConversionsSupport (2)
>  - Enhance Javadoc of ExactConversionsSupport

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 471:

> 469:                                     // o instanceof float
> 470:                                     Label notNumber = cb.newLabel();
> 471:                                     cb.aload(0);

we are wiring constants into code generation: `0`, `3` etc, probably those won't change but I would prefer using static final fields or enums, that can be documented and changed easily in the future if needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465107903

From jlahoda at openjdk.org  Wed Jan 24 15:41:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 24 Jan 2024 15:41:27 GMT
Subject: RFR: 8323815: Source launcher should find classes with $ in names
 [v2]
In-Reply-To: <BaKww-p0L1lxA26uJkhtPBOMTzNANpQDdVLTi6OA9lo=.17c325f9-c191-485f-a299-8bb1686985ae@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
 <BaKww-p0L1lxA26uJkhtPBOMTzNANpQDdVLTi6OA9lo=.17c325f9-c191-485f-a299-8bb1686985ae@github.com>
Message-ID: <2Mi7IF8-kdu21DA67om4fabX1NAsdwSEUyxjQeTxPDk=.3b75f3a8-97c2-4b81-92a0-dd5a9127f206@github.com>

On Wed, 24 Jan 2024 15:33:53 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this fix to make the multi-file source-code launcher find classes with `$` in names, including names of packages, names of compliation units, and also names of enclosed types.
>> 
>> Tested tier1-3
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include more intere'$'ting compilation units

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17526#pullrequestreview-1841700931

From abimpoudis at openjdk.org  Wed Jan 24 15:55:51 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 15:55:51 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Remove redundant test from checkUnconditionallyExact

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/aa9b2fcd..0fcdca82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=43-44

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

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

From abimpoudis at openjdk.org  Wed Jan 24 15:55:55 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 15:55:55 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v42]
In-Reply-To: <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
 <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
Message-ID: <9CCAFcGWzoHFi_4SaMN9i5KxnV3tSPnJAHvjQnZLE6I=.3db99d55-ded7-4a1a-a66e-fc6841af85fa@github.com>

On Wed, 24 Jan 2024 12:20:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set previewEnabled properly in SwitchBootstraps
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5046:
> 
>> 5044: 
>> 5045:         if (target.isPrimitive()) {
>> 5046:             return (source.isReference() && isSubtype(source, target)) ||
> 
> I'm a bit confused here - in here we have:
> * `target.isPrimitive()`
> * `source.isReference()`
> 
> So, isn't it the case that `isSubtype(source, target)` is always false?

Yes! Thanks for spotting. https://github.com/openjdk/jdk/pull/15638/commits/0fcdca8229c0db81fe3503770ed155a6aaa4f250

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465139800

From prappo at openjdk.org  Wed Jan 24 16:34:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 24 Jan 2024 16:34:38 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
Message-ID: <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>

On Fri, 19 Jan 2024 18:37:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge with upstream/master
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 238:

> 236:                         && postamble.isEmpty()
> 237:                         && fullBody.stream().anyMatch(t -> t.getKind() == Kind.MARKDOWN)
> 238:                         ? CommentStyle.JAVADOC_LINE : CommentStyle.JAVADOC_BLOCK;

While clever, it seems to be prone to false positive `JAVADOC_LINE`. Also, it is inconsistent with `null` and `Position.NOPOS` returned from the `getText` and `getSourcePos(int)` methods respectively.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 572:

> 570:                         }
> 571: 
> 572:                         case TEXT -> {

I haven't looked at `SentenceBreaker` in detail, but one thing that bothers me is that it sees a comment before that comment has been transformed. This means that `///` comments might not "feel" like Markdown to authors.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 704:

> 702:             }
> 703: 
> 704:             // If the break is well within the span of the string i.e. not

Oh irony! Sentence segmentation in javadoc has some problems with abbreviations like that.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 790:

> 788: 
> 789:         // end of paragraph is newline, followed by a blank line or the beginning of the next block
> 790:         private static final Pattern endPara = Pattern.compile("\n(([ \t]*\n)|( {0,3}[-+*#=]))");

So DocTreeMaker now also knows about Markdown. I wonder if we can avoid that. Also, I assume you mean this (`+` is not a part of "thematic break"):
Suggestion:

        private static final Pattern endPara = Pattern.compile("\n(([ \t]*\n)|( {0,3}[-_*#=]))");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1464830924
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465191542
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465201174
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465204965

From vromero at openjdk.org  Wed Jan 24 17:32:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 17:32:38 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
Message-ID: <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>

On Wed, 24 Jan 2024 15:55:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant test from checkUnconditionallyExact

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 168:

> 166:         requireNonNull(labels);
> 167: 
> 168:         labels = labels.clone();

just curious, why do we need to clone this array?

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 405:

> 403:      */
> 404:     @SuppressWarnings("removal")
> 405:     private static MethodHandle generateInnerClass(MethodHandles.Lookup caller, Class<?> selectorType, Object[] labels) {

again a matter of style but it seems to me that the huge lambda inside of this method, starting in line 409, really wants to be a separate helper method. That will probably be a better refactoring as we won't be mixing byte code generation with method handles manipulation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465292275
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465308346

From vromero at openjdk.org  Wed Jan 24 17:32:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 17:32:41 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>
Message-ID: <vG61n0KrAgt0bxRFlnDWvTkF14oKqxgy-dRVKogpcyQ=.cfda282c-c0d8-45cc-a9f0-71c9ba39002d@github.com>

On Wed, 24 Jan 2024 15:34:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Enhance Javadoc of ExactConversionsSupport (2)
>>  - Enhance Javadoc of ExactConversionsSupport
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 461:
> 
>> 459:                                     // Object o = ...
>> 460:                                     // o instanceof Wrapped(float)
>> 461:                                     cb.aload(0);
> 
> probably just a matter of style so up to you, but I don't like the mixing of low level code generation here with higher level logic. I would prefer to see the code generation be extracted if possible to helper methods and or a separate helper class.

see my other comment above that I think supersedes this one

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465309941

From darcy at openjdk.org  Wed Jan 24 18:17:35 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 18:17:35 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
Message-ID: <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>

On Wed, 24 Jan 2024 15:55:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant test from checkUnconditionallyExact

test/micro/org/openjdk/bench/jdk/preview/patterns/Exactness.java line 1:

> 1: /*

The exactness predicates should have regression tests on their correct operation in addition to any performance testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465361951

From abimpoudis at openjdk.org  Wed Jan 24 18:17:35 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 18:17:35 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>
Message-ID: <lQBIfpEe1-paJ_FbwCabZD7bRT8BwSzTvmlqfnDCHwM=.6e47de52-b25e-4f2e-a46c-42bceebbebcf@github.com>

On Wed, 24 Jan 2024 18:12:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant test from checkUnconditionallyExact
>
> test/micro/org/openjdk/bench/jdk/preview/patterns/Exactness.java line 1:
> 
>> 1: /*
> 
> The exactness predicates should have regression tests on their correct operation in addition to any performance testing.

I have this regarding numeric values

[test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java](https://github.com/openjdk/jdk/pull/15638/files#diff-0c7b37309d920b4c1af93789aed337c9eb259ad31977b9ef395e7b8c4b47a6d6)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465363618

From darcy at openjdk.org  Wed Jan 24 18:23:38 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 18:23:38 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <lQBIfpEe1-paJ_FbwCabZD7bRT8BwSzTvmlqfnDCHwM=.6e47de52-b25e-4f2e-a46c-42bceebbebcf@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>
 <lQBIfpEe1-paJ_FbwCabZD7bRT8BwSzTvmlqfnDCHwM=.6e47de52-b25e-4f2e-a46c-42bceebbebcf@github.com>
Message-ID: <_UoKEsRH6GvJlMfK10Q486qghFcXnD-MgBjEIAONvZI=.d9bde165-4546-48b2-aed8-a601a11fe044@github.com>

On Wed, 24 Jan 2024 18:14:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> I have this regarding numeric values. Is it the kind of test you have in mind?
> 
> [test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java](https://github.com/openjdk/jdk/pull/15638/files#diff-0c7b37309d920b4c1af93789aed337c9eb259ad31977b9ef395e7b8c4b47a6d6)

IMO, the library methods merit some of their own dedicated direct testing (since an end user could in principle call them too) in addition to indirect tests of their operation via javac's code generation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465371034

From vromero at openjdk.org  Wed Jan 24 18:28:35 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 18:28:35 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
Message-ID: <x2nZYFwy9fivbgvwqXt0sEGEnGg7Xp7_IE78gEdTJ5Y=.1e48ca08-c5ca-407c-bb7d-d2f09375acdc@github.com>

On Wed, 24 Jan 2024 15:55:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant test from checkUnconditionallyExact

test/langtools/tools/javac/patterns/CastConversionMatch.java line 6:

> 4:  * @summary Match which involves a cast conversion
> 5:  * @compile/fail/ref=CastConversionMatch.out -XDrawDiagnostics CastConversionMatch.java
> 6:  * @compile --enable-preview --source ${jdk.version} CastConversionMatch.java */

@enablePreview?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465374452

From abimpoudis at openjdk.org  Wed Jan 24 18:28:36 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 18:28:36 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <x2nZYFwy9fivbgvwqXt0sEGEnGg7Xp7_IE78gEdTJ5Y=.1e48ca08-c5ca-407c-bb7d-d2f09375acdc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <x2nZYFwy9fivbgvwqXt0sEGEnGg7Xp7_IE78gEdTJ5Y=.1e48ca08-c5ca-407c-bb7d-d2f09375acdc@github.com>
Message-ID: <U8aryv_FTnSU0nDMo5qObH1n3vNokjUakmOut35iaI4=.8cebebd2-9501-47aa-a48d-36eeddf3a039@github.com>

On Wed, 24 Jan 2024 18:24:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant test from checkUnconditionallyExact
>
> test/langtools/tools/javac/patterns/CastConversionMatch.java line 6:
> 
>> 4:  * @summary Match which involves a cast conversion
>> 5:  * @compile/fail/ref=CastConversionMatch.out -XDrawDiagnostics CastConversionMatch.java
>> 6:  * @compile --enable-preview --source ${jdk.version} CastConversionMatch.java */
> 
> @enablePreview?

I have two compile commands. Wanted to test one with and one without preview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465376180

From vromero at openjdk.org  Wed Jan 24 18:31:43 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 18:31:43 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
Message-ID: <yiE3AEKqj_mjHkWqs86pnB25yVblUBtAqlbEcQB4drA=.dac7be0b-8799-47b5-ae76-90b137c03dd7@github.com>

On Wed, 24 Jan 2024 15:55:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant test from checkUnconditionallyExact

test/langtools/tools/javac/patterns/PrimitiveInstanceOfPatternOpWithRecordPatterns.java line 28:

> 26:  * @bug 8304487
> 27:  * @summary Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
> 28:  * @compile -g --enable-preview -source ${jdk.version} PrimitiveInstanceOfPatternOpWithRecordPatterns.java

not sure why you need `-g` here

test/langtools/tools/javac/patterns/PrimitiveInstanceOfTypeComparisonOp.java line 28:

> 26:  * @bug 8304487
> 27:  * @summary Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
> 28:  * @compile -g --enable-preview -source ${jdk.version} PrimitiveInstanceOfTypeComparisonOp.java

`-g`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465376609
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465378575

From abimpoudis at openjdk.org  Wed Jan 24 18:41:54 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 18:41:54 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v46]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <pYINAEHW4gCCpSRz5jRT8tRGUTSFIZcszNLV1Da4BuA=.664de2e1-52da-4f7e-bdb4-27dc546a7c2b@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Cleanup test parameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/0fcdca82..ea31a804

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=44-45

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

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

From cstein at openjdk.org  Wed Jan 24 19:08:33 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Jan 2024 19:08:33 GMT
Subject: Integrated: 8323815: Source launcher should find classes with $ in
 names
In-Reply-To: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
References: <C2xdF1pvzOkjrp1-NIwhxqFZamS34I5WtZY-XreA1Bg=.11b9fbe7-6e5e-471d-a4ba-74b3dd2c08b1@github.com>
Message-ID: <zQCtd2J7JTd7YY3q3ng-hjwf9XxuRPIXDmEI92Rg6HE=.d72d3f36-5c4a-47cf-be7b-2275d4576195@github.com>

On Tue, 23 Jan 2024 07:06:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to make the multi-file source-code launcher find classes with `$` in names, including names of packages, names of compliation units, and also names of enclosed types.
> 
> Tested tier1-3

This pull request has now been integrated.

Changeset: c702dcab
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c702dcabf8befc2db2baf53655f20391ee5d2d09
Stats:     38 lines in 2 files changed: 30 ins; 0 del; 8 mod

8323815: Source launcher should find classes with $ in names

Reviewed-by: jlahoda, sundar

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

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

From abimpoudis at openjdk.org  Wed Jan 24 19:33:52 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 19:33:52 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v47]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <l4HLJUwtYx4lZzrgw-zcVcrNGTAdgNKmqmYdHbBarv0=.9721e1c9-5ba9-459a-b002-ea714287021a@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Introduce ExactnessConversionsSupportTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ea31a804..4e5ac772

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=45-46

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

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

From abimpoudis at openjdk.org  Wed Jan 24 19:36:33 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 19:36:33 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <_UoKEsRH6GvJlMfK10Q486qghFcXnD-MgBjEIAONvZI=.d9bde165-4546-48b2-aed8-a601a11fe044@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>
 <lQBIfpEe1-paJ_FbwCabZD7bRT8BwSzTvmlqfnDCHwM=.6e47de52-b25e-4f2e-a46c-42bceebbebcf@github.com>
 <_UoKEsRH6GvJlMfK10Q486qghFcXnD-MgBjEIAONvZI=.d9bde165-4546-48b2-aed8-a601a11fe044@github.com>
Message-ID: <cR5yggfMO79giT3ZnM4r_GdMBWmgj2aZBRB_kO8vE64=.c00efefb-e680-4454-81bb-66c0971da805@github.com>

On Wed, 24 Jan 2024 18:21:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I have this regarding numeric values. Is it the kind of test you have in mind?
>> 
>> [test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java](https://github.com/openjdk/jdk/pull/15638/files#diff-0c7b37309d920b4c1af93789aed337c9eb259ad31977b9ef395e7b8c4b47a6d6)
>
>> I have this regarding numeric values. Is it the kind of test you have in mind?
>> 
>> [test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java](https://github.com/openjdk/jdk/pull/15638/files#diff-0c7b37309d920b4c1af93789aed337c9eb259ad31977b9ef395e7b8c4b47a6d6)
> 
> IMO, the library methods merit some of their own dedicated direct testing (since an end user could in principle call them too) in addition to indirect tests of their operation via javac's code generation.

I did a translation of that file into [ExactnessConversionsSupportTest.java](https://github.com/openjdk/jdk/pull/15638/commits/4e5ac772417a2e50d47fd6fa8feb363a6bffa88c#diff-c24740028b9956d2dd2947907713f5e2d8681e8762f6d8e26e4faf2ded3979a8). What else could I add?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465445954

From vromero at openjdk.org  Wed Jan 24 20:31:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 20:31:34 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <U8aryv_FTnSU0nDMo5qObH1n3vNokjUakmOut35iaI4=.8cebebd2-9501-47aa-a48d-36eeddf3a039@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <x2nZYFwy9fivbgvwqXt0sEGEnGg7Xp7_IE78gEdTJ5Y=.1e48ca08-c5ca-407c-bb7d-d2f09375acdc@github.com>
 <U8aryv_FTnSU0nDMo5qObH1n3vNokjUakmOut35iaI4=.8cebebd2-9501-47aa-a48d-36eeddf3a039@github.com>
Message-ID: <jBwhPfKSEwDR6ybhYpXYm22zinGsk83k2s0dlnHSExs=.a6bd49e0-6fe3-412c-af00-b23207437f29@github.com>

On Wed, 24 Jan 2024 18:26:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/CastConversionMatch.java line 6:
>> 
>>> 4:  * @summary Match which involves a cast conversion
>>> 5:  * @compile/fail/ref=CastConversionMatch.out -XDrawDiagnostics CastConversionMatch.java
>>> 6:  * @compile --enable-preview --source ${jdk.version} CastConversionMatch.java */
>> 
>> @enablePreview?
>
> I have two compile commands. Wanted to test one with and one without preview.

right missed that sorry

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465499180

From mcimadamore at openjdk.org  Wed Jan 24 21:37:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 21:37:34 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v42]
In-Reply-To: <2d_xzWvSpAAcu_RvESs8LipQDSvPL5A5N12t2VL6FMo=.b16e42ce-632a-4b1f-a7ab-a417ea39f86d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
 <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
 <2d_xzWvSpAAcu_RvESs8LipQDSvPL5A5N12t2VL6FMo=.b16e42ce-632a-4b1f-a7ab-a417ea39f86d@github.com>
Message-ID: <k0icjkwLTcTlyIRZgFeTUt8OCydRVDwhc13wdlr04_U=.75aa6aab-8160-4a41-96c9-44bcfcfbbd42@github.com>

On Wed, 24 Jan 2024 14:53:19 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4147:
>> 
>>> 4145:         }
>>> 4146:         if (clazztype.isPrimitive()) {
>>> 4147:             preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);
>> 
>> So, if I have a primitive instanceof, I get two preview warnings, one for the expression, and one for the pattern type? Shouldn't one be enough?
>
> Meaning the `compiler.err.preview.feature.disabled.plural: (compiler.misc.feature.primitive.patterns)` error due to the two `if (clazztype.isPrimitive()) { preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);` ifs? Isn't it better to keep both, for better error reporting regarding the position? (i.e., which position do we report?)

What I mean is that, looking at the code, it seems like:

int x;
if (x instanceof int y) ...

will generate two warnings. Perhaps that's what we want, but it seems a bit on the heavy-side, subjectively. Anyway, no need to take any action.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465569066

From mcimadamore at openjdk.org  Wed Jan 24 21:50:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 21:50:34 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v47]
In-Reply-To: <l4HLJUwtYx4lZzrgw-zcVcrNGTAdgNKmqmYdHbBarv0=.9721e1c9-5ba9-459a-b002-ea714287021a@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <l4HLJUwtYx4lZzrgw-zcVcrNGTAdgNKmqmYdHbBarv0=.9721e1c9-5ba9-459a-b002-ea714287021a@github.com>
Message-ID: <IgYYtX0n0ZeKB0Bw-bGdMnnbttKgWgCFPCmvYCr5rjs=.bee7a753-1579-4962-b226-43465c062313@github.com>

On Wed, 24 Jan 2024 19:33:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce ExactnessConversionsSupportTest

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 33:

> 31:  * said to be unconditionally exact.
> 32:  * <p>
> 33:  * For example, a conversion from {@code int} to {@code byte} for the value 10

Very nice text!

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5045:

> 5043:         }
> 5044: 
> 5045:         if (target.isPrimitive()) {

nit: maybe now a ternary expression can be used

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465579085
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465580461

From abimpoudis at openjdk.org  Wed Jan 24 23:25:03 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:25:03 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v47]
In-Reply-To: <IgYYtX0n0ZeKB0Bw-bGdMnnbttKgWgCFPCmvYCr5rjs=.bee7a753-1579-4962-b226-43465c062313@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <l4HLJUwtYx4lZzrgw-zcVcrNGTAdgNKmqmYdHbBarv0=.9721e1c9-5ba9-459a-b002-ea714287021a@github.com>
 <IgYYtX0n0ZeKB0Bw-bGdMnnbttKgWgCFPCmvYCr5rjs=.bee7a753-1579-4962-b226-43465c062313@github.com>
Message-ID: <OxYJA95lrHGtxuvOz6hy0yN2bu_rgIWenIQhCrKElzU=.4c8b729d-10ca-477e-a900-cfca8b7f829a@github.com>

On Wed, 24 Jan 2024 21:47:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce ExactnessConversionsSupportTest
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5045:
> 
>> 5043:         }
>> 5044: 
>> 5045:         if (target.isPrimitive()) {
> 
> nit: maybe now a ternary expression can be used

Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465656376

From abimpoudis at openjdk.org  Wed Jan 24 23:25:00 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:25:00 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v48]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <c6hsnKQnLHTrtZGJfWm9k2Nkh05OoYZkNRHPuQgKd1Y=.41b85922-d59b-4726-be74-cc9e70d9df6d@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Simplify checkUnconditionallyExact

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/4e5ac772..4ed60e9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=46-47

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

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

From abimpoudis at openjdk.org  Wed Jan 24 23:42:48 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:42:48 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v49]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <ZrgtiMAuOD7pPLWVhozHqBjcHkEzvZKjoczIt6unI2g=.8b62e4f2-95ef-457b-950b-42bf7e274de2@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Cleanup redundant clone

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/4ed60e9d..80cfc06c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=47-48

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

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

From abimpoudis at openjdk.org  Wed Jan 24 23:42:51 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:42:51 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>
Message-ID: <G6TV0yUHitXPGovPRrI6OLE1Wm0qBNNbrnEEkrbBF2o=.b58d90dc-be70-4187-96ed-fe4e33f28abe@github.com>

On Wed, 24 Jan 2024 17:15:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant test from checkUnconditionallyExact
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 168:
> 
>> 166:         requireNonNull(labels);
>> 167: 
>> 168:         labels = labels.clone();
> 
> just curious, why do we need to clone this array?

No need. Remainings of a previous approach. Thanks for spotting

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465672119

From abimpoudis at openjdk.org  Wed Jan 24 23:50:51 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:50:51 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Update year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/80cfc06c..2af70ba2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=48-49

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

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

From darcy at openjdk.org  Thu Jan 25 02:57:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 02:57:40 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides
Message-ID: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>

Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.

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

Commit messages:
 - Appease jcheck.
 - JDK-8302019: Clarify Elements.overrides

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

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

From darcy at openjdk.org  Thu Jan 25 05:17:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 05:17:41 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v2]
In-Reply-To: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
Message-ID: <f70C68xohxqj3enH_lqaXox7W2q4rnppyizEnXpYI78=.d1402a8f-3dc0-4159-af5c-d9eb32e2100a@github.com>

> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.

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

  Update wording.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17564/files
  - new: https://git.openjdk.org/jdk/pull/17564/files/85983e2f..45bc365b

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

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

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

From prappo at openjdk.org  Thu Jan 25 09:25:31 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 Jan 2024 09:25:31 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v2]
In-Reply-To: <f70C68xohxqj3enH_lqaXox7W2q4rnppyizEnXpYI78=.d1402a8f-3dc0-4159-af5c-d9eb32e2100a@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <f70C68xohxqj3enH_lqaXox7W2q4rnppyizEnXpYI78=.d1402a8f-3dc0-4159-af5c-d9eb32e2100a@github.com>
Message-ID: <9YgRi9ryBWc6mjNw3UkzWHBAXvt6-0x0X5u7InSX9uA=.1bfd195c-232b-4014-bacf-4fdbbf3b0e0d@github.com>

On Thu, 25 Jan 2024 05:17:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update wording.

Thanks for addressing this, Joe. I have a few minor comments.

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

> 690:      * Consistent with the usage of the {@code @Override} annotation, if an
> 691:      * interface declares a method override-equivalent to a {@code
> 692:      * public} method on {@code java.lang.Object}, this method treats

Nit: I'm not sure about "on". JLS uses "of" in a similar [context]:
> the method is override-equivalent to a public method of Object

It seems like the only similar use of "on" in javax.** can be found here:
https://github.com/openjdk/jdk/blob/1f89acd8498945e1d531b7845748bcee8194115b/src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java#L149-L151

In other cases, "on" is preceded by "invoke" or "call", which has a different meaning.

[context]: https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.6.4.4

test/langtools/tools/javac/processing/model/util/elements/TestOverrides.java line 63:

> 61:             if (expectedOverrideResult !=
> 62:                 elements.overrides(method, findMethod(methodName, objectElt), objectInterfaceElt ) ) {
> 63:                 throw new RuntimeException("Unexpected overrding relation found for " + method);

Suggestion:

                throw new RuntimeException("Unexpected overriding relation found for " + method);

test/langtools/tools/javac/processing/model/util/elements/TestOverrides.java line 88:

> 86: 
> 87: /**
> 88:  * Interface that has methods override-equivalent to methods on

Similar comment on "on".

test/langtools/tools/javac/processing/model/util/elements/TestOverrides.java line 110:

> 108:     void finalize();
> 109: 
> 110:     // Final methods on Object (getClass, wait, notify[all]) rejected

Ditto.

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

PR Review: https://git.openjdk.org/jdk/pull/17564#pullrequestreview-1843157189
PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466040622
PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466066047
PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466045235
PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466069947

From mcimadamore at openjdk.org  Thu Jan 25 10:00:47 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:00:47 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
Message-ID: <C0ybRaPJXeBL4HC7DoQLeskmohS24VwMb1sevpassZs=.95aa463b-e58f-42a6-b729-fbfe845d6e3d@github.com>

On Wed, 24 Jan 2024 23:50:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update year

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 148:

> 146:      * @throws NullPointerException if any argument is {@code null}
> 147:      * @throws IllegalArgumentException if any element in the labels array is null, if the
> 148:      * invocation type is not a method type of first parameter of a reference type,

One thing we did often in the FFM API was to break up long `@throws` and split them into two or three `@throws` (javadoc allows the same exception to appear multiple times). Not saying you have to change this, just a possible suggestion (as I didn't know this!)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466119276

From mcimadamore at openjdk.org  Thu Jan 25 10:15:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:15:45 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <98Xa1dqszc0IzREHFRDihwUi8_Y-NZ0i47NP-4pcfGc=.fbff61cf-f0ec-49e2-910f-19baa8c68565@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <98Xa1dqszc0IzREHFRDihwUi8_Y-NZ0i47NP-4pcfGc=.fbff61cf-f0ec-49e2-910f-19baa8c68565@github.com>
Message-ID: <QqaM5-VqNW3qNdtaYZ5DtBcbitY79wh6pac7euslO1A=.d5569ffe-207e-4538-945c-db3e67301465@github.com>

On Wed, 24 Jan 2024 15:37:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Enhance Javadoc of ExactConversionsSupport (2)
>>  - Enhance Javadoc of ExactConversionsSupport
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 471:
> 
>> 469:                                     // o instanceof float
>> 470:                                     Label notNumber = cb.newLabel();
>> 471:                                     cb.aload(0);
> 
> we are wiring constants into code generation: `0`, `3` etc, probably those won't change but I would prefer using static final fields or enums, that can be documented and changed easily in the future if needed

Note also that the classfile API supports an higher-level construct to access method parameters, which supports _logical_ indexes (see CodeBuilder::parameterSlot). This would make the indices more robust against changes in types (e.g. int vs. long, where the latter would require two local variable slots)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466139675

From mcimadamore at openjdk.org  Thu Jan 25 10:18:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:18:39 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
Message-ID: <6ca0VuWfm7LeOOW5RZ818DP2zSafC87fdBt3LS2ZxPo=.7d7d6285-63a0-4982-95c3-891a9ff86dd2@github.com>

On Wed, 24 Jan 2024 23:50:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update year

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 592:

> 590:                                     element.caseLabel() instanceof Double ||
> 591:                                     element.caseLabel() instanceof Boolean)) {
> 592:                             //TODO: should call equals on the constant, not on the selector, check

Looking at the code, it seems like we're already calling equals on the constant? (I assume that's to avoid spurious NPEs?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466143827

From mcimadamore at openjdk.org  Thu Jan 25 10:25:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:25:38 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
Message-ID: <EfwyYi-nDkzNYFZ7_NPEQEYbk31wUG63NmDt1NQLyPk=.a47251bc-de34-4fcb-ade0-3ef7b1c0a963@github.com>

On Wed, 24 Jan 2024 23:50:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update year

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 404:

> 402:      */
> 403:     @SuppressWarnings("removal")
> 404:     private static MethodHandle generateInnerClass(MethodHandles.Lookup caller, Class<?> selectorType, Object[] labels) {

I think the name "labels" for the array here is unfortunate, because the code generation also contains "labels" which mean really "jump targets". Maybe `constants` or `labelConstants` or `caseConstants` ?

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 517:

> 515:                                 }
> 516:                             } else {
> 517:                                 Optional<ClassDesc> classLabelConstableOpt = classLabel.describeConstable();

One comment (for future work): we have a bunch of constants that are known by the time we generate this code (at runtime). But we're still serializing them into the constant pool, and then deserialize them at runtime, which is needless work. Hidden classes support injection of already resolved constants into the constant pool - see:

https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte%5B%5D,java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)

Basically, the idea is that you can pass the entire `labels` array as a "constant data" which is stored in the constant pool as a pre-resolved constant. You can then load elements from this array using ready-made method handles:

https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/invoke/MethodHandles.html#classDataAt(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class,int)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466151276
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466149901

From mcimadamore at openjdk.org  Thu Jan 25 10:25:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:25:40 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <vG61n0KrAgt0bxRFlnDWvTkF14oKqxgy-dRVKogpcyQ=.cfda282c-c0d8-45cc-a9f0-71c9ba39002d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>
 <vG61n0KrAgt0bxRFlnDWvTkF14oKqxgy-dRVKogpcyQ=.cfda282c-c0d8-45cc-a9f0-71c9ba39002d@github.com>
Message-ID: <iyult5xESig-et8cFe9IBL3NvwYTF74l2t0DxdxJJjo=.f3815d50-61ca-410a-bc4a-50561ad6a4cd@github.com>

On Wed, 24 Jan 2024 17:30:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 461:
>> 
>>> 459:                                     // Object o = ...
>>> 460:                                     // o instanceof Wrapped(float)
>>> 461:                                     cb.aload(0);
>> 
>> probably just a matter of style so up to you, but I don't like the mixing of low level code generation here with higher level logic. I would prefer to see the code generation be extracted if possible to helper methods and or a separate helper class.
>
> see my other comment above that I think supersedes this one

I see what you mean, that said, I think having some high-level checks driving low-level classfile generation is pretty standard for code generators (e.g. lambda metafactory, invoke bytecode generator, binding specializer). I agree on the fact that the lambda should probably moved onto a separate method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466153248

From jlahoda at openjdk.org  Thu Jan 25 10:54:36 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 25 Jan 2024 10:54:36 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <6ca0VuWfm7LeOOW5RZ818DP2zSafC87fdBt3LS2ZxPo=.7d7d6285-63a0-4982-95c3-891a9ff86dd2@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
 <6ca0VuWfm7LeOOW5RZ818DP2zSafC87fdBt3LS2ZxPo=.7d7d6285-63a0-4982-95c3-891a9ff86dd2@github.com>
Message-ID: <TmLA3DxTvecFJxe-oJW-b6U8mSQld1N-lai2Ro8V7I8=.fa8300e4-ab4e-4ee4-ac9b-7eb08a14b0b2@github.com>

On Thu, 25 Jan 2024 10:15:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update year
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 592:
> 
>> 590:                                     element.caseLabel() instanceof Double ||
>> 591:                                     element.caseLabel() instanceof Boolean)) {
>> 592:                             //TODO: should call equals on the constant, not on the selector, check
> 
> Looking at the code, it seems like we're already calling equals on the constant? (I assume that's to avoid spurious NPEs?)

The note there was to double-check that for selector `s` and constant `l`, we do something like `Long.valueOf(l).equals(s)`, not `s.equals(Long.valueOf(l))`, as the latter does not have the proper semantics. I believe Angelos is adding a test checking this is (and remains) the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466189962

From jlahoda at openjdk.org  Thu Jan 25 10:54:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 25 Jan 2024 10:54:33 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <QqaM5-VqNW3qNdtaYZ5DtBcbitY79wh6pac7euslO1A=.d5569ffe-207e-4538-945c-db3e67301465@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <98Xa1dqszc0IzREHFRDihwUi8_Y-NZ0i47NP-4pcfGc=.fbff61cf-f0ec-49e2-910f-19baa8c68565@github.com>
 <QqaM5-VqNW3qNdtaYZ5DtBcbitY79wh6pac7euslO1A=.d5569ffe-207e-4538-945c-db3e67301465@github.com>
Message-ID: <OjE1NT7kj8psl6VK7AZW5JxTSmkouZXHAfGmjjfyMHw=.0de46281-f09a-43d3-ab67-4b7ae0dcb396@github.com>

On Thu, 25 Jan 2024 10:12:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 471:
>> 
>>> 469:                                     // o instanceof float
>>> 470:                                     Label notNumber = cb.newLabel();
>>> 471:                                     cb.aload(0);
>> 
>> we are wiring constants into code generation: `0`, `3` etc, probably those won't change but I would prefer using static final fields or enums, that can be documented and changed easily in the future if needed
>
> Note also that the classfile API supports an higher-level construct to access method parameters, which supports _logical_ indexes (see CodeBuilder::parameterSlot). This would make the indices more robust against changes in types (e.g. int vs. long, where the latter would require two local variable slots)

This code is intentionally using low-level primitives, as Classfile API is using pattern matching, and using some higher-level primitives is not possible due to the bootstrap issues. `parameterSlot` would probably work, but it does not seem too significant - we know the parameter types that are send to the method, and it is a static method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466187756

From abimpoudis at openjdk.org  Thu Jan 25 11:21:12 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 11:21:12 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v51]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <T4fnCSJKIVf2HGEHcZHKh_ITj4zqcqOCl6SCuZoxsTI=.42c22163-ef56-4a3b-b2b8-d363f2bb0c28@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Improve readability in SwitchBootstraps

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/2af70ba2..13bfc436

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=49-50

  Stats: 347 lines in 2 files changed: 138 ins; 115 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

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

From abimpoudis at openjdk.org  Thu Jan 25 11:21:12 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 11:21:12 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <EfwyYi-nDkzNYFZ7_NPEQEYbk31wUG63NmDt1NQLyPk=.a47251bc-de34-4fcb-ade0-3ef7b1c0a963@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
 <EfwyYi-nDkzNYFZ7_NPEQEYbk31wUG63NmDt1NQLyPk=.a47251bc-de34-4fcb-ade0-3ef7b1c0a963@github.com>
Message-ID: <r2eQqGYZ7ZRMQnG92MapCYvl-37bgQSynhoaBf92x20=.8d0a334b-fc78-43b4-943b-94eea36c3d8f@github.com>

On Thu, 25 Jan 2024 10:21:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update year
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 404:
> 
>> 402:      */
>> 403:     @SuppressWarnings("removal")
>> 404:     private static MethodHandle generateInnerClass(MethodHandles.Lookup caller, Class<?> selectorType, Object[] labels) {
> 
> I think the name "labels" for the array here is unfortunate, because the code generation also contains "labels" which mean really "jump targets". Maybe `constants` or `labelConstants` or `caseConstants` ?

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466217507

From abimpoudis at openjdk.org  Thu Jan 25 11:21:13 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 11:21:13 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>
Message-ID: <VsEc9q9BW94meN_H8Up_whqIrhYdNQ29ZagPSqmRNXk=.9b1f1d90-2a0b-4038-8dd7-eb6ace3a4e69@github.com>

On Wed, 24 Jan 2024 17:29:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant test from checkUnconditionallyExact
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 405:
> 
>> 403:      */
>> 404:     @SuppressWarnings("removal")
>> 405:     private static MethodHandle generateInnerClass(MethodHandles.Lookup caller, Class<?> selectorType, Object[] labels) {
> 
> again a matter of style but it seems to me that the huge lambda inside of this method, starting in line 409, really wants to be a separate helper method. That will probably be a better refactoring as we won't be mixing byte code generation with method handles manipulation.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466217863

From abimpoudis at openjdk.org  Thu Jan 25 11:21:13 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 11:21:13 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <iyult5xESig-et8cFe9IBL3NvwYTF74l2t0DxdxJJjo=.f3815d50-61ca-410a-bc4a-50561ad6a4cd@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>
 <vG61n0KrAgt0bxRFlnDWvTkF14oKqxgy-dRVKogpcyQ=.cfda282c-c0d8-45cc-a9f0-71c9ba39002d@github.com>
 <iyult5xESig-et8cFe9IBL3NvwYTF74l2t0DxdxJJjo=.f3815d50-61ca-410a-bc4a-50561ad6a4cd@github.com>
Message-ID: <u38zE5Xd_22KarF26kUEZuGeHW3NGQe9yn6qLhfKu34=.1c353819-364b-447a-99ec-7cb56486807d@github.com>

On Thu, 25 Jan 2024 10:22:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> see my other comment above that I think supersedes this one
>
> I see what you mean, that said, I think having some high-level checks driving low-level classfile generation is pretty standard for code generators (e.g. lambda metafactory, invoke bytecode generator, binding specializer). I agree on the fact that the lambda should probably moved onto a separate method.

Done in https://github.com/openjdk/jdk/pull/15638/commits/13bfc43654f23f842ac71c1971de32da209d64d3

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466219133

From abimpoudis at openjdk.org  Thu Jan 25 13:53:06 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 13:53:06 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <C0ybRaPJXeBL4HC7DoQLeskmohS24VwMb1sevpassZs=.95aa463b-e58f-42a6-b729-fbfe845d6e3d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
 <C0ybRaPJXeBL4HC7DoQLeskmohS24VwMb1sevpassZs=.95aa463b-e58f-42a6-b729-fbfe845d6e3d@github.com>
Message-ID: <MWT9nsMPdVkpHKVyDClitF2L3dJKPMBLUXYPAaUwf9Q=.09d3979e-12a6-4359-9412-ff8850a56227@github.com>

On Thu, 25 Jan 2024 09:57:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update year
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 148:
> 
>> 146:      * @throws NullPointerException if any argument is {@code null}
>> 147:      * @throws IllegalArgumentException if any element in the labels array is null, if the
>> 148:      * invocation type is not a method type of first parameter of a reference type,
> 
> One thing we did often in the FFM API was to break up long `@throws` and split them into two or three `@throws` (javadoc allows the same exception to appear multiple times). Not saying you have to change this, just a possible suggestion (as I didn't know this!)

Indeed it looks better:

<img width="566" alt="Screenshot 2024-01-25 at 14 49 07" src="https://github.com/openjdk/jdk/assets/765983/84e6ae34-1e6b-4d36-98de-78f101be2336">

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466406565

From abimpoudis at openjdk.org  Thu Jan 25 13:53:04 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 13:53:04 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v52]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <aJg0I0EY3tW9XPpzC5F-fKmARuwBY5EQ40Ny2VP8_iM=.a2f969a2-588d-47e1-9a3d-f4659637bd62@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Tidy up Javadoc of IllegalArgumentException in typeSwitch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/13bfc436..b77d2316

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=50-51

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

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

From prappo at openjdk.org  Thu Jan 25 16:54:44 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 Jan 2024 16:54:44 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
Message-ID: <0zUYUefrZalsT0jrEQtrvFotZ5JPLWuNxSromK26qM8=.2e1139ff-e3f1-4f74-87cf-ffdd684d6b50@github.com>

On Tue, 23 Jan 2024 12:22:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1388:
> 
>> 1386:          * @see <a href="https://spec.commonmark.org/0.30/#thematic-breaks">Thematic Break</a>
>> 1387:          */
>> 1388:         THEMATIC_BREAK(Pattern.compile("((\\+[ \t]*+){3,})|((-[ \t]*+){3,})|((_[ \t]*+){3,})")),
> 
> Suggestion:
> 
>         /**
>          * Thematic break: a line of * - _ interspersed with optional spaces and tabs
>          * @see <a href="https://spec.commonmark.org/0.30/#thematic-breaks">Thematic Break</a>
>          */
>         THEMATIC_BREAK(Pattern.compile("((\*[ \t]*+){3,})|((-[ \t]*+){3,})|((_[ \t]*+){3,})")),

To add to my earlier [comment], DocCommentParser recognises THEMATIC_BREAK consisting of `-` as SETEXT_UNDERLINE. While it's inaccurate, it doesn't seem important, as DCP's goal is to recognise and avoid Markdown, not process it.

[comment]: https://github.com/openjdk/jdk/pull/16388/files#r1462148038

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1466315132

From prappo at openjdk.org  Thu Jan 25 16:54:51 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 Jan 2024 16:54:51 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
Message-ID: <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>

On Fri, 19 Jan 2024 18:37:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge with upstream/master
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 221:

> 219:                         }
> 220:                         String code = t.getContent();
> 221:                         // handle the (unlikely) case of FFFC characters existing in the code

For consistency with the rest of the file:
Suggestion:

                        // handle the (unlikely) case of U+FFFC characters existing in the code

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 230:

> 228:                             start = pos + 1;
> 229:                         }
> 230:                         sourceBuilder.append(code.substring(start));

If I understood this correctly, it could be achieved simpler:
Suggestion:

                            replacements.add(PLACEHOLDER);
                            start = pos + 1;
                        }
                        sourceBuilder.append(code);

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 353:

> 351:             return (equal(desc2, tree.description))
> 352:                     ? tree
> 353:                     : m.at(tree.pos).newReturnTree(tree.inline, desc2).setEndPos(tree.getEndPos());

Don't we need to set end position here only if the tag is in its inline variant?

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 487:

> 485:     }
> 486: 
> 487:     private static final String AUTOREF_PREFIX = "code:";

I wish the prefix were such that it could not be forged: for example, automatically assigned, unique within a document comment.

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 543:

> 541:                 @Override
> 542:                 public LinkReferenceDefinition getLinkReferenceDefinition(String label) {
> 543:                     var l = label.replace("\\[\\]", "[]");

That `String.replace` looks suspicious. FWIW, when I removed that `replace`, no tests failed.

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 559:

> 557:         private boolean isReference(String s) {
> 558:             try {
> 559:                 var ref = refParser.parse(s, ReferenceParser.Mode.MEMBER_OPTIONAL);

Suggestion:

                refParser.parse(s, ReferenceParser.Mode.MEMBER_OPTIONAL);

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 771:

> 769:                 copyTo(getStartPos(link));
> 770:                 // push temporary value for {@code trees} while handling the content of the node
> 771:                 var saveTrees = trees;

"saveTrees": I see what you did there :-)

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 882:

> 880:         private int getStartPos(Node node) {
> 881:             var spans = node.getSourceSpans();
> 882:             var firstSpan = spans.get(0);

Suggestion:

            var firstSpan = spans.getFirst();

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 894:

> 892:         private int getEndPos(Node node) {
> 893:             var spans = node.getSourceSpans();
> 894:             var lastSpan = spans.get(spans.size() - 1);

Suggestion:

            var lastSpan = spans.getLast();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465455477
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465591498
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465400705
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465628293
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465625839
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465626080
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1466197262
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465642275
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1465642491

From darcy at openjdk.org  Thu Jan 25 17:03:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 17:03:46 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v3]
In-Reply-To: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
Message-ID: <cufdZP43lsLKtc9ljx6UfP3F8X_ypHlSJmjIY4MC7P0=.4b6be982-6eee-4603-8568-26952fa367bb@github.com>

> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.

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

  Implement code review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17564/files
  - new: https://git.openjdk.org/jdk/pull/17564/files/45bc365b..b800846f

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

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

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

From darcy at openjdk.org  Thu Jan 25 17:26:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 17:26:51 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v4]
In-Reply-To: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
Message-ID: <vZzYXHdzRbw1uS2H87O1WoMfpayO8o3e76Z8IgzcIOg=.cf1f1b20-abdc-47e9-b057-30d9de9a19f5@github.com>

> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.

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

  Typo fix.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17564/files
  - new: https://git.openjdk.org/jdk/pull/17564/files/b800846f..f1e27bd4

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

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

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

From abimpoudis at openjdk.org  Thu Jan 25 17:33:14 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 17:33:14 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v53]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <KIT17QSUGnDWozPRmmDNl8fmiAmpvrRv4vwRLR-iVbM=.daeab00c-9c4d-49a3-a89d-5968de6f4525@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Tidy up Javadoc of Lower.visitTypeTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/b77d2316..44634684

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=51-52

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

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

From abimpoudis at openjdk.org  Thu Jan 25 17:46:07 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 17:46:07 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v54]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <0P6DMz53NNbzFireeMjPkayWCA93kTUGv0yAH9j-yP0=.27ec38d2-aa91-4aba-9d88-d94978d42abb@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Small fix in Javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/44634684..854c20a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=52-53

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

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

From darcy at openjdk.org  Thu Jan 25 18:12:52 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 18:12:52 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v5]
In-Reply-To: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
Message-ID: <4t4-BAZNflto0d3cVaC-ve7M3prPDV7NzI-Pv2RgHhQ=.8554ab69-4be4-45ae-918f-921bf597f80d@github.com>

> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.

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

  Refine javadoc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17564/files
  - new: https://git.openjdk.org/jdk/pull/17564/files/f1e27bd4..f60114a9

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

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

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

From prappo at openjdk.org  Thu Jan 25 19:04:36 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 Jan 2024 19:04:36 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v5]
In-Reply-To: <4t4-BAZNflto0d3cVaC-ve7M3prPDV7NzI-Pv2RgHhQ=.8554ab69-4be4-45ae-918f-921bf597f80d@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <4t4-BAZNflto0d3cVaC-ve7M3prPDV7NzI-Pv2RgHhQ=.8554ab69-4be4-45ae-918f-921bf597f80d@github.com>
Message-ID: <IRaotR01mfR_T0cI9wuXOuQ_eFi6u-d19HgTuHbW1J4=.d8470d7c-dd71-41fc-813c-e132dcaa0004@github.com>

On Thu, 25 Jan 2024 18:12:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine javadoc.

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

> 692:      * public} method of {@link Object java.lang.Object}, this method treats
> 693:      * any such interface methods as overriding the corresponding {@code
> 694:      * Object} method; example:

1. It doesn't help comprehension when "method" means two things in a sentence at the same time: (i) ExecutableElement that models a method and (ii) the method the doc comment belongs to (i.e. Elements.overrides) and that takes ExecutableElement as its argument(s). 
I understand that it's always tricky in `javax.lang.model` domain, but still wonder if the sentence can be tweaked a bit.

2. "example:"? Would "for example:" be better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466804259

From prappo at openjdk.org  Thu Jan 25 19:11:34 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 Jan 2024 19:11:34 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v5]
In-Reply-To: <4t4-BAZNflto0d3cVaC-ve7M3prPDV7NzI-Pv2RgHhQ=.8554ab69-4be4-45ae-918f-921bf597f80d@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <4t4-BAZNflto0d3cVaC-ve7M3prPDV7NzI-Pv2RgHhQ=.8554ab69-4be4-45ae-918f-921bf597f80d@github.com>
Message-ID: <k8uF-TaACvfecjEa6MDx8uA2AG7ncUrbyJeRHjNE5jA=.6e93f194-408c-4c61-abcd-ecc7751b5d74@github.com>

On Thu, 25 Jan 2024 18:12:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine javadoc.

Marked as reviewed by prappo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17564#pullrequestreview-1844449684

From darcy at openjdk.org  Thu Jan 25 19:21:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 19:21:51 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
Message-ID: <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>

> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.

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

  Respond to review feedback, update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17564/files
  - new: https://git.openjdk.org/jdk/pull/17564/files/f60114a9..ff0bc887

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

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

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

From jjg at openjdk.org  Thu Jan 25 19:57:41 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Jan 2024 19:57:41 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v14]
In-Reply-To: <vbaiokJvzM0jMuE_PF_ofvdwoZvHQH3jBM-LIdp1Eks=.ca0d4b26-36b3-4f88-b0d2-74adae6ed219@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <vbaiokJvzM0jMuE_PF_ofvdwoZvHQH3jBM-LIdp1Eks=.ca0d4b26-36b3-4f88-b0d2-74adae6ed219@github.com>
Message-ID: <n08oUpACiwHohzqlkgPQSc6SdvzxHZra9ptCQc0_eU4=.eef3d5b3-a8e2-41c4-ac1c-96e9235db6bf@github.com>

On Wed, 24 Jan 2024 06:08:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better describe intentions of stripAnnotations method.

LGTM.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/8984#pullrequestreview-1844572199

From jlahoda at openjdk.org  Thu Jan 25 19:57:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 25 Jan 2024 19:57:43 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <7COyJ1b5X_1Z6ZlMJ-LaG8jxOlY6n9qwNWJ8Ry0uvFY=.72cd939d-b535-4114-a312-a70342cd8b6e@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <WB_wJoKBzr1Hnv-XoXro27d6cRNaDb5bw0dPLf_o-18=.c2090a07-7357-4335-927c-20a73aa52b3f@github.com>
 <fSkwqrH3W-2kfhUjGC3tetU2Pcv4sPr7xR6DoSXBuGw=.9989d620-b712-4ac8-8a2f-389ebebfa171@github.com>
 <7COyJ1b5X_1Z6ZlMJ-LaG8jxOlY6n9qwNWJ8Ry0uvFY=.72cd939d-b535-4114-a312-a70342cd8b6e@github.com>
Message-ID: <h4FKBFGMk0xW_-Ymx8kiUyRYRxvrybqFQD3gUI9-yTk=.868bacd8-7995-460b-8019-9248f622cf8a@github.com>

On Wed, 24 Jan 2024 01:26:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> @jddarcy ?
>
> I don't think it is preserved in that case as much as a lookup/construction process is done based on the TypeElement, etc.
> 
> So I think leaving the annotation behavior unspecified is okay.

The `getDeclaredType` accepts `TypeMirror`s as the type arguments. I tried to invoke the method when this `TypeMirror` has an annotation, and the annotation is in the resulting `DeclaredType` as well. I don't mind this behavior, but my reading of the class' javadoc is that there should be no annotations, unless otherwise stated. And there does not seem to be anything in the `getDeclaredType` javadoc related to annotations on the type arguments, so the class' javadoc would apply. But maybe I miss something/read something wrong?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1466897048

From jjg at openjdk.org  Thu Jan 25 20:04:35 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Jan 2024 20:04:35 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
Message-ID: <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>

On Thu, 25 Jan 2024 19:21:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback, update copyright year.

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

> 704:      *                           elementForObjecttoString,
> 705:      *                           elements.getTypeElement("I"));
> 706:      * </pre></blockquote>

This would be better as a `@snippet`
(It's an archaic anti-pattern use of `<blockquote>`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466898015

From darcy at openjdk.org  Thu Jan 25 20:39:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 20:39:49 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v7]
In-Reply-To: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
Message-ID: <ahjC_2IueSwEQEX1PndZEInZY-zBNW3KVSHELJoofMo=.c62443df-dd28-4d26-8571-75e06130bced@github.com>

> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.

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

  Update to use a snippet.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17564/files
  - new: https://git.openjdk.org/jdk/pull/17564/files/ff0bc887..a0d1c762

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

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

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

From darcy at openjdk.org  Thu Jan 25 20:39:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 20:39:51 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
 <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>
Message-ID: <IVKWfMJxPYntCj3GyqoSb_RivURwOFh9dCdkg8g58qk=.852504a0-126b-4070-9b06-1d831e2e3023@github.com>

On Thu, 25 Jan 2024 19:55:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback, update copyright year.
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 706:
> 
>> 704:      *                           elementForObjecttoString,
>> 705:      *                           elements.getTypeElement("I"));
>> 706:      * </pre></blockquote>
> 
> This would be better as a `@snippet`
> (It's an archaic anti-pattern use of `<blockquote>`)

Is there a way to have `@Override` represented in the snippet? I can give that a try.

I don't think there is a strong need for this particular code and to be cut-and-pasted easily, but I can use more current features if possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466929706

From darcy at openjdk.org  Thu Jan 25 20:39:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 20:39:51 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <IVKWfMJxPYntCj3GyqoSb_RivURwOFh9dCdkg8g58qk=.852504a0-126b-4070-9b06-1d831e2e3023@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
 <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>
 <IVKWfMJxPYntCj3GyqoSb_RivURwOFh9dCdkg8g58qk=.852504a0-126b-4070-9b06-1d831e2e3023@github.com>
Message-ID: <2GbzfoUT4FZ8EKBcJs4iibjJd06LWKxlwFb0G4pJhZo=.21babaa0-f238-45e3-bc79-8590f46dbebe@github.com>

On Thu, 25 Jan 2024 20:32:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 706:
>> 
>>> 704:      *                           elementForObjecttoString,
>>> 705:      *                           elements.getTypeElement("I"));
>>> 706:      * </pre></blockquote>
>> 
>> This would be better as a `@snippet`
>> (It's an archaic anti-pattern use of `<blockquote>`)
>
> Is there a way to have `@Override` represented in the snippet? I can give that a try.
> 
> I don't think there is a strong need for this particular code and to be cut-and-pasted easily, but I can use more current features if possible.

Snippet works; change pushed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466933929

From jjg at openjdk.org  Thu Jan 25 21:18:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Jan 2024 21:18:34 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <2GbzfoUT4FZ8EKBcJs4iibjJd06LWKxlwFb0G4pJhZo=.21babaa0-f238-45e3-bc79-8590f46dbebe@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
 <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>
 <IVKWfMJxPYntCj3GyqoSb_RivURwOFh9dCdkg8g58qk=.852504a0-126b-4070-9b06-1d831e2e3023@github.com>
 <2GbzfoUT4FZ8EKBcJs4iibjJd06LWKxlwFb0G4pJhZo=.21babaa0-f238-45e3-bc79-8590f46dbebe@github.com>
Message-ID: <CW-Zcw6ekAmXSuqZvbGh6UIR-RcZMsXt0YoqJZlUw3o=.72bad110-9775-47c1-b5a0-5e60d5bbf250@github.com>

On Thu, 25 Jan 2024 20:37:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Is there a way to have `@Override` represented in the snippet? I can give that a try.
>> 
>> I don't think there is a strong need for this particular code and to be cut-and-pasted easily, but I can use more current features if possible.
>
> Snippet works; change pushed. Thanks.

Annotations in snippets work as expected. A medium-while back we changed the rules for `@` inside inline tags so that `@` inside an inline tag does not prematurely terminate the inline tag and start a block tag. Thus, `@` can be used for annotations inside `{@snippet...}, `{@code ...}` and any other inline tag.

Aside, FWIW, as a result of seeing your initial version, I did a repo-wide search for legacy use of `&commat;` (used a long time ago to avoid the annotation/block-tag conflict.).  The good news is that there are no other instances of `&commat;` in OpenJDK, so we must have done a cleanup in times past.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466966705

From jjg at openjdk.org  Thu Jan 25 21:18:36 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Jan 2024 21:18:36 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <CW-Zcw6ekAmXSuqZvbGh6UIR-RcZMsXt0YoqJZlUw3o=.72bad110-9775-47c1-b5a0-5e60d5bbf250@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
 <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>
 <IVKWfMJxPYntCj3GyqoSb_RivURwOFh9dCdkg8g58qk=.852504a0-126b-4070-9b06-1d831e2e3023@github.com>
 <2GbzfoUT4FZ8EKBcJs4iibjJd06LWKxlwFb0G4pJhZo=.21babaa0-f238-45e3-bc79-8590f46dbebe@github.com>
 <CW-Zcw6ekAmXSuqZvbGh6UIR-RcZMsXt0YoqJZlUw3o=.72bad110-9775-47c1-b5a0-5e60d5bbf250@github.com>
Message-ID: <tbzca0Ju-ZR6yD5jolOQwCzxhTIhrNIBUnK10XiNI_g=.23c3b555-8239-4634-a2ce-4663fceb6105@github.com>

On Thu, 25 Jan 2024 21:13:54 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Snippet works; change pushed. Thanks.
>
> Annotations in snippets work as expected. A medium-while back we changed the rules for `@` inside inline tags so that `@` inside an inline tag does not prematurely terminate the inline tag and start a block tag. Thus, `@` can be used for annotations inside `{@snippet...}, `{@code ...}` and any other inline tag.
> 
> Aside, FWIW, as a result of seeing your initial version, I did a repo-wide search for legacy use of `&commat;` (used a long time ago to avoid the annotation/block-tag conflict.).  The good news is that there are no other instances of `&commat;` in OpenJDK, so we must have done a cleanup in times past.

While snippets do provide the ability to copy the code to the clipboard, they also provide stylistic consistency for the reader, which is good. And maybe one of these days, we'll add support for syntax highlighting ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466968330

From darcy at openjdk.org  Thu Jan 25 21:35:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 21:35:54 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v15]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <O_OSx_8Uyw4_fFcY1EARLNvC5JwwsNz7bQIWqrrvbEc=.5b70b216-b19e-4f4a-a30a-063ac14aa0c8@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Update spec and tests for getDeclaredType

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/aa9154b2..e5ccaa71

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

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

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

From darcy at openjdk.org  Thu Jan 25 21:35:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 21:35:54 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <h4FKBFGMk0xW_-Ymx8kiUyRYRxvrybqFQD3gUI9-yTk=.868bacd8-7995-460b-8019-9248f622cf8a@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
 <WB_wJoKBzr1Hnv-XoXro27d6cRNaDb5bw0dPLf_o-18=.c2090a07-7357-4335-927c-20a73aa52b3f@github.com>
 <fSkwqrH3W-2kfhUjGC3tetU2Pcv4sPr7xR6DoSXBuGw=.9989d620-b712-4ac8-8a2f-389ebebfa171@github.com>
 <7COyJ1b5X_1Z6ZlMJ-LaG8jxOlY6n9qwNWJ8Ry0uvFY=.72cd939d-b535-4114-a312-a70342cd8b6e@github.com>
 <h4FKBFGMk0xW_-Ymx8kiUyRYRxvrybqFQD3gUI9-yTk=.868bacd8-7995-460b-8019-9248f622cf8a@github.com>
Message-ID: <zXuZj8UckIpX0HqJd_KN5RKjp_Ze6Y2vxJGH-kfR1Jk=.244947ec-5e6d-4b0e-8fae-45582899800b@github.com>

On Thu, 25 Jan 2024 19:54:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I don't think it is preserved in that case as much as a lookup/construction process is done based on the TypeElement, etc.
>> 
>> So I think leaving the annotation behavior unspecified is okay.
>
> The `getDeclaredType` accepts `TypeMirror`s as the type arguments. I tried to invoke the method when this `TypeMirror` has an annotation, and the annotation is in the resulting `DeclaredType` as well. I don't mind this behavior, but my reading of the class' javadoc is that there should be no annotations, unless otherwise stated. And there does not seem to be anything in the `getDeclaredType` javadoc related to annotations on the type arguments, so the class' javadoc would apply. But maybe I miss something/read something wrong?

Ah, right; the type arguments. I was thinking of the root return type. Specification and tests updated. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1466983878

From prappo at openjdk.org  Thu Jan 25 21:41:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 Jan 2024 21:41:35 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v7]
In-Reply-To: <ahjC_2IueSwEQEX1PndZEInZY-zBNW3KVSHELJoofMo=.c62443df-dd28-4d26-8571-75e06130bced@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <ahjC_2IueSwEQEX1PndZEInZY-zBNW3KVSHELJoofMo=.c62443df-dd28-4d26-8571-75e06130bced@github.com>
Message-ID: <mN-7b-A1kHA5oZonYfYvaoPm5P4ximlfJmZBZkRuAhg=.2e62cead-56e3-4e47-a4dd-70e3fdb4297f@github.com>

On Thu, 25 Jan 2024 20:39:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to use a snippet.

Marked as reviewed by prappo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17564#pullrequestreview-1844726617

From acobbs at openjdk.org  Thu Jan 25 21:41:36 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 25 Jan 2024 21:41:36 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <tbzca0Ju-ZR6yD5jolOQwCzxhTIhrNIBUnK10XiNI_g=.23c3b555-8239-4634-a2ce-4663fceb6105@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
 <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>
 <IVKWfMJxPYntCj3GyqoSb_RivURwOFh9dCdkg8g58qk=.852504a0-126b-4070-9b06-1d831e2e3023@github.com>
 <2GbzfoUT4FZ8EKBcJs4iibjJd06LWKxlwFb0G4pJhZo=.21babaa0-f238-45e3-bc79-8590f46dbebe@github.com>
 <CW-Zcw6ekAmXSuqZvbGh6UIR-RcZMsXt0YoqJZlUw3o=.72bad110-9775-47c1-b5a0-5e60d5bbf250@github.com>
 <tbzca0Ju-ZR6yD5jolOQwCzxhTIhrNIBUnK10XiNI_g=.23c3b555-8239-4634-a2ce-4663fceb6105@github.com>
Message-ID: <JG2Gd88YaY3uTS5FoAlD0s_3zDuplPelE0tep_fvprE=.9dd409fe-03a6-4bfe-8e9d-4a36131a30b9@github.com>

On Thu, 25 Jan 2024 21:16:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Annotations in snippets work as expected. A medium-while back we changed the rules for `@` inside inline tags so that `@` inside an inline tag does not prematurely terminate the inline tag and start a block tag. Thus, `@` can be used for annotations inside `{@snippet...}, `{@code ...}` and any other inline tag.
>> 
>> Aside, FWIW, as a result of seeing your initial version, I did a repo-wide search for legacy use of `&commat;` (used a long time ago to avoid the annotation/block-tag conflict.).  The good news is that there are no other instances of `&commat;` in OpenJDK, so we must have done a cleanup in times past.
>
> While snippets do provide the ability to copy the code to the clipboard, they also provide stylistic consistency for the reader, which is good. And maybe one of these days, we'll add support for syntax highlighting ;-)

> Aside, FWIW, as a result of seeing your initial version, I did a repo-wide search for legacy use of `&commat;` (used a long time ago to avoid the annotation/block-tag conflict.). The good news is that there are no other instances of `&commat;` in OpenJDK, so we must have done a cleanup in times past.

(drive by comment) One would also need to also look for `&#64;` which is still found in 15 files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1466988820

From jjg at openjdk.org  Thu Jan 25 22:13:37 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Jan 2024 22:13:37 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v7]
In-Reply-To: <ahjC_2IueSwEQEX1PndZEInZY-zBNW3KVSHELJoofMo=.c62443df-dd28-4d26-8571-75e06130bced@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <ahjC_2IueSwEQEX1PndZEInZY-zBNW3KVSHELJoofMo=.c62443df-dd28-4d26-8571-75e06130bced@github.com>
Message-ID: <Tu3vZvaHuX4V-yFpewr1_mrlH57X4hHENWpDTkI2QcA=.cfbb9858-fbe3-439f-97a6-6dbd40b118e2@github.com>

On Thu, 25 Jan 2024 20:39:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to use a snippet.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17564#pullrequestreview-1844769139

From jjg at openjdk.org  Thu Jan 25 22:13:39 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Jan 2024 22:13:39 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <JG2Gd88YaY3uTS5FoAlD0s_3zDuplPelE0tep_fvprE=.9dd409fe-03a6-4bfe-8e9d-4a36131a30b9@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
 <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>
 <IVKWfMJxPYntCj3GyqoSb_RivURwOFh9dCdkg8g58qk=.852504a0-126b-4070-9b06-1d831e2e3023@github.com>
 <2GbzfoUT4FZ8EKBcJs4iibjJd06LWKxlwFb0G4pJhZo=.21babaa0-f238-45e3-bc79-8590f46dbebe@github.com>
 <CW-Zcw6ekAmXSuqZvbGh6UIR-RcZMsXt0YoqJZlUw3o=.72bad110-9775-47c1-b5a0-5e60d5bbf250@github.com>
 <tbzca0Ju-ZR6yD5jolOQwCzxhTIhrNIBUnK10XiNI_g=.23c3b555-8239-4634-a2ce-4663fceb6105@github.com>
 <JG2Gd88YaY3uTS5FoAlD0s_3zDuplPelE0tep_fvprE=.9dd409fe-03a6-4bfe-8e9d-4a36131a30b9@github.com>
Message-ID: <_HPyoGYLt02DjZjuOv_wV7MCP0PF3iZOnAEzwnAKHjU=.7d4c7ad2-6d8b-434e-bd0b-bfa3a0347066@github.com>

On Thu, 25 Jan 2024 21:38:31 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> While snippets do provide the ability to copy the code to the clipboard, they also provide stylistic consistency for the reader, which is good. And maybe one of these days, we'll add support for syntax highlighting ;-)
>
>> Aside, FWIW, as a result of seeing your initial version, I did a repo-wide search for legacy use of `&commat;` (used a long time ago to avoid the annotation/block-tag conflict.). The good news is that there are no other instances of `&commat;` in OpenJDK, so we must have done a cleanup in times past.
> 
> (drive by comment) One would also need to also look for `&#64;` which is still found in 15 files.

@archiecobbs Thanks for that; I'll file an JBS issue to fix them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1467017031

From jjg at openjdk.org  Thu Jan 25 22:19:38 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Jan 2024 22:19:38 GMT
Subject: RFR: JDK-8302019: Clarify Elements.overrides [v6]
In-Reply-To: <_HPyoGYLt02DjZjuOv_wV7MCP0PF3iZOnAEzwnAKHjU=.7d4c7ad2-6d8b-434e-bd0b-bfa3a0347066@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
 <8YtiqgrHfEwUYU2u-JDzK61RBn0GHMGKzr4F_W-frBw=.a19d7d26-e96b-4440-a0cf-56cc9aa74cc4@github.com>
 <ldP4wrXJs6hqrvtCG9Oih09zjdvxlenB2zkpQlzslfw=.c960c405-ca92-4146-949f-95b394167b36@github.com>
 <IVKWfMJxPYntCj3GyqoSb_RivURwOFh9dCdkg8g58qk=.852504a0-126b-4070-9b06-1d831e2e3023@github.com>
 <2GbzfoUT4FZ8EKBcJs4iibjJd06LWKxlwFb0G4pJhZo=.21babaa0-f238-45e3-bc79-8590f46dbebe@github.com>
 <CW-Zcw6ekAmXSuqZvbGh6UIR-RcZMsXt0YoqJZlUw3o=.72bad110-9775-47c1-b5a0-5e60d5bbf250@github.com>
 <tbzca0Ju-ZR6yD5jolOQwCzxhTIhrNIBUnK10XiNI_g=.23c3b555-8239-4634-a2ce-4663fceb6105@github.com>
 <JG2Gd88YaY3uTS5FoAlD0s_3zDuplPelE0tep_fvprE=.9dd409fe-03a6-4bfe-8e9d-4a36131a30b9@github.com>
 <_HPyoGYLt02DjZjuOv_wV7MCP0PF3iZOnAEzwnAKHjU=.7d4c7ad2-6d8b-434e-bd0b-bfa3a0347066@github.com>
Message-ID: <2Q2BbxwqUa5wYxRUyCqBr59wGAcjf-aJ4btXgki2jYQ=.4a7d049c-6136-48cb-b4fd-03e453970ba5@github.com>

On Thu, 25 Jan 2024 22:11:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> Aside, FWIW, as a result of seeing your initial version, I did a repo-wide search for legacy use of `&commat;` (used a long time ago to avoid the annotation/block-tag conflict.). The good news is that there are no other instances of `&commat;` in OpenJDK, so we must have done a cleanup in times past.
>> 
>> (drive by comment) One would also need to also look for `&#64;` which is still found in 15 files.
>
> @archiecobbs Thanks for that; I'll file an JBS issue to fix them

I count 55 instances in 15 files in 5 modules, although not all are in public APIs

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17564#discussion_r1467020053

From darcy at openjdk.org  Thu Jan 25 22:19:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Jan 2024 22:19:40 GMT
Subject: Integrated: JDK-8302019: Clarify Elements.overrides
In-Reply-To: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
References: <URRKWL8LchujVFRSJDFN-1Ng0EAfCoi43PYGIauBJ3c=.be5fc0a6-0f23-45f1-8139-980657ae9480@github.com>
Message-ID: <ejQmGfSHxTH0D2fzKZelSKJhLmNhsDdKpXHhYIOy-mo=.1a9fdfaa-2040-40ee-9827-863caee2642f@github.com>

On Thu, 25 Jan 2024 02:37:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Explicitly discuss and test handling of an interface declaring methods that "override" public methods on java.lang.Object.

This pull request has now been integrated.

Changeset: b5995a76
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5995a76f79e0a70e67b0915e782e881efbbdf5e
Stats:     132 lines in 2 files changed: 131 ins; 0 del; 1 mod

8302019: Clarify Elements.overrides

Reviewed-by: prappo, jjg

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

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

From jjg at openjdk.org  Thu Jan 25 22:39:39 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Jan 2024 22:39:39 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v15]
In-Reply-To: <O_OSx_8Uyw4_fFcY1EARLNvC5JwwsNz7bQIWqrrvbEc=.5b70b216-b19e-4f4a-a30a-063ac14aa0c8@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <O_OSx_8Uyw4_fFcY1EARLNvC5JwwsNz7bQIWqrrvbEc=.5b70b216-b19e-4f4a-a30a-063ac14aa0c8@github.com>
Message-ID: <TKRFj_5_CtpCP3CpSlXb3JAqCLPs6QqQogD-e0LNFYI=.34be2f99-2439-49a3-83ec-62951ba8f78e@github.com>

On Thu, 25 Jan 2024 21:35:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update spec and tests for getDeclaredType

Approved, but suggest waiting for @lahodaj  as well.

src/java.compiler/share/classes/javax/lang/model/util/Types.java line 270:

> 268:      * Given the type element for {@code Set} and the type mirror
> 269:      * for {@code String},
> 270:      * for example, this method may be used to get the

While unrelated to this change, if you cam, I would suggest moving `for example` to the beginning of the sentence, to give the reader more context for the text that follows:

> For example, given the type element for {@code Set} and a type mirror for {@code String},
> this method may be used to get the parameterized type {@code Set<String>}.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/8984#pullrequestreview-1844797947
PR Review Comment: https://git.openjdk.org/jdk/pull/8984#discussion_r1467034294

From prappo at openjdk.org  Fri Jan 26 17:39:43 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 26 Jan 2024 17:39:43 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
Message-ID: <vVADmiqaRr_Vr4KBZLGZ84p7XFHjOnSu3YXHxT3R8ds=.9e9ac84c-d6e8-4f61-9a1f-90f33dbd4c07@github.com>

On Fri, 19 Jan 2024 18:37:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge with upstream/master
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 668:

> 666:          * U+FFFC characters that were found in the original document.
> 667:          */
> 668:         Iterator<?> replaceIter;

Suggestion:

        final Iterator<?> replaceIter;

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 732:

> 730:                 offsets.add(m.end());
> 731:             }
> 732:             sourceLineOffsets = offsets.stream().mapToInt(Integer::intValue).toArray();

Here's an alternative, which you might find better (or not):
Suggestion:

            sourceLineOffsets = Stream.concat(Stream.of(0), lineBreak.matcher(source).results()
                            .map(MatchResult::end)).mapToInt(Integer::intValue).toArray();

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 763:

> 761:          *
> 762:          * @param link the link node
> 763:          */

Suggestion:

        /**
         * Visits a {@code Link} commonmark node.
         *
         * If the destination for the link begins with {@code code:}
         * convert it to {@code {@link ...}} or {@code {@linkplain ...}} doc tree node.
         * {@code {@link ...}} will be used if the content (label) for
         * the link is the same as the reference found after the {@code code:};
         * otherwise, {@code {@linkplain ...}} will be used.
         *
         * The label will be left blank for {@code {@link ...}} nodes,
         * implying that a default label should be used, based on the
         * program element that was referenced.
         *
         * @param link the link node
         */

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 778:

> 776:                     copyTo(getEndPos(link.getLastChild()));
> 777: 
> 778:                     // determine whether to use {@link... } or {@linkplain ...}

Nit:
Suggestion:

                    // determine whether to use {@link ... } or {@linkplain ...}

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 831:

> 829:         /**
> 830:          * {@return the position in the original comment for a position in {@code source},
> 831:          * using {@link #replaceAdjustPos}}.

Suggestion:

         * using {@link #replaceAdjustPos}}

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 840:

> 838: 
> 839:         /**
> 840:          * Process a node and any children.

Suggestion:

         * Processes a node and any children.

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 939:

> 937: 
> 938:         /**
> 939:          * Flush any text in the {@code text} buffer, by creating a new

Suggestion:

         * Flushes any text in the {@code text} buffer, by creating a new

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 950:

> 948:     }
> 949: 
> 950: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467870392
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467870182
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467643549
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467871256
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467876796
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467871714
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467872096
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467872597

From jlahoda at openjdk.org  Fri Jan 26 17:57:39 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 26 Jan 2024 17:57:39 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v15]
In-Reply-To: <O_OSx_8Uyw4_fFcY1EARLNvC5JwwsNz7bQIWqrrvbEc=.5b70b216-b19e-4f4a-a30a-063ac14aa0c8@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <O_OSx_8Uyw4_fFcY1EARLNvC5JwwsNz7bQIWqrrvbEc=.5b70b216-b19e-4f4a-a30a-063ac14aa0c8@github.com>
Message-ID: <wbktFce2aovxKO_BiyBOyY6Zd8UJSvNPURa5Ng1sqZI=.1b204823-4586-4168-b711-9f24a7a30666@github.com>

On Thu, 25 Jan 2024 21:35:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update spec and tests for getDeclaredType

Just for completeness, the `getDeclaredType` method has two overloads, so maybe the second overload should get the note that it preserves the annotations as well. No need for re-review.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/8984#pullrequestreview-1846236174

From abimpoudis at openjdk.org  Fri Jan 26 18:02:58 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 26 Jan 2024 18:02:58 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v55]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Remove redundant null check  and introduce a const boolean for unconditionally exact pairs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/854c20a1..e466cfba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=53-54

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

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

From acobbs at openjdk.org  Fri Jan 26 18:37:49 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 Jan 2024 18:37:49 GMT
Subject: RFR: 8324736: Invalid end positions for EMPTY_STATEMENT
Message-ID: <GhY14ltWGsqQdbxBD-dANqyBGJuBYNoIljUtwkkxJKU=.bf646a22-c02d-4bcc-bf48-b952bd47bf97@github.com>

In the fix for [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), an `EMPTY_STATEMENT` representing a lone semicolon was being created with the wrong source code position. The bug was that the starting position needed to be captured prior to advancing to the next token, not after.

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

Commit messages:
 - Fix bug where source positions got reversed.

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

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

From darcy at openjdk.org  Fri Jan 26 20:04:55 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 20:04:55 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v16]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <2XznoonaMS_MyZmeaRRfj7k0jYNH50ZrxjLJtuNszgM=.3b25359c-23f6-434f-ae25-732e1ac15964@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Add spec update to overloaded method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/e5ccaa71..ef6e1e64

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

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

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

From darcy at openjdk.org  Fri Jan 26 20:48:42 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 20:48:42 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v17]
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <s8Inka9aMymnr8mkE2uOBPotyRZCY-SK3-0cz6RPoJg=.e8a37bda-22bf-42b0-b8f9-43f6c8836eb6@github.com>

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

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

  Add test cases.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8984/files
  - new: https://git.openjdk.org/jdk/pull/8984/files/ef6e1e64..425516af

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

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

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

From darcy at openjdk.org  Fri Jan 26 20:58:44 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 20:58:44 GMT
Subject: Integrated: JDK-8042981: Strip type annotations in Types' utility
 methods
In-Reply-To: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
Message-ID: <ajtP7bCJPnfZqP8jmrq1kr2A8KTRlPaBEBV_86tRx94=.7829eee9-ea90-456f-a872-b905f67cb57e@github.com>

On Thu, 2 Jun 2022 01:09:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
> 
> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.

This pull request has now been integrated.

Changeset: ed3272cc
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed3272cc44a5b1ae918b573e6c3d792665b6bbc7
Stats:     449 lines in 5 files changed: 438 ins; 0 del; 11 mod

8042981: Strip type annotations in Types' utility methods

Co-authored-by: Liam Miller-Cushon <cushon at openjdk.org>
Reviewed-by: cushon, jjg, jlahoda

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

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

From darcy at openjdk.org  Fri Jan 26 21:02:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 21:02:53 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods [v4]
In-Reply-To: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
Message-ID: <FWzVoCfbiHgO145_pQRUfZ-LKOooB9lDKUZ3pgsiYV8=.d9cef5b5-cd02-4880-8373-0d0138454262@github.com>

> Incremental improvements and clarifications in the specification of Types.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8175386
 - Implement review feedback.
 - Fix typo found in code review.
 - JDK-8175386: Clarify exception behavior of Types utility methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17523/files
  - new: https://git.openjdk.org/jdk/pull/17523/files/9aa3b2fa..c7433074

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

  Stats: 4985 lines in 319 files changed: 3563 ins; 691 del; 731 mod
  Patch: https://git.openjdk.org/jdk/pull/17523.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17523/head:pull/17523

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

From jjg at openjdk.org  Fri Jan 26 21:14:18 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Jan 2024 21:14:18 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v8]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <ZTqya-1C7BPE5QpdOLZS4idCre7WltxoyeLot8dnocw=.6988cfea-5015-4c73-a7b0-53c58a865ae3@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons 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 remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Merge with upstream/master
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Address review comments
 - Fix whitespace
 - Improve handling of embedded inline taglets
 - Customize support for Markdown headings
 - JDK-8298405: Support Markdown in Documentation Comments

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=07
  Stats: 21334 lines in 191 files changed: 20679 ins; 266 del; 389 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jjg at openjdk.org  Fri Jan 26 21:24:26 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Jan 2024 21:24:26 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods [v4]
In-Reply-To: <FWzVoCfbiHgO145_pQRUfZ-LKOooB9lDKUZ3pgsiYV8=.d9cef5b5-cd02-4880-8373-0d0138454262@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
 <FWzVoCfbiHgO145_pQRUfZ-LKOooB9lDKUZ3pgsiYV8=.d9cef5b5-cd02-4880-8373-0d0138454262@github.com>
Message-ID: <ut-5n3UQhSSbGukBSGCP_e3fCyIqcOFkw_waYi2OVZI=.cc9dcc6f-d068-4db2-b282-48b0213e4399@github.com>

On Fri, 26 Jan 2024 21:02:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Incremental improvements and clarifications in the specification of Types.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8175386
>  - Implement review feedback.
>  - Fix typo found in code review.
>  - JDK-8175386: Clarify exception behavior of Types utility methods

Marked as reviewed by jjg (Reviewer).

src/java.compiler/share/classes/javax/lang/model/util/Types.java line 48:

> 46:  * methods. One or more out of scope arguments will typically result
> 47:  * in a method throwing an {@link IllegalArgumentException
> 48:  * IllegalArgumentException}.

Nit: do you need the second argument? It should be the default string.

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

PR Review: https://git.openjdk.org/jdk/pull/17523#pullrequestreview-1846568129
PR Review Comment: https://git.openjdk.org/jdk/pull/17523#discussion_r1468158159

From darcy at openjdk.org  Fri Jan 26 21:54:33 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 21:54:33 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods [v4]
In-Reply-To: <ut-5n3UQhSSbGukBSGCP_e3fCyIqcOFkw_waYi2OVZI=.cc9dcc6f-d068-4db2-b282-48b0213e4399@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
 <FWzVoCfbiHgO145_pQRUfZ-LKOooB9lDKUZ3pgsiYV8=.d9cef5b5-cd02-4880-8373-0d0138454262@github.com>
 <ut-5n3UQhSSbGukBSGCP_e3fCyIqcOFkw_waYi2OVZI=.cc9dcc6f-d068-4db2-b282-48b0213e4399@github.com>
Message-ID: <GJFxQkE0i_1m-GNfelJ12LQrIB2irAvQ0m9G91ahot0=.a8f2d118-0023-454f-8206-ed8f2f0954a6@github.com>

On Fri, 26 Jan 2024 21:21:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8175386
>>  - Implement review feedback.
>>  - Fix typo found in code review.
>>  - JDK-8175386: Clarify exception behavior of Types utility methods
>
> src/java.compiler/share/classes/javax/lang/model/util/Types.java line 48:
> 
>> 46:  * methods. One or more out of scope arguments will typically result
>> 47:  * in a method throwing an {@link IllegalArgumentException
>> 48:  * IllegalArgumentException}.
> 
> Nit: do you need the second argument? It should be the default string.

I'll check if "java.lang" is inserted without the second argument.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17523#discussion_r1468181148

From darcy at openjdk.org  Fri Jan 26 22:22:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 22:22:46 GMT
Subject: RFR: JDK-8175386: Clarify exception behavior of Types utility
 methods [v5]
In-Reply-To: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
Message-ID: <AUZ-1EjPv_vD4R0ztdQRvHxOkwiSX1Z54TYxvSCJjCE=.dc6aced8-a411-45e9-b6e2-b884f06a8731@github.com>

> Incremental improvements and clarifications in the specification of Types.

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/17523/files
  - new: https://git.openjdk.org/jdk/pull/17523/files/c7433074..3c995e51

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

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

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

From darcy at openjdk.org  Fri Jan 26 22:36:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 22:36:40 GMT
Subject: Integrated: JDK-8175386: Clarify exception behavior of Types utility
 methods
In-Reply-To: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
References: <oHOju56Fes6Uux3RZWW73zgTfpj2vxRwzLwT3E8pFpY=.3a2c8c05-108b-4ddc-84d3-3ac57f78acf4@github.com>
Message-ID: <7AR1jJ93RAi3a-EzKwa_E2PBQBtSI5j_ZFF0jW-4LUg=.b6a59224-0ba7-421b-85b1-bfcda778b86b@github.com>

On Mon, 22 Jan 2024 21:51:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Incremental improvements and clarifications in the specification of Types.

This pull request has now been integrated.

Changeset: 2e748c99
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e748c998ee490d8c3b1c7ab2fadfcb4596fc07b
Stats:     17 lines in 1 file changed: 15 ins; 0 del; 2 mod

8175386: Clarify exception behavior of Types utility methods

Reviewed-by: jjg

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

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

From jlahoda at openjdk.org  Mon Jan 29 16:18:53 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Jan 2024 16:18:53 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v55]
In-Reply-To: <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
Message-ID: <8lRWOKmFWcWkgP5XCyXZGacvbtPRdco7AyVyJ4aVhNs=.afbba2a2-6757-4129-965e-f6c4609e8304@github.com>

On Fri, 26 Jan 2024 18:02:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant null check  and introduce a const boolean for unconditionally exact pairs

javac changes look sensible to me - some minor comments inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5040:

> 5038:      *  @param target     Target primitive or reference type
> 5039:      */
> 5040:     public boolean checkUnconditionallyExact(Type source, Type target) {

Maybe something like `isUnconditionallyExact`?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5060:

> 5058:      *  @param targetType       Target type
> 5059:      */
> 5060:     public boolean checkUnconditionallyExactPrimitives(Type selectorType, Type targetType) {

Maybe something like `isUnconditionallyExactPrimitives`?

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

> 1797:                             log.error(label.pos(), Errors.UnconditionalPatternAndDefault);
> 1798:                         }  else if (booleanSwitch && constants.containsAll(Set.of(0, 1))) {
> 1799:                             log.error(label.pos(), Errors.UnconditionalPatternAndDefault); // TODO improve error

Maybe file a follow-up to improve the error?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3079:

> 3077: 
> 3078:         // Resolve the exactness method
> 3079:         Symbol ecsym = rs.resolveQualifiedMethod(null,

Minor: better use `rs.resolveInternalMethod` or `this.lookupMethod`, so that the compilation fails more obviously if the method cannot be found.

test/langtools/tools/javac/diags/examples/NotApplicableTypes.java line 21:

> 19:  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> 20:  * or visit www.oracle.com if you need additional information or have any
> 21:  * questions.

The key does not exist any, per my understanding. I would suggest to simply delete the file.

test/langtools/tools/javac/diags/examples/SelectorTypeNotAllowed.java line 24:

> 22:  */
> 23: 
> 24: // key: compiler.err.preview.feature.disabled.plural

The key does not exist any, per my understanding. I would suggest to simply delete the file.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15638#pullrequestreview-1848712425
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469805646
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469806136
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469614384
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469811642
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469838360
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469838529

From vromero at openjdk.org  Mon Jan 29 20:27:46 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 29 Jan 2024 20:27:46 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v55]
In-Reply-To: <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
Message-ID: <7kcOKMS7ryi8yOLlyzjgRW7cK0aJzFIQHpqoRsV_sB4=.1caaf2cc-860a-44c3-9180-79b7df7ab7f2@github.com>

On Fri, 26 Jan 2024 18:02:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant null check  and introduce a const boolean for unconditionally exact pairs

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15638#pullrequestreview-1849695360

From jjg at openjdk.org  Mon Jan 29 21:16:59 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 21:16:59 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v9]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <pgWfUHbRb4SePjo5eXIolRkGgzPSs7WxjCUQHDXqduE=.08b7330d-cc08-48ef-8c81-6143598111d5@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons 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 remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Merge with upstream/master
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Address review comments
 - Fix whitespace
 - Improve handling of embedded inline taglets
 - Customize support for Markdown headings
 - JDK-8298405: Support Markdown in Documentation Comments

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=08
  Stats: 21334 lines in 191 files changed: 20679 ins; 266 del; 389 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jjg at openjdk.org  Mon Jan 29 22:14:42 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 22:14:42 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <81GrAewa5NKD4xg8oTdTzr3X_whVENpiaI-aUbUHMC8=.9c18fc4d-155d-4825-9d72-1fda0c0ff66c@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>
 <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
 <81GrAewa5NKD4xg8oTdTzr3X_whVENpiaI-aUbUHMC8=.9c18fc4d-155d-4825-9d72-1fda0c0ff66c@github.com>
Message-ID: <8M-Q1_V6QTLNtS503174G4CFD87BNmavK8kPijRV3Nc=.9a957e2e-b9c4-4ffe-bd6c-2399fc96e5cf@github.com>

On Wed, 13 Dec 2023 14:53:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> Should this issue have a CSR for the behavioral change?
>> 
>> My understanding of the issue is that the lookup of explicit-class member references in enclosing classes was an unintended consequence of doing the same for classless references from within nested classes. So I consider this a bug fix, not a feature change (even though it unfortunately changes javadoc to become stricter in what it accepts).
>> 
>> Actually, the feature of extending member reference lookup to enclosing classes is not specified in the taglet spec, which only says this:
>> 
>>> When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity.
>> 
>> This could be extended to include enclosing classes, but this is existing behaviour, not changed by this issue.
>
> @hns would you be able to create a linked bug to track that lookup order issue?

I note the preceding discussion including @pavelrappo's notes about order of lookup, and the separate issue to pursue this further.

It's also not clear to me that the statement in the description is "right":  _but @see Inner#method() should not_ 
If `Inner.method()` has a meaning (making allowances for `static` or not, etc) in nearby code, then shouldn't `Inner#method()` have a similar meaning?

I think that we should
1.  determine the lexical scope for the doc comment
2. follow the JLS rules as much as possible, with matching examples for doc comments and Java code as much as possible
3. clearly specify that doc comment names follow the JLS rules, except when they're not, and clearly specify any exceptions to those rules

All that is out of scope for here, and can be handled in [JDK-8324320](https://bugs.openjdk.org/browse/JDK-8324320), so I have one last question before I add my approval (or Pavel can lower the `/reviewer` count):
Does this change affect the published/latest JDK API documentation in any way?  I'm guessing not, but we've been surprised before.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1915665305

From jjg at openjdk.org  Mon Jan 29 22:45:44 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 22:45:44 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v2]
In-Reply-To: <T1KLSyGfObQ4z3a-4QgUjT04p89uCkArdpLdDLqEQMc=.e601055e-ac61-4b8e-a183-9bcca3403796@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vwdVQznmh6zobqCK-FAgF2lm-OXjsBw3uzrNGz2RBU4=.561f8895-fb52-4a9c-b67b-7279435abdc4@github.com>
 <f6GZy-khspCeJNrtdfOofvHDNHAnS05sIifH0P8kTrs=.d13e1487-accf-468f-9894-84df4b862640@github.com>
 <FdSxw9wT96YfeOcMM7N3uJZlcM9_c0GRzLpVCXSLdZE=.9cc8914d-b6c6-405a-9a8d-731deda75272@github.com>
 <0xaWRD1add432FW4NF8dhU3gi3q6BzPbhdnSMWKs2CY=.6ed27293-a889-4802-8e3f-e9f5d0a030e2@github.com>
 <oOjXFBl9kz1qSTVAjZ0qPTJFWwtB7pUeOWeeogvF0A4=.ba1a8d40-63c3-4d1b-ba64-00ceb9914524@github.com>
 <T1KLSyGfObQ4z3a-4QgUjT04p89uCkArdpLdDLqEQMc=.e601055e-ac61-4b8e-a183-9bcca3403796@github.com>
Message-ID: <JpRX3X6JISzAVZEOPqmLrme81kqY4_yLK5JuN62G36Q=.47253d69-c275-48b6-bfe1-00d4a26d465b@github.com>

On Wed, 17 Jan 2024 00:13:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Understood. FWIW, here are a few examples of headings in user-defined tags in JDK:
>> 
>> https://github.com/openjdk/jdk/blob/a6785e4d633908596ddb6de6d2eeab1c9ebdf2c3/src/java.base/share/classes/java/math/BigDecimal.java#L229-L239
>> 
>> https://github.com/openjdk/jdk/blob/ddbbd36e4b064b9e7433f0a55973d72cd6dbc0d3/src/java.xml/share/classes/module-info.java#L402-L420
>> 
>> https://github.com/openjdk/jdk/blob/6f6486e97743eadfb20b4175e1b4b2b05b59a17a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#L1089-L1093
>
> Thanks for the examples.
> 
> Stylistically, they are maybe questionable.  But we can make sure that something sensible happens, and deal with stylistic issues later.

Filed [JDK-8324876](https://bugs.openjdk.org/browse/JDK-8324876) to reconsider these tags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470321290

From jjg at openjdk.org  Mon Jan 29 22:49:46 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 22:49:46 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <hL9JteagRGnCieZjoYUuDU9wdyr9w4RrHGxDCQgS2Ts=.809da3ed-6515-4f2e-b56e-bd9d632810f7@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <hL9JteagRGnCieZjoYUuDU9wdyr9w4RrHGxDCQgS2Ts=.809da3ed-6515-4f2e-b56e-bd9d632810f7@github.com>
Message-ID: <puNCE037UiJ2U6MuGZhJ-ySLGd8vyGigZC42i4Xlwjk=.df7ecebd-c43f-42be-90fa-bdb42cac0c06@github.com>

On Fri, 12 Jan 2024 12:08:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.internal.md/share/classes/module-info.java line 29:
> 
>> 27:  * Internal support for Markdown.
>> 28:  *
>> 29:  * @since 22
> 
> Suggestion:
> 
>  * @since 23

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470324945

From jjg at openjdk.org  Mon Jan 29 23:04:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 23:04:32 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <0LBA9kWWGHD3jfYp5BD-pagDJ502nqoAv2jJg09Zs9o=.ac7495cc-6c94-4e6e-93fd-92464762f29b@github.com>

On Fri, 12 Jan 2024 14:28:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 97:
> 
>> 95:      */
>> 96:     public enum CommentKind {
>> 97:         /** The style of comments whose lines are prefixed by{@code ///}. */
> 
> Suggestion:
> 
>         /** The style of comments whose lines are prefixed by {@code ///}. */

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470340279

From jjg at openjdk.org  Mon Jan 29 23:07:38 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 23:07:38 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <nZ5mSOGZqmmKcYfBsEHq4zjevwVxP8J-fl3cJxid1o4=.092dc234-5174-4449-b2a9-37b3cfba4573@github.com>

On Fri, 12 Jan 2024 15:20:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 303:
> 
>> 301:      * @since 22
>> 302:      */
>> 303:     RawTextTree newRawTextTree(DocTree.Kind kind, String code) throws IllegalArgumentException;
> 
> It's unusual for a JDK method to declare a runtime exception.

removed; there is an `@throws` for the exception; that is enough

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470342549

From jjg at openjdk.org  Mon Jan 29 23:19:36 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 23:19:36 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <w8lQxY5brSRBfHvIQq-Qb12dg5HdAKbkfR_5tJIPjkY=.ae66d225-f916-4719-be19-03372eaf8b23@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
 <w8lQxY5brSRBfHvIQq-Qb12dg5HdAKbkfR_5tJIPjkY=.ae66d225-f916-4719-be19-03372eaf8b23@github.com>
Message-ID: <lzR9vfCD4WW8ZALNmLawTdZrwzJkIOyxbTGzg_fvyeo=.d589ee28-2c42-457f-991a-ed20bd91c9cd@github.com>

On Wed, 17 Jan 2024 00:24:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/source/doctree/RawTextTree.java line 40:
>> 
>>> 38:  * @apiNote
>>> 39:  * This class may be used to represent tree nodes containing
>>> 40:  * {@linkplain DocTree.Kind#MARKDOWN Markdown} text.
>> 
>> This means that there is one-to-many relationship between `RawTextTree` and `DocTree.KIND`. This in turn perpetuates the pattern of checking the kind followed by casting as opposed to more modern `instanceof` pattern matching. There's nothing wrong with it per se, however I wonder what the rationale is for leaving this part of the API open-ended. Is it to support other types of raw text in the future?
>
> Yes, the thinking was to allow it to be open-ended.
> 
> In this case, while I think we should specify the ability to use `instanceof`-style checks with this API, I do not think it would be necessary ... there is no need for a subtype for `MarkdownTree`, nor would I expect there to be one for any other kind of raw text.

Related: filed [JDK-8324877](https://bugs.openjdk.org/browse/JDK-8324877) to better specify the 1-1 relationship between subtypes of `DocTree` and members of `DocTree.Kind`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470351155

From jjg at openjdk.org  Mon Jan 29 23:19:42 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 23:19:42 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <_Bn8h9_cccQpycmJm4bBotvZP15JZDW68zLad29IGPg=.c200821c-04b1-481f-afdb-e73424fd648d@github.com>

On Fri, 12 Jan 2024 16:02:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 104:
> 
>> 102: 
>> 103:     /**
>> 104:      * {@return the style of the documentation comment associated with a tree node.}
> 
> Period is redundant:
> Suggestion:
> 
>      * {@return the style of the documentation comment associated with a tree node}

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470353416

From jjg at openjdk.org  Mon Jan 29 23:30:47 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 23:30:47 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <YTQu-JSFTbXtblo7gsfuk8QPmWQZTF31_JGV1iKurBo=.0c12a773-16e3-42e6-b1cc-c37983bb011d@github.com>

On Fri, 12 Jan 2024 16:49:31 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java line 157:
> 
>> 155:      * @param fileObject the content container
>> 156:      * @return the doc comment tree
>> 157:      * @throws IllegalArgumentException if the file type is not supported
> 
> It seems like this exception could've been thrown before, it's just that you have documented it for the first time. This might be important for CSR.

It's effectively a new exception, since before this work, we simply assumed that any file being read was in HTML format. Now, we check the file type, as described in the modified doc comment.   The entire doc comment is subject to CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470362514

From jjg at openjdk.org  Mon Jan 29 23:38:31 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 23:38:31 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <uv0-wEcbk0cdgcF2V4G7SHPu3WoH6hfdjspkWJk31SA=.40a3fe04-523b-40bd-83f9-28708de46901@github.com>

On Mon, 15 Jan 2024 12:30:09 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 215:
> 
>> 213:                  case '\n', '\r' -> {
>> 214:                      return newString(bp, p);
>> 215:                  }
> 
> Hm... this does not seem to be consistent with `newline` in `nextChar`; should it be consistent?

I think it is OK, isn't it?

In both cases, a newline sequence can begin with `\r` or `\n`.

In this `peekLine` method, we only want the content up to but not including the newline, so there is no need to handle the possibility of `\r\n`.   In `nextChar`, we do want to detect `r` and `\r\n` and treat both as equivalent to `\n`.

Or am I missing something?

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 241:
> 
>> 239:      * <li>{@code PREAMBLE}: the appearance of {@code <body>} (or {@code <main>}),
>> 240:      *      as determined by {@link #isEndPreamble()}
>> 241:      * <li>{@code BODY}: the beginning of a block tag, or when readung from
> 
> Suggestion:
> 
>      * <li>{@code BODY}: the beginning of a block tag, or when reading from

fixed

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 249:
> 
>> 247:      *
>> 248:      *
>> 249:      *
> 
> Suggestion:

fixed

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1000:
> 
>> 998:      * <li>cdata: {@code <![CDATA[ ... ]]>}
>> 999:      * </ul>
>> 1000:      *  or
> 
> Dangling "or".

Oops. fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470367971
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470369401
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470368948
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470368478

From abimpoudis at openjdk.org  Mon Jan 29 23:53:08 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 29 Jan 2024 23:53:08 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v56]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

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

  Address review by Jan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/e466cfba..8c27c5c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=54-55

  Stats: 165 lines in 12 files changed: 78 ins; 68 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

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

From jjg at openjdk.org  Mon Jan 29 23:53:44 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 23:53:44 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <w8lQxY5brSRBfHvIQq-Qb12dg5HdAKbkfR_5tJIPjkY=.ae66d225-f916-4719-be19-03372eaf8b23@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
 <w8lQxY5brSRBfHvIQq-Qb12dg5HdAKbkfR_5tJIPjkY=.ae66d225-f916-4719-be19-03372eaf8b23@github.com>
Message-ID: <4Tqtmfv4DzkI4sbb6bLBY9Ll0xd34vm9KBUzthu3fd8=.2e94fa19-e555-4371-bd2e-8506938527e8@github.com>

On Wed, 17 Jan 2024 00:25:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 89:
>> 
>>> 87:         POSTAMBLE,
>>> 88:         /** The rich-text content of an inline documentation comment tag. */
>>> 89:         INLINE
>> 
>> Do we also need to say something about `.md` files here?
>
> Probably, yes.

New class comment added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470380797

From jjg at openjdk.org  Tue Jan 30 00:05:46 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 00:05:46 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
Message-ID: <LXty2py7Lty6qg686-jkHWvNvClhTWp60UoxpLCZopc=.e6499029-e4b6-43c9-ad2c-d5bac3cd75c6@github.com>

On Mon, 15 Jan 2024 16:13:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1295:
> 
>> 1293:             switch (ch) {
>> 1294:                 case ' ' -> indent++;
>> 1295:                 case '\t' -> indent = 4;
> 
> Shouldn't it be like this or it does not matter?
>  ```suggestion
>                  case '\t' -> indent += 4;

I did mean `indent = 4`.
It would not mean `indent +=4` because you would have to take preceding character count into account, to round up to a multiple of 4.
But anyway, it's enough to know the indent is 4 or more, meaning the code is looking at an indented code block.
https://spec.commonmark.org/0.30/#indented-code-blocks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470390472

From jjg at openjdk.org  Tue Jan 30 00:31:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 00:31:43 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v5]
In-Reply-To: <Djw9flhSIBqkEoXerycl6GsJeykdYVN3Fjnn7TmSbFA=.38442fba-91ad-48fa-b870-4c44641dbe83@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5D_gyGHDR52UTLCcFnUNSWYXjYgcy3jYnffOXZ70xsg=.e1389d08-c9ae-481f-9c53-1ccd1e389102@github.com>
 <Djw9flhSIBqkEoXerycl6GsJeykdYVN3Fjnn7TmSbFA=.38442fba-91ad-48fa-b870-4c44641dbe83@github.com>
Message-ID: <xcvcJS9dDuY7PqwcwJg4nckU_qaooHreMfFr_yxAc2o=.bd5a642f-8511-4f2e-b61b-e867d83e0b00@github.com>

On Wed, 22 Nov 2023 09:37:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 178:
> 
>> 176:         List<DCTree> postamble = isHtmlFile ? content(Phase.POSTAMBLE) : List.nil();
>> 177: 
>> 178:         int pos = textKind == DocTree.Kind.MARKDOWN  ? 0
> 
> Suggestion:
> 
>         int pos = textKind == DocTree.Kind.MARKDOWN ? 0

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470411957

From jjg at openjdk.org  Tue Jan 30 00:31:46 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 00:31:46 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
Message-ID: <bLvDikZPDn2NrYxJp1f-OB8N34LTdQB5QSN8_5tJfpU=.b6d5cede-3bdf-405a-be07-0295a1bfe662@github.com>

On Mon, 15 Jan 2024 18:08:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1336:
> 
>> 1334:                     switch (initialLineKind) {
>> 1335:                         case CODE_FENCE -> {
>> 1336:                             if (lineKind == LineKind.CODE_FENCE && ch == term && count(ch) == count) {
> 
> https://spec.commonmark.org/0.30/#example-124 shows that the closing fence may be longer than the opening one: consider `count(ch) >= count`.
> 
> That said, I note that on my experiment the resulting output was identical with or without the change I ask you to consider. Perhaps I haven't yet understood how the parsing works.

Good catch. The spec has the words: _and with at least as many backticks or tildes_
Will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1421:
> 
>> 1419:             case '#', '=', '-', '+', '_', '`', '~' -> {
>> 1420:                 String line = peekLine();
>> 1421:                 for (LineKind lk : LineKind.values()) {
> 
> Nothing wrong here, just noting that this is one more way one can depend on an enum constant order. Change it, and a peeked line kind might change too (e.g. `OTHER` matches everything.)

Like it or not, JLS defines that enum members are ordered, and even has an example 8.9.3-1 of using the `values` method in an enhanced `for` loop. Any change to the order of the members of any enum has the potential to be a breaking change and should never be done lightly.  Curiously, JLS 13.4.26 does not say that reordering enum constants may break clients.

Anyway, I added comments to the LineKind enum declaration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470410143
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470408047

From jjg at openjdk.org  Tue Jan 30 00:36:48 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 00:36:48 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
Message-ID: <0Hd6nB-tCMmyw_kKynscXZOOOdOfxYoahOQ8ATPTPuQ=.cbd6411a-4b71-4be9-bc69-2745af2ca198@github.com>

On Mon, 15 Jan 2024 17:35:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1377:
> 
>> 1375:          * @see <a href="https://spec.commonmark.org/0.30/#atx-headings">ATX Headings</a>
>> 1376:          */
>> 1377:         ATX_HEADER(Pattern.compile("#{1,6}( .*|$)")),
> 
> Nothing wrong here, I just didn't know that an ATX header "opening sequence of # characters" can be followed by the end of line". Interesting.

:-) I think this comes in the general category of the _principle of least surprise and no errors_.  The only other possibility would be to treat it as an ordinary line starting with `#` characters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470419341

From jjg at openjdk.org  Tue Jan 30 00:42:47 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 00:42:47 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
Message-ID: <mYUhOCbMeG5EtIygSHpOAYyVun1Q8YcA3GucL1z1qcE=.33866d2d-c942-49c8-bc48-91df3021981d@github.com>

On Fri, 19 Jan 2024 11:38:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 259:
> 
>> 257:         LineKind lineKind = textKind == DocTree.Kind.MARKDOWN ? peekLineKind() : null;
>> 258: 
>> 259:         if (DEBUG) System.err.println("starting content " + showPos(bp) + " " + newline);
> 
> Debug output is useful. I wonder if we should consider https://openjdk.org/jeps/264.

My oops for leaving the code in, or at least not cleaning it up more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470424344

From jjg at openjdk.org  Tue Jan 30 00:50:45 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 00:50:45 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <flR9QGfiaBhXqoK_j0z67KC8aSbVgmV15-ZGGU1Nfog=.a06bc2dc-7e1c-4586-af4a-80ddfa0cd753@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
 <flR9QGfiaBhXqoK_j0z67KC8aSbVgmV15-ZGGU1Nfog=.a06bc2dc-7e1c-4586-af4a-80ddfa0cd753@github.com>
Message-ID: <5BjUOMWcopR-ouu-BVzMiDNUU5uZTFBhS4E0orGR9H4=.cb1112d1-7832-428f-b485-c417798248ab@github.com>

On Fri, 19 Jan 2024 16:59:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Musing on this more.
> 
> Can/should we, without introducing probably unwelcome `Kind.MD` to `javax.tools.JavaFileObject.Kind`, teach javac to recognise `package.md` similarly to how it recognises legacy `package.html`? If we are aiming for Markdown to be a drop in replacement for traditional javadoc comments, we might want to go the extra mile.
> 
> I'm pleased to see that Markdown `-overview` files work just fine.

No.  There are times to let go of legacy behavior, and even if this is not the time to remove support for `package.html`, there is no reason to go backwards and support `package.md`.   The preferred replacement for `package.html` has long been `package-info.java` and you can put Markdown content in that file with no issues.  

In similar fashion, remember the recent discussion as to whether we should support `@deprecated` in Markdown comments as marking the declaration as _deprecated_, even without the `@Deprecated` annotation. The general consensus was to not persist with that legacy behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1470430534

From jjg at openjdk.org  Tue Jan 30 01:03:53 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 01:03:53 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v10]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <Yt_JKhLea9GOkOqzeGZBx7f24UM2ApRjZvBWGOhD3Ic=.07cb1641-8ee1-4b40-a7fc-594d4fc82186@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:

 - fix @since tags
 - fix copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/4d22a100..5e3f03c8

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

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

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

From abimpoudis at openjdk.org  Tue Jan 30 08:33:49 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 30 Jan 2024 08:33:49 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v55]
In-Reply-To: <8lRWOKmFWcWkgP5XCyXZGacvbtPRdco7AyVyJ4aVhNs=.afbba2a2-6757-4129-965e-f6c4609e8304@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
 <8lRWOKmFWcWkgP5XCyXZGacvbtPRdco7AyVyJ4aVhNs=.afbba2a2-6757-4129-965e-f6c4609e8304@github.com>
Message-ID: <bpXeJbYfnvP2tE__FpNpsGTPnElofZejaxtGu1yaf0k=.8f971547-c238-4c01-a7d3-52a0dc2b5890@github.com>

On Mon, 29 Jan 2024 16:16:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
>
> javac changes look sensible to me - some minor comments inline.

Thx for all the comments @lahodaj @mcimadamore @vicente-romero-oracle @rgiulietti @jddarcy ? 

Addressed all @lahodaj

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1916314623

From jlahoda at openjdk.org  Tue Jan 30 10:07:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 30 Jan 2024 10:07:28 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v56]
In-Reply-To: <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>
Message-ID: <WAk8Ci4cciAoqnBZQeSyF9f3UI1bHc2XxOfOMhd0S60=.81692780-c81e-479c-a495-c9a2747fbb59@github.com>

On Mon, 29 Jan 2024 23:53:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review by Jan

lgtm

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15638#pullrequestreview-1850754613

From hannesw at openjdk.org  Tue Jan 30 16:17:18 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 30 Jan 2024 16:17:18 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <8M-Q1_V6QTLNtS503174G4CFD87BNmavK8kPijRV3Nc=.9a957e2e-b9c4-4ffe-bd6c-2399fc96e5cf@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>
 <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
 <81GrAewa5NKD4xg8oTdTzr3X_whVENpiaI-aUbUHMC8=.9c18fc4d-155d-4825-9d72-1fda0c0ff66c@github.com>
 <8M-Q1_V6QTLNtS503174G4CFD87BNmavK8kPijRV3Nc=.9a957e2e-b9c4-4ffe-bd6c-2399fc96e5cf@github.com>
Message-ID: <wD7sDb0l24TRpb_Q0_lfo7UfWPrhroEBlK6f8Ku9xA8=.508d03aa-c70e-4b3d-b439-676dcbda5a43@github.com>

On Mon, 29 Jan 2024 22:11:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> All that is out of scope for here, and can be handled in [JDK-8324320](https://bugs.openjdk.org/browse/JDK-8324320), so I have one last question before I add my approval (or Pavel can lower the `/reviewer` count): Does this change affect the published/latest JDK API documentation in any way? I'm guessing not, but we've been surprised before.

It affects the published JDK API docs insofar as it exposed [3 cases of method references with wrong types](https://bugs.openjdk.org/browse/JDK-8321889). This has already been fixed back in December.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1917081762

From hannesw at openjdk.org  Tue Jan 30 16:17:23 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 30 Jan 2024 16:17:23 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
Message-ID: <hZmqIBaNDmKwKPZeA83Yye98KLDkGJXw0tMzeIY2T5Q=.54aaaa58-5dfb-4680-8047-09413cb210bd@github.com>

On Tue, 12 Dec 2023 12:42:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a simple fix in `JavacTrees` to only look up member references in the enclosing type if the reference does not contain an explicit type name. For example, `@see #method()` in a a doc comment of class `Outer.Inner` should find method `Outer.method()`, but `@see Inner#method()` should not (regardless of comment location).
>
> Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8164094
>  - Additional test
>  - JDK-8164094: javadoc allows to create a @link to a non-existent method

Just to make sure I generated JDK API docs with and without this fix and there was no diff in outputs.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1917188014

From jjg at openjdk.org  Tue Jan 30 19:31:40 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 19:31:40 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <CFjtWK1WETf8v3nN5x1eSCWSJns0-IuLzNgat6U422g=.f0017a35-2118-4769-9f19-de6f950e0acc@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <CFjtWK1WETf8v3nN5x1eSCWSJns0-IuLzNgat6U422g=.f0017a35-2118-4769-9f19-de6f950e0acc@github.com>
Message-ID: <nIEg_Z_0G2mgbq_do1Xpga9OumWm_lN42ALSsb8zX6Y=.fbfee78b-123f-43c9-8e27-f6211130c66c@github.com>

On Mon, 22 Jan 2024 15:35:41 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 271:
> 
>> 269: //                        if (textStart == -1) {
>> 270: //                            textStart = bp;
>> 271: //                        }
> 
> What's up with that?

It was a temporary senior moment, attempting to trim the content of the comment -- but the leading whitespace is significant and should not be removed. The lines have been removed.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1165:
> 
>> 1163:     }
>> 1164: 
>> 1165: 
> 
> Please delete this blank line.

Done

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1333:
> 
>> 1331:                     lineKind = (ch == '\n' || ch == '\r') ? LineKind.BLANK
>> 1332:                             : (indent <= 3) ? peekLineKind()
>> 1333:                             : LineKind.OTHER;
> 
> Nested ternary-s are hard to read. Nested if-s are bulky. Sigh.

That was the neatest I could make it ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1471829709
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1471831762
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1471830921

From darcy at openjdk.org  Tue Jan 30 21:00:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Jan 2024 21:00:41 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>
 <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
Message-ID: <DYAzdVDGgi6MjpTNMMU28uVNj_fSDfyN0OMtq0eulQ8=.55232aa3-5c62-420c-a8ef-3ad6fac73649@github.com>

On Wed, 13 Dec 2023 10:44:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> > Should this issue have a CSR for the behavioral change?
> 
> My understanding of the issue is that the lookup of explicit-class member references in enclosing classes was an unintended consequence of doing the same for classless references from within nested classes. So I consider this a bug fix, not a feature change (even though it unfortunately changes javadoc to become stricter in what it accepts).
> 
> Actually, the feature of extending member reference lookup to enclosing classes is not specified in the taglet spec, which only says this:
> 
> > When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity.
> 
> This could be extended to include enclosing classes, but this is existing behaviour, not changed by this issue.

Looping back on this, independent of what the intended or specified behavior was before, if the behavior is changing now, even in agreed upon ways, the change should probably go through CSR review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1917882512

From jjg at openjdk.org  Tue Jan 30 21:01:39 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 21:01:39 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
Message-ID: <RgguBz62zNdVucu8FCnZlq4S6aLUBWiuctZORtVdDns=.aca1a3a6-94ae-4fff-828e-deb4e5e32208@github.com>

On Tue, 23 Jan 2024 12:01:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 225:
> 
>> 223:         while (ch == ' ' && bp < buflen) {
>> 224:             nextChar();
>> 225:         }
> 
> Why do we specifically care about `\s` symbols here rather than about broader whitespace?

Good catch and a tricky question. It's a conflict between typically skipping whitespace after a tag name (in traditional comments) and leading whitespace being significant in Markdown text.

Resolved in a compromise by using `isHorizontalWhiteSpace(c)` and adding an explanatory comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1471950685

From darcy at openjdk.org  Tue Jan 30 21:15:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Jan 2024 21:15:36 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v56]
In-Reply-To: <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>
Message-ID: <NlAdd_aRh0FyDnkSEKMLuhppVwiGx8RdxCDn-svUTw8=.82eb9cf5-bfe6-4b02-a51f-de28031bf44f@github.com>

On Mon, 29 Jan 2024 23:53:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review by Jan

test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java line 46:

> 44:  * @test
> 45:  * @bug 8304487
> 46:  * @summary Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

While the bug synopsis isn't off-topic for the summary, the summary could be more informative, something like:
"Verify boundary and special cases of exact conversion predicates", etc.

test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java line 65:

> 63:     }
> 64: 
> 65:     public static void testByte() {

If this test had the likelihood of needing to be updated, I would recommend some kind of refactoring so that the implicit loops ("for each of these boundary values in type T..") were explicit, but given that the test should not need to be updated often, I think the current approach is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1471963476
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1471968497

From jjg at openjdk.org  Tue Jan 30 21:20:37 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 21:20:37 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <0zUYUefrZalsT0jrEQtrvFotZ5JPLWuNxSromK26qM8=.2e1139ff-e3f1-4f74-87cf-ffdd684d6b50@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
 <0zUYUefrZalsT0jrEQtrvFotZ5JPLWuNxSromK26qM8=.2e1139ff-e3f1-4f74-87cf-ffdd684d6b50@github.com>
Message-ID: <oYoc9pCdcn_SSIbGx1Qk0EqnIpIOvppKuMkiFw0WQrE=.bc451693-3a0b-45c6-8442-5e5e4f56b83a@github.com>

On Thu, 25 Jan 2024 12:41:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1388:
>> 
>>> 1386:          * @see <a href="https://spec.commonmark.org/0.30/#thematic-breaks">Thematic Break</a>
>>> 1387:          */
>>> 1388:         THEMATIC_BREAK(Pattern.compile("((\\+[ \t]*+){3,})|((-[ \t]*+){3,})|((_[ \t]*+){3,})")),
>> 
>> Suggestion:
>> 
>>         /**
>>          * Thematic break: a line of * - _ interspersed with optional spaces and tabs
>>          * @see <a href="https://spec.commonmark.org/0.30/#thematic-breaks">Thematic Break</a>
>>          */
>>         THEMATIC_BREAK(Pattern.compile("((\*[ \t]*+){3,})|((-[ \t]*+){3,})|((_[ \t]*+){3,})")),
>
> To add to my earlier [comment], DocCommentParser recognises THEMATIC_BREAK consisting of `-` as SETEXT_UNDERLINE. While it's inaccurate, it doesn't seem important, as DCP's goal is to recognise and avoid Markdown, not process it.
> 
> [comment]: https://github.com/openjdk/jdk/pull/16388/files#r1462148038

Added lots more comment to the `LineKind` enum.

For the record, I would rephrase your statement about DCP's goal as follows: _DCP's goal is to recognize block boundaries when skipping over literal text, such as a code span; the specific kind of boundary generally does not matter._

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1471973350

From jjg at openjdk.org  Tue Jan 30 21:42:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 21:42:43 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
Message-ID: <VIgOZy_4rC8rWkb-re-lYOmabLq6vwl9lpg9U1Lbz7U=.ac116c11-dd6c-4fe6-82d6-fbe92354702c@github.com>

On Tue, 23 Jan 2024 12:50:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1396:
> 
>> 1394:          * @see <a href="https://spec.commonmark.org/0.30/#code-fence">Code Fence</a>
>> 1395:          */
>> 1396:         CODE_FENCE(Pattern.compile("(`{3,}[^`]*+)|(~{3,}.*+)")),
> 
> Why are this and the previous patterns possessive (`+`), while others aren't?

Trying to avoid the runaway performance problem, such as described here:
https://www.regular-expressions.info/catastrophic.html

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1065:
> 
>> 1063: 
>> 1064:                     if (accept('/')) { // (Spec. 3.7)
>> 1065:                         if (accept('/')) { // Markdown comment
> 
> Here and elsewhere in this file: do we need to mention Markdown?

The "M" word appears 10 times in this file. I'll work to convert them to an alternate nomenclature, such as "line comment".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1471991081
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1471995407

From jjg at openjdk.org  Tue Jan 30 22:09:10 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 22:09:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
Message-ID: <xgEj8rLKkoHksCTsuNsnOR_W1g6S2wdA_D29zOmiXjs=.7a2e95ee-1a6e-4757-98d4-579789cce561@github.com>

On Tue, 23 Jan 2024 15:07:15 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1553:
> 
>> 1551: 
>> 1552:         /**
>> 1553:          * Determine how much indent to remove from markdown comment.
> 
> Suggestion:
> 
>          * Determine how much indent to remove from Markdown comment.

fixed

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1585:
> 
>> 1583:          */
>> 1584:         UnicodeReader trimMarkdownComment(UnicodeReader line, int indent) {
>> 1585:             int pos = line.position();
> 
> Unused.

Yes, and the method has no side effects. Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472018320
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472020269

From jjg at openjdk.org  Tue Jan 30 22:15:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 22:15:34 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <CFjtWK1WETf8v3nN5x1eSCWSJns0-IuLzNgat6U422g=.f0017a35-2118-4769-9f19-de6f950e0acc@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <CFjtWK1WETf8v3nN5x1eSCWSJns0-IuLzNgat6U422g=.f0017a35-2118-4769-9f19-de6f950e0acc@github.com>
Message-ID: <-lRAdoRxdP6KQp7EeUDMEMnOTe_EbNRPZAiSQnfvRes=.e8c57191-3f8c-406f-a609-baba15bd233e@github.com>

On Mon, 22 Jan 2024 16:57:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1377:
> 
>> 1375:          * @see <a href="https://spec.commonmark.org/0.30/#atx-headings">ATX Headings</a>
>> 1376:          */
>> 1377:         ATX_HEADER(Pattern.compile("#{1,6}( .*|$)")),
> 
> Actually, I wonder how accurate those regexes should match spec. Given the definition [^*] of an ATX header and the fact that we always match the complete (not find inside) a line, which by definition should not have line terminators, shouldn't it be like this?
> 
>     #{1,6}([ \t]+.*)?
> 
> [^*]: The opening sequence of # characters must be followed by spaces or tabs, or by the end of line.

The spec says:

> The opening sequence of # characters must be followed by spaces or tabs, or by the end of line. 

so we're both slightly wrong. :-)

I will fix to `"#{1,6}([ \t].*|$)"))`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472036765

From jjg at openjdk.org  Tue Jan 30 22:20:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 22:20:32 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
Message-ID: <ohYloz8wCYEOYIyZikVorGO_-rBUdIBE6JD92WC5npE=.5d5b5755-5436-412e-ac77-35b45012cd55@github.com>

On Tue, 23 Jan 2024 15:17:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ParserFactory.java line 30:
> 
>> 28: import java.util.Locale;
>> 29: 
>> 30: import com.sun.source.util.DocTrees;
> 
> Unused.

removed

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 35:
> 
>> 33: import com.sun.source.doctree.*;
>> 34: import com.sun.source.doctree.AttributeTree.ValueKind;
>> 35: import com.sun.source.util.DocTreeScanner;
> 
> Unused.

removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472042122
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472042782

From jjg at openjdk.org  Tue Jan 30 23:05:01 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 23:05:01 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
Message-ID: <VTji38I7HGKI1AUlEMVsi9JYigC95o9CtsixpbEsOWQ=.07171023-990d-40f9-815b-7721537d3264@github.com>

On Wed, 24 Jan 2024 12:17:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 238:
> 
>> 236:                         && postamble.isEmpty()
>> 237:                         && fullBody.stream().anyMatch(t -> t.getKind() == Kind.MARKDOWN)
>> 238:                         ? CommentStyle.JAVADOC_LINE : CommentStyle.JAVADOC_BLOCK;
> 
> While clever, it seems to be prone to false positive `JAVADOC_LINE`. Also, it is inconsistent with `null` and `Position.NOPOS` returned from the `getText` and `getSourcePos(int)` methods respectively.

I'm not worried about false positive `JAVADOC_LINE` than maybe false _negative_ `JAVADOC_LINE`.  Generally, the underlying issue here is how to handle weird combinations of `DocTrees` constructed by a user of the public API.  For example, should we check, and reject, a `fullBody` containing `MARKDOWN` nodes and non-empty  `preamble` or `postamble`, since that combination will never come from `DocCommentParser`.

I'm not worried about comparison with `getText` and `getSourcePos`, since there really is no other value for the source text or source position that we can return. But we can infer a best guess for the style.

Arguably, we should check the `tags` as well.

------

I dug deeper.

We do create synthetic trees in the standard doclet, such as for the descriptions of mandated methods (like `values` and `valueOf` for any enum class.  Those synthetic trees do utilize this code path, although the `getStyle` method is not currently invoked. (Verified by changing code to throw `UnsupportedOperationException` and run all the tests.) It's also true those synthetic trees do not leverage any Markdown support at this time.

I prefer to leave the code as-is at this time.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 704:
> 
>> 702:             }
>> 703: 
>> 704:             // If the break is well within the span of the string i.e. not
> 
> Oh irony! Sentence segmentation in javadoc has some problems with abbreviations like that.

This was fixed 10/26/23.
Both forms of the sentence breaker are supposed to get this correct, but yes, chuckle, irony.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472082408
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472089239

From jjg at openjdk.org  Tue Jan 30 23:11:05 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 23:11:05 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v10]
In-Reply-To: <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
Message-ID: <h1baGO4_88DIboIvFWEK-QfaeWbjLrkuwFV5Xz1iOIw=.a878dcce-b168-4114-a842-a704ddb0caf3@github.com>

On Wed, 24 Jan 2024 16:24:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix @since tags
>>  - fix copyright year
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 572:
> 
>> 570:                         }
>> 571: 
>> 572:                         case TEXT -> {
> 
> I haven't looked at `SentenceBreaker` in detail, but one thing that bothers me is that it sees a comment before that comment has been transformed. This means that `///` comments might not "feel" like Markdown to authors.

First up: I do not understand your second sentence: _This means that /// comments might not "feel" like Markdown to authors._    Please rephrase or clarify that.

That aside, there's a big case of chickens and eggs here.  The API assumes that the first sentence is distinct from the rest of the description, so we cannot transform it at that early stage.  But generally, the first sentence is supposed to be reasonably simple text, and for cases where it is not, you can use the `summary` tag to circumvent any use of the sentence breaker.

Bottom line, I do not see any cause for concern at this time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472097755

From jjg at openjdk.org  Tue Jan 30 23:18:15 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 23:18:15 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
Message-ID: <e0aoGsEBu6BxJgwRLe8EWXsZuRzJYC8POqB22FVVWhE=.c15250b4-1680-48d7-82de-bb512e0f3afd@github.com>

On Wed, 24 Jan 2024 16:30:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 790:
> 
>> 788: 
>> 789:         // end of paragraph is newline, followed by a blank line or the beginning of the next block
>> 790:         private static final Pattern endPara = Pattern.compile("\n(([ \t]*\n)|( {0,3}[-+*#=]))");
> 
> So DocTreeMaker now also knows about Markdown. I wonder if we can avoid that. Also, I assume you mean this (`+` is not a part of "thematic break"):
> Suggestion:
> 
>         private static final Pattern endPara = Pattern.compile("\n(([ \t]*\n)|( {0,3}[-_*#=]))");

The code is doing its best to model the non-Markdown behavior, which is to detect paragraph breaks, which terminate the first sentence in the absence of any period.

`+` is in the pattern as a list marker; I added `_` for thematic break, and added more comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472103907

From jjg at openjdk.org  Tue Jan 30 23:39:51 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 23:39:51 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
Message-ID: <nktrhX348MwRMbBWHcWaj-nuOcbt0P7D0mFn-zrbZws=.9ee9c64e-98ff-4d4b-ba33-e5c1dc69f93c@github.com>

On Wed, 24 Jan 2024 19:43:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 221:
> 
>> 219:                         }
>> 220:                         String code = t.getContent();
>> 221:                         // handle the (unlikely) case of FFFC characters existing in the code
> 
> For consistency with the rest of the file:
> Suggestion:
> 
>                         // handle the (unlikely) case of U+FFFC characters existing in the code

Fixed

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 230:
> 
>> 228:                             start = pos + 1;
>> 229:                         }
>> 230:                         sourceBuilder.append(code.substring(start));
> 
> If I understood this correctly, it could be achieved simpler:
> Suggestion:
> 
>                             replacements.add(PLACEHOLDER);
>                             start = pos + 1;
>                         }
>                         sourceBuilder.append(code);

clever!

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 353:
> 
>> 351:             return (equal(desc2, tree.description))
>> 352:                     ? tree
>> 353:                     : m.at(tree.pos).newReturnTree(tree.inline, desc2).setEndPos(tree.getEndPos());
> 
> Don't we need to set end position here only if the tag is in its inline variant?

It has an `endPos` field; we might as well set it.

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 559:
> 
>> 557:         private boolean isReference(String s) {
>> 558:             try {
>> 559:                 var ref = refParser.parse(s, ReferenceParser.Mode.MEMBER_OPTIONAL);
> 
> Suggestion:
> 
>                 refParser.parse(s, ReferenceParser.Mode.MEMBER_OPTIONAL);

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472107834
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472111878
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472106632
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472112635

From jjg at openjdk.org  Tue Jan 30 23:56:14 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Jan 2024 23:56:14 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
Message-ID: <82KgOfWLlL77CZkJUnSaiWxaSuu4C1uLkzr6BHnCUd4=.aeeb8842-7c6c-4db3-bf70-690e0008f74c@github.com>

On Wed, 24 Jan 2024 22:38:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 487:
> 
>> 485:     }
>> 486: 
>> 487:     private static final String AUTOREF_PREFIX = "code:";
> 
> I wish the prefix were such that it could not be forged: for example, automatically assigned, unique within a document comment.

I guess I don't see this as being as big a deal as you seem to think it is. What is it that you are so concerned about?

I also think it is a potential feature to document and use reference links with `code:` URLs, using the reference link syntax to avoid having long method signatures in narrative text.

For example, 

   One of the methods on [List] has [lots of args][List.of10].
   
   [List.of10]code:List.of(E,E,E,E,E,E,E,E,E,E)

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 763:
> 
>> 761:          *
>> 762:          * @param link the link node
>> 763:          */
> 
> Suggestion:
> 
>         /**
>          * Visits a {@code Link} commonmark node.
>          *
>          * If the destination for the link begins with {@code code:}
>          * convert it to {@code {@link ...}} or {@code {@linkplain ...}} doc tree node.
>          * {@code {@link ...}} will be used if the content (label) for
>          * the link is the same as the reference found after the {@code code:};
>          * otherwise, {@code {@linkplain ...}} will be used.
>          *
>          * The label will be left blank for {@code {@link ...}} nodes,
>          * implying that a default label should be used, based on the
>          * program element that was referenced.
>          *
>          * @param link the link node
>          */

fixed

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 771:
> 
>> 769:                 copyTo(getStartPos(link));
>> 770:                 // push temporary value for {@code trees} while handling the content of the node
>> 771:                 var saveTrees = trees;
> 
> "saveTrees": I see what you did there :-)

?? Not sure I understand this comment.

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 778:
> 
>> 776:                     copyTo(getEndPos(link.getLastChild()));
>> 777: 
>> 778:                     // determine whether to use {@link... } or {@linkplain ...}
> 
> Nit:
> Suggestion:
> 
>                     // determine whether to use {@link ... } or {@linkplain ...}

fixed

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 840:
> 
>> 838: 
>> 839:         /**
>> 840:          * Process a node and any children.
> 
> Suggestion:
> 
>          * Processes a node and any children.

fixed

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 882:
> 
>> 880:         private int getStartPos(Node node) {
>> 881:             var spans = node.getSourceSpans();
>> 882:             var firstSpan = spans.get(0);
> 
> Suggestion:
> 
>             var firstSpan = spans.getFirst();

done

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 894:
> 
>> 892:         private int getEndPos(Node node) {
>> 893:             var spans = node.getSourceSpans();
>> 894:             var lastSpan = spans.get(spans.size() - 1);
> 
> Suggestion:
> 
>             var lastSpan = spans.getLast();

Done

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 950:
> 
>> 948:     }
>> 949: 
>> 950: 
> 
> Suggestion:

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472122002
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472129024
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472125185
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472129294
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472129971
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472123360
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472124337
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1472130370

From jjg at openjdk.org  Wed Jan 31 00:06:37 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 00:06:37 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v11]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <ljfoiCnsIuzQ9DBBxgxUXNaFG4_iqAm8-ufGPJhCr1E=.658ef95f-7585-4769-8b4d-b6fae887d535@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/5e3f03c8..50c3a40b

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

  Stats: 101 lines in 8 files changed: 47 ins; 16 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From abimpoudis at openjdk.org  Wed Jan 31 10:03:23 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 31 Jan 2024 10:03:23 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v57]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <M06P1ym-MnvjB2Z-v9hfGFjXV2RbBeIqg0EMzWr9LNU=.b363d892-f5da-42dc-b53d-7a9a0ed1689e@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:

 - Merge branch 'master' into primitive-patterns
 - Update summary in ExactnessConversionsSupportTest
 - Address review by Jan
 - Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
 - Small fix in Javadoc
 - Tidy up Javadoc of Lower.visitTypeTest
 - Tidy up Javadoc of IllegalArgumentException in typeSwitch
 - Improve readability in SwitchBootstraps
 - Update year
 - Cleanup redundant clone
 - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1

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

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=56
  Stats: 3818 lines in 45 files changed: 3385 ins; 212 del; 221 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

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

From hannesw at openjdk.org  Wed Jan 31 12:10:02 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 31 Jan 2024 12:10:02 GMT
Subject: RFR: JDK-8164094: javadoc allows to create a @link to a
 non-existent method [v2]
In-Reply-To: <DYAzdVDGgi6MjpTNMMU28uVNj_fSDfyN0OMtq0eulQ8=.55232aa3-5c62-420c-a8ef-3ad6fac73649@github.com>
References: <-xM8YSleEZ-CQY1FwsTvPsgYW3s8GmkOkGi-9r8icuI=.da06c781-54fe-463a-abd7-c714e4d3982f@github.com>
 <boJdnkhR2GiQNMwOcJX2MLv32Nk20TeKrnivxrgXwvM=.10646638-d84f-4c87-89de-2489bef3a26c@github.com>
 <Mpqc4k6Kz5M8VFVJIzhTXOeBbyE1RaYdn29t-WIq-Bw=.2ad01fe7-add8-43a2-94d3-3af6f28fb1ce@github.com>
 <_pikP7s04dGw96fPV2zU1ONXSPGQoZo4SRfYNifChBM=.00cf8f90-bb98-4ca2-9dc0-1a77d76462b6@github.com>
 <DYAzdVDGgi6MjpTNMMU28uVNj_fSDfyN0OMtq0eulQ8=.55232aa3-5c62-420c-a8ef-3ad6fac73649@github.com>
Message-ID: <_RHFv82Vn2S2MtARHaN_19u82LDY3nbng0ZkoaM2k8s=.6bc7b0f8-9ae0-4981-b50b-827687b20599@github.com>

On Tue, 30 Jan 2024 20:58:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Looping back on this, independent of what the intended or specified behavior was before, if the behavior is changing now, even in agreed upon ways, the change should probably go through CSR review.

Ok, I've written a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17069#issuecomment-1918979643

From abimpoudis at openjdk.org  Wed Jan 31 14:21:14 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 31 Jan 2024 14:21:14 GMT
Subject: Integrated: 8303374: Implement JEP 455: Primitive Types in Patterns, 
 instanceof, and switch (Preview)
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <7MBpFjawIZA1YtjJ8_wP_6UeqG7n7wXF6N1yehtb150=.c8531d10-e969-4cac-bd95-d4e8748bfc49@github.com>

On Fri, 8 Sep 2023 14:17:29 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

This pull request has now been integrated.

Changeset: 1733d2ea
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1733d2ea244756238c302d802511eb1557cd46ac
Stats:     3818 lines in 45 files changed: 3385 ins; 212 del; 221 mod

8303374: Implement JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Co-authored-by: Gavin Bierman <gbierman at openjdk.org>
Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Raffaello Giulietti <rgiulietti at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: vromero, jlahoda

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

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

From jjg at openjdk.org  Wed Jan 31 21:14:38 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 21:14:38 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v12]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <b23L3EKsKwDd3SNR_bZ_IGp4XfX6721w43g1pRPw-yc=.c490d484-704c-45b7-bd5b-04860d77dc82@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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

 - refine the Comment used for synthetic doc comments
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - address review feedback
 - fix @since tags
 - fix copyright year
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Merge with upstream/master
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - ... and 5 more: https://git.openjdk.org/jdk/compare/2cd1ba6a...0da7ba5c

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=11
  Stats: 21376 lines in 191 files changed: 20712 ins; 271 del; 393 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jjg at openjdk.org  Wed Jan 31 21:18:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 21:18:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <VTji38I7HGKI1AUlEMVsi9JYigC95o9CtsixpbEsOWQ=.07171023-990d-40f9-815b-7721537d3264@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
 <VTji38I7HGKI1AUlEMVsi9JYigC95o9CtsixpbEsOWQ=.07171023-990d-40f9-815b-7721537d3264@github.com>
Message-ID: <Z7Ol-xJc34se9ze0cQL_ES1KTc1YeNzYXwj4xlrMPCw=.d16e3ab1-2236-4468-95f9-cb19d70c9b65@github.com>

On Tue, 30 Jan 2024 22:55:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 238:
>> 
>>> 236:                         && postamble.isEmpty()
>>> 237:                         && fullBody.stream().anyMatch(t -> t.getKind() == Kind.MARKDOWN)
>>> 238:                         ? CommentStyle.JAVADOC_LINE : CommentStyle.JAVADOC_BLOCK;
>> 
>> While clever, it seems to be prone to false positive `JAVADOC_LINE`. Also, it is inconsistent with `null` and `Position.NOPOS` returned from the `getText` and `getSourcePos(int)` methods respectively.
>
> I'm not worried about false positive `JAVADOC_LINE` than maybe false _negative_ `JAVADOC_LINE`.  Generally, the underlying issue here is how to handle weird combinations of `DocTrees` constructed by a user of the public API.  For example, should we check, and reject, a `fullBody` containing `MARKDOWN` nodes and non-empty  `preamble` or `postamble`, since that combination will never come from `DocCommentParser`.
> 
> I'm not worried about comparison with `getText` and `getSourcePos`, since there really is no other value for the source text or source position that we can return. But we can infer a best guess for the style.
> 
> Arguably, we should check the `tags` as well.
> 
> ------
> 
> I dug deeper.
> 
> We do create synthetic trees in the standard doclet, such as for the descriptions of mandated methods (like `values` and `valueOf` for any enum class.  Those synthetic trees do utilize this code path, although the `getStyle` method is not currently invoked. (Verified by changing code to throw `UnsupportedOperationException` and run all the tests.) It's also true those synthetic trees do not leverage any Markdown support at this time.
> 
> I prefer to leave the code as-is at this time.

I revisited this, and rewrote the code and added more comments for now and for later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473474540

From jjg at openjdk.org  Wed Jan 31 22:06:26 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 22:06:26 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v13]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <MalttXdMJM_KI1TWKgeuAMlAbWMt86MFiytVuwOFF-I=.75552385-12a5-4350-80d2-b2ba4b37b3fe@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  change AUTOREF_PREFIX from a static string to a dynamically generated autorefScheme

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/0da7ba5c..71ce4b16

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

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

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

From jjg at openjdk.org  Wed Jan 31 22:13:11 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 22:13:11 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
Message-ID: <UbOd3C2ZrB35hFrkossEp7LIUWFk9dpBZh6v8IS0HeA=.84a2e253-8eb2-40fc-8256-c38a8a4e4399@github.com>

On Wed, 24 Jan 2024 22:35:31 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 543:
> 
>> 541:                 @Override
>> 542:                 public LinkReferenceDefinition getLinkReferenceDefinition(String label) {
>> 543:                     var l = label.replace("\\[\\]", "[]");
> 
> That `String.replace` looks suspicious. FWIW, when I removed that `replace`, no tests failed.

My recollection is that you have to escape square brackets in a reference label.  I will investigate, and if necessary, add a test case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473528775

From jjg at openjdk.org  Wed Jan 31 22:18:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 22:18:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <82KgOfWLlL77CZkJUnSaiWxaSuu4C1uLkzr6BHnCUd4=.aeeb8842-7c6c-4db3-bf70-690e0008f74c@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
 <82KgOfWLlL77CZkJUnSaiWxaSuu4C1uLkzr6BHnCUd4=.aeeb8842-7c6c-4db3-bf70-690e0008f74c@github.com>
Message-ID: <HfTVo2rOdZeEXe3qGclLIHgptXeQ568_eWNRU66dOWU=.94fa57b9-1e4d-4151-a7f7-0cbd66598f50@github.com>

On Tue, 30 Jan 2024 23:42:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 487:
>> 
>>> 485:     }
>>> 486: 
>>> 487:     private static final String AUTOREF_PREFIX = "code:";
>> 
>> I wish the prefix were such that it could not be forged: for example, automatically assigned, unique within a document comment.
>
> I guess I don't see this as being as big a deal as you seem to think it is. What is it that you are so concerned about?
> 
> I also think it is a potential feature to document and use reference links with `code:` URLs, using the reference link syntax to avoid having long method signatures in narrative text.
> 
> For example, 
> 
>    One of the methods on [List] has [lots of args][List.of10].
>    
>    [List.of10]code:List.of(E,E,E,E,E,E,E,E,E,E)

I've changed the prefix to be dynamically generated. It's now called `autorefScheme` and is passed around as needed. It contains a hex hashcode, so is reasonably unguessable.

I'm still sort-of sad to lose the ability to use `code:` URLs directly, so I've left a comment in the code hinting that that is a possibility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473532970

From jjg at openjdk.org  Wed Jan 31 23:13:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 23:13:07 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <UbOd3C2ZrB35hFrkossEp7LIUWFk9dpBZh6v8IS0HeA=.84a2e253-8eb2-40fc-8256-c38a8a4e4399@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
 <UbOd3C2ZrB35hFrkossEp7LIUWFk9dpBZh6v8IS0HeA=.84a2e253-8eb2-40fc-8256-c38a8a4e4399@github.com>
Message-ID: <t12_cx8L88XOIB668UOHrnt7TPsyJiVC48ic7BribrI=.4b9996e0-a930-48cb-a8f4-6f2f7e0d717a@github.com>

On Wed, 31 Jan 2024 22:10:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 543:
>> 
>>> 541:                 @Override
>>> 542:                 public LinkReferenceDefinition getLinkReferenceDefinition(String label) {
>>> 543:                     var l = label.replace("\\[\\]", "[]");
>> 
>> That `String.replace` looks suspicious. FWIW, when I removed that `replace`, no tests failed.
>
> My recollection is that you have to escape square brackets in a reference label.  I will investigate, and if necessary, add a test case.

Yes, you need to escape `[` and `]` within the label of any Markdown reference link, by preceding each with backslash.   (Remember, the label is the string used to find the URL for the link; not the displayed text of the link).
That's a CommonMark feature independent of this work.

While we could change that `replace` call into two separate ones, in reference signatures they always appear together as a pair, and can be replaced together.   We need to remove the escape characters in the generated URL so that the signature is a standard signature with unescaped `[]`

For fun/demo, try the following:


/// First sentence.
/// * Link 0 to [java.lang.Object]
/// * Link 1a to [Arrays-equals][java.util.Arrays#equals(Object[],Object[])]
/// * Link 1b to [Arrays-equals][java.util.Arrays#equals(Object[],Object[])]
/// * Link 2a to [java.util.Arrays#equals(Object[],Object[])]
/// * Link 2b to [java.util.Arrays#equals(Object[],Object[])]
public class C { }


Link 1a and 2a end up as unprocessed "literal" text (because the `[]` were not escaped.)  That is, they are not even recognized by the CommonMark parser as reference links.  Link 1b and 2b get processed as links, as expected.

FWIW, this issue with needing to escape `[]` pairs is specifically mentioned in the JEP as an inescapable (sic) limitation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473593860

From jjg at openjdk.org  Wed Jan 31 23:13:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 23:13:07 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <t12_cx8L88XOIB668UOHrnt7TPsyJiVC48ic7BribrI=.4b9996e0-a930-48cb-a8f4-6f2f7e0d717a@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
 <UbOd3C2ZrB35hFrkossEp7LIUWFk9dpBZh6v8IS0HeA=.84a2e253-8eb2-40fc-8256-c38a8a4e4399@github.com>
 <t12_cx8L88XOIB668UOHrnt7TPsyJiVC48ic7BribrI=.4b9996e0-a930-48cb-a8f4-6f2f7e0d717a@github.com>
Message-ID: <9udnoUCtCVEEO3rIQypPb3f14bMp6wVRRO4x0yNKZpw=.b1245fbf-e2eb-44c1-9b44-76ccbefe200f@github.com>

On Wed, 31 Jan 2024 23:09:22 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> My recollection is that you have to escape square brackets in a reference label.  I will investigate, and if necessary, add a test case.
>
> Yes, you need to escape `[` and `]` within the label of any Markdown reference link, by preceding each with backslash.   (Remember, the label is the string used to find the URL for the link; not the displayed text of the link).
> That's a CommonMark feature independent of this work.
> 
> While we could change that `replace` call into two separate ones, in reference signatures they always appear together as a pair, and can be replaced together.   We need to remove the escape characters in the generated URL so that the signature is a standard signature with unescaped `[]`
> 
> For fun/demo, try the following:
> 
> 
> /// First sentence.
> /// * Link 0 to [java.lang.Object]
> /// * Link 1a to [Arrays-equals][java.util.Arrays#equals(Object[],Object[])]
> /// * Link 1b to [Arrays-equals][java.util.Arrays#equals(Object[],Object[])]
> /// * Link 2a to [java.util.Arrays#equals(Object[],Object[])]
> /// * Link 2b to [java.util.Arrays#equals(Object[],Object[])]
> public class C { }
> 
> 
> Link 1a and 2a end up as unprocessed "literal" text (because the `[]` were not escaped.)  That is, they are not even recognized by the CommonMark parser as reference links.  Link 1b and 2b get processed as links, as expected.
> 
> FWIW, this issue with needing to escape `[]` pairs is specifically mentioned in the JEP as an inescapable (sic) limitation.

I'll add a test case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473594252

From jjg at openjdk.org  Wed Jan 31 23:49:25 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 Jan 2024 23:49:25 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v14]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <WpZ-VnZN6sFqsVXgzHeek456YhGJoD_6unV8IjV3ZK4=.32d16778-5fd2-48f4-9afe-bb5d0c27a83c@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback for MarkdownTransformer `label.replace("\\[\\]", "[]");`
  add corresponding test case in TestMarkdown.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/71ce4b16..586daddf

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

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

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