From clanger at openjdk.org  Wed Jul  5 13:53:58 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 5 Jul 2023 13:53:58 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>
Message-ID: <ubqaW-6fAyiJbYVbziD0X5vER4bMyP_1qBXmDDoeEdg=.51cfaf72-603e-443c-b2db-8c6bc5ff0215@github.com>

On Fri, 30 Jun 2023 11:37:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove import

Looks good overall. I made a few suggestions.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java line 40:

> 38:  *     Agent's JAR file contains modified class java.util.TooManyListenersException (it is assumed
> 39:  *     that this class isn't loaded before agent is loaded), agent instantiates TooManyListenersException
> 40:  *     and checks that non-modified version of this class was loaded from jdk image (not from agent's JAR).

"from the jdk image"

test/jdk/com/sun/tools/attach/ProviderTest.java line 110:

> 108:         public static void main(String args[]) throws Exception {
> 109:             // deal with internal builds where classes are loaded from the
> 110:             // 'classes' directory rather than the image modules file

"... rather than the runtime image"

test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 27:

> 25:  * @test
> 26:  * @bug 4798312
> 27:  * @summary In Windows, javap doesn't load classes from image

"... from the runtime image"

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

Changes requested by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1514576016
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253140142
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253141204
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253142105

From clanger at openjdk.org  Wed Jul  5 13:54:01 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 5 Jul 2023 13:54:01 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
 <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>
Message-ID: <Kl7Oa4UKUteVNTsTijnPc1q3tiNojlxtwldtJdUcXfU=.70212614-1ffa-4487-9d09-b4fe97b26612@github.com>

On Thu, 22 Jun 2023 09:21:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196:
>> 
>>> 194: 
>>> 195:     /**
>>> 196:      * Set whether or not to use ct.sym as an alternate
>> 
>> As an alternate to what? This needs something else.
>
> should "to the image modules files"  be used instead ?

maybe "... to the current runtime."?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253139297

From mbaesken at openjdk.org  Wed Jul  5 15:07:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Jul 2023 15:07:15 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/9b2232a7..3a7b057a

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

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

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

From clanger at openjdk.org  Wed Jul  5 15:07:16 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 5 Jul 2023 15:07:16 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4]
In-Reply-To: <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>
Message-ID: <ilbUZTTFeWpuxDgfjIAm8V_mHGN6dB7fzOT_LyjRg00=.6cd9a766-600c-4cdf-b9b5-f43593181d5e@github.com>

On Wed, 5 Jul 2023 15:01:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comments

Fine from my end now. Just one minor nit left. ?

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196:

> 194: 
> 195:     /**
> 196:      * Set whether or not to use ct.sym as an alternate to the current runtime

You should bring back the period at the end of the sentence.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1514740197
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1253244166

From mbaesken at openjdk.org  Wed Jul  5 15:07:17 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Jul 2023 15:07:17 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>
Message-ID: <Mmx3ALXzgyehKSzS46dg6O6_E5jgT3Qh6PGdgdjCgWo=.9c92adab-f6a2-45b2-acb9-c5acfdc3f088@github.com>

On Fri, 30 Jun 2023 11:37:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove import

Hi  Christoph, thanks for the suggestions, I added some changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14593#issuecomment-1621939153

From mbaesken at openjdk.org  Thu Jul  6 07:35:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Jul 2023 07:35:10 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <98WmwQW2HwA0y6V4kHm-Mz75WifXcX1R6eKMq-jQyjU=.b07ce857-c2d1-46cb-9dc5-0dd075ad8dd4@github.com>

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/3a7b057a..f29c4019

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

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

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

From mbaesken at openjdk.org  Thu Jul  6 07:35:11 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Jul 2023 07:35:11 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v4]
In-Reply-To: <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <C4Bimt6SEUdL7KSK5tk64Q5zxRTWr5PvT_PTpEaMx3I=.d56fba5b-e89c-46d8-9b7f-488a6c559fe1@github.com>
Message-ID: <ACVSe2CyRIW9jGwYeYFV8vVzvLZP9s--c_DRlennbC0=.6a79f38d-83a0-4bcb-892a-9ee4a26c1ef7@github.com>

On Wed, 5 Jul 2023 15:07:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comments

Hi Christoph, thanks for the review !
I added the '.' as suggested.

Any objections to the latest revision?

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

PR Comment: https://git.openjdk.org/jdk/pull/14593#issuecomment-1623132227

From dholmes at openjdk.org  Thu Jul  6 07:35:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Jul 2023 07:35:12 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5]
In-Reply-To: <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
 <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>
Message-ID: <bOO1io-5BepHCKflts0nCy6cRslj4BacSPPfy5QSlsA=.459b6299-df27-4cb3-a0b1-cb4308d021e1@github.com>

On Thu, 22 Jun 2023 09:23:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 1:
>> 
>>> 1: /*
>> 
>> The name of this test includes RTJar. It needs to be changed too I think. Does this test actually still test something?
>
> It seems to start a javap. So I think it tests something, how important this is and what other tests might cover similar stuff, I do not know unfortunately .

This is a trivial test for a trivial issue. javap will be tested much more thoroughly by other tests. I think this test can be deleted without any loss of coverage. Or it can just be left.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1254047816

From duke at openjdk.org  Thu Jul  6 23:02:09 2023
From: duke at openjdk.org (duke)
Date: Thu, 6 Jul 2023 23:02:09 GMT
Subject: Withdrawn: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent
In-Reply-To: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
References: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
Message-ID: <8X27mPNirgGq3e_woE6asHN5jgoWPSjghVHMidRznnA=.0964b0f7-26a8-423b-9401-652de9fc4ea7@github.com>

On Tue, 11 Apr 2023 18:13:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.
> 
> **Note:** This is dependent on PR #13362, to convert `DocCommentParser` to use enhanced switch.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Jul  6 23:35:09 2023
From: duke at openjdk.org (duke)
Date: Thu, 6 Jul 2023 23:35:09 GMT
Subject: Withdrawn: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <uaRK1W4uoY8WriKgYieJVUIGwgh0EMcgfXRicbKTmg4=.e68ef291-6589-493a-b7e9-8086097fb392@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Fri Jul  7 07:00:05 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Jul 2023 07:00:05 GMT
Subject: Integrated: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <5z7tycp2SolizjphgpOZ9dewDyUSx4kL-Ad-D9_fKZE=.0f5bda5f-2d9c-41cf-b6cd-dd4ee866aaf9@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

This pull request has now been integrated.

Changeset: 25cbe85d
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25cbe85d6f46bed82c7f1266ce52c86943e29d60
Stats:     17 lines in 12 files changed: 0 ins; 8 del; 9 mod

8310550: Adjust references to rt.jar

Reviewed-by: erikj, clanger

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

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

From pyltsinm at gmail.com  Fri Jul  7 17:51:37 2023
From: pyltsinm at gmail.com (Mikhail Pyltsin)
Date: Fri, 7 Jul 2023 19:51:37 +0200
Subject: Exhaustiveness for record pattern with switch (JEP 440+441)
Message-ID: <CAOo1M=mY5Y+DO6HVKJADPdYeoS12y7qaVZP0Hvwzdti3OAzfTg@mail.gmail.com>

Hi!
I investigated the algorithm, which Javac 21 (Build 30 (2023/7/6))
) uses to check exhaustiveness for record patterns (JEP 440+441), and found
the strange behavior:
- let's take compilable code
```
class Test22 {

  record Pair(I i1, I i2) {}

  sealed interface I {}

  record C() implements I {}

  record D() implements I {}

  void exhaustinvenessWithInterface(Pair pairI) {
    switch (pairI) {
      case Pair(C fst, D snd) -> {
      }
      case Pair(C fst, C snd) -> {
      }
      case Pair(I fst, C snd) -> {
      }
      case Pair(D fst, D snd) -> {
      }
    }
  }
}
```
- If we swap types of components, it starts to produce the error "java: the
switch statement does not cover all possible input values":
```
  void exhaustinvenessWithInterface(Pair pairI) {
    switch (pairI) {
      case Pair(D fst, C snd) -> {
      }
      case Pair(C fst, C snd) -> {
      }
      case Pair(C fst, I snd) -> {
      }
      case Pair(D fst, D snd) -> {
      }
    }
  }
```
It happens because Javac tries to find the first distinguished type from
the beginning, but I couldn't find any mention of it in JEP.
Is this the expected behavior?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230707/8815ae90/attachment.htm>

From vromero at openjdk.org  Fri Jul  7 18:08:59 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 7 Jul 2023 18:08:59 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
Message-ID: <nqhbzWFBRWCeX54dXVJn5YSN3_xro06k0UJ9yrjhcu8=.1a95b8f4-5d75-41b8-abb6-36ddba71b53c@github.com>

On Tue, 13 Jun 2023 15:14:41 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - Merge branch 'master' into SuperInit
>  - Use @enablePreview in tests in preference to explicit command line flags.
>  - Make "statements before super()" support a preview feature.
>    
>    Thanks to Jim Laskey for help with preview logic.
>  - Small refactoring to avoid redundant test.
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c0aa6bf4...a5f8cc5e

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

> 1051: 
> 1052:             // Is this method a constructor?
> 1053:             boolean isConstructor = tree.name == names.init;

consider using TreeInfo::isConstructor instead, which is a more general approach. Valhalla could use another special name for constructors

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1256240564

From acobbs at openjdk.org  Fri Jul  7 19:11:14 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 7 Jul 2023 19:11:14 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v8]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <xx035-LICbOUfJ8a3Db1xGZGiq0DRcAXL96Y7Dp8FaU=.2774ffe8-7115-4b7e-8e0d-da91ecaafe52@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Use TreeInfo.isConstructor() for detecting constructors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/a5f8cc5e..c6cf80fc

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

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

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

From acobbs at openjdk.org  Fri Jul  7 19:11:19 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 7 Jul 2023 19:11:19 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <nqhbzWFBRWCeX54dXVJn5YSN3_xro06k0UJ9yrjhcu8=.1a95b8f4-5d75-41b8-abb6-36ddba71b53c@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
 <nqhbzWFBRWCeX54dXVJn5YSN3_xro06k0UJ9yrjhcu8=.1a95b8f4-5d75-41b8-abb6-36ddba71b53c@github.com>
Message-ID: <RJoW8fniepdPmT2vkx2358CJkzH3yJMjbCT9zaCKczI=.675e08f6-184d-4577-a5c4-22696fe022b8@github.com>

On Fri, 7 Jul 2023 18:05:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into SuperInit
>>  - Fix mistake in previous merge commit 80ba6be4.
>>  - Merge branch 'master' into SuperInit
>>  - Rename unit test to be consistent with other feature exampless.
>>  - Update unit test after merged-in commit eaa80ad08.
>>  - Add unit tests with local class decl's prior to super().
>>  - Merge branch 'master' into SuperInit
>>  - Use @enablePreview in tests in preference to explicit command line flags.
>>  - Make "statements before super()" support a preview feature.
>>    
>>    Thanks to Jim Laskey for help with preview logic.
>>  - Small refactoring to avoid redundant test.
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c0aa6bf4...a5f8cc5e
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1053:
> 
>> 1051: 
>> 1052:             // Is this method a constructor?
>> 1053:             boolean isConstructor = tree.name == names.init;
> 
> consider using TreeInfo::isConstructor instead, which is a more general approach. Valhalla could use another special name for constructors

Thanks. I fixed that example and a few others as well in c6cf80fc621.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1256331970

From davidalayachew at gmail.com  Fri Jul  7 19:43:26 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 7 Jul 2023 15:43:26 -0400
Subject: Exhaustiveness for record pattern with switch (JEP 440+441)
In-Reply-To: <CAOo1M=mY5Y+DO6HVKJADPdYeoS12y7qaVZP0Hvwzdti3OAzfTg@mail.gmail.com>
References: <CAOo1M=mY5Y+DO6HVKJADPdYeoS12y7qaVZP0Hvwzdti3OAzfTg@mail.gmail.com>
Message-ID: <CAA9v-_MPpXVOf-OgqNFr3ik6B+MOkgBZbA05ne3TmMLuttqqSg@mail.gmail.com>

I've CC'd the Amber Dev Team.

On Fri, Jul 7, 2023 at 1:52?PM Mikhail Pyltsin <pyltsinm at gmail.com> wrote:

> Hi!
> I investigated the algorithm, which Javac 21 (Build 30 (2023/7/6))
> ) uses to check exhaustiveness for record patterns (JEP 440+441), and
> found the strange behavior:
> - let's take compilable code
> ```
> class Test22 {
>
>   record Pair(I i1, I i2) {}
>
>   sealed interface I {}
>
>   record C() implements I {}
>
>   record D() implements I {}
>
>   void exhaustinvenessWithInterface(Pair pairI) {
>     switch (pairI) {
>       case Pair(C fst, D snd) -> {
>       }
>       case Pair(C fst, C snd) -> {
>       }
>       case Pair(I fst, C snd) -> {
>       }
>       case Pair(D fst, D snd) -> {
>       }
>     }
>   }
> }
> ```
> - If we swap types of components, it starts to produce the error "java:
> the switch statement does not cover all possible input values":
> ```
>   void exhaustinvenessWithInterface(Pair pairI) {
>     switch (pairI) {
>       case Pair(D fst, C snd) -> {
>       }
>       case Pair(C fst, C snd) -> {
>       }
>       case Pair(C fst, I snd) -> {
>       }
>       case Pair(D fst, D snd) -> {
>       }
>     }
>   }
> ```
> It happens because Javac tries to find the first distinguished type from
> the beginning, but I couldn't find any mention of it in JEP.
> Is this the expected behavior?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230707/02706016/attachment.htm>

From vromero at openjdk.org  Fri Jul  7 20:12:58 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 7 Jul 2023 20:12:58 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
Message-ID: <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>

On Tue, 13 Jun 2023 15:14:41 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - Merge branch 'master' into SuperInit
>  - Use @enablePreview in tests in preference to explicit command line flags.
>  - Make "statements before super()" support a preview feature.
>    
>    Thanks to Jim Laskey for help with preview logic.
>  - Small refactoring to avoid redundant test.
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c0aa6bf4...a5f8cc5e

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3975:

> 3973:     }
> 3974: 
> 3975:     private class SuperThisChecker extends TreeScanner {

we usually create only one instance of these type of visitors that will be used very often and reuse it whenever necessary

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4078:

> 4076: 
> 4077:         @Override
> 4078:         public void visitClassDef(JCClassDecl tree) {

will you be descending into lambdas with this visitor?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1256278772
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1256331686

From forax at univ-mlv.fr  Fri Jul  7 20:34:32 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 7 Jul 2023 22:34:32 +0200 (CEST)
Subject: Exhaustiveness for record pattern with switch (JEP 440+441)
In-Reply-To: <CAA9v-_MPpXVOf-OgqNFr3ik6B+MOkgBZbA05ne3TmMLuttqqSg@mail.gmail.com>
References: <CAOo1M=mY5Y+DO6HVKJADPdYeoS12y7qaVZP0Hvwzdti3OAzfTg@mail.gmail.com>
 <CAA9v-_MPpXVOf-OgqNFr3ik6B+MOkgBZbA05ne3TmMLuttqqSg@mail.gmail.com>
Message-ID: <314406701.99141832.1688762072167.JavaMail.zimbra@univ-eiffel.fr>

Looks like a bug too me, 
the possible combinations are (C, C), (C, D) (D, C) (D,D), they are all covered. 

R?mi 

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "Mikhail Pyltsin" <pyltsinm at gmail.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.org>, "amber-dev"
> <amber-dev at openjdk.org>
> Sent: Friday, July 7, 2023 10:43:26 PM
> Subject: Re: Exhaustiveness for record pattern with switch (JEP 440+441)

> I've CC'd the Amber Dev Team.

> On Fri, Jul 7, 2023 at 1:52 PM Mikhail Pyltsin < [ mailto:pyltsinm at gmail.com |
> pyltsinm at gmail.com ] > wrote:

>> Hi!
>> I investigated the algorithm, which Javac 21 (Build 30 (2023/7/6))
>> ) uses to check exhaustiveness for record patterns (JEP 440+441), and found the
>> strange behavior:
>> - let's take compilable code
>> ```
>> class Test22 {

>> record Pair(I i1, I i2) {}

>> sealed interface I {}

>> record C() implements I {}

>> record D() implements I {}

>> void exhaustinvenessWithInterface(Pair pairI) {
>> switch (pairI) {
>> case Pair(C fst, D snd) -> {
>> }
>> case Pair(C fst, C snd) -> {
>> }
>> case Pair(I fst, C snd) -> {
>> }
>> case Pair(D fst, D snd) -> {
>> }
>> }
>> }
>> }
>> ```
>> - If we swap types of components, it starts to produce the error "java: the
>> switch statement does not cover all possible input values":
>> ```
>> void exhaustinvenessWithInterface(Pair pairI) {
>> switch (pairI) {
>> case Pair(D fst, C snd) -> {
>> }
>> case Pair(C fst, C snd) -> {
>> }
>> case Pair(C fst, I snd) -> {
>> }
>> case Pair(D fst, D snd) -> {
>> }
>> }
>> }
>> ```
>> It happens because Javac tries to find the first distinguished type from the
>> beginning, but I couldn't find any mention of it in JEP.
>> Is this the expected behavior?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230707/9cca413c/attachment-0001.htm>

From davidalayachew at gmail.com  Fri Jul  7 20:38:25 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 7 Jul 2023 16:38:25 -0400
Subject: Exhaustiveness for record pattern with switch (JEP 440+441)
In-Reply-To: <314406701.99141832.1688762072167.JavaMail.zimbra@univ-eiffel.fr>
References: <CAOo1M=mY5Y+DO6HVKJADPdYeoS12y7qaVZP0Hvwzdti3OAzfTg@mail.gmail.com>
 <CAA9v-_MPpXVOf-OgqNFr3ik6B+MOkgBZbA05ne3TmMLuttqqSg@mail.gmail.com>
 <314406701.99141832.1688762072167.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAA9v-_O2iPSeJ8bwMSayOZhSSsinhuu_q=QCPQRVKHnYutPzRw@mail.gmail.com>

Definitely agreed.

On Fri, Jul 7, 2023 at 4:34?PM Remi Forax <forax at univ-mlv.fr> wrote:

> Looks like a bug too me,
> the possible combinations are (C, C), (C, D) (D, C) (D,D), they are all
> covered.
>
> R?mi
>
> ------------------------------
>
> *From: *"David Alayachew" <davidalayachew at gmail.com>
> *To: *"Mikhail Pyltsin" <pyltsinm at gmail.com>
> *Cc: *"compiler-dev" <compiler-dev at openjdk.org>, "amber-dev" <
> amber-dev at openjdk.org>
> *Sent: *Friday, July 7, 2023 10:43:26 PM
> *Subject: *Re: Exhaustiveness for record pattern with switch (JEP 440+441)
>
> I've CC'd the Amber Dev Team.
>
> On Fri, Jul 7, 2023 at 1:52?PM Mikhail Pyltsin <pyltsinm at gmail.com> wrote:
>
>> Hi!
>> I investigated the algorithm, which Javac 21 (Build 30 (2023/7/6))
>> ) uses to check exhaustiveness for record patterns (JEP 440+441), and
>> found the strange behavior:
>> - let's take compilable code
>> ```
>> class Test22 {
>>
>>   record Pair(I i1, I i2) {}
>>
>>   sealed interface I {}
>>
>>   record C() implements I {}
>>
>>   record D() implements I {}
>>
>>   void exhaustinvenessWithInterface(Pair pairI) {
>>     switch (pairI) {
>>       case Pair(C fst, D snd) -> {
>>       }
>>       case Pair(C fst, C snd) -> {
>>       }
>>       case Pair(I fst, C snd) -> {
>>       }
>>       case Pair(D fst, D snd) -> {
>>       }
>>     }
>>   }
>> }
>> ```
>> - If we swap types of components, it starts to produce the error "java:
>> the switch statement does not cover all possible input values":
>> ```
>>   void exhaustinvenessWithInterface(Pair pairI) {
>>     switch (pairI) {
>>       case Pair(D fst, C snd) -> {
>>       }
>>       case Pair(C fst, C snd) -> {
>>       }
>>       case Pair(C fst, I snd) -> {
>>       }
>>       case Pair(D fst, D snd) -> {
>>       }
>>     }
>>   }
>> ```
>> It happens because Javac tries to find the first distinguished type from
>> the beginning, but I couldn't find any mention of it in JEP.
>> Is this the expected behavior?
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230707/187991ca/attachment.htm>

From acobbs at openjdk.org  Fri Jul  7 21:21:22 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 7 Jul 2023 21:21:22 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v9]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <QmXBmniuzRUophhhsLcU9_2lw669Q_ETdVbK7gt5OMg=.4695075b-70e7-4884-b83d-afe6ebc5ade2@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add unit test verifying super() can't appear inside a lambda.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/c6cf80fc..b0b13b2a

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

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

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

From acobbs at openjdk.org  Fri Jul  7 21:21:24 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 7 Jul 2023 21:21:24 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
 <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
Message-ID: <_BhqTR2yUVWHaMFVmATGUtnv65xclNNY865Op5UceCo=.09fbff02-0b5d-4e3f-9f8d-5afcff6ea6a3@github.com>

On Fri, 7 Jul 2023 19:05:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into SuperInit
>>  - Fix mistake in previous merge commit 80ba6be4.
>>  - Merge branch 'master' into SuperInit
>>  - Rename unit test to be consistent with other feature exampless.
>>  - Update unit test after merged-in commit eaa80ad08.
>>  - Add unit tests with local class decl's prior to super().
>>  - Merge branch 'master' into SuperInit
>>  - Use @enablePreview in tests in preference to explicit command line flags.
>>  - Make "statements before super()" support a preview feature.
>>    
>>    Thanks to Jim Laskey for help with preview logic.
>>  - Small refactoring to avoid redundant test.
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c0aa6bf4...a5f8cc5e
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4078:
> 
>> 4076: 
>> 4077:         @Override
>> 4078:         public void visitClassDef(JCClassDecl tree) {
> 
> will you be descending into lambdas with this visitor?

Yes, that's the intent. For good measure, I just added an explicit test to verify that `super()` inside a lambda is not allowed in b0b13b2ad22.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1256489033

From acobbs at openjdk.org  Fri Jul  7 21:32:07 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 7 Jul 2023 21:32:07 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v10]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <2D9gRZAVazf7OQbPN4Ek0yEFhTsZq7V1z-HX1EMPSfg=.12665791-ecbd-4bcb-b55d-9b6dca8548b8@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Create and cache a single instance of the oft-used SuperThisChecker.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/b0b13b2a..599d761b

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

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

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

From acobbs at openjdk.org  Fri Jul  7 21:32:10 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 7 Jul 2023 21:32:10 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
 <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
Message-ID: <-OFSsQ30T3f664GaGFzWykIbonJefislVTFWJV1qkXU=.050ca4c3-8aa8-4c37-bbf1-413ef884512c@github.com>

On Fri, 7 Jul 2023 18:32:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into SuperInit
>>  - Fix mistake in previous merge commit 80ba6be4.
>>  - Merge branch 'master' into SuperInit
>>  - Rename unit test to be consistent with other feature exampless.
>>  - Update unit test after merged-in commit eaa80ad08.
>>  - Add unit tests with local class decl's prior to super().
>>  - Merge branch 'master' into SuperInit
>>  - Use @enablePreview in tests in preference to explicit command line flags.
>>  - Make "statements before super()" support a preview feature.
>>    
>>    Thanks to Jim Laskey for help with preview logic.
>>  - Small refactoring to avoid redundant test.
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c0aa6bf4...a5f8cc5e
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3975:
> 
>> 3973:     }
>> 3974: 
>> 3975:     private class SuperThisChecker extends TreeScanner {
> 
> we usually create only one instance of these type of visitors that will be used very often and reuse it whenever necessary

Thanks - fixed in 599d761b309.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1256499145

From duke at openjdk.org  Sat Jul  8 11:55:55 2023
From: duke at openjdk.org (Sebastian Stenzel)
Date: Sat, 8 Jul 2023 11:55:55 GMT
Subject: RFR: JDK-8264488: Improve warning for module names ending with
 digits [v2]
In-Reply-To: <61JoRbYu5N5bUzVxrA7HyVn5x5DNU2vzcSMoAEutCpI=.5f14d799-995d-4dc3-a0a2-94b187e81617@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
 <61JoRbYu5N5bUzVxrA7HyVn5x5DNU2vzcSMoAEutCpI=.5f14d799-995d-4dc3-a0a2-94b187e81617@github.com>
Message-ID: <8dxX1wpo9ggn7VB1-A-CnJNZONOmK80mj06FD5af7xk=.d8b2df32-4594-49fe-9b18-e8997b087c2f@github.com>

On Sat, 3 Jun 2023 05:46:39 GMT, Sebastian Stenzel <duke at openjdk.org> wrote:

>> Since this is a rather trivial change, I didn't start a new discussion, as I deem this sufficiently discussed [back in early 2021](https://mail.openjdk.org/pipermail/discuss/2021-March/005779.html).
>
> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied latest proposal
>   
>   result of discussion openjdk/jdk#14099

Isn't there anyone willing to sponsor this? It is such a trivial change that has been discussed years ago already. Ignoring it for a couple of more years doesn't paint a good picture of how contributions are handled that are seemingly too insignificant. If this gets auto-closed due to idleness, I can't promise I find motivation to look into this any longer. ????

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

PR Comment: https://git.openjdk.org/jdk/pull/14099#issuecomment-1627175039

From acobbs at openjdk.org  Sat Jul  8 15:46:07 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 8 Jul 2023 15:46:07 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

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

 - Merge branch 'master' into SuperInit
 - Create and cache a single instance of the oft-used SuperThisChecker.
 - Add unit test verifying super() can't appear inside a lambda.
 - Use TreeInfo.isConstructor() for detecting constructors.
 - Merge branch 'master' into SuperInit
 - Fix mistake in previous merge commit 80ba6be4.
 - Merge branch 'master' into SuperInit
 - Rename unit test to be consistent with other feature exampless.
 - Update unit test after merged-in commit eaa80ad08.
 - Add unit tests with local class decl's prior to super().
 - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

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

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=10
  Stats: 1419 lines in 24 files changed: 1149 ins; 165 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

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

From alanb at openjdk.org  Mon Jul 10 05:33:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jul 2023 05:33:12 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v5]
In-Reply-To: <o1kCrnJzTAiEKF84HDgMZQltwIDLeTBOBXouGC5S_0E=.4087cdc2-b4db-4e35-80ed-72241aee7120@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
 <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
 <o1kCrnJzTAiEKF84HDgMZQltwIDLeTBOBXouGC5S_0E=.4087cdc2-b4db-4e35-80ed-72241aee7120@github.com>
Message-ID: <Li41Umr9wkDUT1zMjWQHBg8LFgSOQkOPTqbN-rv6_e8=.c9f65e17-1d39-4481-a776-9cfdb6d38e83@github.com>

On Fri, 30 Jun 2023 09:57:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, I adjusted the comment in DriverManager.java .

Thanks, the update looks okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1257728322

From pyltsinm at gmail.com  Mon Jul 10 08:20:15 2023
From: pyltsinm at gmail.com (Mikhail Pyltsin)
Date: Mon, 10 Jul 2023 10:20:15 +0200
Subject: Using qualified enum in `old` switch
Message-ID: <CAOo1M=m7DbNYhqqmkpzX9_heS3x0gJYVoTTFWpFjJGFW_+hmxQ@mail.gmail.com>

  Hi!
I am investigating a new version of jep440+441
(
https://cr.openjdk.org/~gbierman/jep440%2B441/jep440+441-20230612/specs/patterns-switch-record-patterns-jls.html
)
After `2023-06-12: Misc editorial changes.` I can't find any explicit
mention that it is allowed to use qualified names for enums in `old` switch.
But according to https://openjdk.org/jeps/441 it must be allowed
```

static void goodEnumSwitch2(Coin c) {
    switch (c) {
        case HEADS -> {
            System.out.println("Heads");
        }
        case Coin.TAILS -> {    // Unnecessary qualification but allowed
            System.out.println("Tails");
        }
    }
}


```
before  `2023-06-12: Misc editorial changes.`, It was
```Every case constant must be either (1) the null literal, (2) a constant
expression (15.29
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.29>),
or (3) the (simple or qualified) name of an enum constant (8.9.1
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.9.1>);
otherwise a compile-time error occurs. A single null case constant may also
be paired with the default keyword.
```,  but now there is no mention of the type of enum names.

Could you help me, which point allows it now?

This question arose because the next code doesn't produce errors:
```
    enum EN{A, B}

    public void test(EN en) {
        switch (en) {
            case A -> System.out.println("a");
            case EN.A -> System.out.println("a too");
            case EN.B -> System.out.println("b");
        }
    }
```
Is this expected?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230710/6fb34014/attachment.htm>

From davidalayachew at gmail.com  Mon Jul 10 13:31:27 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Jul 2023 09:31:27 -0400
Subject: Using qualified enum in `old` switch
In-Reply-To: <CAOo1M=m7DbNYhqqmkpzX9_heS3x0gJYVoTTFWpFjJGFW_+hmxQ@mail.gmail.com>
References: <CAOo1M=m7DbNYhqqmkpzX9_heS3x0gJYVoTTFWpFjJGFW_+hmxQ@mail.gmail.com>
Message-ID: <CAA9v-_O19fbzMOCYHyMfBTF_oqieVXWZaZGyi50QfwkOFDKAjg@mail.gmail.com>

CC'ing the Amber Dev Team.

On Mon, Jul 10, 2023 at 4:21?AM Mikhail Pyltsin <pyltsinm at gmail.com> wrote:

>   Hi!
> I am investigating a new version of jep440+441
> (
> https://cr.openjdk.org/~gbierman/jep440%2B441/jep440+441-20230612/specs/patterns-switch-record-patterns-jls.html
> )
> After `2023-06-12: Misc editorial changes.` I can't find any explicit
> mention that it is allowed to use qualified names for enums in `old` switch.
> But according to https://openjdk.org/jeps/441 it must be allowed
> ```
>
> static void goodEnumSwitch2(Coin c) {
>     switch (c) {
>         case HEADS -> {
>             System.out.println("Heads");
>         }
>         case Coin.TAILS -> {    // Unnecessary qualification but allowed
>             System.out.println("Tails");
>         }
>     }
> }
>
>
> ```
> before  `2023-06-12: Misc editorial changes.`, It was
> ```Every case constant must be either (1) the null literal, (2) a
> constant expression (15.29
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.29>),
> or (3) the (simple or qualified) name of an enum constant (8.9.1
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.9.1>);
> otherwise a compile-time error occurs. A single null case constant may
> also be paired with the default keyword.
> ```,  but now there is no mention of the type of enum names.
>
> Could you help me, which point allows it now?
>
> This question arose because the next code doesn't produce errors:
> ```
>     enum EN{A, B}
>
>     public void test(EN en) {
>         switch (en) {
>             case A -> System.out.println("a");
>             case EN.A -> System.out.println("a too");
>             case EN.B -> System.out.println("b");
>         }
>     }
> ```
> Is this expected?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230710/16ea4eaa/attachment-0001.htm>

From jan.lahoda at oracle.com  Mon Jul 10 15:26:33 2023
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 10 Jul 2023 17:26:33 +0200
Subject: Exhaustiveness for record pattern with switch (JEP 440+441)
In-Reply-To: <CAOo1M=mY5Y+DO6HVKJADPdYeoS12y7qaVZP0Hvwzdti3OAzfTg@mail.gmail.com>
References: <CAOo1M=mY5Y+DO6HVKJADPdYeoS12y7qaVZP0Hvwzdti3OAzfTg@mail.gmail.com>
Message-ID: <07f45f84-c1f4-0087-d1bc-7b8dc82b1a34@oracle.com>

Hi Mikhail,


I've filled:

https://bugs.openjdk.org/browse/JDK-8311815


for this. Thanks for the report!


Jan


On 07. 07. 23 19:51, Mikhail Pyltsin wrote:
> Hi!
> I investigated the algorithm, which Javac 21 (Build 30 (2023/7/6))
> ) uses to check exhaustiveness for record patterns (JEP 440+441), and 
> found the strange behavior:
> - let's take compilable code
> ```
> class Test22 {
>
> ? record Pair(I i1, I i2) {}
>
> ? sealed interface I {}
>
> ? record C() implements I {}
>
> ? record D() implements I {}
>
> ? void exhaustinvenessWithInterface(Pair pairI) {
> ? ? switch (pairI) {
> ? ? ? case Pair(C fst, D snd) -> {
> ? ? ? }
> ? ? ? case Pair(C fst, C snd) -> {
> ? ? ? }
> ? ? ? case Pair(I fst, C snd) -> {
> ? ? ? }
> ? ? ? case Pair(D fst, D snd) -> {
> ? ? ? }
> ? ? }
> ? }
> }
> ```
> - If we swap types of components, it starts to produce the error 
> "java: the switch statement does not cover all possible input values":
> ```
> ? void exhaustinvenessWithInterface(Pair pairI) {
> ? ? switch (pairI) {
> ? ? ? case Pair(D fst, C snd) -> {
> ? ? ? }
> ? ? ? case Pair(C fst, C snd) -> {
> ? ? ? }
> ? ? ? case Pair(C fst, I snd) -> {
> ? ? ? }
> ? ? ? case Pair(D fst, D snd) -> {
> ? ? ? }
> ? ? }
> ? }
> ```
> It happens because Javac tries to find the first distinguished type 
> from the beginning, but I couldn't find any mention of it in JEP.
> Is this the expected behavior?
>

From jan.lahoda at oracle.com  Mon Jul 10 15:31:43 2023
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 10 Jul 2023 17:31:43 +0200
Subject: Using qualified enum in `old` switch
In-Reply-To: <CAOo1M=m7DbNYhqqmkpzX9_heS3x0gJYVoTTFWpFjJGFW_+hmxQ@mail.gmail.com>
References: <CAOo1M=m7DbNYhqqmkpzX9_heS3x0gJYVoTTFWpFjJGFW_+hmxQ@mail.gmail.com>
Message-ID: <14eb93ae-1912-0965-1348-e6cd042eba9b@oracle.com>

Hi Mikhail,


Oops, filed:

https://bugs.openjdk.org/browse/JDK-8311825


Thanks for the report!


Jan


On 10. 07. 23 10:20, Mikhail Pyltsin wrote:
> ? Hi!
> I am investigating a new version of jep440+441
> (https://cr.openjdk.org/~gbierman/jep440%2B441/jep440+441-20230612/specs/patterns-switch-record-patterns-jls.html)
> After `2023-06-12: Misc editorial changes.` I can't find any explicit 
> mention that it is allowed to use qualified names for enums in `old` 
> switch.
> But according to https://openjdk.org/jeps/441?it must be allowed
> ```
> |static void goodEnumSwitch2(Coin c) { switch (c) { case HEADS -> { 
> System.out.println("Heads"); } case Coin.TAILS -> { // Unnecessary 
> qualification but allowed System.out.println("Tails"); } } }|
>
> ```
> before? `2023-06-12: Misc editorial changes.`, It was
> ```Every|case|constant must be either (1) the|null|literal, (2) a 
> constant expression (15.29 
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.29>), 
> or (3) the (simple or qualified)name of an enum constant (8.9.1 
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.9.1>); 
> otherwise a compile-time error occurs. A single|null|case constant may 
> also be paired with the|default|keyword.
> ```,? but now there is no mention of the type of enum names.
>
> Could you help me, which point allows it now?
>
> This question arose because the next code doesn't produce errors:
> ```
> ? ? enum EN{A, B}
>
> ? ? public void test(EN en) {
> ? ? ? ? switch (en) {
> ? ? ? ? ? ? case A -> System.out.println("a");
> ? ? ? ? ? ? case EN.A -> System.out.println("a too");
> ? ? ? ? ? ? case EN.B -> System.out.println("b");
> ? ? ? ? }
> ? ? }
> ```
> Is this expected?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230710/2d2af1f2/attachment-0001.htm>

From acobbs at openjdk.org  Mon Jul 10 16:09:21 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 10 Jul 2023 16:09:21 GMT
Subject: RFR: 8269957: facilitate alternate impls of NameTable and Name
 [v2]
In-Reply-To: <x-Rxw4lDuUoyqSvj6lj_J5GUFRQj_1KeLBc-PfBauDg=.904d293c-467c-41e7-b176-1bee7c7ca387@github.com>
References: <l4Cfs5xcp95oza_uYuCwox3iGYejS_-IO39sfBwfJ20=.d4e88095-fb22-4d20-91f2-27a607cd1723@github.com>
 <x-Rxw4lDuUoyqSvj6lj_J5GUFRQj_1KeLBc-PfBauDg=.904d293c-467c-41e7-b176-1bee7c7ca387@github.com>
Message-ID: <7mxy5wpRKNOcUV2WdxiQSe-RGiGeUBltArILZZu511c=.18dd36c9-b156-4780-a007-3bf69f818c3f@github.com>

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

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

Keep alive...

Does a 17% speedup in compile time interest anyone??

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

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

From darcy at openjdk.org  Tue Jul 11 02:28:22 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 11 Jul 2023 02:28:22 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac [v2]
In-Reply-To: <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
Message-ID: <GuRijaPqubZnPeP4DPn8BvsFPh4xDArCwkI-fA-VEkY=.9bfb3938-377d-466b-9897-36755fc7cef4@github.com>

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

>> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-2
>  - Remove Visual C++ specific workaround in javac

Catching up on reviews...

For the behavioral change being proposed, I think a CSR is deserved (as well as a release note).

I concur with @jonathan-gibbons 's suggestion of providing some kind of configuration knob to get the hold behavior in case is matters in an unanticipated situation.

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

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

From jwaters at openjdk.org  Tue Jul 11 06:25:17 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Jul 2023 06:25:17 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac [v2]
In-Reply-To: <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
Message-ID: <Z5vyImsjIlpQlit68jzFaML0AYt38fZBADUtg5UYbXs=.e56db7db-0a4f-4577-97e2-fe18e1cb88cf@github.com>

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

>> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-2
>  - Remove Visual C++ specific workaround in javac

Alright, I've reopened the CSR now. There is already a Release Note:


> Release Note created as https://bugs.openjdk.org/browse/JDK-8309551
> 
> > @TheShermanTanker only [Reviewers](https://openjdk.org/bylaws#reviewer) can determine that a CSR is not needed.
> 
> ...

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

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

From pyltsinm at gmail.com  Tue Jul 11 13:07:26 2023
From: pyltsinm at gmail.com (Mikhail Pyltsin)
Date: Tue, 11 Jul 2023 15:07:26 +0200
Subject: Unreachable statements after exhaustive switch statement
Message-ID: <CAOo1M=k3YM-AYUUr8ZpRSmf06-TeJ_yiejWzLMNfD_GpzG522w@mail.gmail.com>

  Hi!
I am investigating a new version of jep440+441
(
https://cr.openjdk.org/~gbierman/jep440%2B441/jep440+441-20230612/specs/patterns-switch-record-patterns-jls.html
)
and notice the next fact:
```
class Test22 {
    enum E {A, B}

    int testAll(Integer i, E e) {
        switch (e) {
            case E d when d.hashCode()==1:
                return 1;
            case A:
                return -1;
            case B:
                return -2;
        }
        return 1;
    }
}
```
this code produces an error: `java: unreachable statement`. It is expected,
but this draft doesn't mention any changes about reachability. 14.22
contains the statement, that
```
  A switch statement whose switch block consists of switch labeled
statement groups can complete normally if at least one of the following is
true:
....  ? The switch block does not contain a default label.
```
According to it, this `switch` can complete normally.
Perhaps, something is missing in this draft or I can't find some changes.
Could you help me why according to the jep this switch cannot complete
normally?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230711/711423ba/attachment-0001.htm>

From gavin.bierman at oracle.com  Tue Jul 11 13:24:07 2023
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Tue, 11 Jul 2023 13:24:07 +0000
Subject: Unreachable statements after exhaustive switch statement
In-Reply-To: <CAOo1M=k3YM-AYUUr8ZpRSmf06-TeJ_yiejWzLMNfD_GpzG522w@mail.gmail.com>
References: <CAOo1M=k3YM-AYUUr8ZpRSmf06-TeJ_yiejWzLMNfD_GpzG522w@mail.gmail.com>
Message-ID: <61AEFE41-73D2-4FFE-BDDE-DDC035BC0DB2@oracle.com>

Hi Mikhail,

Thanks. Looks like there might be a case missing in the spec - I will investigate and get back to you.

Gavin

On 11 Jul 2023, at 14:07, Mikhail Pyltsin <pyltsinm at gmail.com> wrote:

  Hi!
I am investigating a new version of jep440+441
(https://cr.openjdk.org/~gbierman/jep440%2B441/jep440+441-20230612/specs/patterns-switch-record-patterns-jls.html)
and notice the next fact:
```
class Test22 {
    enum E {A, B}

    int testAll(Integer i, E e) {
        switch (e) {
            case E d when d.hashCode()==1:
                return 1;
            case A:
                return -1;
            case B:
                return -2;
        }
        return 1;
    }
}
```
this code produces an error: `java: unreachable statement`. It is expected, but this draft doesn't mention any changes about reachability. 14.22 contains the statement, that
```
  A switch statement whose switch block consists of switch labeled statement groups can complete normally if at least one of the following is true:
....  ? The switch block does not contain a default label.
```
According to it, this `switch` can complete normally.
Perhaps, something is missing in this draft or I can't find some changes.
Could you help me why according to the jep this switch cannot complete normally?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230711/1e848456/attachment.htm>

From asotona at openjdk.org  Tue Jul 11 15:09:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 11 Jul 2023 15:09:48 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v9]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <4NCOczzNv-G14FVzqmO60GagflxNSI1RIv8_Yt7nXrI=.57cfc798-0e28-4ee9-be99-4df12ed3c9f8@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed code printing and ConstantPoolException reporting indoex

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/834de482..eb9d864f

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

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

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

From jjg at openjdk.org  Wed Jul 12 00:12:21 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 12 Jul 2023 00:12:21 GMT
Subject: RFR: 8305955: Remove Visual C++ specific workaround in javac [v2]
In-Reply-To: <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
 <iu0nPd1MefkM_ot5r4rtnYp18TJ48tWImiZhL6sWcY8=.7a9cda79-666f-4acc-b170-0198bc4a5027@github.com>
Message-ID: <P5Jq_TpkB0C3gdNJqZEjvA-ZpE0dtGguEvUAa4l-gbs=.68ac7cbc-ad56-4e87-a4aa-5bd8b1fe792f@github.com>

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

>> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-2
>  - Remove Visual C++ specific workaround in javac

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java line 274:

> 272:                 break;
> 273:             case LONG:
> 274:                 valueStr = value.toString() + "LL";

`JNIWriter` has access to the `Context` and thus to options, including "backdoor" options.

I suggest adding a definition of a member variable, something like the following, modeled on `checkAll`

private boolean visualCPlusPlus;

visualCPlusPlus = options.isSet("java:visualCPlusPlus");


then change line 275 to:

valueStr = value.toString() + ((isWindows && visualCPlusPlus) ? "i64" : "LL");


Overall, the intent is that the do-nothing default is the proposed new behavior, but that the command-line option `-XDvisualCPlusPlus` can be specified to recover the current behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13457#discussion_r1260412078

From ljnelson at gmail.com  Wed Jul 12 23:37:08 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Wed, 12 Jul 2023 16:37:08 -0700
Subject: Annotation type first encountered during ClassReader annotation
 parsing has wrong module?
Message-ID: <CAHNdxumzKh4N0XA_KWP4oRK8BSCDhMCLwAfLrXHVKdg+D=t_ig@mail.gmail.com>

I'm noticing that the type and element information for an
AnnotationMirror's annotation type is erroneous when read from a class file
via ClassReader in certain situations.

Specifically, consider:
* a module M with
* a class p.A with
* a method B annotated with
* a runtime visible annotation q.C where
* q (and therefore C) is not contained by M:

package p; // enclosed by module M
public class A {
  @q.C // q is not enclosed by M
  public void B() {}
}

Assuming I use javax.lang.util.Elements to get the ExecutableElement
corresponding to B, this should (it seems to me) succeed (q.C's type's kind
should be DECLARED):

TypeElement e = elements.getTypeElement("p.A");
// boring recipe for getting ExecutableElement for B from e omitted for
brevity
assert TypeKind.DECLARED ==
executableElementForB.getAnnotationMirrors().get(0).getAnnotationType().getKind();

Instead it fails because the TypeKind in question is TypeKind.ERROR.
(Recall this is not source-related; I'm asking javax.lang.model.* to read
valid already-compiled class files.)

>From debugging into the compiler (I am a not very bright bull in a china
shop), it seems to my na?ve eyes that when the ClassSymbol for q.C is
created as part of annotation bytecode reading, ClassReader assumes
incorrectly that the module that should enclose q.C is M (see
https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L535-L550,
and note that at #enterClass(Name)-time currentModule is M (
https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L2468
).

At any rate, the classfile attribute for the ClassSymbol for q.C when q.C
is encountered/created via this annotation-bytecode-reading pathway is
never set (probably because M is asked for its classes or packages or
something and q.C is not among them, correctly, so the completion machinery
doesn't know how to get it?), and that nullness seems to be the root cause
for the TypeKind.ERROR being reported.

Also of note: if I ask for the TypeElement corresponding to q.C directly
(via, say, elements.getTypeElement("q.C")) its ElementKind and associated
TypeKinds are correct.

The situation in which I encountered this is rather convoluted so I don't
have a simple executable reproducer ready to hand, but all the information
that I know of is here.

Shall I file a bug, or work with someone offline, or is this expected
behavior, or?? Thanks for everyone's time.

Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230712/f96d72c3/attachment.htm>

From jlahoda at openjdk.org  Thu Jul 13 12:59:16 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Jul 2023 12:59:16 GMT
Subject: RFR: 8311825: Duplicate qualified enum constants not detected
Message-ID: <OhKu86g3I3jmY3DdacPqM7QjeJU6kw5n0TzGGiWeYUA=.9ba54b64-b957-4925-85c9-3a757e66db52@github.com>

Duplicate enum constant check is missing for switches, when the qualified constants are used, so code like:

switch (...) {
     case E.A -> {}
     case E.A -> {}
}


Does not produce any errors. This patch is trying to fix this problem by adding the duplicate checks (sadly the codepaths are distinct, so the check is simply added to the various codepaths).

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

Commit messages:
 - 8311825: Duplicate qualified enum constants not detected

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

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

From jlahoda at openjdk.org  Thu Jul 13 15:30:42 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Jul 2023 15:30:42 GMT
Subject: RFR: 8311815: Incorrect exhaustivity computation
Message-ID: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>

Consider code like:

class Test22 {

  record Pair(I i1, I i2) {}

  sealed interface I {}

  record C() implements I {}

  record D() implements I {}

  void exhaustinvenessWithInterface(Pair pairI) {
    switch (pairI) {
      case Pair(D fst, C snd) -> {}
      case Pair(C fst, C snd) -> {}
      case Pair(C fst, I snd) -> {}
      case Pair(D fst, D snd) -> {}
    }
  }
} 


when evaluating exhaustivity, the outcome is wrong: if `Pair(D fst, C snd)` and `Pair(C fst, C snd)` get merged into `Pair(I _, C_)` (and the existing patterns are removed from the pattern set), the remaining patterns are `Pair(I _, C_)`, `Pair(C fst, I snd)` and `Pair(D fst, D snd)`. The existing implementation does not know how to continue from here (it would need to replace `Pair(C fst, I snd)` with `Pair(C fst, D snd)`, which would allow to unify `Pair(C fst, D snd)` and `Pair(D fst, D snd)` into `Pair(I _, D _)` and then continue, but that is tricky, as such speculation may not lead to a good result, and we would need to implement backtracking).

But, if `Pair(D fst, C snd)` and `Pair(D fst, D snd)` was merged into `Pair(D _, I _)`, it could then be merge with `Pair(C fst, I snd)` to produce `Pair(I _, I _)`.

The proposal here is aiming to allow the second path, by not removing the existing patterns when merging sealed subtypes. I.e. starting with `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _)}`, we would merge to `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), *Pair(I _, C_)*}`, and then `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), Pair(I _, C_), *Pair(D _, I _)*}`, which would then lead to `Pair(I _, I _)`, leading to `Pair` and confirmed exhaustivity.

This can be achieved easily by not removing binding in `reduceBindingPatterns`. The problem is that when we stop removing bindings, the algorithm may get into an infinite loop re-adding the same binding over and over. The solution to that is using Sets instead of Lists. To make the algorithm faster and more stable, there are two more additions: a) all record patterns covered by binding patterns are removed from the pattern set; b) `reduceNestedPatterns` attempts to produce results for all mismatching positions without returning (otherwise the algorithm may constantly only process the first mismatching position without progressing).

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

Depends on: https://git.openjdk.org/jdk/pull/14711

Commit messages:
 - 8311815: Incorrect exhaustivity computation

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

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

From vromero at openjdk.org  Thu Jul 13 20:13:12 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 13 Jul 2023 20:13:12 GMT
Subject: RFR: 8311825: Duplicate qualified enum constants not detected
In-Reply-To: <OhKu86g3I3jmY3DdacPqM7QjeJU6kw5n0TzGGiWeYUA=.9ba54b64-b957-4925-85c9-3a757e66db52@github.com>
References: <OhKu86g3I3jmY3DdacPqM7QjeJU6kw5n0TzGGiWeYUA=.9ba54b64-b957-4925-85c9-3a757e66db52@github.com>
Message-ID: <5nJq8UbQ950MQYsBsVAYCuFiLTfn2mmNg7s5YbTW15k=.756e6409-bf8c-40e2-8a08-e01ef27cd311@github.com>

On Thu, 13 Jul 2023 12:52:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Duplicate enum constant check is missing for switches, when the qualified constants are used, so code like:
> 
> switch (...) {
>      case E.A -> {}
>      case E.A -> {}
> }
> 
> 
> Does not produce any errors. This patch is trying to fix this problem by adding the duplicate checks (sadly the codepaths are distinct, so the check is simply added to the various codepaths).

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14870#pullrequestreview-1529171467

From darcy at openjdk.org  Fri Jul 14 00:49:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 00:49:42 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks
Message-ID: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>

Improve serial lint messages for externalizable records (and potentially other situations).

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

Commit messages:
 - Merge branch 'master' into JDK-8310835
 - Refactor implementation and add test.
 - Remove unused method.
 - Merge branch 'master' into JDK-8310835
 - Fix method call.
 - Merge branch 'master' into JDK-8310835
 - Checkpoint.
 - Update tests.
 - JDK-8310835: Address gaps in -Xlint:serial checks

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

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

From darcy at openjdk.org  Fri Jul 14 00:49:43 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 00:49:43 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks
In-Reply-To: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
Message-ID: <iyCRRSyDZNUcXAZ37w-1zFWBzBZCcAPIT7PJQ713L5o=.21828639-f8da-440d-b4d6-93309cc54211@github.com>

On Sat, 24 Jun 2023 22:27:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Improve serial lint messages for externalizable records (and potentially other situations).

There may be a similar opportunity for a more precise warning message for Externalizable enums, whether or not such message are appropriate depends on verifying that the externalization form of an enum cannot be customized.

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

PR Comment: https://git.openjdk.org/jdk/pull/14639#issuecomment-1635096268

From darcy at openjdk.org  Fri Jul 14 00:59:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 00:59:30 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks
In-Reply-To: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
Message-ID: <xjNxXTcFpdjCohq8bb1rfq_5d5qce-HTcZwzs9Jx1Cs=.4d969dc9-7f3d-4c10-aff2-9c50c208ef24@github.com>

On Sat, 24 Jun 2023 22:27:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Improve serial lint messages for externalizable records (and potentially other situations).

Note the design center for warnings about Externalizable types is somewhat different than for just Serializable types since Externalizable is an interface that defines methods and the compiler can checked whether or not those methods are implemented by a class (unlike for Serialization where the methods can be and by convention are private).

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

PR Comment: https://git.openjdk.org/jdk/pull/14639#issuecomment-1635104795

From joe.darcy at oracle.com  Fri Jul 14 04:19:44 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 13 Jul 2023 21:19:44 -0700
Subject: Annotation type first encountered during ClassReader annotation
 parsing has wrong module?
In-Reply-To: <CAHNdxumzKh4N0XA_KWP4oRK8BSCDhMCLwAfLrXHVKdg+D=t_ig@mail.gmail.com>
References: <CAHNdxumzKh4N0XA_KWP4oRK8BSCDhMCLwAfLrXHVKdg+D=t_ig@mail.gmail.com>
Message-ID: <c6f0faeb-c426-4545-1642-608938aaf529@oracle.com>

Some additional context, to construct annotations from a class file, 
either runtime via core reflection or at compile-time for javac, at some 
point a name -> annotation type lookup needs to be performed. The name 
of the annotation type is what is represented in the class file along 
with the actual data for the methods of the annotation to return.

At runtime it is *not* an error if the annotation type for an annotation 
is not found, no annotation for that type is returned.

If the "path"/environment to perform the annotation type name -> 
annotation type is not configured to include the annotation type, it 
won't be found.

Without looking at the javac implementation, it is certainly feasible 
that the environment to do the annotation type name mapping is not 
correctly configured in a case like that. For example, any public 
annotations in java.base should always be accessible even to code in 
other modules.

HTH,

-Joe

On 7/12/2023 4:37 PM, Laird Nelson wrote:
> I'm noticing that the type and element information for an 
> AnnotationMirror's?annotation type is erroneous when read from a class 
> file via ClassReader in certain situations.
>
> Specifically, consider:
> * a module M with
> * a class p.A with
> * a method B annotated with
> * a runtime visible annotation q.C where
> * q (and therefore C) is not contained by M:
>
> package p; // enclosed by module M
> public class A {
> ??@q.C // q is not enclosed by M
> ? public void B() {}
> }
>
> Assuming I use javax.lang.util.Elements to get the ExecutableElement 
> corresponding to B, this should (it seems to me) succeed (q.C's type's 
> kind should?be DECLARED):
>
> TypeElement e = elements.getTypeElement("p.A");
> // boring recipe for getting ExecutableElement for B from e omitted 
> for brevity
> assert TypeKind.DECLARED == 
> executableElementForB.getAnnotationMirrors().get(0).getAnnotationType().getKind();
>
> Instead it fails because the TypeKind in question is TypeKind.ERROR.? 
> (Recall this is not source-related; I'm asking javax.lang.model.* to 
> read valid already-compiled class files.)
>
> From debugging into the compiler (I am a not very bright bull in a 
> china shop), it seems to my na?ve eyes that when the ClassSymbol for 
> q.C is created as part of annotation bytecode reading, ClassReader 
> assumes incorrectly that the module that should enclose q.C is M (see 
> https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L535-L550, 
> and note that at #enterClass(Name)-time currentModule is M 
> (https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L2468).
>
> At any rate, the classfile?attribute for the ClassSymbol for q.C when 
> q.C is encountered/created via this annotation-bytecode-reading 
> pathway is never set (probably because M is asked for its classes or 
> packages or something and q.C is not among them, correctly, so the 
> completion machinery doesn't know how to get it?), and that nullness 
> seems to be the root cause for the TypeKind.ERROR being reported.
>
> Also of note: if I ask for the TypeElement corresponding to q.C 
> directly (via, say, elements.getTypeElement("q.C")) its ElementKind 
> and associated TypeKinds are correct.
>
> The situation in which I encountered this is rather convoluted so I 
> don't have a simple executable reproducer ready to hand, but all the 
> information that I know of is here.
>
> Shall I file a bug, or work with someone offline, or is this expected 
> behavior, or?? Thanks for everyone's time.
>
> Best,
> Laird

From jan.lahoda at oracle.com  Fri Jul 14 08:05:33 2023
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 14 Jul 2023 10:05:33 +0200
Subject: Annotation type first encountered during ClassReader annotation
 parsing has wrong module?
In-Reply-To: <CAHNdxumzKh4N0XA_KWP4oRK8BSCDhMCLwAfLrXHVKdg+D=t_ig@mail.gmail.com>
References: <CAHNdxumzKh4N0XA_KWP4oRK8BSCDhMCLwAfLrXHVKdg+D=t_ig@mail.gmail.com>
Message-ID: <5e70c1ef-e479-fdd1-421a-4656d5684c59@oracle.com>

Hello Laird,


I am afraid a reproducible case is likely needed for this. I tried a 
simple testcase, where a use in module "use" uses an annotation from 
different module "lib", and the usages is from classfile:

https://github.com/lahodaj/jdk/blob/e74368cb72790a399f3bb28c0dde2146d015757e/test/langtools/tools/javac/modules/AnnotationsAndMultipleModules.java


Also, please note that the semantics of "Symtab.enterClass(ModuleSymbol 
msym, Name flatname)" is not "create a class called flatname in module 
msym", but "create a class called flatname accessible from module msym". 
This method follows the module rules, and looks into the modules the 
given module is reading, to find the correct package in the correct 
module to place the class. (It will fallback to placing the class into 
the given module, if there's no dependency where it would belong, which 
might be cause e.g. by improperly setup modules.)


Jan


On 13. 07. 23 1:37, Laird Nelson wrote:
> I'm noticing that the type and element information for an 
> AnnotationMirror's?annotation type is erroneous when read from a class 
> file via ClassReader in certain situations.
>
> Specifically, consider:
> * a module M with
> * a class p.A with
> * a method B annotated with
> * a runtime visible annotation q.C where
> * q (and therefore C) is not contained by M:
>
> package p; // enclosed by module M
> public class A {
> ??@q.C // q is not enclosed by M
> ? public void B() {}
> }
>
> Assuming I use javax.lang.util.Elements to get the ExecutableElement 
> corresponding to B, this should (it seems to me) succeed (q.C's type's 
> kind should?be DECLARED):
>
> TypeElement e = elements.getTypeElement("p.A");
> // boring recipe for getting ExecutableElement for B from e omitted 
> for brevity
> assert TypeKind.DECLARED == 
> executableElementForB.getAnnotationMirrors().get(0).getAnnotationType().getKind();
>
> Instead it fails because the TypeKind in question is TypeKind.ERROR.? 
> (Recall this is not source-related; I'm asking javax.lang.model.* to 
> read valid already-compiled class files.)
>
> From debugging into the compiler (I am a not very bright bull in a 
> china shop), it seems to my na?ve eyes that when the ClassSymbol for 
> q.C is created as part of annotation bytecode reading, ClassReader 
> assumes incorrectly that the module that should enclose q.C is M (see 
> https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L535-L550, 
> and note that at #enterClass(Name)-time currentModule is M 
> (https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L2468).
>
> At any rate, the classfile?attribute for the ClassSymbol for q.C when 
> q.C is encountered/created via this annotation-bytecode-reading 
> pathway is never set (probably because M is asked for its classes or 
> packages or something and q.C is not among them, correctly, so the 
> completion machinery doesn't know how to get it?), and that nullness 
> seems to be the root cause for the TypeKind.ERROR being reported.
>
> Also of note: if I ask for the TypeElement corresponding to q.C 
> directly (via, say, elements.getTypeElement("q.C")) its ElementKind 
> and associated TypeKinds are correct.
>
> The situation in which I encountered this is rather convoluted so I 
> don't have a simple executable reproducer ready to hand, but all the 
> information that I know of is here.
>
> Shall I file a bug, or work with someone offline, or is this expected 
> behavior, or?? Thanks for everyone's time.
>
> Best,
> Laird

From jlahoda at openjdk.org  Fri Jul 14 08:25:23 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Jul 2023 08:25:23 GMT
Subject: Integrated: 8311038: Incorrect exhaustivity computation
In-Reply-To: <O0ux_r2SFBkYplgo6tHml1fgdgluKhE-QbE_u542TNc=.249c86c4-a181-4dd7-9b85-87b47608071b@github.com>
References: <O0ux_r2SFBkYplgo6tHml1fgdgluKhE-QbE_u542TNc=.249c86c4-a181-4dd7-9b85-87b47608071b@github.com>
Message-ID: <GFEG-44eDvETDaxnNhgRctIzVsZaOQrl4MzsaanfRRE=.030ce7af-e658-490c-8868-02e5d65af61b@github.com>

On Thu, 29 Jun 2023 13:24:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this code:
> 
> public class Test {
> 
>     record Rec(Object t) {}
> 
>     private void test2() {
>         Rec r = new Rec("test");
>         int res = switch (r) {
>             case Rec(String x): {
>                 yield x.length();
>             }
>             case Rec(Object x): {
>                 yield -3;
>             }
>         };
>     }
> 
> }
> 
> 
> It is obviously exhaustive (there's `Rec(Object x)`, which is unconditional on `Rec`), but javac fails to compile this code:
> 
> /tmp/Test.java:7: error: the switch expression does not cover all possible input values
>         int res = switch (r) {
>                   ^
> 1 error
> 
> 
> The cause seems to be that when binding patterns for the (nested) `String` and `Object` are reduced, they are reduced to `String` and `ConstantDesc`, which is no longer exhaustive for `Object`.
> 
> This is a result of this code:
> https://github.com/openjdk/jdk/blob/07734f6dde2b29574b6ef98eeb9e007d8801a3ea/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java#L886
> which is intended to help with patterns that don't stand directly in the selector's hierarchy, like:
> https://github.com/openjdk/jdk/blob/07734f6dde2b29574b6ef98eeb9e007d8801a3ea/test/langtools/tools/javac/patterns/Exhaustiveness.java#L1494
> where `I3` is only related to the selector (`I`) via a permitted subtype.
> 
> Part of the problem is that `Object` is removed from the pattern set - adding `ConstantDesc` is not a problem. The proposal in this patch is to keep supertypes of the type that is being added in the pattern set. This will lead to pattern set `ConstantDesc`, `Object` and `String`, which should be OK for correctness, although generally enhancing the pattern set might slow down the processing.
> 
> There are two complicating factors, which make the observed bug surprising and difficult to diagnose:
>  - if (in this example) `ConstantDesc` has not been completed yet, `.isSealed()` will return `false` for it, and the code will compile. This may happen when `x.length()` is removed/replaced in the example. This patch proposes to complete the Symbols before checking for sealedness.
>  - it appears to be difficult to reproduce with a synthetic testcase, due to variations in ordering in maps. Hence this patch is using `String` in the testcase, as opposed to a test-only class.

This pull request has now been integrated.

Changeset: bbb7ce51
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bbb7ce5137cd3e8365552b42610e19b7ebe43ba1
Stats:     28 lines in 2 files changed: 26 ins; 0 del; 2 mod

8311038: Incorrect exhaustivity computation

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Fri Jul 14 08:32:03 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Jul 2023 08:32:03 GMT
Subject: RFR: 8311815: Incorrect exhaustivity computation [v2]
In-Reply-To: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
References: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
Message-ID: <4CEfhUphz5UfRThqxozpoirn8IT3WjqYMS00IbsmZfI=.8de8d8d5-daf2-4413-a767-3b4c3dfe7712@github.com>

> Consider code like:
> 
> class Test22 {
> 
>   record Pair(I i1, I i2) {}
> 
>   sealed interface I {}
> 
>   record C() implements I {}
> 
>   record D() implements I {}
> 
>   void exhaustinvenessWithInterface(Pair pairI) {
>     switch (pairI) {
>       case Pair(D fst, C snd) -> {}
>       case Pair(C fst, C snd) -> {}
>       case Pair(C fst, I snd) -> {}
>       case Pair(D fst, D snd) -> {}
>     }
>   }
> } 
> 
> 
> when evaluating exhaustivity, the outcome is wrong: if `Pair(D fst, C snd)` and `Pair(C fst, C snd)` get merged into `Pair(I _, C_)` (and the existing patterns are removed from the pattern set), the remaining patterns are `Pair(I _, C_)`, `Pair(C fst, I snd)` and `Pair(D fst, D snd)`. The existing implementation does not know how to continue from here (it would need to replace `Pair(C fst, I snd)` with `Pair(C fst, D snd)`, which would allow to unify `Pair(C fst, D snd)` and `Pair(D fst, D snd)` into `Pair(I _, D _)` and then continue, but that is tricky, as such speculation may not lead to a good result, and we would need to implement backtracking).
> 
> But, if `Pair(D fst, C snd)` and `Pair(D fst, D snd)` was merged into `Pair(D _, I _)`, it could then be merge with `Pair(C fst, I snd)` to produce `Pair(I _, I _)`.
> 
> The proposal here is aiming to allow the second path, by not removing the existing patterns when merging sealed subtypes. I.e. starting with `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _)}`, we would merge to `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), *Pair(I _, C_)*}`, and then `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), Pair(I _, C_), *Pair(D _, I _)*}`, which would then lead to `Pair(I _, I _)`, leading to `Pair` and confirmed exhaustivity.
> 
> This can be achieved easily by not removing binding in `reduceBindingPatterns`. The problem is that when we stop removing bindings, the algorithm may get into an infinite loop re-adding the same binding over and over. The solution to that is using Sets instead of Lists. To make the algorithm faster and more stable, there are two more additions: a) all record patterns covered by binding patterns are removed from the pattern set; b) `reduceNestedPatterns` attempts to produce results for all mismatching positions without returning (otherwise the algorithm may constantly only process the first mismatching position without progressing).

Jan Lahoda 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-8311815
 - 8311815: Incorrect exhaustivity computation
 - 8311038: Incorrect exhaustivity computation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14872/files
  - new: https://git.openjdk.org/jdk/pull/14872/files/b5b1515b..1f5c1735

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

  Stats: 75624 lines in 1342 files changed: 18076 ins; 51990 del; 5558 mod
  Patch: https://git.openjdk.org/jdk/pull/14872.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14872/head:pull/14872

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

From jlahoda at openjdk.org  Fri Jul 14 09:58:09 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Jul 2023 09:58:09 GMT
Subject: Integrated: 8311825: Duplicate qualified enum constants not detected
In-Reply-To: <OhKu86g3I3jmY3DdacPqM7QjeJU6kw5n0TzGGiWeYUA=.9ba54b64-b957-4925-85c9-3a757e66db52@github.com>
References: <OhKu86g3I3jmY3DdacPqM7QjeJU6kw5n0TzGGiWeYUA=.9ba54b64-b957-4925-85c9-3a757e66db52@github.com>
Message-ID: <gDtGceew41rjry-nJo27aaBJWp9jOqEcM2fg0QTnGGw=.f4c8ad8b-2d36-4f33-bcfc-a6c79e76448c@github.com>

On Thu, 13 Jul 2023 12:52:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Duplicate enum constant check is missing for switches, when the qualified constants are used, so code like:
> 
> switch (...) {
>      case E.A -> {}
>      case E.A -> {}
> }
> 
> 
> Does not produce any errors. This patch is trying to fix this problem by adding the duplicate checks (sadly the codepaths are distinct, so the check is simply added to the various codepaths).

This pull request has now been integrated.

Changeset: d1fa1a86
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1fa1a868636dc15e96d1b4bf4acf28257c9551f
Stats:     33 lines in 3 files changed: 31 ins; 0 del; 2 mod

8311825: Duplicate qualified enum constants not detected

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Fri Jul 14 10:05:42 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Jul 2023 10:05:42 GMT
Subject: [jdk21] RFR: 8311038: Incorrect exhaustivity computation
Message-ID: <FlQZdWaGQbJaCfcAG6P0R3gbS3ugYBhRXmA1pDrRSCw=.2913787f-aea6-4713-a223-876aab24aaeb@github.com>

Hi all,

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

The commit being backported was authored by Jan Lahoda on 14 Jul 2023 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport bbb7ce5137cd3e8365552b42610e19b7ebe43ba1

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

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

From jlahoda at openjdk.org  Fri Jul 14 10:07:38 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Jul 2023 10:07:38 GMT
Subject: [jdk21] RFR: 8311825: Duplicate qualified enum constants not detected
Message-ID: <7ieBH12DWildK4Soy2zPcBDbOBxmM4HiEpqyPNau8Jg=.3e52c473-b766-47bd-b7df-2b83f74e7137@github.com>

Hi all,

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

The commit being backported was authored by Jan Lahoda on 14 Jul 2023 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport d1fa1a868636dc15e96d1b4bf4acf28257c9551f

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

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

From vromero at openjdk.org  Fri Jul 14 13:12:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jul 2023 13:12:10 GMT
Subject: [jdk21] RFR: 8311825: Duplicate qualified enum constants not
 detected
In-Reply-To: <7ieBH12DWildK4Soy2zPcBDbOBxmM4HiEpqyPNau8Jg=.3e52c473-b766-47bd-b7df-2b83f74e7137@github.com>
References: <7ieBH12DWildK4Soy2zPcBDbOBxmM4HiEpqyPNau8Jg=.3e52c473-b766-47bd-b7df-2b83f74e7137@github.com>
Message-ID: <KllmOIRdAnaW-sVcswgSlPNDMKFJ3jg1Xu5VseaiVXk=.216ca3fb-28c5-4f30-b9e6-18f6319aa915@github.com>

On Fri, 14 Jul 2023 09:58:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/128#pullrequestreview-1530278196

From ljnelson at gmail.com  Fri Jul 14 13:26:26 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Fri, 14 Jul 2023 06:26:26 -0700
Subject: Annotation type first encountered during ClassReader annotation
 parsing has wrong module?
In-Reply-To: <5e70c1ef-e479-fdd1-421a-4656d5684c59@oracle.com>
References: <CAHNdxumzKh4N0XA_KWP4oRK8BSCDhMCLwAfLrXHVKdg+D=t_ig@mail.gmail.com>
 <5e70c1ef-e479-fdd1-421a-4656d5684c59@oracle.com>
Message-ID: <CAHNdxumzsgObsENBWP-jySzuw26mv9abpYY76Li=ZZm18M2PuA@mail.gmail.com>

On Fri, Jul 14, 2023 at 1:05?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> I tried a
> simple testcase, where a use in module "use" uses an annotation from
> different module "lib", and the usages is from classfile:
>
>
> https://github.com/lahodaj/jdk/blob/e74368cb72790a399f3bb28c0dde2146d015757e/test/langtools/tools/javac/modules/AnnotationsAndMultipleModules.java
>

Would it matter if "different module" were the/an unnamed module? And if
"use" were a patched module?

In case it turns out to matter, the scenario is one that is commonly set up
by Maven's JUnit test machinery unless you actively work against it: at
test time, unit test code under src/test/java is automagically patched into
(via --patch-module) your project's "main" module (M) (whose classes reside
conventionally under src/main/java). The command line contains
--module-path "/path/to/M", --add-reads M=ALL-UNNAMED, and --add-opens
M/p=ALL-UNNAMED, and --add-modules M (if I've typed all that properly).
JUnit itself, though modular, is on the classpath. The annotation in my
example (q.C) is actually org.junit.jupiter.api.Test, if it matters. The
net effect is (not defending it, just noting) M's module-info does not have
to explicitly read any JUnit module, but your project's JUnit-based unit
test code can nevertheless "see" package-private methods etc. in M as if it
were a proper member of M.

In this case, in such an environment, if you
access @org.junit.jupiter.api.Test (annotating a method in your unit test
under src/test/java, patched in to M), its type will be erroneous. Or so I
am observing.

I'll see if I can put together a reproducer but this is not at all high
priority for me. I'm also getting the strong sense here that this is
somehow likely pilot error in some way, though I'm not sure on what input.

Thanks for your time,
Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230714/bffa4a2d/attachment.htm>

From rriggs at openjdk.org  Fri Jul 14 14:51:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Jul 2023 14:51:04 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks
In-Reply-To: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
Message-ID: <466xxNcbkui2DFQAGMbTfMPKKHS9u-uBAeuJgXx-YjM=.0bb66a76-c39b-489a-9148-68d38eb8ba08@github.com>

On Sat, 24 Jun 2023 22:27:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Improve serial lint messages for externalizable records (and potentially other situations).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5429:

> 5427:                                                  MethodSymbol method,
> 5428:                                                  Type expectedType) {
> 5429:             var parameters= method.getParameters();

Missing space before "=".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14639#discussion_r1263819068

From jlahoda at openjdk.org  Fri Jul 14 15:08:34 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Jul 2023 15:08:34 GMT
Subject: RFR: 8312093: Incorrect javadoc comment text
Message-ID: <SYQjvCeMiRAl3bpuA6Z_GY_w5umjHSk6tRtWU6fp5wE=.86047eeb-5e1c-4d1f-bbec-ea9c6f337bf1@github.com>

Consider a javadoc comment like:

public class Test {
    /***/
    void main() {
    }
}


The doc comment's String for the javadoc comment will be "`/`", which is wrong. The reason is that the third '*' is ignored, and the closing '/' is used as the content of the comment.

The proposed solution is to tweak the parser to properly handle the closing '*/' in this case.

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

Commit messages:
 - 8312093: Incorrect javadoc comment text

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

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

From cushon at google.com  Fri Jul 14 15:19:02 2023
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 14 Jul 2023 08:19:02 -0700
Subject: Annotation type first encountered during ClassReader annotation
 parsing has wrong module?
In-Reply-To: <5e70c1ef-e479-fdd1-421a-4656d5684c59@oracle.com>
References: <CAHNdxumzKh4N0XA_KWP4oRK8BSCDhMCLwAfLrXHVKdg+D=t_ig@mail.gmail.com>
 <5e70c1ef-e479-fdd1-421a-4656d5684c59@oracle.com>
Message-ID: <CAL4Qsgv8j8Q+pGc04KdtHkG2BXJrhCgdE3No3HrsSOWqtW+z5A@mail.gmail.com>

On Fri, Jul 14, 2023 at 1:05?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Also, please note that the semantics of "Symtab.enterClass(ModuleSymbol
> msym, Name flatname)" is not "create a class called flatname in module
> msym", but "create a class called flatname accessible from module msym".
> This method follows the module rules, and looks into the modules the
> given module is reading, to find the correct package in the correct
> module to place the class. (It will fallback to placing the class into
> the given module, if there's no dependency where it would belong, which
> might be cause e.g. by improperly setup modules.)


This explains something I had been confused about :)

I have seen unexpected class.file.not.found for annotations referenced in
bytecode, where the module graph is ill-formed and the annotations aren't
supposed to be readable by the classes that reference them. I think that
explains why that happens.

I was curious why javac doesn't try to errors like what would be reported
during compilation when referencing a package that exists somewhere but
isn't readable (e.g. ''package X is declared in module Y, which does not
export it', and the other 'not.def.access' diagnostics). Are there
performance reasons? Perhaps it is too expensive to keep track of all
classes during classloading, including ones that shouldn't be readable, to
support that kind of diagnostic?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230714/8b924f26/attachment-0001.htm>

From jlaskey at openjdk.org  Fri Jul 14 15:19:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 14 Jul 2023 15:19:14 GMT
Subject: RFR: 8312093: Incorrect javadoc comment text
In-Reply-To: <SYQjvCeMiRAl3bpuA6Z_GY_w5umjHSk6tRtWU6fp5wE=.86047eeb-5e1c-4d1f-bbec-ea9c6f337bf1@github.com>
References: <SYQjvCeMiRAl3bpuA6Z_GY_w5umjHSk6tRtWU6fp5wE=.86047eeb-5e1c-4d1f-bbec-ea9c6f337bf1@github.com>
Message-ID: <11k2y1hgQex2vra7Gj-coOMn-Xo1fHfPqLiw96I5i60=.6eed53ea-ae90-4958-8d56-bf39bc00efee@github.com>

On Fri, 14 Jul 2023 15:00:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a javadoc comment like:
> 
> public class Test {
>     /***/
>     void main() {
>     }
> }
> 
> 
> The doc comment's String for the javadoc comment will be "`/`", which is wrong. The reason is that the third '*' is ignored, and the closing '/' is used as the content of the comment.
> 
> The proposed solution is to tweak the parser to properly handle the closing '*/' in this case.

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14890#pullrequestreview-1530496112

From darcy at openjdk.org  Fri Jul 14 16:42:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 16:42:30 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v2]
In-Reply-To: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
Message-ID: <m5Pr6MW-_sueUwwirwL8FLSMlNFFATkc1Y5s1vUydk8=.bcb27f4f-c423-4492-9691-f456ba56abce@github.com>

> Improve serial lint messages for externalizable records (and potentially other situations).

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/14639/files
  - new: https://git.openjdk.org/jdk/pull/14639/files/7fb31569..6196f9b8

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

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

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

From vromero at openjdk.org  Fri Jul 14 17:29:04 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jul 2023 17:29:04 GMT
Subject: RFR: 8311815: Incorrect exhaustivity computation [v2]
In-Reply-To: <4CEfhUphz5UfRThqxozpoirn8IT3WjqYMS00IbsmZfI=.8de8d8d5-daf2-4413-a767-3b4c3dfe7712@github.com>
References: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
 <4CEfhUphz5UfRThqxozpoirn8IT3WjqYMS00IbsmZfI=.8de8d8d5-daf2-4413-a767-3b4c3dfe7712@github.com>
Message-ID: <frNz9zUrYfkm0JEuGfY3_jT5oHOM2SfSedAz7htD95s=.f92c48aa-d3e9-4c13-8d16-6f47d6811ebb@github.com>

On Fri, 14 Jul 2023 08:32:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> class Test22 {
>> 
>>   record Pair(I i1, I i2) {}
>> 
>>   sealed interface I {}
>> 
>>   record C() implements I {}
>> 
>>   record D() implements I {}
>> 
>>   void exhaustinvenessWithInterface(Pair pairI) {
>>     switch (pairI) {
>>       case Pair(D fst, C snd) -> {}
>>       case Pair(C fst, C snd) -> {}
>>       case Pair(C fst, I snd) -> {}
>>       case Pair(D fst, D snd) -> {}
>>     }
>>   }
>> } 
>> 
>> 
>> when evaluating exhaustivity, the outcome is wrong: if `Pair(D fst, C snd)` and `Pair(C fst, C snd)` get merged into `Pair(I _, C_)` (and the existing patterns are removed from the pattern set), the remaining patterns are `Pair(I _, C_)`, `Pair(C fst, I snd)` and `Pair(D fst, D snd)`. The existing implementation does not know how to continue from here (it would need to replace `Pair(C fst, I snd)` with `Pair(C fst, D snd)`, which would allow to unify `Pair(C fst, D snd)` and `Pair(D fst, D snd)` into `Pair(I _, D _)` and then continue, but that is tricky, as such speculation may not lead to a good result, and we would need to implement backtracking).
>> 
>> But, if `Pair(D fst, C snd)` and `Pair(D fst, D snd)` was merged into `Pair(D _, I _)`, it could then be merge with `Pair(C fst, I snd)` to produce `Pair(I _, I _)`.
>> 
>> The proposal here is aiming to allow the second path, by not removing the existing patterns when merging sealed subtypes. I.e. starting with `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _)}`, we would merge to `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), *Pair(I _, C_)*}`, and then `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), Pair(I _, C_), *Pair(D _, I _)*}`, which would then lead to `Pair(I _, I _)`, leading to `Pair` and confirmed exhaustivity.
>> 
>> This can be achieved easily by not removing binding in `reduceBindingPatterns`. The problem is that when we stop removing bindings, the algorithm may get into an infinite loop re-adding the same binding over and over. The solution to that is using Sets instead of Lists. To make the algorithm faster and more stable, there are two more additions: a) all record patterns covered by binding patterns are removed from the pattern set; b) `reduceNestedPatterns` attempts to produce results for all mismatching positions without returning (otherwise the algorithm may constantly only process the first mismatching position without progressing).
>
> Jan Lahoda 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-8311815
>  - 8311815: Incorrect exhaustivity computation
>  - 8311038: Incorrect exhaustivity computation

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14872#pullrequestreview-1530689121

From vromero at openjdk.org  Fri Jul 14 18:53:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jul 2023 18:53:29 GMT
Subject: RFR: 8311815: Incorrect exhaustivity computation [v2]
In-Reply-To: <4CEfhUphz5UfRThqxozpoirn8IT3WjqYMS00IbsmZfI=.8de8d8d5-daf2-4413-a767-3b4c3dfe7712@github.com>
References: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
 <4CEfhUphz5UfRThqxozpoirn8IT3WjqYMS00IbsmZfI=.8de8d8d5-daf2-4413-a767-3b4c3dfe7712@github.com>
Message-ID: <HIx-b42cjVAH0R9CaJHStjaMfSF1e5_qCFvG-y-iFJc=.b88fe039-da08-402a-af79-404fd05a5894@github.com>

On Fri, 14 Jul 2023 08:32:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> class Test22 {
>> 
>>   record Pair(I i1, I i2) {}
>> 
>>   sealed interface I {}
>> 
>>   record C() implements I {}
>> 
>>   record D() implements I {}
>> 
>>   void exhaustinvenessWithInterface(Pair pairI) {
>>     switch (pairI) {
>>       case Pair(D fst, C snd) -> {}
>>       case Pair(C fst, C snd) -> {}
>>       case Pair(C fst, I snd) -> {}
>>       case Pair(D fst, D snd) -> {}
>>     }
>>   }
>> } 
>> 
>> 
>> when evaluating exhaustivity, the outcome is wrong: if `Pair(D fst, C snd)` and `Pair(C fst, C snd)` get merged into `Pair(I _, C_)` (and the existing patterns are removed from the pattern set), the remaining patterns are `Pair(I _, C_)`, `Pair(C fst, I snd)` and `Pair(D fst, D snd)`. The existing implementation does not know how to continue from here (it would need to replace `Pair(C fst, I snd)` with `Pair(C fst, D snd)`, which would allow to unify `Pair(C fst, D snd)` and `Pair(D fst, D snd)` into `Pair(I _, D _)` and then continue, but that is tricky, as such speculation may not lead to a good result, and we would need to implement backtracking).
>> 
>> But, if `Pair(D fst, C snd)` and `Pair(D fst, D snd)` was merged into `Pair(D _, I _)`, it could then be merge with `Pair(C fst, I snd)` to produce `Pair(I _, I _)`.
>> 
>> The proposal here is aiming to allow the second path, by not removing the existing patterns when merging sealed subtypes. I.e. starting with `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _)}`, we would merge to `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), *Pair(I _, C_)*}`, and then `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), Pair(I _, C_), *Pair(D _, I _)*}`, which would then lead to `Pair(I _, I _)`, leading to `Pair` and confirmed exhaustivity.
>> 
>> This can be achieved easily by not removing binding in `reduceBindingPatterns`. The problem is that when we stop removing bindings, the algorithm may get into an infinite loop re-adding the same binding over and over. The solution to that is using Sets instead of Lists. To make the algorithm faster and more stable, there are two more additions: a) all record patterns covered by binding patterns are removed from the pattern set; b) `reduceNestedPatterns` attempts to produce results for all mismatching positions without returning (otherwise the algorithm may constantly only process the first mismatching position without progressing).
>
> Jan Lahoda 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-8311815
>  - 8311815: Incorrect exhaustivity computation
>  - 8311038: Incorrect exhaustivity computation

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3511:

> 3509:         public RecordPattern(Type recordType, Type[] fullComponentTypes, PatternDescription[] nested) {
> 3510:             this(recordType, hashCode(-1, recordType, nested), fullComponentTypes, nested);
> 3511:             if ("test.Test.R(test.Test.C _, test.Test.R(test.Test.C _, test.Test.R(test.Test.C _, test.Test.C _, test.Test.C _), test.Test.I _), test.Test.I _)".equals(toString())) {

sorry missed this, this seems like testing code that should be removed right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14872#discussion_r1264044634

From jlahoda at openjdk.org  Fri Jul 14 19:12:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 14 Jul 2023 19:12:18 GMT
Subject: RFR: 8311815: Incorrect exhaustivity computation [v2]
In-Reply-To: <HIx-b42cjVAH0R9CaJHStjaMfSF1e5_qCFvG-y-iFJc=.b88fe039-da08-402a-af79-404fd05a5894@github.com>
References: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
 <4CEfhUphz5UfRThqxozpoirn8IT3WjqYMS00IbsmZfI=.8de8d8d5-daf2-4413-a767-3b4c3dfe7712@github.com>
 <HIx-b42cjVAH0R9CaJHStjaMfSF1e5_qCFvG-y-iFJc=.b88fe039-da08-402a-af79-404fd05a5894@github.com>
Message-ID: <gB9Fbza4X0tSJ8crBl4BCMZguER8Gd7VYnz52sdM40w=.8be190ea-389f-4086-894b-8b5c8e2ed97e@github.com>

On Fri, 14 Jul 2023 18:49:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda 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-8311815
>>  - 8311815: Incorrect exhaustivity computation
>>  - 8311038: Incorrect exhaustivity computation
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3511:
> 
>> 3509:         public RecordPattern(Type recordType, Type[] fullComponentTypes, PatternDescription[] nested) {
>> 3510:             this(recordType, hashCode(-1, recordType, nested), fullComponentTypes, nested);
>> 3511:             if ("test.Test.R(test.Test.C _, test.Test.R(test.Test.C _, test.Test.R(test.Test.C _, test.Test.C _, test.Test.C _), test.Test.I _), test.Test.I _)".equals(toString())) {
> 
> sorry missed this, this seems like testing code that should be removed right?

Oops, sorry, will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14872#discussion_r1264063915

From darcy at openjdk.org  Fri Jul 14 22:40:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 22:40:14 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v2]
In-Reply-To: <m5Pr6MW-_sueUwwirwL8FLSMlNFFATkc1Y5s1vUydk8=.bcb27f4f-c423-4492-9691-f456ba56abce@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
 <m5Pr6MW-_sueUwwirwL8FLSMlNFFATkc1Y5s1vUydk8=.bcb27f4f-c423-4492-9691-f456ba56abce@github.com>
Message-ID: <B7AtGV64QFB90RLUcDqOa82vHOubj9Oue8kf_8SNpNw=.7f6fab76-da8e-4d53-8fca-76d5de2d5036@github.com>

On Fri, 14 Jul 2023 16:42:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve serial lint messages for externalizable records (and potentially other situations).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo found in code review.

After some one-off checking with a small test program, I verified the implementation does _not_ call readExternal or writeExternal on an Externalizable enum. I'll update the messages accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/14639#issuecomment-1636518761

From darcy at openjdk.org  Fri Jul 14 23:37:38 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jul 2023 23:37:38 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v3]
In-Reply-To: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
Message-ID: <emdS0htKF4_mpW6gV65e2K7UxOjbMqsRuzXgr2AaBxs=.628974b2-11fd-4431-82b9-dbea68a1bc97@github.com>

> Improve serial lint messages for externalizable records (and potentially other situations).

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

  Add support for externalizable enum checks.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14639/files
  - new: https://git.openjdk.org/jdk/pull/14639/files/6196f9b8..17b6dfd7

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

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

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

From darcy at openjdk.org  Sat Jul 15 02:05:24 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 15 Jul 2023 02:05:24 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v4]
In-Reply-To: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
Message-ID: <DFWyQbSsvizvD7sMKdigdbeLpfpVeH8Fw0rtlcWXUaA=.9c194332-6e1d-4a1f-975f-39e8e5a65e1e@github.com>

> Improve serial lint messages for externalizable records (and potentially other situations).

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

  Refactor Externalizable check.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14639/files
  - new: https://git.openjdk.org/jdk/pull/14639/files/17b6dfd7..74a3055a

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

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

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

From jlahoda at openjdk.org  Mon Jul 17 06:11:45 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 17 Jul 2023 06:11:45 GMT
Subject: RFR: 8311815: Incorrect exhaustivity computation [v3]
In-Reply-To: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
References: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
Message-ID: <00XqMalgn4eiFLbK-kd22vNw5SigwD0vqH826YRJ_1g=.a94566ae-4c80-4e39-b94f-2eaac7127188@github.com>

> Consider code like:
> 
> class Test22 {
> 
>   record Pair(I i1, I i2) {}
> 
>   sealed interface I {}
> 
>   record C() implements I {}
> 
>   record D() implements I {}
> 
>   void exhaustinvenessWithInterface(Pair pairI) {
>     switch (pairI) {
>       case Pair(D fst, C snd) -> {}
>       case Pair(C fst, C snd) -> {}
>       case Pair(C fst, I snd) -> {}
>       case Pair(D fst, D snd) -> {}
>     }
>   }
> } 
> 
> 
> when evaluating exhaustivity, the outcome is wrong: if `Pair(D fst, C snd)` and `Pair(C fst, C snd)` get merged into `Pair(I _, C_)` (and the existing patterns are removed from the pattern set), the remaining patterns are `Pair(I _, C_)`, `Pair(C fst, I snd)` and `Pair(D fst, D snd)`. The existing implementation does not know how to continue from here (it would need to replace `Pair(C fst, I snd)` with `Pair(C fst, D snd)`, which would allow to unify `Pair(C fst, D snd)` and `Pair(D fst, D snd)` into `Pair(I _, D _)` and then continue, but that is tricky, as such speculation may not lead to a good result, and we would need to implement backtracking).
> 
> But, if `Pair(D fst, C snd)` and `Pair(D fst, D snd)` was merged into `Pair(D _, I _)`, it could then be merge with `Pair(C fst, I snd)` to produce `Pair(I _, I _)`.
> 
> The proposal here is aiming to allow the second path, by not removing the existing patterns when merging sealed subtypes. I.e. starting with `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _)}`, we would merge to `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), *Pair(I _, C_)*}`, and then `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), Pair(I _, C_), *Pair(D _, I _)*}`, which would then lead to `Pair(I _, I _)`, leading to `Pair` and confirmed exhaustivity.
> 
> This can be achieved easily by not removing binding in `reduceBindingPatterns`. The problem is that when we stop removing bindings, the algorithm may get into an infinite loop re-adding the same binding over and over. The solution to that is using Sets instead of Lists. To make the algorithm faster and more stable, there are two more additions: a) all record patterns covered by binding patterns are removed from the pattern set; b) `reduceNestedPatterns` attempts to produce results for all mismatching positions without returning (otherwise the algorithm may constantly only process the first mismatching position without progressing).

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

  Removing debug code.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14872/files
  - new: https://git.openjdk.org/jdk/pull/14872/files/1f5c1735..e7172838

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

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

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

From jlahoda at openjdk.org  Mon Jul 17 06:46:19 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 17 Jul 2023 06:46:19 GMT
Subject: Integrated: 8312093: Incorrect javadoc comment text
In-Reply-To: <SYQjvCeMiRAl3bpuA6Z_GY_w5umjHSk6tRtWU6fp5wE=.86047eeb-5e1c-4d1f-bbec-ea9c6f337bf1@github.com>
References: <SYQjvCeMiRAl3bpuA6Z_GY_w5umjHSk6tRtWU6fp5wE=.86047eeb-5e1c-4d1f-bbec-ea9c6f337bf1@github.com>
Message-ID: <zNH9xDHSCBDZB1Jlp0P3bEskn1lyTbC-cX6ueMYYfb4=.4ec9b900-649f-4591-8f3e-bcf25d175cbb@github.com>

On Fri, 14 Jul 2023 15:00:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a javadoc comment like:
> 
> public class Test {
>     /***/
>     void main() {
>     }
> }
> 
> 
> The doc comment's String for the javadoc comment will be "`/`", which is wrong. The reason is that the third '*' is ignored, and the closing '/' is used as the content of the comment.
> 
> The proposed solution is to tweak the parser to properly handle the closing '*/' in this case.

This pull request has now been integrated.

Changeset: 1c9691b1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c9691b1f762812aa090b88507d60a2e2e5f4933
Stats:     33 lines in 2 files changed: 31 ins; 0 del; 2 mod

8312093: Incorrect javadoc comment text

Reviewed-by: jlaskey

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

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

From jlahoda at openjdk.org  Mon Jul 17 08:23:20 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 17 Jul 2023 08:23:20 GMT
Subject: Integrated: 8311815: Incorrect exhaustivity computation
In-Reply-To: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
References: <KVhKwlt1nfi7u5a3iQzBftcgwW6310ZBy8U_BbTO4Yc=.3d08eb22-5001-4cba-aeeb-450b9ac7c0bc@github.com>
Message-ID: <OkpSsNmPnzszH5TyTdBiZd4x1pkyMZyEGOwYkfPL2aA=.701f2b2e-82d6-408a-b78a-a294709b574d@github.com>

On Thu, 13 Jul 2023 15:22:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> class Test22 {
> 
>   record Pair(I i1, I i2) {}
> 
>   sealed interface I {}
> 
>   record C() implements I {}
> 
>   record D() implements I {}
> 
>   void exhaustinvenessWithInterface(Pair pairI) {
>     switch (pairI) {
>       case Pair(D fst, C snd) -> {}
>       case Pair(C fst, C snd) -> {}
>       case Pair(C fst, I snd) -> {}
>       case Pair(D fst, D snd) -> {}
>     }
>   }
> } 
> 
> 
> when evaluating exhaustivity, the outcome is wrong: if `Pair(D fst, C snd)` and `Pair(C fst, C snd)` get merged into `Pair(I _, C_)` (and the existing patterns are removed from the pattern set), the remaining patterns are `Pair(I _, C_)`, `Pair(C fst, I snd)` and `Pair(D fst, D snd)`. The existing implementation does not know how to continue from here (it would need to replace `Pair(C fst, I snd)` with `Pair(C fst, D snd)`, which would allow to unify `Pair(C fst, D snd)` and `Pair(D fst, D snd)` into `Pair(I _, D _)` and then continue, but that is tricky, as such speculation may not lead to a good result, and we would need to implement backtracking).
> 
> But, if `Pair(D fst, C snd)` and `Pair(D fst, D snd)` was merged into `Pair(D _, I _)`, it could then be merge with `Pair(C fst, I snd)` to produce `Pair(I _, I _)`.
> 
> The proposal here is aiming to allow the second path, by not removing the existing patterns when merging sealed subtypes. I.e. starting with `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _)}`, we would merge to `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), *Pair(I _, C_)*}`, and then `{Pair(D _, C _), Pair(C _, C_), Pair(C _, I _), Pair(D _, D _), Pair(I _, C_), *Pair(D _, I _)*}`, which would then lead to `Pair(I _, I _)`, leading to `Pair` and confirmed exhaustivity.
> 
> This can be achieved easily by not removing binding in `reduceBindingPatterns`. The problem is that when we stop removing bindings, the algorithm may get into an infinite loop re-adding the same binding over and over. The solution to that is using Sets instead of Lists. To make the algorithm faster and more stable, there are two more additions: a) all record patterns covered by binding patterns are removed from the pattern set; b) `reduceNestedPatterns` attempts to produce results for all mismatching positions without returning (otherwise the algorithm may constantly only process the first mismatching position without progressing).

This pull request has now been integrated.

Changeset: a4412166
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a4412166ec8526db5e5e8e1ca324f86124055b30
Stats:     102 lines in 2 files changed: 55 ins; 24 del; 23 mod

8311815: Incorrect exhaustivity computation

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Mon Jul 17 09:46:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 17 Jul 2023 09:46:41 GMT
Subject: [jdk21] RFR: 8312093: Incorrect javadoc comment text
Message-ID: <3rmfhnK-0mMy7hsV6Oa2T7nfdnxEqiTo3CxenF82DHU=.45e29541-c543-4cea-bf40-c25034157ea8@github.com>

A backport of:
https://github.com/openjdk/jdk/pull/14890

that has been previously pushed into the JDK mainline. Conflicts in tests were manually resolved.

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

Commit messages:
 - Backport 1c9691b1f762812aa090b88507d60a2e2e5f4933

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

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

From asotona at openjdk.org  Mon Jul 17 13:32:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jul 2023 13:32:48 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v10]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <warwY6Uc-k1ldxms-yVB6R8gbOb8SVwwIClAYglGfoI=.cb2c1dc2-a4f1-498a-98c6-dd2e6b47cef0@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 226 commits:

 - Merge branch 'master' into JDK-8294969-javap
 - fixed code printing and ConstantPoolException reporting indoex
 - added DydnamicConstantPoolEntry::bootstrapMethodIndex
   fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
 - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
 - throwing ConstantPoolException for invalid BSM entry index
 - Merge branch 'master' into JDK-8294969-javap
 - fixed JavapTask
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
 - fixed build
 - ... and 216 more: https://git.openjdk.org/jdk/compare/3fb9d117...b63758dd

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=09
  Stats: 3830 lines in 29 files changed: 1001 ins; 1701 del; 1128 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From jlaskey at openjdk.org  Mon Jul 17 16:04:22 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 17 Jul 2023 16:04:22 GMT
Subject: [jdk21] RFR: 8312093: Incorrect javadoc comment text
In-Reply-To: <3rmfhnK-0mMy7hsV6Oa2T7nfdnxEqiTo3CxenF82DHU=.45e29541-c543-4cea-bf40-c25034157ea8@github.com>
References: <3rmfhnK-0mMy7hsV6Oa2T7nfdnxEqiTo3CxenF82DHU=.45e29541-c543-4cea-bf40-c25034157ea8@github.com>
Message-ID: <NHm8oZCPeRIrKDxBimZgjoYCRhOqNYgH_rqp9Bjdyyo=.1a1a874c-b7d9-4b75-8adb-621d1b71f2a6@github.com>

On Mon, 17 Jul 2023 09:38:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A backport of:
> https://github.com/openjdk/jdk/pull/14890
> 
> that has been previously pushed into the JDK mainline. Conflicts in tests were manually resolved.

Marked as reviewed by jlaskey (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/132#pullrequestreview-1533141705

From iris at openjdk.org  Mon Jul 17 16:14:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 17 Jul 2023 16:14:21 GMT
Subject: [jdk21] RFR: 8312093: Incorrect javadoc comment text
In-Reply-To: <3rmfhnK-0mMy7hsV6Oa2T7nfdnxEqiTo3CxenF82DHU=.45e29541-c543-4cea-bf40-c25034157ea8@github.com>
References: <3rmfhnK-0mMy7hsV6Oa2T7nfdnxEqiTo3CxenF82DHU=.45e29541-c543-4cea-bf40-c25034157ea8@github.com>
Message-ID: <5v7QDy7NFlqwb7Kc3muAf1Gs-BtRCh66GSp8k_SjIdI=.b852cb95-dd05-48d9-890a-939956ef7939@github.com>

On Mon, 17 Jul 2023 09:38:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A backport of:
> https://github.com/openjdk/jdk/pull/14890
> 
> that has been previously pushed into the JDK mainline. Conflicts in tests were manually resolved.

Same as 22, as expected.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/132#pullrequestreview-1533158998

From rriggs at openjdk.org  Mon Jul 17 16:47:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Jul 2023 16:47:57 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v4]
In-Reply-To: <DFWyQbSsvizvD7sMKdigdbeLpfpVeH8Fw0rtlcWXUaA=.9c194332-6e1d-4a1f-975f-39e8e5a65e1e@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
 <DFWyQbSsvizvD7sMKdigdbeLpfpVeH8Fw0rtlcWXUaA=.9c194332-6e1d-4a1f-975f-39e8e5a65e1e@github.com>
Message-ID: <EUkmuw1E0alvRb4NUzAmDE3NJzu_ylT4QTafWPWkVRk=.a8dfc7c0-aaeb-4496-a8ba-0520bd728fa8@github.com>

On Sat, 15 Jul 2023 02:05:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve serial lint messages for externalizable records (and potentially other situations).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor Externalizable check.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14639#pullrequestreview-1533223336

From rriggs at openjdk.org  Mon Jul 17 16:48:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Jul 2023 16:48:01 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v3]
In-Reply-To: <emdS0htKF4_mpW6gV65e2K7UxOjbMqsRuzXgr2AaBxs=.628974b2-11fd-4431-82b9-dbea68a1bc97@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
 <emdS0htKF4_mpW6gV65e2K7UxOjbMqsRuzXgr2AaBxs=.628974b2-11fd-4431-82b9-dbea68a1bc97@github.com>
Message-ID: <9U-qQIwHPwptYXRXYUyqvwU5Qtm2CN6NJy_lFkufo9c=.3135a2ce-154f-4e9a-a01a-0b666cceb54d@github.com>

On Fri, 14 Jul 2023 23:37:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve serial lint messages for externalizable records (and potentially other situations).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for externalizable enum checks.

test/langtools/tools/javac/warnings/Serial/EnumSerial.java line 5:

> 3:  * @bug 8202056
> 4:  * @compile/ref=EnumSerial.out -XDrawDiagnostics -Xlint:serial EnumSerial.java
> 5:  * @compile/ref=empty.out      -XDrawDiagnostics               EnumSerial.java

extra spaces snuck in

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14639#discussion_r1265635307

From darcy at openjdk.org  Mon Jul 17 16:54:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Jul 2023 16:54:05 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v3]
In-Reply-To: <9U-qQIwHPwptYXRXYUyqvwU5Qtm2CN6NJy_lFkufo9c=.3135a2ce-154f-4e9a-a01a-0b666cceb54d@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
 <emdS0htKF4_mpW6gV65e2K7UxOjbMqsRuzXgr2AaBxs=.628974b2-11fd-4431-82b9-dbea68a1bc97@github.com>
 <9U-qQIwHPwptYXRXYUyqvwU5Qtm2CN6NJy_lFkufo9c=.3135a2ce-154f-4e9a-a01a-0b666cceb54d@github.com>
Message-ID: <1K8eXLokWQ4HEXeDSGA4aR1aBrrYyjP15KFNXSAw_JQ=.e1d13e36-2450-48f7-836b-45caef3a3952@github.com>

On Mon, 17 Jul 2023 16:42:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> extra spaces snuck in

I added the extra spaces to align the argument on the second `@compile` line with the corresponding arguments on the first line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14639#discussion_r1265644167

From abimpoudis at openjdk.org  Mon Jul 17 22:04:35 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 17 Jul 2023 22:04:35 GMT
Subject: RFR: 8312163: Crash in dominance check when compiling unnamed patterns
Message-ID: <eFXEH1-8h9Ta2HcQMPkkn0PONfEgR_3vfBxCSxahPKA=.4f4f9700-bb52-4a58-a960-987475311b7b@github.com>

The following fixes a crash in dominance checking involving unnamed patterns by teaching the method `patternDominated` how to handle `AnyPattern` nodes. The test file includes snippets with `_` that need to expose the same behavior as if `var _` was used in all nested positions in place of just `_`.

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

Commit messages:
 - 8312163: Crash in dominance check when compiling unnamed patterns

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

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

From jlahoda at openjdk.org  Tue Jul 18 04:52:52 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Jul 2023 04:52:52 GMT
Subject: RFR: 8312163: Crash in dominance check when compiling unnamed
 patterns
In-Reply-To: <eFXEH1-8h9Ta2HcQMPkkn0PONfEgR_3vfBxCSxahPKA=.4f4f9700-bb52-4a58-a960-987475311b7b@github.com>
References: <eFXEH1-8h9Ta2HcQMPkkn0PONfEgR_3vfBxCSxahPKA=.4f4f9700-bb52-4a58-a960-987475311b7b@github.com>
Message-ID: <biB5d71BENPzxNqtDd_--IZspUBFnw052rCd8bJCPUY=.d3554c18-9660-4049-9676-e9660dc8e234@github.com>

On Mon, 17 Jul 2023 21:57:07 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The following fixes a crash in dominance checking involving unnamed patterns by teaching the method `patternDominated` how to handle `AnyPattern` nodes. The test file includes snippets with `_` that need to expose the same behavior as if `var _` was used in all nested positions in place of just `_`.

Looks reasonable to me.

Could be made more compact by using this:

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 57061d38dd8..e6de3f574b3 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
@@ -4733,10 +4733,13 @@ public class Check {
                     return false;
                 }
             }
-            if (currentPattern instanceof JCBindingPattern) {
-                return existingPattern instanceof JCBindingPattern;
+            if (currentPattern instanceof JCBindingPattern ||
+                currentPattern instanceof JCAnyPattern) {
+                return existingPattern instanceof JCBindingPattern ||
+                       existingPattern instanceof JCAnyPattern;
             } else if (currentPattern instanceof JCRecordPattern currentRecordPattern) {
-                if (existingPattern instanceof JCBindingPattern) {
+                if (existingPattern instanceof JCBindingPattern ||
+                    existingPattern instanceof JCAnyPattern) {
                     return true;
                 } else if (existingPattern instanceof JCRecordPattern existingRecordPattern) {
                     List<JCPattern> existingNested = existingRecordPattern.nested;


in `Check.java`.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14912#pullrequestreview-1534166293

From abimpoudis at openjdk.org  Tue Jul 18 07:49:30 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 18 Jul 2023 07:49:30 GMT
Subject: RFR: 8312163: Crash in dominance check when compiling unnamed
 patterns [v2]
In-Reply-To: <eFXEH1-8h9Ta2HcQMPkkn0PONfEgR_3vfBxCSxahPKA=.4f4f9700-bb52-4a58-a960-987475311b7b@github.com>
References: <eFXEH1-8h9Ta2HcQMPkkn0PONfEgR_3vfBxCSxahPKA=.4f4f9700-bb52-4a58-a960-987475311b7b@github.com>
Message-ID: <xZT3ZMErsOP46aPs0cGMJObx4hBSihq5Q5uftAG-SHY=.b9dbddd6-d7e9-474d-8feb-7f110547b3fc@github.com>

> The following fixes a crash in dominance checking involving unnamed patterns by teaching the method `patternDominated` how to handle `AnyPattern` nodes. The test file includes snippets with `_` that need to expose the same behavior as if `var _` was used in all nested positions in place of just `_`.

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

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14912/files
  - new: https://git.openjdk.org/jdk/pull/14912/files/c8b6c196..a250ead5

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

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

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

From jlahoda at openjdk.org  Tue Jul 18 08:25:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Jul 2023 08:25:18 GMT
Subject: [jdk21] Integrated: 8312093: Incorrect javadoc comment text
In-Reply-To: <3rmfhnK-0mMy7hsV6Oa2T7nfdnxEqiTo3CxenF82DHU=.45e29541-c543-4cea-bf40-c25034157ea8@github.com>
References: <3rmfhnK-0mMy7hsV6Oa2T7nfdnxEqiTo3CxenF82DHU=.45e29541-c543-4cea-bf40-c25034157ea8@github.com>
Message-ID: <7USw0ifKMlDH6VYqX-IZoGB0NrgjQE9zx44mNK3zNjs=.8e0af85d-c9db-4153-8b26-8e22e6b74895@github.com>

On Mon, 17 Jul 2023 09:38:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A backport of:
> https://github.com/openjdk/jdk/pull/14890
> 
> that has been previously pushed into the JDK mainline. Conflicts in tests were manually resolved.

This pull request has now been integrated.

Changeset: a08c6b9b
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a08c6b9b2e709691ed2a5fd8c540dfa389a3e473
Stats:     33 lines in 2 files changed: 31 ins; 0 del; 2 mod

8312093: Incorrect javadoc comment text

Reviewed-by: jlaskey, iris
Backport-of: 1c9691b1f762812aa090b88507d60a2e2e5f4933

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

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

From jlahoda at openjdk.org  Tue Jul 18 08:26:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Jul 2023 08:26:24 GMT
Subject: [jdk21] Integrated: 8311825: Duplicate qualified enum constants not
 detected
In-Reply-To: <7ieBH12DWildK4Soy2zPcBDbOBxmM4HiEpqyPNau8Jg=.3e52c473-b766-47bd-b7df-2b83f74e7137@github.com>
References: <7ieBH12DWildK4Soy2zPcBDbOBxmM4HiEpqyPNau8Jg=.3e52c473-b766-47bd-b7df-2b83f74e7137@github.com>
Message-ID: <5THJPXIDIC_IrQglrw7wGc6X-5V8LZcAZhQDK2MyX7Y=.dc30237e-2010-4b2e-b54f-eb55e0335e49@github.com>

On Fri, 14 Jul 2023 09:58:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: b6827ff3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/b6827ff331b8a6ce89e50446788b1fcc626f4d92
Stats:     33 lines in 3 files changed: 31 ins; 0 del; 2 mod

8311825: Duplicate qualified enum constants not detected

Reviewed-by: vromero
Backport-of: d1fa1a868636dc15e96d1b4bf4acf28257c9551f

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

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

From abimpoudis at openjdk.org  Tue Jul 18 11:45:34 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 18 Jul 2023 11:45:34 GMT
Subject: Integrated: 8312163: Crash in dominance check when compiling unnamed
 patterns
In-Reply-To: <eFXEH1-8h9Ta2HcQMPkkn0PONfEgR_3vfBxCSxahPKA=.4f4f9700-bb52-4a58-a960-987475311b7b@github.com>
References: <eFXEH1-8h9Ta2HcQMPkkn0PONfEgR_3vfBxCSxahPKA=.4f4f9700-bb52-4a58-a960-987475311b7b@github.com>
Message-ID: <nf1GyS6q9BGdu344G8thg29DklvI8GYyw10jMNvg484=.a6057b42-eace-4574-92bf-40e259de57b2@github.com>

On Mon, 17 Jul 2023 21:57:07 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The following fixes a crash in dominance checking involving unnamed patterns by teaching the method `patternDominated` how to handle `AnyPattern` nodes. The test file includes snippets with `_` that need to expose the same behavior as if `var _` was used in all nested positions in place of just `_`.

This pull request has now been integrated.

Changeset: 1fc726a8
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1fc726a8b34fcd41dae12a6d7c63232f9ccef3f4
Stats:     73 lines in 4 files changed: 70 ins; 0 del; 3 mod

8312163: Crash in dominance check when compiling unnamed patterns

Reviewed-by: jlahoda

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

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

From abimpoudis at openjdk.org  Tue Jul 18 12:15:26 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 18 Jul 2023 12:15:26 GMT
Subject: [jdk21] RFR: 8312163: Crash in dominance check when compiling unnamed
 patterns
Message-ID: <PKFl9i2LhgT7ZRHGLeKWI42OaG4k9yUoZu9oa5jrA3E=.e90ff7d1-9428-4cd3-8d72-ea6bb1e0dbfc@github.com>

8312163: Crash in dominance check when compiling unnamed patterns

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

Commit messages:
 - Backport 1fc726a8b34fcd41dae12a6d7c63232f9ccef3f4

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

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

From jlahoda at openjdk.org  Tue Jul 18 13:34:20 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Jul 2023 13:34:20 GMT
Subject: [jdk21] RFR: 8312163: Crash in dominance check when compiling
 unnamed patterns
In-Reply-To: <PKFl9i2LhgT7ZRHGLeKWI42OaG4k9yUoZu9oa5jrA3E=.e90ff7d1-9428-4cd3-8d72-ea6bb1e0dbfc@github.com>
References: <PKFl9i2LhgT7ZRHGLeKWI42OaG4k9yUoZu9oa5jrA3E=.e90ff7d1-9428-4cd3-8d72-ea6bb1e0dbfc@github.com>
Message-ID: <N2Iac8kZk-robr3FubtC-kvuoIfJDqfUbrw8lG90dsM=.5943d3a8-d18c-4392-9600-5846a95146c8@github.com>

On Tue, 18 Jul 2023 12:07:18 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> 8312163: Crash in dominance check when compiling unnamed patterns

Looks good.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/134#pullrequestreview-1535048221

From vromero at openjdk.org  Tue Jul 18 16:28:16 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 18 Jul 2023 16:28:16 GMT
Subject: [jdk21] RFR: 8311038: Incorrect exhaustivity computation
In-Reply-To: <FlQZdWaGQbJaCfcAG6P0R3gbS3ugYBhRXmA1pDrRSCw=.2913787f-aea6-4713-a223-876aab24aaeb@github.com>
References: <FlQZdWaGQbJaCfcAG6P0R3gbS3ugYBhRXmA1pDrRSCw=.2913787f-aea6-4713-a223-876aab24aaeb@github.com>
Message-ID: <XiskSVRdT0b_lsKo_S5mjQfT4rhcbWKDzPTXnACdTl4=.c5603664-f2bd-4e90-bcf7-b7a8f79568e0@github.com>

On Fri, 14 Jul 2023 09:57:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/127#pullrequestreview-1535446084

From jjg at openjdk.org  Tue Jul 18 17:36:32 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 18 Jul 2023 17:36:32 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v4]
In-Reply-To: <DFWyQbSsvizvD7sMKdigdbeLpfpVeH8Fw0rtlcWXUaA=.9c194332-6e1d-4a1f-975f-39e8e5a65e1e@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
 <DFWyQbSsvizvD7sMKdigdbeLpfpVeH8Fw0rtlcWXUaA=.9c194332-6e1d-4a1f-975f-39e8e5a65e1e@github.com>
Message-ID: <6Qx_H8gBCU5a8qppu-Pms0nNpc1I9Mk0m6bbFfyOD7c=.1f141755-6818-4707-8ec1-f1e758a57670@github.com>

On Sat, 15 Jul 2023 02:05:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve serial lint messages for externalizable records (and potentially other situations).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor Externalizable check.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14639#pullrequestreview-1535589080

From jlahoda at openjdk.org  Tue Jul 18 17:53:43 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Jul 2023 17:53:43 GMT
Subject: [jdk21] Integrated: 8311038: Incorrect exhaustivity computation
In-Reply-To: <FlQZdWaGQbJaCfcAG6P0R3gbS3ugYBhRXmA1pDrRSCw=.2913787f-aea6-4713-a223-876aab24aaeb@github.com>
References: <FlQZdWaGQbJaCfcAG6P0R3gbS3ugYBhRXmA1pDrRSCw=.2913787f-aea6-4713-a223-876aab24aaeb@github.com>
Message-ID: <WP3pnBqzyngz9nWJqBl6m889CR2Fz1ngJQuXS9YAnpI=.71154039-a78a-4638-9fa2-09c81d7624fa@github.com>

On Fri, 14 Jul 2023 09:57:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 7a5d6f90
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/7a5d6f90f0ed5cc299ec54255368f12c141fc2fe
Stats:     28 lines in 2 files changed: 26 ins; 0 del; 2 mod

8311038: Incorrect exhaustivity computation

Reviewed-by: vromero
Backport-of: bbb7ce5137cd3e8365552b42610e19b7ebe43ba1

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

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

From jlahoda at openjdk.org  Tue Jul 18 18:33:03 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Jul 2023 18:33:03 GMT
Subject: [jdk21] RFR: 8311815: Incorrect exhaustivity computation
Message-ID: <eXfnGrFJSwC4qQYF33mHd47P_LY9Z4GrYv1tT47RLcg=.856c138b-f049-4859-9511-f9de6c647d5c@github.com>

Hi all,

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

The commit being backported was authored by Jan Lahoda on 17 Jul 2023 and was reviewed by Vicente Romero.

Thanks!

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

Commit messages:
 - Backport a4412166ec8526db5e5e8e1ca324f86124055b30

Changes: https://git.openjdk.org/jdk21/pull/138/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=138&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311815
  Stats: 102 lines in 2 files changed: 55 ins; 24 del; 23 mod
  Patch: https://git.openjdk.org/jdk21/pull/138.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/138/head:pull/138

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

From vromero at openjdk.org  Tue Jul 18 18:53:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 18 Jul 2023 18:53:49 GMT
Subject: [jdk21] RFR: 8311815: Incorrect exhaustivity computation
In-Reply-To: <eXfnGrFJSwC4qQYF33mHd47P_LY9Z4GrYv1tT47RLcg=.856c138b-f049-4859-9511-f9de6c647d5c@github.com>
References: <eXfnGrFJSwC4qQYF33mHd47P_LY9Z4GrYv1tT47RLcg=.856c138b-f049-4859-9511-f9de6c647d5c@github.com>
Message-ID: <ABiKLd-AFl9eZpF616XcW5awK4FRKVlAjRFomCwvlLM=.2fcbd6e1-e641-4c08-b451-2436bfe1db10@github.com>

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

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

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/138#pullrequestreview-1535703350

From rgiulietti at openjdk.org  Tue Jul 18 22:01:45 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 18 Jul 2023 22:01:45 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v4]
In-Reply-To: <DFWyQbSsvizvD7sMKdigdbeLpfpVeH8Fw0rtlcWXUaA=.9c194332-6e1d-4a1f-975f-39e8e5a65e1e@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
 <DFWyQbSsvizvD7sMKdigdbeLpfpVeH8Fw0rtlcWXUaA=.9c194332-6e1d-4a1f-975f-39e8e5a65e1e@github.com>
Message-ID: <mqdA_XPvwCsovnWlEAC3cf0Yv7WXFbpB2Z5abyNc0L4=.12fcb658-5684-4561-a46b-4cadc86206fb@github.com>

On Sat, 15 Jul 2023 02:05:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Improve serial lint messages for externalizable records (and potentially other situations).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor Externalizable check.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5218:

> 5216: 
> 5217:                         if (isExtern && externMethodNames.contains(name)) {
> 5218:                             log.warning(LintCategory.SERIAL,

The check for an enum class seems less specific than for record classes, where not only the name but also the flags, return and parameter types are checked.
But for enum classes this also holds for other methods and fields, so it might be a deliberate choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14639#discussion_r1267341421

From abimpoudis at openjdk.org  Wed Jul 19 07:40:57 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 19 Jul 2023 07:40:57 GMT
Subject: [jdk21] Integrated: 8312163: Crash in dominance check when compiling
 unnamed patterns
In-Reply-To: <PKFl9i2LhgT7ZRHGLeKWI42OaG4k9yUoZu9oa5jrA3E=.e90ff7d1-9428-4cd3-8d72-ea6bb1e0dbfc@github.com>
References: <PKFl9i2LhgT7ZRHGLeKWI42OaG4k9yUoZu9oa5jrA3E=.e90ff7d1-9428-4cd3-8d72-ea6bb1e0dbfc@github.com>
Message-ID: <PNi8TpHjbKL6_7o3taeIQMPtiJExru8Q_ClODoH21tk=.d4456383-590e-4cbf-95b9-d4ef027b19b3@github.com>

On Tue, 18 Jul 2023 12:07:18 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> 8312163: Crash in dominance check when compiling unnamed patterns

This pull request has now been integrated.

Changeset: 48760d7a
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/48760d7a044560dea6eeaca675ed27b5096cadd8
Stats:     73 lines in 4 files changed: 70 ins; 0 del; 3 mod

8312163: Crash in dominance check when compiling unnamed patterns

Reviewed-by: jlahoda
Backport-of: 1fc726a8b34fcd41dae12a6d7c63232f9ccef3f4

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

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

From jlahoda at openjdk.org  Wed Jul 19 08:50:51 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 19 Jul 2023 08:50:51 GMT
Subject: [jdk21] Integrated: 8311815: Incorrect exhaustivity computation
In-Reply-To: <eXfnGrFJSwC4qQYF33mHd47P_LY9Z4GrYv1tT47RLcg=.856c138b-f049-4859-9511-f9de6c647d5c@github.com>
References: <eXfnGrFJSwC4qQYF33mHd47P_LY9Z4GrYv1tT47RLcg=.856c138b-f049-4859-9511-f9de6c647d5c@github.com>
Message-ID: <tKbR2wz8cFSom2vIHzclOEFXbBe8n6q7RxgGGW9Afo8=.f96d6917-5781-4ed0-be3c-06d927981bfe@github.com>

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

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

This pull request has now been integrated.

Changeset: 6d9da7ce
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6d9da7ce6291658ac8025ef7a297e335d49d43b5
Stats:     102 lines in 2 files changed: 55 ins; 24 del; 23 mod

8311815: Incorrect exhaustivity computation

Reviewed-by: vromero
Backport-of: a4412166ec8526db5e5e8e1ca324f86124055b30

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

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

From jlahoda at openjdk.org  Wed Jul 19 10:51:00 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 19 Jul 2023 10:51:00 GMT
Subject: RFR: 8312229: Crash involving yield, switch and anonymous classes
Message-ID: <3IBcWPyTRIAEtTaY2vqKA-TCrcePHVJoetOemQj2BMg=.8960e0d0-e0b1-4b5d-9c05-7242d552cdf7@github.com>

Consider code like:

    void test(Object o) {
        Runnable r = () -> {
            switch (o) {
                default -> {
                    Integer i = 42;
                    new Runnable() {
                        public void run() {
                            i.toString();
                        }
                    };
                }
            };
        };
    }


During `LambdaToMethod`, the `i` variable is seen as a local variable in the lambda, and re-written to a different variable inside the new lambda method. This is due to:
https://github.com/openjdk/jdk/blob/d33e8e6f93d7b0806e1d0087c3c0a11fe1bc8e21/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#L1573

note the lambda frame is the topmost frame in this case.

But, if the code is altered to:

    void test(Object o) {
        Runnable r = () -> {
            var l = switch (o) {
                default -> {
                    Integer i = 42;
                    yield new Runnable() {
                        public void run() {
                            i.toString();
                        }
                    };
                }
            };
        };
    }


the topmost frame will not be the lambda frame, but rather a variable frame, so that the `i` variable is not seem as a lambda-local variable, and the translations eventually fail.

The proposed solution is to search for the lambda frame, ignoring intervening variable frames.

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

Commit messages:
 - 8312229: Crash involving yield, switch and anonymous classes

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

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

From darcy at openjdk.org  Wed Jul 19 19:53:27 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Jul 2023 19:53:27 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v5]
In-Reply-To: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
Message-ID: <GGoa7ql7WGXFoik95u-QPcUxZvYvhTB6ZJW4YdJMLrk=.2fecd736-dada-4daa-b840-895aa70fb0bf@github.com>

> Improve serial lint messages for externalizable records (and potentially other situations).

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Respond to review feedback; make messages for enum externalizable methods more precise.
 - Merge branch 'master' into JDK-8310835
 - Refactor Externalizable check.
 - Add support for externalizable enum checks.
 - Fix typo found in code review.
 - Merge branch 'master' into JDK-8310835
 - Refactor implementation and add test.
 - Remove unused method.
 - Merge branch 'master' into JDK-8310835
 - Fix method call.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/b5b6f4e7...2c90546a

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

Changes: https://git.openjdk.org/jdk/pull/14639/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14639&range=04
  Stats: 322 lines in 10 files changed: 306 ins; 9 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14639/head:pull/14639

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

From darcy at openjdk.org  Wed Jul 19 19:53:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Jul 2023 19:53:30 GMT
Subject: RFR: JDK-8310835: Address gaps in -Xlint:serial checks [v4]
In-Reply-To: <mqdA_XPvwCsovnWlEAC3cf0Yv7WXFbpB2Z5abyNc0L4=.12fcb658-5684-4561-a46b-4cadc86206fb@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
 <DFWyQbSsvizvD7sMKdigdbeLpfpVeH8Fw0rtlcWXUaA=.9c194332-6e1d-4a1f-975f-39e8e5a65e1e@github.com>
 <mqdA_XPvwCsovnWlEAC3cf0Yv7WXFbpB2Z5abyNc0L4=.12fcb658-5684-4561-a46b-4cadc86206fb@github.com>
Message-ID: <WEmqM2WqRds9aBcGnd1167mgzUeknYsAmJOW9GwWOWM=.b2a7a903-92a7-443b-a194-3722a071c33e@github.com>

On Tue, 18 Jul 2023 21:58:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor Externalizable check.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5218:
> 
>> 5216: 
>> 5217:                         if (isExtern && externMethodNames.contains(name)) {
>> 5218:                             log.warning(LintCategory.SERIAL,
> 
> The check for an enum class seems less specific than for record classes, where not only the name but also the flags, return and parameter types are checked.
> But for enum classes this also holds for other methods and fields, so it might be a deliberate choice.

Good catch; addressed in subsequent push.

As follow-up work, I've filed JDK-8312415: "Expand -Xlint:serial checks to enum constants with specialized class bodies."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14639#discussion_r1268600875

From darcy at openjdk.org  Thu Jul 20 01:14:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 20 Jul 2023 01:14:07 GMT
Subject: Integrated: JDK-8310835: Address gaps in -Xlint:serial checks
In-Reply-To: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
References: <jfakJS01gpaLBrODUTg0CI4lzsKERGORFtpZ5KXWBmw=.ea221def-a085-4dd0-9e30-5db460c006e2@github.com>
Message-ID: <mhJ98rcid1TNDwjWk9BIxocqdgzyd4PvmbUR8b9gLI0=.b66e74a0-c628-4355-a1ed-5e2ee5ae48c0@github.com>

On Sat, 24 Jun 2023 22:27:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Improve serial lint messages for externalizable records (and potentially other situations).

This pull request has now been integrated.

Changeset: 61ab2708
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61ab27087e1dd6cd2b52c608c87fba4393a0e081
Stats:     322 lines in 10 files changed: 306 ins; 9 del; 7 mod

8310835: Address gaps in -Xlint:serial checks

Reviewed-by: rriggs, jjg

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

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

From asotona at openjdk.org  Thu Jul 20 09:11:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 20 Jul 2023 09:11:20 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:

 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
 - fixed code printing and ConstantPoolException reporting indoex
 - added DydnamicConstantPoolEntry::bootstrapMethodIndex
   fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
 - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
 - throwing ConstantPoolException for invalid BSM entry index
 - Merge branch 'master' into JDK-8294969-javap
 - fixed JavapTask
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
 - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=10
  Stats: 3830 lines in 29 files changed: 1001 ins; 1701 del; 1128 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From vromero at openjdk.org  Thu Jul 20 20:55:39 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Jul 2023 20:55:39 GMT
Subject: RFR: 8312229: Crash involving yield, switch and anonymous classes
In-Reply-To: <3IBcWPyTRIAEtTaY2vqKA-TCrcePHVJoetOemQj2BMg=.8960e0d0-e0b1-4b5d-9c05-7242d552cdf7@github.com>
References: <3IBcWPyTRIAEtTaY2vqKA-TCrcePHVJoetOemQj2BMg=.8960e0d0-e0b1-4b5d-9c05-7242d552cdf7@github.com>
Message-ID: <TE26rmNzsY2VrG59lnQ6GCTZDC-8XXs5AildUJhnst0=.20414a50-9e30-46bb-a31d-17f736645584@github.com>

On Wed, 19 Jul 2023 10:44:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
>     void test(Object o) {
>         Runnable r = () -> {
>             switch (o) {
>                 default -> {
>                     Integer i = 42;
>                     new Runnable() {
>                         public void run() {
>                             i.toString();
>                         }
>                     };
>                 }
>             };
>         };
>     }
> 
> 
> During `LambdaToMethod`, the `i` variable is seen as a local variable in the lambda, and re-written to a different variable inside the new lambda method. This is due to:
> https://github.com/openjdk/jdk/blob/d33e8e6f93d7b0806e1d0087c3c0a11fe1bc8e21/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#L1573
> 
> note the lambda frame is the topmost frame in this case.
> 
> But, if the code is altered to:
> 
>     void test(Object o) {
>         Runnable r = () -> {
>             var l = switch (o) {
>                 default -> {
>                     Integer i = 42;
>                     yield new Runnable() {
>                         public void run() {
>                             i.toString();
>                         }
>                     };
>                 }
>             };
>         };
>     }
> 
> 
> the topmost frame will not be the lambda frame, but rather a variable frame, so that the `i` variable is not seem as a lambda-local variable, and the translations eventually fail.
> 
> The proposed solution is to search for the lambda frame, ignoring intervening variable frames.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14930#pullrequestreview-1540071418

From darcy at openjdk.org  Mon Jul 24 19:38:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 24 Jul 2023 19:38:16 GMT
Subject: RFR: JDK-8312415: Expand -Xlint:serial checks to enum constants with
 specialized class bodies
Message-ID: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>

Thanks to @lahodaj for providing the code to bridge into the class used for a enum constant with a specialized body.

This changes expands serialization warnings to the contents of any such class bodies.

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

Commit messages:
 - Appease jcheck.
 - JDK-8312415: Expand -Xlint:serial checks to enum constants with specialized class bodies

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

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

From jjg at openjdk.org  Mon Jul 24 19:56:45 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Jul 2023 19:56:45 GMT
Subject: RFR: JDK-8312415: Expand -Xlint:serial checks to enum constants
 with specialized class bodies
In-Reply-To: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
References: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
Message-ID: <9sU-ZsuZh1ke2Q8o1wemcZ2bVNPyE2vIO0c-349Ewj4=.177aed12-66cd-40fd-8028-dd73319a6e29@github.com>

On Mon, 24 Jul 2023 19:15:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Thanks to @lahodaj for providing the code to bridge into the class used for a enum constant with a specialized body.
> 
> This changes expands serialization warnings to the contents of any such class bodies.

Approved, but see question for Check.java

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5219:

> 5217:                     case ENUM_CONSTANT -> {
> 5218:                         var field = (VarSymbol)enclosed;
> 5219:                         if (field.isEnum()) {

It's not wrong, but is this check redundant?  When can an `ENUM_CONSTANT` not be `isEnum()` ?

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15004#pullrequestreview-1544158757
PR Review Comment: https://git.openjdk.org/jdk/pull/15004#discussion_r1272687421

From jjg at openjdk.org  Mon Jul 24 20:03:44 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Jul 2023 20:03:44 GMT
Subject: RFR: JDK-8312415: Expand -Xlint:serial checks to enum constants
 with specialized class bodies
In-Reply-To: <9sU-ZsuZh1ke2Q8o1wemcZ2bVNPyE2vIO0c-349Ewj4=.177aed12-66cd-40fd-8028-dd73319a6e29@github.com>
References: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
 <9sU-ZsuZh1ke2Q8o1wemcZ2bVNPyE2vIO0c-349Ewj4=.177aed12-66cd-40fd-8028-dd73319a6e29@github.com>
Message-ID: <PcJsa3JURsPakynGVFl4mCL8Mr2Z92KfKjIL8rGzFOc=.8df5e9d0-18be-423e-aa15-d794fe16442e@github.com>

On Mon, 24 Jul 2023 19:53:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Thanks to @lahodaj for providing the code to bridge into the class used for a enum constant with a specialized body.
>> 
>> This changes expands serialization warnings to the contents of any such class bodies.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5219:
> 
>> 5217:                     case ENUM_CONSTANT -> {
>> 5218:                         var field = (VarSymbol)enclosed;
>> 5219:                         if (field.isEnum()) {
> 
> It's not wrong, but is this check redundant?  When can an `ENUM_CONSTANT` not be `isEnum()` ?

See these lines in `Symbol.java` `public ElementKind getKind()` line 1725:

            } else if ((flags & ENUM) != 0) {
                return ElementKind.ENUM_CONSTANT;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15004#discussion_r1272694387

From jlahoda at openjdk.org  Tue Jul 25 14:45:07 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Jul 2023 14:45:07 GMT
Subject: RFR: 8312619: Strange error message when switching over long
Message-ID: <E6HPpGIdbJ3Cis_lq4wRnnlTfV_4NNAqFmtxrrJ69ec=.f8963b12-51e7-4338-99b2-eb2471034dcc@github.com>

For code like:

public class SelectorTypeNotAllowed {
    private void noLong(long sel) {
        switch (sel) {
            case 0L -> {}
            default -> {}
        }
    }
}


which is invalid (due to the `long` selector) produces this compile-time error:

/tmp/SelectorTypeNotAllowed.java:4: error: constant label of type long is not compatible with switch selector type long
            case 0L -> {}
                 ^
1 error


This is a confusing error message. The proposal here is to change the error message to:

/tmp/SelectorTypeNotAllowed.java:3: error: selector type long is not allowed
        switch (sel) {
               ^
1 error

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

Commit messages:
 - 8312619: Strange error message when switching over long

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

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

From jlahoda at openjdk.org  Tue Jul 25 15:18:52 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Jul 2023 15:18:52 GMT
Subject: RFR: JDK-8312415: Expand -Xlint:serial checks to enum constants
 with specialized class bodies
In-Reply-To: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
References: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
Message-ID: <ogF4jsRAT4j_9GyfOfTxKAKEbNa2nDowI9kuNYii_Fs=.f1465041-b871-42bf-a7e8-a8927a5a31ac@github.com>

On Mon, 24 Jul 2023 19:15:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Thanks to @lahodaj for providing the code to bridge into the class used for a enum constant with a specialized body.
> 
> This changes expands serialization warnings to the contents of any such class bodies.

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15004#pullrequestreview-1545753903

From jlahoda at openjdk.org  Tue Jul 25 15:18:54 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Jul 2023 15:18:54 GMT
Subject: RFR: JDK-8312415: Expand -Xlint:serial checks to enum constants
 with specialized class bodies
In-Reply-To: <PcJsa3JURsPakynGVFl4mCL8Mr2Z92KfKjIL8rGzFOc=.8df5e9d0-18be-423e-aa15-d794fe16442e@github.com>
References: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
 <9sU-ZsuZh1ke2Q8o1wemcZ2bVNPyE2vIO0c-349Ewj4=.177aed12-66cd-40fd-8028-dd73319a6e29@github.com>
 <PcJsa3JURsPakynGVFl4mCL8Mr2Z92KfKjIL8rGzFOc=.8df5e9d0-18be-423e-aa15-d794fe16442e@github.com>
Message-ID: <H3M2WyDgxektcu3J6UXRYbEw-w7UxrBC91aRuXSRkp4=.d0429a3f-214f-40c4-906c-7c4f8bc84b04@github.com>

On Mon, 24 Jul 2023 20:00:54 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5219:
>> 
>>> 5217:                     case ENUM_CONSTANT -> {
>>> 5218:                         var field = (VarSymbol)enclosed;
>>> 5219:                         if (field.isEnum()) {
>> 
>> It's not wrong, but is this check redundant?  When can an `ENUM_CONSTANT` not be `isEnum()` ?
>
> See these lines in `Symbol.java` `public ElementKind getKind()` line 1725:
> 
>             } else if ((flags & ENUM) != 0) {
>                 return ElementKind.ENUM_CONSTANT;

Yes, sorry for that, I've originally had the code elsewhere. The `isEnum` check should not be needed here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15004#discussion_r1273710986

From vromero at openjdk.org  Tue Jul 25 16:21:41 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 25 Jul 2023 16:21:41 GMT
Subject: RFR: 8312619: Strange error message when switching over long
In-Reply-To: <E6HPpGIdbJ3Cis_lq4wRnnlTfV_4NNAqFmtxrrJ69ec=.f8963b12-51e7-4338-99b2-eb2471034dcc@github.com>
References: <E6HPpGIdbJ3Cis_lq4wRnnlTfV_4NNAqFmtxrrJ69ec=.f8963b12-51e7-4338-99b2-eb2471034dcc@github.com>
Message-ID: <85gH1f_qr-5gR7WBj8_XqhNGCdcs4WoEP0vLfGHV_Yo=.d5dc8d6f-bdda-4f58-b950-33e5cbc18821@github.com>

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

> For code like:
> 
> public class SelectorTypeNotAllowed {
>     private void noLong(long sel) {
>         switch (sel) {
>             case 0L -> {}
>             default -> {}
>         }
>     }
> }
> 
> 
> which is invalid (due to the `long` selector) produces this compile-time error:
> 
> /tmp/SelectorTypeNotAllowed.java:4: error: constant label of type long is not compatible with switch selector type long
>             case 0L -> {}
>                  ^
> 1 error
> 
> 
> This is a confusing error message. The proposal here is to change the error message to:
> 
> /tmp/SelectorTypeNotAllowed.java:3: error: selector type long is not allowed
>         switch (sel) {
>                ^
> 1 error

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15020#pullrequestreview-1545890747

From jlahoda at openjdk.org  Tue Jul 25 18:15:58 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Jul 2023 18:15:58 GMT
Subject: RFR: 8312984: javac may crash on a record pattern with too few
 components
Message-ID: <bynqITbAsz-MNULrzDftP5H0ZUEXgDG8GlX4uv_fDB8=.2a635116-a2bc-4691-a8c9-c1b8636fc2e2@github.com>

Processing code like:

public class Err {
    record R(String x) {}

    public void(Object obj) {
        switch(obj) {
            case R(var v, ) -> 1; //note the missing component/nested pattern
        }
    }
} 


may crash with an ArrayIndexOutOfBoundsException, because requesting component type for a non-existing component, while evaluating exhaustivity.

The proposal is to simply use `errType` for this case, to prevent the crash.

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

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

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

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

From darcy at openjdk.org  Tue Jul 25 18:58:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 25 Jul 2023 18:58:14 GMT
Subject: RFR: JDK-8312415: Expand -Xlint:serial checks to enum constants
 with specialized class bodies [v2]
In-Reply-To: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
References: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
Message-ID: <-X27QC5jZhWwspkJTnmAmlOlPP-YrJGXUtqpv8K2TYY=.1583f770-7d01-4d1f-8c18-be87faa2cf6e@github.com>

> Thanks to @lahodaj for providing the code to bridge into the class used for a enum constant with a specialized body.
> 
> This changes expands serialization warnings to the contents of any such class bodies.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15004/files
  - new: https://git.openjdk.org/jdk/pull/15004/files/d61f9114..d659d7f4

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

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

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

From darcy at openjdk.org  Tue Jul 25 18:58:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 25 Jul 2023 18:58:14 GMT
Subject: RFR: JDK-8312415: Expand -Xlint:serial checks to enum constants
 with specialized class bodies [v2]
In-Reply-To: <H3M2WyDgxektcu3J6UXRYbEw-w7UxrBC91aRuXSRkp4=.d0429a3f-214f-40c4-906c-7c4f8bc84b04@github.com>
References: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
 <9sU-ZsuZh1ke2Q8o1wemcZ2bVNPyE2vIO0c-349Ewj4=.177aed12-66cd-40fd-8028-dd73319a6e29@github.com>
 <PcJsa3JURsPakynGVFl4mCL8Mr2Z92KfKjIL8rGzFOc=.8df5e9d0-18be-423e-aa15-d794fe16442e@github.com>
 <H3M2WyDgxektcu3J6UXRYbEw-w7UxrBC91aRuXSRkp4=.d0429a3f-214f-40c4-906c-7c4f8bc84b04@github.com>
Message-ID: <_LPKD5vydu5Kvck0h8cbN-2LI3W20jqLjc7S51Ezzrw=.17a46c56-5c76-447a-8120-b8c1503ca15d@github.com>

On Tue, 25 Jul 2023 15:16:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> See these lines in `Symbol.java` `public ElementKind getKind()` line 1725:
>> 
>>             } else if ((flags & ENUM) != 0) {
>>                 return ElementKind.ENUM_CONSTANT;
>
> Yes, sorry for that, I've originally had the code elsewhere. The `isEnum` check should not be needed here.

Code updated; all langtools tests pas when run locally. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15004#discussion_r1273958967

From darcy at openjdk.org  Tue Jul 25 19:00:55 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 25 Jul 2023 19:00:55 GMT
Subject: Integrated: JDK-8312415: Expand -Xlint:serial checks to enum constants
 with specialized class bodies
In-Reply-To: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
References: <vcO16-Bd8MKb6GiGsSgUWy11mWx_mWQ_ZyDDMY3vgmE=.797f6414-5aef-401c-b74a-d5d0ddfc1d11@github.com>
Message-ID: <_psOE24ScKkNktgnPeDzFaHkoJmS-GNUoFwfCQeW_Zc=.d9c48686-2c65-4081-804f-e4a3b1f29908@github.com>

On Mon, 24 Jul 2023 19:15:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Thanks to @lahodaj for providing the code to bridge into the class used for a enum constant with a specialized body.
> 
> This changes expands serialization warnings to the contents of any such class bodies.

This pull request has now been integrated.

Changeset: cb82c954
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb82c954e3a37892ad504fcbb279bcf7619222dc
Stats:     144 lines in 3 files changed: 144 ins; 0 del; 0 mod

8312415: Expand -Xlint:serial checks to enum constants with specialized class bodies

Reviewed-by: jjg, jlahoda

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

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

From vromero at openjdk.org  Tue Jul 25 20:13:45 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 25 Jul 2023 20:13:45 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
Message-ID: <UNWy6unlW-QI1MnS31lizxTYWwdZQrhZ5UNsXxBZvWc=.bc959b25-1a6e-4fdd-9776-18f59fe537c8@github.com>

On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Create and cache a single instance of the oft-used SuperThisChecker.
>  - Add unit test verifying super() can't appear inside a lambda.
>  - Use TreeInfo.isConstructor() for detecting constructors.
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13656#pullrequestreview-1546376641

From jlahoda at openjdk.org  Wed Jul 26 09:47:59 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Jul 2023 09:47:59 GMT
Subject: Integrated: 8312229: Crash involving yield,
 switch and anonymous classes
In-Reply-To: <3IBcWPyTRIAEtTaY2vqKA-TCrcePHVJoetOemQj2BMg=.8960e0d0-e0b1-4b5d-9c05-7242d552cdf7@github.com>
References: <3IBcWPyTRIAEtTaY2vqKA-TCrcePHVJoetOemQj2BMg=.8960e0d0-e0b1-4b5d-9c05-7242d552cdf7@github.com>
Message-ID: <QEXiUxgV7dyrENHkhi2iWirIVoRu92zl76_9Pcw4iYw=.01117cc7-1432-484e-941c-8fc683342a10@github.com>

On Wed, 19 Jul 2023 10:44:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
>     void test(Object o) {
>         Runnable r = () -> {
>             switch (o) {
>                 default -> {
>                     Integer i = 42;
>                     new Runnable() {
>                         public void run() {
>                             i.toString();
>                         }
>                     };
>                 }
>             };
>         };
>     }
> 
> 
> During `LambdaToMethod`, the `i` variable is seen as a local variable in the lambda, and re-written to a different variable inside the new lambda method. This is due to:
> https://github.com/openjdk/jdk/blob/d33e8e6f93d7b0806e1d0087c3c0a11fe1bc8e21/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#L1573
> 
> note the lambda frame is the topmost frame in this case.
> 
> But, if the code is altered to:
> 
>     void test(Object o) {
>         Runnable r = () -> {
>             var l = switch (o) {
>                 default -> {
>                     Integer i = 42;
>                     yield new Runnable() {
>                         public void run() {
>                             i.toString();
>                         }
>                     };
>                 }
>             };
>         };
>     }
> 
> 
> the topmost frame will not be the lambda frame, but rather a variable frame, so that the `i` variable is not seem as a lambda-local variable, and the translations eventually fail.
> 
> The proposed solution is to search for the lambda frame, ignoring intervening variable frames.

This pull request has now been integrated.

Changeset: 1f81e5b1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f81e5b19ebfb7cd1b5a01d6cf79efda7e827c35
Stats:     53 lines in 2 files changed: 51 ins; 0 del; 2 mod

8312229: Crash involving yield, switch and anonymous classes

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Wed Jul 26 10:39:00 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Jul 2023 10:39:00 GMT
Subject: Integrated: 8312619: Strange error message when switching over long
In-Reply-To: <E6HPpGIdbJ3Cis_lq4wRnnlTfV_4NNAqFmtxrrJ69ec=.f8963b12-51e7-4338-99b2-eb2471034dcc@github.com>
References: <E6HPpGIdbJ3Cis_lq4wRnnlTfV_4NNAqFmtxrrJ69ec=.f8963b12-51e7-4338-99b2-eb2471034dcc@github.com>
Message-ID: <4QKjh8iBzCDJIRKaGtCeb-gMsUyUnqTjBt5H1cpcRSQ=.1b9994b1-9e5d-444d-ac4e-11491b4ff9aa@github.com>

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

> For code like:
> 
> public class SelectorTypeNotAllowed {
>     private void noLong(long sel) {
>         switch (sel) {
>             case 0L -> {}
>             default -> {}
>         }
>     }
> }
> 
> 
> which is invalid (due to the `long` selector) produces this compile-time error:
> 
> /tmp/SelectorTypeNotAllowed.java:4: error: constant label of type long is not compatible with switch selector type long
>             case 0L -> {}
>                  ^
> 1 error
> 
> 
> This is a confusing error message. The proposal here is to change the error message to:
> 
> /tmp/SelectorTypeNotAllowed.java:3: error: selector type long is not allowed
>         switch (sel) {
>                ^
> 1 error

This pull request has now been integrated.

Changeset: cc2a75e1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc2a75e11c4b5728c547aa764067427fdea8c941
Stats:     50 lines in 4 files changed: 43 ins; 0 del; 7 mod

8312619: Strange error message when switching over long

Reviewed-by: vromero

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

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

From jlu at openjdk.org  Wed Jul 26 20:47:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Jul 2023 20:47:11 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
Message-ID: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>

Please review this PR which contains the IPS translations for updates to localized resources in the JDK since RDP1.

Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.

The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).

- src/java.base/share/classes/sun/launcher/resources/launcher.properties
- src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
- src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
- src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
- src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties

It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.

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

Commit messages:
 - Revert zh_CN translation of 'private' for consistency
 - Revert IPS newline changes to MsiInstallerStrings_en.wxl
 - Move CurrencyNames_xx.properties to jdk.localedata (no changes)
 - Remove extra quotes in 'main.usage' values in jdeprscan
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Standardize trailing WS in l10n.properties
 - Revert MsiInstallerStrings culture value changes
 - Apply WS Tool
 - Apply IPS translations

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

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

From dnguyen at openjdk.org  Thu Jul 27 00:24:42 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 27 Jul 2023 00:24:42 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
Message-ID: <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com>

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

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

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185:

> 183: jshell.console.no.javadoc = <no documentation found>
> 184: jshell.console.do.nothing = Do nothing
> 185: jshell.console.choice = Choice:\u0020

I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1275600311

From asotona at openjdk.org  Thu Jul 27 01:41:03 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 01:41:03 GMT
Subject: RFR: 8295059: test/langtools/tools/javap 12 test classes use
 com.sun.tools.classfile library
In-Reply-To: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
References: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
Message-ID: <UyrNAIQLuhbVwLllj-CNc_rssjShKhKOjr8UBC9jong=.17eb26b2-1254-432d-a97e-2601b9b0030b@github.com>

On Tue, 11 Jul 2023 20:17:58 GMT, Qing Xiao <duke at openjdk.org> wrote:

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

I think it looks good, good job ?

It looks good, thanks.

test/langtools/tools/javap/TestClassNameWarning.java line 182:

> 180:         Classfile.of().buildTo(
> 181:                 classes.resolve("Z.class"),
> 182:                 ClassDesc.of("0"), cb -> {

Zero constant pool index means there is physically no entry (a kind of null value).
According to the spec the class name CP entry is mandatory, so Classfile API does not allow to enter no value and create a class file with 0 index of the class name.
We will have to figure out the way how to write 0 CP index for class name or skip this part of the test.
ClassDesc.of("0") is valid class name, so testing of the 0 CP index is skipped here.

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

PR Review: https://git.openjdk.org/jdk/pull/14837#pullrequestreview-1526023965
PR Review: https://git.openjdk.org/jdk/pull/14837#pullrequestreview-1544948636
PR Review Comment: https://git.openjdk.org/jdk/pull/14837#discussion_r1260961973

From duke at openjdk.org  Thu Jul 27 01:41:04 2023
From: duke at openjdk.org (Qing Xiao)
Date: Thu, 27 Jul 2023 01:41:04 GMT
Subject: RFR: 8295059: test/langtools/tools/javap 12 test classes use
 com.sun.tools.classfile library
In-Reply-To: <UyrNAIQLuhbVwLllj-CNc_rssjShKhKOjr8UBC9jong=.17eb26b2-1254-432d-a97e-2601b9b0030b@github.com>
References: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
 <UyrNAIQLuhbVwLllj-CNc_rssjShKhKOjr8UBC9jong=.17eb26b2-1254-432d-a97e-2601b9b0030b@github.com>
Message-ID: <jd8KPfyCEH_Bzb6n7U3b7E2FTSizT7bU34oebQLmkWQ=.84ba503f-a868-4d77-8352-18cfd5c47b8e@github.com>

On Wed, 12 Jul 2023 10:24:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Modified 10 of 12 test/langtools/tools/javap test classes to replace com.sun.tools.classfile library.
>
> test/langtools/tools/javap/TestClassNameWarning.java line 182:
> 
>> 180:         Classfile.of().buildTo(
>> 181:                 classes.resolve("Z.class"),
>> 182:                 ClassDesc.of("0"), cb -> {
> 
> Zero constant pool index means there is physically no entry (a kind of null value).
> According to the spec the class name CP entry is mandatory, so Classfile API does not allow to enter no value and create a class file with 0 index of the class name.
> We will have to figure out the way how to write 0 CP index for class name or skip this part of the test.
> ClassDesc.of("0") is valid class name, so testing of the 0 CP index is skipped here.

Hi Adam. Another file of Javac package: test/langtools/tools/javac/classreader/BadClass.java also changed the CP index with sun.tools.classfile API. Can you take a look at it?
Until we figured out the way of changing CP index, should I rollback my changes and leave these two tests open?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14837#discussion_r1261346434

From duke at openjdk.org  Thu Jul 27 01:41:03 2023
From: duke at openjdk.org (Qing Xiao)
Date: Thu, 27 Jul 2023 01:41:03 GMT
Subject: RFR: 8295059: test/langtools/tools/javap 12 test classes use
 com.sun.tools.classfile library
Message-ID: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>

Modified 10 of 12 test/langtools/tools/javap test classes to replace com.sun.tools.classfile library.

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

Commit messages:
 - Modified test/langtools/tools/javap/classfile/6888367/T6888367.java
 - 8295059: test/langtools/tools/javap 10 tests classes use com.sun.tools.classfile library

Changes: https://git.openjdk.org/jdk/pull/14837/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295059
  Stats: 718 lines in 11 files changed: 128 ins; 196 del; 394 mod
  Patch: https://git.openjdk.org/jdk/pull/14837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14837/head:pull/14837

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

From asotona at openjdk.org  Thu Jul 27 01:41:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 01:41:04 GMT
Subject: RFR: 8295059: test/langtools/tools/javap 12 test classes use
 com.sun.tools.classfile library
In-Reply-To: <jd8KPfyCEH_Bzb6n7U3b7E2FTSizT7bU34oebQLmkWQ=.84ba503f-a868-4d77-8352-18cfd5c47b8e@github.com>
References: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
 <UyrNAIQLuhbVwLllj-CNc_rssjShKhKOjr8UBC9jong=.17eb26b2-1254-432d-a97e-2601b9b0030b@github.com>
 <jd8KPfyCEH_Bzb6n7U3b7E2FTSizT7bU34oebQLmkWQ=.84ba503f-a868-4d77-8352-18cfd5c47b8e@github.com>
Message-ID: <aNd9FDFAnhfuFwLP1LmACS6zwjsjYZy63HwFmfHvcKo=.46236d0d-449d-4994-a936-3581603b5596@github.com>

On Wed, 12 Jul 2023 15:22:33 GMT, Qing Xiao <duke at openjdk.org> wrote:

>> test/langtools/tools/javap/TestClassNameWarning.java line 182:
>> 
>>> 180:         Classfile.of().buildTo(
>>> 181:                 classes.resolve("Z.class"),
>>> 182:                 ClassDesc.of("0"), cb -> {
>> 
>> Zero constant pool index means there is physically no entry (a kind of null value).
>> According to the spec the class name CP entry is mandatory, so Classfile API does not allow to enter no value and create a class file with 0 index of the class name.
>> We will have to figure out the way how to write 0 CP index for class name or skip this part of the test.
>> ClassDesc.of("0") is valid class name, so testing of the 0 CP index is skipped here.
>
> Hi Adam. Another file of Javac package: test/langtools/tools/javac/classreader/BadClass.java also changed the CP index with sun.tools.classfile API. Can you take a look at it?
> Until we figured out the way of changing CP index, should I rollback my changes and leave these two tests open?

Classfile API doesn't allow to create an invalid entry.
I'll investigate if it is worth to extend the API, implement some low-lever workaround or skip this specific test case and leave it with valid class name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14837#discussion_r1261414225

From asotona at openjdk.org  Thu Jul 27 01:41:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 01:41:04 GMT
Subject: RFR: 8295059: test/langtools/tools/javap 12 test classes use
 com.sun.tools.classfile library
In-Reply-To: <aNd9FDFAnhfuFwLP1LmACS6zwjsjYZy63HwFmfHvcKo=.46236d0d-449d-4994-a936-3581603b5596@github.com>
References: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
 <UyrNAIQLuhbVwLllj-CNc_rssjShKhKOjr8UBC9jong=.17eb26b2-1254-432d-a97e-2601b9b0030b@github.com>
 <jd8KPfyCEH_Bzb6n7U3b7E2FTSizT7bU34oebQLmkWQ=.84ba503f-a868-4d77-8352-18cfd5c47b8e@github.com>
 <aNd9FDFAnhfuFwLP1LmACS6zwjsjYZy63HwFmfHvcKo=.46236d0d-449d-4994-a936-3581603b5596@github.com>
Message-ID: <_YOBswVeNqzUeySBCALh6gfkVURYvaZtcmI3IuDFIsc=.27d7b7b6-452b-4ddc-8833-a39d1cd714ac@github.com>

On Wed, 12 Jul 2023 16:11:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi Adam. Another file of Javac package: test/langtools/tools/javac/classreader/BadClass.java also changed the CP index with sun.tools.classfile API. Can you take a look at it?
>> Until we figured out the way of changing CP index, should I rollback my changes and leave these two tests open?
>
> Classfile API doesn't allow to create an invalid entry.
> I'll investigate if it is worth to extend the API, implement some low-lever workaround or skip this specific test case and leave it with valid class name.

I would suggest to remove the whole testNoNameClass test case as the warning message is tested by  similar testWrongNameClass test case below. Testing specifically for 0 class name CP index is obsolete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14837#discussion_r1261435891

From jlu at openjdk.org  Thu Jul 27 06:51:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Jul 2023 06:51:48 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
 <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com>
Message-ID: <BTGa-RsKKoRdt_7wbgU_LRoenJQtW_bLV1ifxXxrFY4=.08d867b7-6363-4b1f-9e07-d886e075cdd6@github.com>

On Thu, 27 Jul 2023 00:16:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1.
>> 
>> Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.
>> 
>> The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).
>> 
>> - src/java.base/share/classes/sun/launcher/resources/launcher.properties
>> - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>> - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
>> - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
>> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
>> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
>> 
>> It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.
>
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185:
> 
>> 183: jshell.console.no.javadoc = <no documentation found>
>> 184: jshell.console.do.nothing = Do nothing
>> 185: jshell.console.choice = Choice:\u0020
> 
> I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode.

Thanks for reviewing Damon, the `` is used to signify the white space after the `:` is intentional. However, using a trailing `\u0020` is more intentional and clear, and allows for consistency between the original and localized versions, so I manually made this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1275806234

From asotona at openjdk.org  Thu Jul 27 15:07:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 15:07:52 GMT
Subject: RFR: 8295059: test/langtools/tools/javap 12 test classes use
 com.sun.tools.classfile library
In-Reply-To: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
References: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
Message-ID: <4qjqW-b6FZgeZnnCYVizfX9ED6EojwGvjTDhBsvXEaE=.34bee6af-a9c4-47d2-b3c6-54ecf0c2adf3@github.com>

On Tue, 11 Jul 2023 20:17:58 GMT, Qing Xiao <duke at openjdk.org> wrote:

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

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14837#pullrequestreview-1550090427

From dnguyen at openjdk.org  Thu Jul 27 16:55:51 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 27 Jul 2023 16:55:51 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <BTGa-RsKKoRdt_7wbgU_LRoenJQtW_bLV1ifxXxrFY4=.08d867b7-6363-4b1f-9e07-d886e075cdd6@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
 <-EvTASKrIweBzLE7uRXAtnLmG4XXp5oN4Q6Qq4ETm3M=.37d25be2-2296-499e-a925-7ab24be4e99e@github.com>
 <BTGa-RsKKoRdt_7wbgU_LRoenJQtW_bLV1ifxXxrFY4=.08d867b7-6363-4b1f-9e07-d886e075cdd6@github.com>
Message-ID: <UOrz91rra5bod31BzvAbODUb2nlHlqYxe_lqWX4cPHs=.edffbff6-f814-4f57-9eaa-089cf59f841a@github.com>

On Thu, 27 Jul 2023 06:48:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties line 185:
>> 
>>> 183: jshell.console.no.javadoc = <no documentation found>
>>> 184: jshell.console.do.nothing = Do nothing
>>> 185: jshell.console.choice = Choice:\u0020
>> 
>> I see this backslash is also being removed. It does seem misplaced since none of the other lines use it. But just double checking with you that this is the desired change because for the other locales, the change was to just translate the space to unicode.
>
> Thanks for reviewing Damon, the `` is used to signify the white space after the `:` is intentional. However, using a trailing `\u0020` is more intentional and clear, and allows for consistency between the original and localized versions, so I manually made this change.

Sure, I agree. Just checking to see if this was a product of the translation tool used, because if so, this might've been a mistake or issue with the tool. Looks fine here then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15047#discussion_r1276566404

From asotona at openjdk.org  Thu Jul 27 17:23:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Jul 2023 17:23:53 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
Message-ID: <DqlLJxk7U1rSzrnWk6lVU1Q9vTR3hToCUXfWbhdbYaE=.d5759c84-a5bb-4caf-808d-6f48f10569e0@github.com>

On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed code printing and ConstantPoolException reporting indoex
>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>  - throwing ConstantPoolException for invalid BSM entry index
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed JavapTask
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

Important fixes have been integrated and all tests are now passing.

Please review.

Thanks,
Adam

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

PR Comment: https://git.openjdk.org/jdk/pull/11411#issuecomment-1654064732

From naoto at openjdk.org  Thu Jul 27 17:59:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Jul 2023 17:59:40 GMT
Subject: RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
Message-ID: <_lkKzTNMcBXmMJ12xdYHuY7huc4G4sM7nPdN6ZtmrOk=.7b163449-bf71-4f74-a0aa-3881f0645dec@github.com>

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

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

Haven't looked at each translation, but good to me overall.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15047#pullrequestreview-1550448645

From archie.cobbs at gmail.com  Thu Jul 27 18:33:41 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 27 Jul 2023 13:33:41 -0500
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
Message-ID: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>

This issue caught my eye: JDK-8308023
<https://bugs.openjdk.org/browse/JDK-8308023> - Javac generates
exponentially large class file with nested try catch statements

In a nutshell, since JSR/RET is no longer allowed/used, we now compile try
{ X } finally { Y } into this:

    X
    Y
    goto L2
L1: Store exception in local e1
    Y
    Load exception from local e1
    Throw exception
L2: ...

The L1 label is the target for the exception range surrounding X.

Note that the finally block Y is duplicated.

This means that if we hare N nested finally's:

    try {
      X0
    } finally {
      try {
        X1
      } finally {
        try {
          X2
        } finally {
          .... try {
                XN
              } finally {
                // done
          ... }
          }
        }
      }
    }

then each block Xi will be replicated 2^i times in the classfile.

Question: Can we solve this problem simply by avoiding the duplication of
finally blocks?

What if we compiled try { X } finally { Y } into this:

    X
    Store null in local e1         // new instruction
    goto L2
L1: Store exception in local e1
L2: Y
    Load exception from local e1
    If null, goto L3               // new instruction
    Load exception from local e1   // new instruction
    Throw exception
L3: ...

There are three new instructions, so in trivial cases this would make the
classfile larger. But in the highly nested cases it would change the
classfile growth from exponential to linear.

Thoughts? What am I missing?

-Archie

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

From forax at univ-mlv.fr  Thu Jul 27 20:16:49 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 27 Jul 2023 22:16:49 +0200 (CEST)
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
Message-ID: <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>

> From: "Archie Cobbs" <archie.cobbs at gmail.com>
> To: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Thursday, July 27, 2023 8:33:41 PM
> Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally

> This issue caught my eye: [ https://bugs.openjdk.org/browse/JDK-8308023 |
> JDK-8308023 ] - Javac generates exponentially large class file with nested try
> catch statements
> In a nutshell, since JSR/RET is no longer allowed/used, we now compile try { X }
> finally { Y } into this:

> X
> Y
> goto L2
> L1: Store exception in local e1
> Y
> Load exception from local e1
> Throw exception
> L2: ...

> The L1 label is the target for the exception range surrounding X .

> Note that the finally block Y is duplicated.

> This means that if we hare N nested finally's:

> try {
> X0
> } finally {
> try {
> X1
> } finally {
> try {
> X2
> } finally {
> .... try {
> XN
> } finally {
> // done
> ... }
> }
> }
> }
> }

> then each block Xi will be replicated 2^i times in the classfile.

> Question: Can we solve this problem simply by avoiding the duplication of
> finally blocks?

> What if we compiled try { X } finally { Y } into this:

> X
> Store null in local e1 // new instruction
> goto L2
> L1: Store exception in local e1
> L2: Y
> Load exception from local e1
> If null, goto L3 // new instruction
> Load exception from local e1 // new instruction
> Throw exception
> L3: ...

> There are three new instructions, so in trivial cases this would make the
> classfile larger. But in the highly nested cases it would change the classfile
> growth from exponential to linear.

> Thoughts? What am I missing?

It's a well known issue since the introduction of the split-verifier, the alternative is exponential verification time. 
If you try to generate the code above most JITs will refuse to optimize the code, sharing the nominal path and the exception path is a big no no. 

The official workaround if there are a lot on enclosed try/finally blocks is to use several methods. 

> -Archie

regards, 
R?mi 

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

From archie.cobbs at gmail.com  Thu Jul 27 20:26:14 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 27 Jul 2023 15:26:14 -0500
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
 <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>

Thanks for your comments.

Bear with me while I play devil's advocate...

On Thu, Jul 27, 2023 at 3:16?PM Remi Forax <forax at univ-mlv.fr> wrote:

> What if we compiled try { X } finally { Y } into this:
>
>     X
>     Store null in local e1         // new instruction
>   goto L2
> L1: Store exception in local e1
> L2:Y
>     Load exception from local e1
>     If null, goto L3               // new instruction
>     Load exception from local e1// new instruction
>   Throw exception
> L3: ...
>
>
> It's a well known issue since the introduction of the split-verifier, the
> alternative is exponential verification time.
>

Wait - are you saying the split-verifier has exponential verification time
in certain cases?

If so, how is that not just a stupid verifier bug? Not to mention an easy
way to DOS Java's widely heralded code portability.


> If you try to generate the code above most JITs will refuse to optimize
> the code, sharing the nominal path and the exception path is a big no no.
>

And this is whose fault... ?

Isn't it a JIT's job to be aware of any such effects (if they exist on some
particular hardware) and deal with them??


> The official workaround if there are a lot on enclosed try/finally blocks
> is to use several methods.
>

Workaround for whom?

If for the programmer, then so what? The existence of a workaround doesn't
mean a bug shouldn't still be fixed.

If for the compiler, then when is the "official" workaround going to be
actually implemented?

Thanks,
-Archie

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

From forax at univ-mlv.fr  Thu Jul 27 22:22:15 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 28 Jul 2023 00:22:15 +0200 (CEST)
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
 <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>
Message-ID: <1589265839.4411669.1690496535565.JavaMail.zimbra@univ-eiffel.fr>

> From: "Archie Cobbs" <archie.cobbs at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Thursday, July 27, 2023 10:26:14 PM
> Subject: Re: JDK-8308023 - Exponential classfile blowup with nested try/finally

> Thanks for your comments.

> Bear with me while I play devil's advocate...

> On Thu, Jul 27, 2023 at 3:16 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>>> What if we compiled try { X } finally { Y } into this:

>>> X
>>> Store null in local e1 // new instruction
>>> goto L2
>>> L1: Store exception in local e1
>>> L2: Y
>>> Load exception from local e1
>>> If null, goto L3 // new instruction
>>> Load exception from local e1 // new instruction
>>> Throw exception
>>> L3: ...

>> It's a well known issue since the introduction of the split-verifier, the
>> alternative is exponential verification time.

> Wait - are you saying the split-verifier has exponential verification time in
> certain cases?

> If so, how is that not just a stupid verifier bug? Not to mention an easy way to
> DOS Java's widely heralded code portability.

There are two verifiers, the old one that does not use StackMapTable attributes has an exponential verification time if JSR/RET are used. 
The new one, the split-verifier, is linear but requires StackMapTable attributes and to duplicated finally blocks. 

see [ https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.10.2 | https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.10.2 ] 

>> If you try to generate the code above most JITs will refuse to optimize the
>> code, sharing the nominal path and the exception path is a big no no.

> And this is whose fault... ?

> Isn't it a JIT's job to be aware of any such effects (if they exist on some
> particular hardware) and deal with them??

It has nothing to do with a peculiar hardware, a JIT is an optimizing bytecode to assembly compiler, like any optimizing compiler, not all bytecode shapes are equal. 

The crux of this issue is this question, Why do want a VM engineer to spend time on a bytecode shape that no sane bytecode generators will ever generate ? 
And do not forget that there are several existing Java VMs, so each VM will have to dedicate engineering time to do that optimization. 

>> The official workaround if there are a lot on enclosed try/finally blocks is to
>> use several methods.

> Workaround for whom?

> If for the programmer, then so what? The existence of a workaround doesn't mean
> a bug shouldn't still be fixed.

> If for the compiler, then when is the "official" workaround going to be actually
> implemented?

For the developer. 

> Thanks,
> -Archie

R?mi 

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

From archie.cobbs at gmail.com  Thu Jul 27 22:51:59 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 27 Jul 2023 17:51:59 -0500
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <1589265839.4411669.1690496535565.JavaMail.zimbra@univ-eiffel.fr>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
 <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>
 <1589265839.4411669.1690496535565.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CANSoFxs07oVE=b=R6B-381R+YOt452L+P8Q9BSpmg=XceokeuQ@mail.gmail.com>

On Thu, Jul 27, 2023 at 5:22?PM <forax at univ-mlv.fr> wrote:

> Wait - are you saying the split-verifier has exponential verification time
> in certain cases?
>
> If so, how is that not just a stupid verifier bug? Not to mention an easy
> way to DOS Java's widely heralded code portability.
>
>
> There are two verifiers, the old one that does not use StackMapTable
> attributes has an exponential verification time if JSR/RET are used.
> The new one, the split-verifier, is linear but requires StackMapTable
> attributes and to duplicated finally blocks.
>

Got it. So the old verifier is not really relevant to this discussion,
because we're talking here about class files that don't use JSR/RET (major
version >= 50).


> Isn't it a JIT's job to be aware of any such effects (if they exist on
> some particular hardware) and deal with them??
>
>
> It has nothing to do with a peculiar hardware, a JIT is an optimizing
> bytecode to assembly compiler, like any optimizing compiler, not all
> bytecode shapes are equal.
>
> The crux of this issue is this question, Why do want a VM engineer to
> spend time on a bytecode shape that no sane bytecode generators will ever
> generate ?
>

I don't really understand your point. It sounds to me like you're saying
"Doing anything other than what we're already doing would be crazy" but
without providing any specific justification.

What I'm suggesting seems much more sane to me than what we're currently
doing. What's sane about exponential blowup and excessively duplicated
bytecode??

While I'm sure you're right that there are JITs out there that have evolved
to work better (or worse) based on typical (or atypical) bytecode patterns,
that's not an a priori reason to throw your hands up and say something
could never work.

In fact, I bet it would be faster without any JIT changes at all. After
all, you're going to have N code paths instead of 2^N!

-Archie

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

From darcy at openjdk.org  Fri Jul 28 02:31:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 28 Jul 2023 02:31:07 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment
Message-ID: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>

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

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

Commit messages:
 - JDK-8307184: Incorrect/inconsistent specification and implementation for Elements.getDocComment

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

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

From darcy at openjdk.org  Fri Jul 28 02:41:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 28 Jul 2023 02:41:09 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v2]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <6ZaNDK3wdx2O5Ed9j98hRjnuzN05hKw01MqnpJGLUfM=.afc970db-5ed6-4c39-b170-bd9256cc2c77@github.com>

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

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

  Update non-beginning, non-eneding lines of the spec.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15062/files
  - new: https://git.openjdk.org/jdk/pull/15062/files/59737bea..71fb0d1d

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

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

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

From darcy at openjdk.org  Fri Jul 28 04:48:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 28 Jul 2023 04:48:17 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v3]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <GmZe1vFAGI16bFiLRRNGnz2qXsVbwHg4LMJAuAr7sUA=.5fd5fac2-6d7d-48fe-9625-3c8f138929ae@github.com>

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

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

  Add tests; adjust spec.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15062/files
  - new: https://git.openjdk.org/jdk/pull/15062/files/71fb0d1d..faeabe3e

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

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

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

From darcy at openjdk.org  Fri Jul 28 05:38:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 28 Jul 2023 05:38:15 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v4]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <YVgr0ZkQNVHLN-7nsF2fdXWTHPavW-ioY6A6pWuZvPE=.19174915-11d5-468d-af72-a86cfe9d0281@github.com>

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

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

  Updates.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15062/files
  - new: https://git.openjdk.org/jdk/pull/15062/files/faeabe3e..9ac4610a

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

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

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

From darcy at openjdk.org  Fri Jul 28 05:51:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 28 Jul 2023 05:51:58 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v5]
In-Reply-To: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
Message-ID: <tt6bTvqFFR9zlSqCv7oR6mib1hgrUnRqPkVVD1jqEDs=.cca57b8f-9773-4d71-a75d-7de540c3e257@github.com>

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

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

  Appease jcheck.

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

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

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

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

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

From darcy at openjdk.org  Fri Jul 28 05:52:00 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 28 Jul 2023 05:52:00 GMT
Subject: RFR: JDK-8307184: Incorrect/inconsistent specification and
 implementation for Elements.getDocComment [v4]
In-Reply-To: <YVgr0ZkQNVHLN-7nsF2fdXWTHPavW-ioY6A6pWuZvPE=.19174915-11d5-468d-af72-a86cfe9d0281@github.com>
References: <FI_CpHRYxexlLGyYLXeGgRP-_uTwHEaKQWKa_Whew2c=.76d58a57-c534-445b-aea5-7816f5a45315@github.com>
 <YVgr0ZkQNVHLN-7nsF2fdXWTHPavW-ioY6A6pWuZvPE=.19174915-11d5-468d-af72-a86cfe9d0281@github.com>
Message-ID: <o_u0II407FYx5uECuiBMKEl5Mao0zJc2cMJ_-zinhVs=.c1a2fd8d-351d-42b7-a045-d106a992e878@github.com>

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

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

Once we've settled on the spec changes, I'll populate the CSR accordingly.

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

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

From jan.lahoda at oracle.com  Fri Jul 28 08:16:50 2023
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 28 Jul 2023 10:16:50 +0200
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <CANSoFxs07oVE=b=R6B-381R+YOt452L+P8Q9BSpmg=XceokeuQ@mail.gmail.com>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
 <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>
 <1589265839.4411669.1690496535565.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxs07oVE=b=R6B-381R+YOt452L+P8Q9BSpmg=XceokeuQ@mail.gmail.com>
Message-ID: <64c0c844-89dd-ad70-1119-8e4f4b75b1d4@oracle.com>

Hi,


I believe a few of us were looking at this some time ago. There is a 
range of potential solutions, some with a possibly lesser impact, but 
safer, some with potentially bigger impact, but possibly more dangerous.


Overall, I am personally a bit worried about adding conditional jumps 
that were not in the source code - these might affect way how the code 
performs (as Remi says). This might be more OK for deeply nested 
try-finally, which are probably already problematic, but possibly not 
for a simple/lightly nested try-finally. But having two ways to generate 
try-finally is somewhat problematic for javac.


There are potentially safer options, like for example, considering:

         try {
             a = 0;
         } finally {
             try {
                 b = 1;
             } finally {
                 c = 2;
             }
         }

this gets translated roughly as:

         try {
             a = 0;
         } catch (Throwable t0) {
             try {
                 b = 1;
             } catch (Throwable t1) {
                 c = 2;
                 throw t1;
             }
             c = 2;
             throw t0;
         }
         try {
             b = 1;
         } catch (Throwable t1) {
             c = 2;
             throw t1;
         }
         c = 2;


We probably could only have one copy of (by just re-wiring Exceptions 
table entries, and producing only one copy of the code):

         } catch (Throwable t1) {
             c = 2;
             throw t1;
         }

It may not seem like a saving a lot, but for deeply nested try-finally 
(in the simple form from this report), this actually saves a lot 
(because for deeper nesting, the shared snippets get bigger and bigger). 
I've had some prototype, but it has some problems (does not generate 
proper StackMaps, and allocating the variable for the exception is 
somewhat tricky).


Overall, given the usual complexity of doing anything in Gen, I believe 
the inclination was to see if we can wait until javac will use the 
ClassFile API to generate bytecode, and revisit then. This would at 
least help us generate proper StackMaps much more easier.


Also please note that the situation will get much more difficult when 
there are exits from inside of the try block - return, break, continue, 
yield, where break and continue instances can (in general) 
break/continue to more than one target. Some unifications are possible 
then at the cost of unconditional jump, which may be OK, but would still 
need a careful evaluation.


Overall, I suspect that whatever we do, we would need to run proper 
experiments to ensure there's no problem with performance of the new code.


Jan


On 28. 07. 23 0:51, Archie Cobbs wrote:
> On Thu, Jul 27, 2023 at 5:22?PM <forax at univ-mlv.fr> wrote:
>
>         Wait - are you saying the split-verifier has exponential
>         verification time in certain cases?
>
>         If so, how is that not just a stupid verifier bug? Not to
>         mention an easy way to DOS Java's widely heralded code
>         portability.
>
>
>     There are two verifiers, the old one that does not use
>     StackMapTable attributes has an exponential verification time if
>     JSR/RET are used.
>     The new one, the split-verifier, is linear but requires
>     StackMapTable attributes and to duplicated finally blocks.
>
>
> Got it. So the old verifier is not really relevant to this discussion, 
> because we're talking here about class files that don't use JSR/RET 
> (major version >= 50).
>
>
>         Isn't it a JIT's job to be aware of any such effects (if they
>         exist on some particular hardware) and deal with them??
>
>
>     It has nothing to do with a peculiar hardware, a JIT is an
>     optimizing bytecode to assembly compiler, like any optimizing
>     compiler, not all bytecode shapes are equal.
>
>     The crux of this issue is this question, Why do want a VM engineer
>     to spend time on a bytecode shape that no sane bytecode generators
>     will ever generate ?
>
>
> I don't really understand your point. It sounds to me like you're 
> saying "Doing anything other than what we're already doing would be 
> crazy" but without providing any specific justification.
>
> What I'm suggesting seems much more sane to me than what we're 
> currently doing. What's sane about exponential blowup and excessively 
> duplicated bytecode??
>
> While I'm sure you're right that there are JITs out there that have 
> evolved to work better (or worse) based on typical (or atypical) 
> bytecode patterns, that's not an a priori reason to throw your hands 
> up and say something could never work.
>
> In fact, I bet it would be faster without any JIT changes at all. 
> After all, you're going to have N code paths instead of 2^N!
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230728/245e5414/attachment-0001.htm>

From archie.cobbs at gmail.com  Fri Jul 28 14:06:36 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 28 Jul 2023 09:06:36 -0500
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <64c0c844-89dd-ad70-1119-8e4f4b75b1d4@oracle.com>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
 <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>
 <1589265839.4411669.1690496535565.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxs07oVE=b=R6B-381R+YOt452L+P8Q9BSpmg=XceokeuQ@mail.gmail.com>
 <64c0c844-89dd-ad70-1119-8e4f4b75b1d4@oracle.com>
Message-ID: <CANSoFxsY=jeDdt9iizpF3Bo_SdNS8gTKxwh8FV=eA-JrkrD0cA@mail.gmail.com>

Hi Jan,

Thanks for the (helpful) comments.

On Fri, Jul 28, 2023 at 3:17?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Overall, given the usual complexity of doing anything in Gen, I believe
> the inclination was to see if we can wait until javac will use the
> ClassFile API to generate bytecode, and revisit then. This would at least
> help us generate proper StackMaps much more easier.
>

What's the timeline for this work?

Overall, I suspect that whatever we do, we would need to run proper
> experiments to ensure there's no problem with performance of the new code.
>

I agree that this will be an important litmus test for any new strategy.

But do you have a clear idea what "proper experiments" would look like? Are
there any simple off-the-shelf tests that would serve as reasonable initial
feedback while prototyping?

As they say, you can't improve (or tweak) what you don't measure, so it
seems a prerequisite is to properly define the "measure" and get agreement
on it.

I'm sure no one (including me) wants to invest in experimentation without
some established goalposts that can't be moved after the fact by naysayers.

-Archie

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

From archie.cobbs at gmail.com  Sun Jul 30 21:24:13 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 30 Jul 2023 16:24:13 -0500
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <64c0c844-89dd-ad70-1119-8e4f4b75b1d4@oracle.com>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
 <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>
 <1589265839.4411669.1690496535565.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxs07oVE=b=R6B-381R+YOt452L+P8Q9BSpmg=XceokeuQ@mail.gmail.com>
 <64c0c844-89dd-ad70-1119-8e4f4b75b1d4@oracle.com>
Message-ID: <CANSoFxskZx++7uC67N11Cc1m4Q7yLvgENYLjJu9LbpVsLTgWNA@mail.gmail.com>

On Fri, Jul 28, 2023 at 3:17?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> I believe a few of us were looking at this some time ago.
>

I played around with this some more and now realize there is a bigger (and
more subtle) obstacle with this idea or any other similar variant that
attempts to "reuse" the same finally block bytecode for both normal and
exceptional execution paths.

Suppose you have code like this:

public int method() {
    int x;
    try {
        x = 7;
    } finally {
        doWhatever();
    }
    return x;
}

If the finally block is only emitted once, then there must be two possible
exit paths out of it - one where it rethrows some caught exception, and the
other where it falls through to the return statement.

My idea was to store the caught exception (in the former case) or a null
placeholder (in the latter case) in a local variable as a way of telling
the finally block which exit path to take:

public int method();
    descriptor: ()I
    Code:
       0: bipush        7
       2: istore_1
       3: aconst_null
       4: astore_2
       5: aload_0
       6: invokevirtual #14                 // Method doWhatever:()V
       9: aload_2
      10: ifnull        15
      13: aload_2
      14: athrow
      15: iload_1
      16: ireturn
    Exception table:
       from    to  target type
           0     4     4   any

The problem is that there's no way to prove to the verifier that in the
second case, the local variable corresponding to 'x' (Local#1) is always
definitely assigned, even though of course we know that it always will be
in that case. So you get a 'Bad local variable type' verifier error.

This could be worked-around by initializing, prior to entering the try
block, the locals that get (a) assigned for the first time within the try
block and (b) referenced in the finally block. Not very elegant though.

In summary, JSR/RET is gone now, and the verifier also makes it difficult
to synthesize "subroutines". This makes the compiler's job a lot harder
wrt. finally blocks.

-Archie

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

From jlahoda at openjdk.org  Mon Jul 31 06:59:19 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Jul 2023 06:59:19 GMT
Subject: RFR: 8313323: javac -g on a java file which uses unnamed variable
 leads to ClassFormatError when launching that class
Message-ID: <br-nxJW7FzbxPvGl6V_5KTdhF6EsWUyexSbrn64birs=.bedda06e-0140-489b-90e3-4cb38d554409@github.com>

When unnamed (`_`) variables are present, and javac emits the `LocalVariableTable` (and potentially the `LocalVariableTypeTable`), it includes the unnamed variable in the table. As the variable does not have a name, the table contains an empty name, which is not allowed by the spec, see [1], [2], [3].

The proposed solution is to simply not include the unnamed variables in these tables, but not adding them to the internal `Code.varBuffer`.

[1] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.2.2
[2] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.13
[3] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.14

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

Commit messages:
 - Adding testcase for LocalVariableTypeTable.
 - 8313323: javac -g on a java file which uses unnamed variable leads to ClassFormatError when launching that class

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

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

From dholmes at openjdk.org  Mon Jul 31 08:39:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Jul 2023 08:39:02 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
Message-ID: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>

Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:

- src/java.base/share/man/java.1

 [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
 [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front

There are also some formatting differences related to:

 [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete

Likely a different version of pandoc was used.

- src/java.base/share/man/keytool.1

 [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character

- src/jdk.compiler/share/man/javac.1

 [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full

also some formatting differences.

- src/jdk.jartool/share/man/jarsigner.1

 [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)

- src/jdk.jcmd/share/man/jcmd.1

 [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion

- src/jdk.jdeps/share/man/jdeps.1

 [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option

- src/jdk.jfr/share/man/jfr.1

Formatting changes.

- src/jdk.jshell/share/man/jshell.1

 [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

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

Commit messages:
 - 8300937: Update nroff pages in JDK 21 before RC

Changes: https://git.openjdk.org/jdk21/pull/151/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300937
  Stats: 163 lines in 28 files changed: 37 ins; 60 del; 66 mod
  Patch: https://git.openjdk.org/jdk21/pull/151.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/151/head:pull/151

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

From jlahoda at openjdk.org  Mon Jul 31 08:51:10 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Jul 2023 08:51:10 GMT
Subject: RFR: 8312204: unexpected else with statement causes compiler crash
Message-ID: <CI9Cs0q1AFFy8Poi8PmA_1uSWI39A3gptHIfHBDUAcU=.6935df1a-960f-426c-a466-f3de3ab5221b@github.com>

Compiling (erroneous) code like:

void main() {
    else ;
}


Leads to:

$ javac --enable-preview -source 22 /tmp/Test.java 
An exception has occurred in the compiler (22-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError
        at jdk.compiler/com.sun.tools.javac.parser.VirtualParser$VirtualScanner.errPos(VirtualParser.java:151)
        at jdk.compiler/com.sun.tools.javac.parser.JavacParser.doRecover(JavacParser.java:3122)
...


The proposed solution is to implement the two corresponding `errPos` methods for `VirtualScanner`.

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

Commit messages:
 - 8312204: unexpected else with statement causes compiler crash

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

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

From maurizio.cimadamore at oracle.com  Mon Jul 31 09:44:03 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 31 Jul 2023 10:44:03 +0100
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <CANSoFxskZx++7uC67N11Cc1m4Q7yLvgENYLjJu9LbpVsLTgWNA@mail.gmail.com>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
 <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>
 <1589265839.4411669.1690496535565.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxs07oVE=b=R6B-381R+YOt452L+P8Q9BSpmg=XceokeuQ@mail.gmail.com>
 <64c0c844-89dd-ad70-1119-8e4f4b75b1d4@oracle.com>
 <CANSoFxskZx++7uC67N11Cc1m4Q7yLvgENYLjJu9LbpVsLTgWNA@mail.gmail.com>
Message-ID: <db1600c0-bad7-6060-6a2c-96ca6a2ea781@oracle.com>


On 30/07/2023 22:24, Archie Cobbs wrote:
> In summary, JSR/RET is gone now, and the verifier also makes it 
> difficult to synthesize "subroutines". This makes the compiler's job a 
> lot harder wrt. finally blocks.

I tend to agree with this analysis. I think there are some tricks that 
could be done to reduce the overall size, or avoid combinatorial 
explosion, but, as observed in this thread, the caveat is that such 
tricks would only work with certain code shapes. There are two things 
that typically require duplication:

* the stack types might be different in the two exit points (because of 
the extra exception)
* the target instruction we should "jump to" immediately after executing 
the finalizer might vary depending on the exit point

This means that not all duplicated finalizers we see in the generated 
bytecode are really 100% duplicates. The case Jan brings up is a little 
different, as there's nested try/finally there (so the innermost 
exceptional exit point is repeated twice). That said, all really bad 
combinatorial cases will end up with nested try/finally in some shape 
and form, so perhaps targeting this specific idiom is a pragmatic 
compromise.

I just wanted to add a concrete note to the problem of performance 
w.r.t. shape of generated try/finally blocks. Look at this bug:

https://bugs.openjdk.org/browse/JDK-8267532

The problem here is that using a TWR is slower than not using it. The 
issue has to do with the fact that the compiler emits to calls to 
Resource::close, one in the "hot path" and one in the exceptional path. 
Unfortunately, the call to "close" in the exceptional path is not 
inlined (because it's never taken), so the compiler sees a way for the 
Resource to escape outside the method, meaning that now the resource 
object can no longer be scalarized (thus resulting in increase in GC 
activity).

So, my general sense is that having a combinatorial number of exit 
points (which will only rarely be taken) might be detrimental to 
performance anyway - as C2 will see a lot of "cold" code paths by which 
objects can escape. That said, even if javac deduplicates the exit 
points, I'm not sure that C2 might be able to keep the code in the same 
shape as generated by javac, as C2 likes to emit one version of the code 
for the "common, hot path", and one version of the code for the 
"uncommon, cold path" (which is typically executed when some invariants 
are violated). So, reducing bytecode footprint in javac might well 
result in more work for the C2 compiler which would have to disentangle 
the nest of try/finally blocks.

Maurizio


From archie.cobbs at gmail.com  Mon Jul 31 14:15:44 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 31 Jul 2023 09:15:44 -0500
Subject: JDK-8308023 - Exponential classfile blowup with nested try/finally
In-Reply-To: <db1600c0-bad7-6060-6a2c-96ca6a2ea781@oracle.com>
References: <CANSoFxvfFAN9vjPP5JADmFPyMY9=uBzQ-B4dKqrCiOeORjXR4A@mail.gmail.com>
 <710943925.4388942.1690489009315.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxvBoJ5wMZ1Bnvi5Ny72WSW3U0pGTpo=acsAxxE+T6n4TA@mail.gmail.com>
 <1589265839.4411669.1690496535565.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxs07oVE=b=R6B-381R+YOt452L+P8Q9BSpmg=XceokeuQ@mail.gmail.com>
 <64c0c844-89dd-ad70-1119-8e4f4b75b1d4@oracle.com>
 <CANSoFxskZx++7uC67N11Cc1m4Q7yLvgENYLjJu9LbpVsLTgWNA@mail.gmail.com>
 <db1600c0-bad7-6060-6a2c-96ca6a2ea781@oracle.com>
Message-ID: <CANSoFxsDx2t7etmTHDvfD-0ZVe05jR+7-Ni4q+rkunPF-fAjoQ@mail.gmail.com>

Hi Maurizio,

On Mon, Jul 31, 2023 at 4:44?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> So, my general sense is that having a combinatorial number of exit
> points (which will only rarely be taken) might be detrimental to
> performance anyway - as C2 will see a lot of "cold" code paths by which
> objects can escape.


I agree. If the problem is one how the JVM optimizes code with a hot path
and a cold path, I don't see how the compiler could ever do anything about
this problem (either way) in the context of try/finally. With try/finally
there are always going to be at least two code paths regardless of whether
the finally block is duplicated or consolidated in the bytecode.

Note also that the bug you referenced, which talks about a performance
degradation, is comparing open-DoSomething-close vs. try-with-resources.
These are obviously not the same thing - the former has only one path and
fails to close the resource when an exception is thrown.


> That said, even if javac deduplicates the exit
> points, I'm not sure that C2 might be able to keep the code in the same
> shape as generated by javac, as C2 likes to emit one version of the code
> for the "common, hot path", and one version of the code for the
> "uncommon, cold path" (which is typically executed when some invariants
> are violated). So, reducing bytecode footprint in javac might well
> result in more work for the C2 compiler which would have to disentangle
> the nest of try/finally blocks.
>

I'm not an expert on C2, but who knows? It also might result in less work,
or have no effect. We'd need to do performance testing, or get expert
analysis.

I wouldn't be surprised if it has no effect, in which case this issue would
simply be about controlling excessive class file size.

Regardless, that original issue remains - you can't nest more than 10
try/finally blocks without getting an error. That seems pretty absurd.

-Archie

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

From dfuchs at openjdk.org  Mon Jul 31 14:24:57 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 31 Jul 2023 14:24:57 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <ZCnxqhxOMB5j9kYy7elrAETowcCKkK5EtGoxN0qhzjU=.7bc683d4-e058-4217-8977-ee839554aca4@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Changes to jwebserver.1 look good to me.

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

PR Comment: https://git.openjdk.org/jdk21/pull/151#issuecomment-1658469731

From duke at openjdk.org  Mon Jul 31 15:06:01 2023
From: duke at openjdk.org (Qing Xiao)
Date: Mon, 31 Jul 2023 15:06:01 GMT
Subject: Integrated: 8295059: test/langtools/tools/javap 12 test classes use
 com.sun.tools.classfile library
In-Reply-To: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
References: <yuZoFzoFWznZ-pzuFN02-d_QJvKK4c05pX5RUNpFlr0=.aae44b7e-cf49-4db4-b1c5-74773b73e225@github.com>
Message-ID: <4qgBV-MdBHsFNAYHStEvZjiADmvkzFxrsXHZMTlaxUg=.e598e905-188a-4c59-b489-9fb83cfb8db0@github.com>

On Tue, 11 Jul 2023 20:17:58 GMT, Qing Xiao <duke at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 97b68834
Author:    Qing Xiao <qing.xiao at oracle.com>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97b688340e2adce8e5f6abf7c3f5cb41e71afc33
Stats:     718 lines in 11 files changed: 128 ins; 196 del; 394 mod

8295059: test/langtools/tools/javap 12 test classes use com.sun.tools.classfile library

Reviewed-by: asotona

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

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

From mchung at openjdk.org  Mon Jul 31 16:48:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 31 Jul 2023 16:48:58 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <Ka8_23z0VV93yF6loJ1RvpM37WznPRDQnonXsQVtUvc=.e6b134fc-7ada-4a2e-aeff-5dc02b8f956a@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Changes in java and jdeps are good.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/151#pullrequestreview-1555334390

From duke at openjdk.org  Mon Jul 31 17:02:20 2023
From: duke at openjdk.org (Qing Xiao)
Date: Mon, 31 Jul 2023 17:02:20 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library
Message-ID: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>

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

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

Commit messages:
 - Rolled back the original version and migrated helper methods(with old classfile API). Relates to issue JDK-8313258
 - Modified test affected by the modification of ClassfileInspector.java
 - Modified all tests in tools/javac/classfiles/attributes/Signature
 - Modified all tests in tools/javac/classfiles/attributes/Synthetic,affected by the modification of TestBase
 - Modified 2 tests affected by the modification of TestBase
 - Modified all files in langtools/tools/javac/classfiles/attributes/deprecated
 - Modified tests in test/langtools/tools/javac/annotations/typeAnnotations/classfile (CombinationsTargetTest3 is WIP)
 - Modified ClassfileTestHelper to tests in javac/annotations/typeAnnotations/classfile. Modified InnerClassAttrMustNotHaveStrictFPFlagTest.java
 - Modified 2 tests in test/langtools/tools/javac/annotations/typeAnnotations/classfile
 - Modified TestBase, tests in javac/classfiles/attributes/Module
 - ... and 7 more: https://git.openjdk.org/jdk/compare/8c9d091f...27cc2f10

Changes: https://git.openjdk.org/jdk/pull/14874/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295058
  Stats: 3110 lines in 117 files changed: 1100 ins; 706 del; 1304 mod
  Patch: https://git.openjdk.org/jdk/pull/14874.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14874/head:pull/14874

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

From asotona at openjdk.org  Mon Jul 31 17:02:21 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 31 Jul 2023 17:02:21 GMT
Subject: RFR: 8295058: test/langtools/tools/javac 116 tests classes use
 com.sun.tools.classfile library
In-Reply-To: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
References: <9Gh147ffCzZjGAOBG6MIDtdmE8ScAIOpxFim3WtI_-o=.5611b00f-2585-410a-a219-04a452ad9fae@github.com>
Message-ID: <iJD6IOhh-aZCWiwB4m2khgc2wRTQ94KD78z19IlLagY=.f599f7c4-be9e-44d0-9c56-50297687dda0@github.com>

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

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

I would suggest to minimise footprint of the patch and do not change unrelated code.
Any unnecessary reformat can cause conflicts when merging into or from another project or when backporting and requires to review also reformatted-only code.

There are also missing new lines at the end of each modified source.

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

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

From iris at openjdk.org  Mon Jul 31 17:02:58 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 31 Jul 2023 17:02:58 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <IDTZVPoehnNAcfQAtY7KWm0s1jo7RMzhdttwdxoH6vI=.00094ef1-8a19-4884-b3f4-cd8ffb3e40e9@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Looks good.

The flow changes are unfortunate, but a tool update has the potential to have far more wide-spread changes.  I'm happy that's all there was.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/151#pullrequestreview-1555365638

From egahlin at openjdk.org  Mon Jul 31 18:51:50 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 31 Jul 2023 18:51:50 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <9NqTSNFI28Ew52fVBR40-QdAioWNizm9lnuMHr8hVoo=.0f709ec1-8ec2-4e6e-a30c-f69f2026200b@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/151#pullrequestreview-1555541442

From dholmes at openjdk.org  Mon Jul 31 21:13:04 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Jul 2023 21:13:04 GMT
Subject: [jdk21] Integrated: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <CmpiBFKECHa2MW7JqbiBo7dLDr_HgLSwsIUwHl1DsRw=.a6c3df50-b0c2-492d-973f-83defe84514a@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

This pull request has now been integrated.

Changeset: 0439d584
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/0439d584221f4d92fd1f4097a331f83dcdb2c12c
Stats:     163 lines in 28 files changed: 37 ins; 60 del; 66 mod

8300937: Update nroff pages in JDK 21 before RC

Reviewed-by: mchung, iris, egahlin

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

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

From dholmes at openjdk.org  Mon Jul 31 21:13:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Jul 2023 21:13:03 GMT
Subject: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC
In-Reply-To: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
References: <yYCsVWqbTRBVViIaRDn3RgaLKIaBvDgJiFUc0hfV0MI=.bb51767b-b678-465e-ae28-0af1b21c289b@github.com>
Message-ID: <Ksw1iyNt46vuKnXO6vAKBi1F1nBZQTCyYlahDuhFwPw=.c6de8a61-0add-4be7-b8ed-3f6e65f9a164@github.com>

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources:
> 
> - src/java.base/share/man/java.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>  [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> 
> There are also some formatting differences related to:
> 
>  [JDK-8309670](https://bugs.openjdk.org/browse/JDK-8309670): java -help output for --module-path / -p is incomplete
> 
> Likely a different version of pandoc was used.
> 
> - src/java.base/share/man/keytool.1
> 
>  [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> 
> - src/jdk.compiler/share/man/javac.1
> 
>  [JDK-8308456](https://bugs.openjdk.org/browse/JDK-8308456): Update javac tool page for -proc:full
> 
> also some formatting differences.
> 
> - src/jdk.jartool/share/man/jarsigner.1
> 
>  [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> 
> - src/jdk.jcmd/share/man/jcmd.1
> 
>  [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> 
> - src/jdk.jdeps/share/man/jdeps.1
> 
>  [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> - src/jdk.jfr/share/man/jfr.1
> 
> Formatting changes.
> 
> - src/jdk.jshell/share/man/jshell.1
> 
>  [JDK-8308988](https://bugs.openjdk.org/browse/JDK-8308988): Update JShell manpage to include TOOLING description

Thanks for the reviews everyone.

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

PR Comment: https://git.openjdk.org/jdk21/pull/151#issuecomment-1659164663