From tanksherman27 at gmail.com  Wed Apr  6 13:33:22 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Wed, 6 Apr 2022 21:33:22 +0800
Subject: Is it worth to use the bipush opcode for booleans instead of iconst?
Message-ID: <CAP2b4GNtp5zaRnpNJ5aMr-ExCxUFwgzTsoA5ou7OS9vbTkgTbw@mail.gmail.com>

Quick question, would it be better for javac to compile booleans to use
bipush, instead of the current iconst?

best regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220406/4aa21a26/attachment.htm>

From amaembo at gmail.com  Wed Apr  6 15:15:07 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 6 Apr 2022 22:15:07 +0700
Subject: Is it worth to use the bipush opcode for booleans instead of
 iconst?
In-Reply-To: <CAP2b4GNtp5zaRnpNJ5aMr-ExCxUFwgzTsoA5ou7OS9vbTkgTbw@mail.gmail.com>
References: <CAP2b4GNtp5zaRnpNJ5aMr-ExCxUFwgzTsoA5ou7OS9vbTkgTbw@mail.gmail.com>
Message-ID: <CAE+3fjYz=FAg7xcFhNWt+Cm6CTw1gXYEhAz-RPUy9n7-iZnteA@mail.gmail.com>

Why emitting two bytes when it's possible to emit only one?

??, 6 ???. 2022 ?., 20:34 Julian Waters <tanksherman27 at gmail.com>:

> Quick question, would it be better for javac to compile booleans to use
> bipush, instead of the current iconst?
>
> best regards,
> Julian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220406/cbfa477a/attachment.htm>

From shade at openjdk.java.net  Wed Apr  6 15:52:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 6 Apr 2022 15:52:38 GMT
Subject: Integrated: 8284167: Make internal javac exceptions stackless
In-Reply-To: <sitMlSkxJma_PLRzmjUKKIn6KQl7igVkgAy4-EWgfwM=.a21be004-baba-434f-98e4-87a516b64ad8@github.com>
References: <sitMlSkxJma_PLRzmjUKKIn6KQl7igVkgAy4-EWgfwM=.a21be004-baba-434f-98e4-87a516b64ad8@github.com>
Message-ID: <1Zcgbd2M5ulwInvHLH9knixdpO58ch4hkbrEKv1NnG4=.23364235-f241-4f82-bb46-32b7779697e1@github.com>

On Fri, 1 Apr 2022 10:12:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> async-profiling of SPECjvm2008 benchmarks (heavily modified to run with newer JDKs) shows that a considerable time is spent creating and throwing internal exceptions like:
>   - `Infer$InferenceException`
>   - `Resolve$InapplicableMethodException`
>   - `Types$FunctionDescriptorLookupError`
> 
> These exceptions do not seem to leak outside javac and are only used to deliver asynchronous errors and related diagnostics. Stack trace does not seem relevant there and can be omitted. 
> 
> This patch improves `Compiler.compiler` and `Compiler.sunflow` benchmarks for about +4.3%. There is no measurable impact on JDK build times.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier2`
>  - [x] Linux x86_64 fastdebug `tier3`

This pull request has now been integrated.

Changeset: 3cd3a836
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3cd3a83647297f525f5eab48ce688e024ca6b08c
Stats:     27 lines in 3 files changed: 24 ins; 0 del; 3 mod

8284167: Make internal javac exceptions stackless

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/jdk/pull/8072

From naoto at openjdk.java.net  Wed Apr  6 17:52:08 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 17:52:08 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
Message-ID: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>

This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

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

Commit messages:
 - 8283698: Refactor Locale constructors used in src/test

Changes: https://git.openjdk.java.net/jdk/pull/8130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8130&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283698
  Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8130/head:pull/8130

PR: https://git.openjdk.java.net/jdk/pull/8130

From iris at openjdk.java.net  Wed Apr  6 19:36:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 6 Apr 2022 19:36:40 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <r5RSuZEt-YT0EOWQmAH1kV7c1apKvBn-ss866xTyF5E=.903a7419-865c-472e-9e20-632d882293e7@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 00:13:45 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:13:45 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:

> 79: 
> 80:     /**
> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");

Locale.France?

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 00:20:31 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:20:31 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <oWowG5ZF6uQhqEOWoDSp17TbGHZqZjmcaxL_5_yGxuU=.b7e9daaf-b3eb-4620-a0a6-01635f37e8ec@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/DateFormat/NonGregorianFormatTest.java line 131:

> 129: 
> 130:         // Tests with the Japanese imperial calendar
> 131:         Locale calendarLocale = Locale.of("ja", "JP", "JP");

Locale.JAPAN?

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 00:31:55 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:31:55 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <UYhQLIeSUDpGNeR1pFuD9ll9SIPZFAnzvRiX-rft8f8=.bdb3a956-ca7a-4523-87d6-71e9a12e5a76@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:

> 61:             Locale.of("it", "IT", "EURO"),
> 62:             Locale.forLanguageTag("de-AT"),
> 63:             Locale.forLanguageTag("fr-CH"),

Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.

test/jdk/java/text/Format/common/Bug6215962.java line 58:

> 56:         check(mf1, mf2, false);
> 57: 
> 58:         mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));

Locale.JAPAN?

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From naoto at openjdk.java.net  Thu Apr  7 01:19:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Apr 2022 01:19:35 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
Message-ID: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>

On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.
>
> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
> 
>> 79: 
>> 80:     /**
>> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
> 
> Locale.France?

The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here.

> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
> 
>> 61:             Locale.of("it", "IT", "EURO"),
>> 62:             Locale.forLanguageTag("de-AT"),
>> 63:             Locale.forLanguageTag("fr-CH"),
> 
> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.

`Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors.

> test/jdk/java/text/Format/common/Bug6215962.java line 58:
> 
>> 56:         check(mf1, mf2, false);
>> 57: 
>> 58:         mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));
> 
> Locale.JAPAN?

The test intends to compare the generated `MessageFormat` objects (`mf2` & `mf1`) from using a constant `Locale.JAPAN` and the factory method. So I believe leaving it as `Locale.of()` makes sense.

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From vromero at openjdk.java.net  Thu Apr  7 03:38:59 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 7 Apr 2022 03:38:59 GMT
Subject: RFR: 8284361: Updating ASM to 9.3 for JDK 19
Message-ID: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>

We recently updated our ASM version to 9.2 and just this week version 9.3 was announced with support for JDK19 so it makes sense to update to this last version.

Thanks in advance for the reviews,
Vicente

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

Commit messages:
 - updating test ValidateJarWithSealedAndRecord
 - adaptations after automatic conversion
 - 8284361: Updating ASM to 9.3 for JDK 19

Changes: https://git.openjdk.java.net/jdk/pull/8135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284361
  Stats: 438 lines in 57 files changed: 73 ins; 70 del; 295 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8135/head:pull/8135

PR: https://git.openjdk.java.net/jdk/pull/8135

From joehw at openjdk.java.net  Thu Apr  7 04:51:38 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:51:38 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
 <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
Message-ID: <0Zxp9nACKCy12wn8Viwd5lYHz3KXojuy02cZLiz8Wiw=.f1a9f3b3-8cfb-4845-87e7-bef9b69ada8a@github.com>

On Thu, 7 Apr 2022 01:16:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
>> 
>>> 79: 
>>> 80:     /**
>>> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
>> 
>> Locale.France?
>
> The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here.

I see.

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 04:59:39 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:59:39 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <c7WnJL_FTC92jBi5LhA8s1EA-5LMgBW7ucldQb0GQVk=.aa5aa4d7-07a4-4f44-ab61-e89f54adb1ec@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 04:59:40 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:59:40 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
 <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
Message-ID: <VhDD3losQJHv-SpTfyDeEG5Jb3lX9kYSQ9CoOMD2YIU=.47de2cb7-1289-4f2d-8648-c75320e44ac9@github.com>

On Thu, 7 Apr 2022 01:16:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
>> 
>>> 61:             Locale.of("it", "IT", "EURO"),
>>> 62:             Locale.forLanguageTag("de-AT"),
>>> 63:             Locale.forLanguageTag("fr-CH"),
>> 
>> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.
>
> `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors.

Ok, I didn't realize the existing method is preferred over the new method in creating a Locale. The javadoc does state that it does not make any syntactic checks. That's good to know.

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From ihse at openjdk.java.net  Fri Apr  8 15:06:00 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 8 Apr 2022 15:06:00 GMT
Subject: RFR: 8284588: Remove GensrcCommonLangtools.gmk
Message-ID: <oR42eaj3U52Fumte3mSQmP0EwgR93eZ16gZ6OTCW0Ok=.e79ccbc4-f266-4b45-aebb-027cef0947a5@github.com>

There's been unnecessary (near) duplication of functionality, and messy logic, in the langtools gensrc step, for a long time. (Basically since we got rid of the mercurial forest...)

This is a first attempt at cleaning this up. The file GensrcCommonLangtools.gmk is removed. This contained three pieces of functionality. 

* SetupVersionProperties was moved to GensrcCommonJdk.gmk (which was renamed to GensrcCommon.gmk). 
* PropertiesParser was only used in one place, and moved there. (jdk.compiler/Gensrc.gmk). It was also heavily rewritten to show more clearly what it actually is doing.
* SetupCompileProperties (from langtools) were replaced with calls to SetupCompileProperties (from GensrcCommon/"jdk"), which was modified slightly to accomodate for the differences. (Also the Java tool needed to be slightly modified to accept the same syntax as the JDK version of this tool.)

A reasonable follow-up is to research if the two SetupCompileProperties tools can be unified into one.

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

Commit messages:
 - Unify SetupCompilePropertiesLangtools with SetupCompileProperties
 - Get rid of GensrcCommonLangtools.gmk
 - Clean up parseproperties

Changes: https://git.openjdk.java.net/jdk/pull/8167/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8167&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284588
  Stats: 367 lines in 21 files changed: 124 ins; 185 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8167/head:pull/8167

PR: https://git.openjdk.java.net/jdk/pull/8167

From naoto at openjdk.java.net  Fri Apr  8 15:26:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Apr 2022 15:26:35 GMT
Subject: Integrated: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <r6its8TfgpC32jQ7YIdERQEA2ElBz-DOEd9zkKv5vGY=.38b6000b-7b2b-4180-8981-19fc570c322a@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

This pull request has now been integrated.

Changeset: d6b4693c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6b4693c0527385f8999089b3f8b2120548efecb
Stats:     750 lines in 182 files changed: 3 ins; 3 del; 744 mod

8283698: Refactor Locale constructors used in src/test

Reviewed-by: iris, joehw

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

PR: https://git.openjdk.java.net/jdk/pull/8130

From mchung at openjdk.java.net  Fri Apr  8 16:47:54 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 8 Apr 2022 16:47:54 GMT
Subject: RFR: 8284361: Updating ASM to 9.3 for JDK 19
In-Reply-To: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
References: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
Message-ID: <B37CXk2dVwFAFS9V0crI8Lm4gIfHTwd7_a1Gu-aWeh0=.2628f335-5335-4c57-a8fd-feae1717098e@github.com>

On Thu, 7 Apr 2022 03:33:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> We recently updated our ASM version to 9.2 and just this week version 9.3 was announced with support for JDK19 so it makes sense to update to this last version.
> 
> Thanks in advance for the reviews,
> Vicente

Looks okay.   Most of the changes is in javadoc and rename `var` to `varIndex`.  The change in ASMifier looks good.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8135

From vromero at openjdk.java.net  Fri Apr  8 16:59:35 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 8 Apr 2022 16:59:35 GMT
Subject: RFR: 8284361: Updating ASM to 9.3 for JDK 19
In-Reply-To: <B37CXk2dVwFAFS9V0crI8Lm4gIfHTwd7_a1Gu-aWeh0=.2628f335-5335-4c57-a8fd-feae1717098e@github.com>
References: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
 <B37CXk2dVwFAFS9V0crI8Lm4gIfHTwd7_a1Gu-aWeh0=.2628f335-5335-4c57-a8fd-feae1717098e@github.com>
Message-ID: <KsoQYl3H2Z6Q_rgwz2bX-xZbazTBJUDHfkm-oRW7Cr0=.8fd38104-23ca-44de-b3c8-517ef677432d@github.com>

On Fri, 8 Apr 2022 16:44:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> We recently updated our ASM version to 9.2 and just this week version 9.3 was announced with support for JDK19 so it makes sense to update to this last version.
>> 
>> Thanks in advance for the reviews,
>> Vicente
>
> Looks okay.   Most of the changes is in javadoc and rename `var` to `varIndex`.  The change in ASMifier looks good.

thanks @mlchung for the review

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

PR: https://git.openjdk.java.net/jdk/pull/8135

From vromero at openjdk.java.net  Fri Apr  8 17:04:42 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 8 Apr 2022 17:04:42 GMT
Subject: Integrated: 8284361: Updating ASM to 9.3 for JDK 19
In-Reply-To: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
References: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
Message-ID: <mvuIv28zWYOe-t_QL5ZBeTysMYB3IMbOh9vGeonYcJA=.86409f34-bdd3-4fbe-bd59-f716de3bb6e2@github.com>

On Thu, 7 Apr 2022 03:33:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> We recently updated our ASM version to 9.2 and just this week version 9.3 was announced with support for JDK19 so it makes sense to update to this last version.
> 
> Thanks in advance for the reviews,
> Vicente

This pull request has now been integrated.

Changeset: 1bd8975c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1bd8975cafade1234f653ab994cb7c6f0a82590f
Stats:     438 lines in 57 files changed: 73 ins; 70 del; 295 mod

8284361: Updating ASM to 9.3 for JDK 19

Reviewed-by: mchung

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

PR: https://git.openjdk.java.net/jdk/pull/8135

From erikj at openjdk.java.net  Fri Apr  8 17:10:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 8 Apr 2022 17:10:35 GMT
Subject: RFR: 8284588: Remove GensrcCommonLangtools.gmk
In-Reply-To: <oR42eaj3U52Fumte3mSQmP0EwgR93eZ16gZ6OTCW0Ok=.e79ccbc4-f266-4b45-aebb-027cef0947a5@github.com>
References: <oR42eaj3U52Fumte3mSQmP0EwgR93eZ16gZ6OTCW0Ok=.e79ccbc4-f266-4b45-aebb-027cef0947a5@github.com>
Message-ID: <iy9MZ3UyLV0zQPrPm20PKyvHXzDdeob1_z7T3RG9DAg=.73774e68-1e9d-4350-9e5c-c3f28e796cf0@github.com>

On Fri, 8 Apr 2022 14:57:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There's been unnecessary (near) duplication of functionality, and messy logic, in the langtools gensrc step, for a long time. (Basically since we got rid of the mercurial forest...)
> 
> This is a first attempt at cleaning this up. The file GensrcCommonLangtools.gmk is removed. This contained three pieces of functionality. 
> 
> * SetupVersionProperties was moved to GensrcCommonJdk.gmk (which was renamed to GensrcCommon.gmk). 
> * PropertiesParser was only used in one place, and moved there. (jdk.compiler/Gensrc.gmk). It was also heavily rewritten to show more clearly what it actually is doing.
> * SetupCompileProperties (from langtools) were replaced with calls to SetupCompileProperties (from GensrcCommon/"jdk"), which was modified slightly to accomodate for the differences. (Also the Java tool needed to be slightly modified to accept the same syntax as the JDK version of this tool.)
> 
> A reasonable follow-up is to research if the two SetupCompileProperties tools can be unified into one.

Marked as reviewed by erikj (Reviewer).

make/modules/jdk.compiler/Gensrc.gmk line 63:

> 61:     $(PARSEPROPERTIES_FILES))
> 62: 
> 63: PARSEPROPERTIES_ARGS := $(foreach file, $(PARSEPROPERTIES_FILES), \

This could be simplified by iterating over PARSEPROPERTIES_SRC.

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

PR: https://git.openjdk.java.net/jdk/pull/8167

From ihse at openjdk.java.net  Fri Apr  8 20:22:40 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 8 Apr 2022 20:22:40 GMT
Subject: RFR: 8284588: Remove GensrcCommonLangtools.gmk
In-Reply-To: <iy9MZ3UyLV0zQPrPm20PKyvHXzDdeob1_z7T3RG9DAg=.73774e68-1e9d-4350-9e5c-c3f28e796cf0@github.com>
References: <oR42eaj3U52Fumte3mSQmP0EwgR93eZ16gZ6OTCW0Ok=.e79ccbc4-f266-4b45-aebb-027cef0947a5@github.com>
 <iy9MZ3UyLV0zQPrPm20PKyvHXzDdeob1_z7T3RG9DAg=.73774e68-1e9d-4350-9e5c-c3f28e796cf0@github.com>
Message-ID: <k_H9HoUyPFP3JWCFwwwhjh4kmidTHtoay49wydccvx8=.820ffb95-8a51-4e02-903a-ba0300ef0bed@github.com>

On Fri, 8 Apr 2022 16:59:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> There's been unnecessary (near) duplication of functionality, and messy logic, in the langtools gensrc step, for a long time. (Basically since we got rid of the mercurial forest...)
>> 
>> This is a first attempt at cleaning this up. The file GensrcCommonLangtools.gmk is removed. This contained three pieces of functionality. 
>> 
>> * SetupVersionProperties was moved to GensrcCommonJdk.gmk (which was renamed to GensrcCommon.gmk). 
>> * PropertiesParser was only used in one place, and moved there. (jdk.compiler/Gensrc.gmk). It was also heavily rewritten to show more clearly what it actually is doing.
>> * SetupCompileProperties (from langtools) were replaced with calls to SetupCompileProperties (from GensrcCommon/"jdk"), which was modified slightly to accomodate for the differences. (Also the Java tool needed to be slightly modified to accept the same syntax as the JDK version of this tool.)
>> 
>> A reasonable follow-up is to research if the two SetupCompileProperties tools can be unified into one.
>
> make/modules/jdk.compiler/Gensrc.gmk line 63:
> 
>> 61:     $(PARSEPROPERTIES_FILES))
>> 62: 
>> 63: PARSEPROPERTIES_ARGS := $(foreach file, $(PARSEPROPERTIES_FILES), \
> 
> This could be simplified by iterating over PARSEPROPERTIES_SRC.

Indeed. :) I am a bit amazed that this code still had potential to be even more simplified. I don't even remember how much junk I throw away, and I still missed this.

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

PR: https://git.openjdk.java.net/jdk/pull/8167

From ihse at openjdk.java.net  Fri Apr  8 20:31:45 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 8 Apr 2022 20:31:45 GMT
Subject: RFR: 8284588: Remove GensrcCommonLangtools.gmk [v2]
In-Reply-To: <oR42eaj3U52Fumte3mSQmP0EwgR93eZ16gZ6OTCW0Ok=.e79ccbc4-f266-4b45-aebb-027cef0947a5@github.com>
References: <oR42eaj3U52Fumte3mSQmP0EwgR93eZ16gZ6OTCW0Ok=.e79ccbc4-f266-4b45-aebb-027cef0947a5@github.com>
Message-ID: <6ohy0os5i9lILr6C7zbc5XrO9K91lI4WK6mAm3rI4JE=.ba0aef8d-91f7-496c-9d7d-faa90dc3e06e@github.com>

> There's been unnecessary (near) duplication of functionality, and messy logic, in the langtools gensrc step, for a long time. (Basically since we got rid of the mercurial forest...)
> 
> This is a first attempt at cleaning this up. The file GensrcCommonLangtools.gmk is removed. This contained three pieces of functionality. 
> 
> * SetupVersionProperties was moved to GensrcCommonJdk.gmk (which was renamed to GensrcCommon.gmk). 
> * PropertiesParser was only used in one place, and moved there. (jdk.compiler/Gensrc.gmk). It was also heavily rewritten to show more clearly what it actually is doing.
> * SetupCompileProperties (from langtools) were replaced with calls to SetupCompileProperties (from GensrcCommon/"jdk"), which was modified slightly to accomodate for the differences. (Also the Java tool needed to be slightly modified to accept the same syntax as the JDK version of this tool.)
> 
> A reasonable follow-up is to research if the two SetupCompileProperties tools can be unified into one.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Simplify PARSEPROPERTIES_ARGS

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8167/files
  - new: https://git.openjdk.java.net/jdk/pull/8167/files/11ede464..e84aa180

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8167&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8167&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8167

From ihse at openjdk.java.net  Fri Apr  8 20:36:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 8 Apr 2022 20:36:46 GMT
Subject: Integrated: 8284588: Remove GensrcCommonLangtools.gmk
In-Reply-To: <oR42eaj3U52Fumte3mSQmP0EwgR93eZ16gZ6OTCW0Ok=.e79ccbc4-f266-4b45-aebb-027cef0947a5@github.com>
References: <oR42eaj3U52Fumte3mSQmP0EwgR93eZ16gZ6OTCW0Ok=.e79ccbc4-f266-4b45-aebb-027cef0947a5@github.com>
Message-ID: <13Hgrf1QtyeX5wKD5HDliXwYgfckab6RPSVUDAJLw8E=.b809f75c-78c5-4568-a965-7452a65fe758@github.com>

On Fri, 8 Apr 2022 14:57:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There's been unnecessary (near) duplication of functionality, and messy logic, in the langtools gensrc step, for a long time. (Basically since we got rid of the mercurial forest...)
> 
> This is a first attempt at cleaning this up. The file GensrcCommonLangtools.gmk is removed. This contained three pieces of functionality. 
> 
> * SetupVersionProperties was moved to GensrcCommonJdk.gmk (which was renamed to GensrcCommon.gmk). 
> * PropertiesParser was only used in one place, and moved there. (jdk.compiler/Gensrc.gmk). It was also heavily rewritten to show more clearly what it actually is doing.
> * SetupCompileProperties (from langtools) were replaced with calls to SetupCompileProperties (from GensrcCommon/"jdk"), which was modified slightly to accomodate for the differences. (Also the Java tool needed to be slightly modified to accept the same syntax as the JDK version of this tool.)
> 
> A reasonable follow-up is to research if the two SetupCompileProperties tools can be unified into one.

This pull request has now been integrated.

Changeset: 3357d9a1
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3357d9a168f031e1de4fa0d203f16a6f060fd062
Stats:     367 lines in 21 files changed: 124 ins; 185 del; 58 mod

8284588: Remove GensrcCommonLangtools.gmk

Reviewed-by: erikj

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

PR: https://git.openjdk.java.net/jdk/pull/8167

From ksakata at openjdk.java.net  Mon Apr 11 05:39:11 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Mon, 11 Apr 2022 05:39:11 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale is
 ja or zh_CN
Message-ID: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>

# Summary
Running jdeprscan with --help option causes an exception on any OSs when the locale is ja or zh_CN.

# How to reproduce this issue

$ jdeprscan -J-Duser.language=ja --help
Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
        at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
        at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
        at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
        at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
        at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
        at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
        at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
        at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
        at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
        at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
        at java.base/java.lang.Integer.parseInt(Integer.java:668)
        at java.base/java.lang.Integer.parseInt(Integer.java:786)
        at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
        ... 8 more

$ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
?Same as above?

Of course, it works well when the locale is anything other than those locales.

# Details
I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 

I removed extra single quotes.

# Test
It seems there is no test class for it. So I run commands as I mentioned before.

$ jdeprscan -J-Duser.language=ja --help
????: jdeprscan [options] {dir|jar|class} ...

?????:
        --class-path PATH
        --for-removal
        --full-version
  -? -h --help
  -l    --list
        --release 7|8|9|10|11|12|13|14|15|16|17|18|19
  -v    --verbose
        --version

???API????????????????????????
???????????????????????JAR?????
?????????????????????????????
???????????????????????????????
????$????????:

    java.lang.Thread$State

--class-path?????????????????????
???????????

--for-removal??????????????????????????API?
????????????6?7???8????????????

--full-version????????????????????????????

--help (-? -h)?????????????????????????

--list (-l)?????????API???????????????????????
???????JAR??????????????????????

--release????????????????API?????????Java SE
???????????

--verbose (-v)????????????????????????????????

--version????????????????????????????????

$ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
???jdeprscan [options] {dir|jar|class} ...

???
        --class-path PATH
        --for-removal
        --full-version
  -? -h --help
  -l    --list
        --release 7|8|9|10|11|12|13|14|15|16|17|18|19
  -v    --verbose
        --version

????????????????? API?
???????????????JAR ???
????????????????
????????????? $ ???
?????????

    java.lang.Thread$State

--class-path ?????????????
?????

--for-removal ????????????????
? API???????? 6?7 ? 8 ?????

--full-version ???????????????

--help (-? -h) ????????????

--list (-l) ?????????? API???????
???????????jar ?????

--release ????????????? API ?
? Java SE ????

--verbose (-v) ????????????????

--version ???????????????

$ jdeprscan -J-Duser.language=en --help                    
Usage: jdeprscan [options] {dir|jar|class} ...

options:
        --class-path PATH
        --for-removal
        --full-version
  -? -h --help
  -l    --list
        --release 7|8|9|10|11|12|13|14|15|16|17|18|19
  -v    --verbose
        --version

Scans each argument for usages of deprecated APIs. An argument
may be a directory specifying the root of a package hierarchy,
a JAR file, a class file, or a class name. The class name must be
specified using a fully qualified class name using the $ separator
character for nested classes, for example,

    java.lang.Thread$State

The --class-path option provides a search path for resolution
of dependent classes.

The --for-removal option limits scanning or listing to APIs that are
deprecated for removal. Cannot be used with a release value of 6, 7, or 8.

The --full-version option prints out the full version string of the tool.

The --help (-? -h) option prints out a full help message.

The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
so no directory, jar, or class arguments should be provided.

The --release option specifies the Java SE release that provides the set
of deprecated APIs for scanning.

The --verbose (-v) option enables additional message output during processing.

The --version option prints out the abbreviated version string of the tool.

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

Commit messages:
 - Remove unnecessary single quotes

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

PR: https://git.openjdk.java.net/jdk/pull/8174

From rgoers at apache.org  Mon Apr 11 08:43:01 2022
From: rgoers at apache.org (Ralph Goers)
Date: Mon, 11 Apr 2022 10:43:01 +0200
Subject: File name, method name, and line number constants
Message-ID: <CFB423B1-0FD9-4A97-8915-20CF00B16463@apache.org>

Logging frameworks such as Log4j 2 provide the ability to include the caller?s line number, method name, class name, file name, and possibly module name in every log event. Currently, collecting this data requires a call to StackWalker for every event logged. This is very expensive. Since this information could be determined at compile time it seems logical that the compiler could inject it where requested. For example, a logging call like:

logger.debug(System.currentStackTraceElement(), ?log message?);

Could have the call to currentStackTraceElement() replaced by the compiler with a constant StackTraceElement containing the correct information. This would result in zero overhead at runtime instead of expensive call we have to perform now. It would have the drawback that uses would have to add that to the method invocation but that is a small price to pay for the efficiency gain.

Cound this, or something like it, be added?

Ralph

From mcimadamore at openjdk.java.net  Mon Apr 11 12:47:40 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 11 Apr 2022 12:47:40 GMT
Subject: RFR: 8284308: mismatch between key and content in compiler error
 message
In-Reply-To: <BYRk0dMdVuJLrgXO9Hm5sKhl0oS0oW_WMhaUHGfTsls=.d65cc3d4-a5bb-4a9f-9dc3-2ac4fe68f700@github.com>
References: <BYRk0dMdVuJLrgXO9Hm5sKhl0oS0oW_WMhaUHGfTsls=.d65cc3d4-a5bb-4a9f-9dc3-2ac4fe68f700@github.com>
Message-ID: <K3obWSJEC9YS9EubbWIsCWlUiKWrLyS9AH-1ywazIcE=.0d87c995-6d92-4749-886e-fd07c36131e5@github.com>

On Mon, 4 Apr 2022 21:35:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This compiler error message:
> 
> compiler.misc.upper.bounds=\
>         lower bounds: {0}
> 
> had a clear mismatch between its key and its contents. It should be:
> 
> compiler.misc.upper.bounds=\
>         upper bounds: {0}
> 
> TIA

Looks good! Some of the inference compiler messages left me scratching my head because of this :-)

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8099

From vromero at openjdk.java.net  Mon Apr 11 14:42:41 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 11 Apr 2022 14:42:41 GMT
Subject: RFR: 8284308: mismatch between key and content in compiler error
 message
In-Reply-To: <BYRk0dMdVuJLrgXO9Hm5sKhl0oS0oW_WMhaUHGfTsls=.d65cc3d4-a5bb-4a9f-9dc3-2ac4fe68f700@github.com>
References: <BYRk0dMdVuJLrgXO9Hm5sKhl0oS0oW_WMhaUHGfTsls=.d65cc3d4-a5bb-4a9f-9dc3-2ac4fe68f700@github.com>
Message-ID: <-JaA7qZRk9m5nnS4cflX9ToHBWQ_ytUq6ZuVysUB1ac=.76f118ca-f3aa-44b2-9753-f3e0fc79fda0@github.com>

On Mon, 4 Apr 2022 21:35:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This compiler error message:
> 
> compiler.misc.upper.bounds=\
>         lower bounds: {0}
> 
> had a clear mismatch between its key and its contents. It should be:
> 
> compiler.misc.upper.bounds=\
>         upper bounds: {0}
> 
> TIA

thanks for the review

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

PR: https://git.openjdk.java.net/jdk/pull/8099

From jlahoda at openjdk.java.net  Mon Apr 11 16:45:18 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 11 Apr 2022 16:45:18 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for switch
 (Third Preview)
Message-ID: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>

This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).

Draft JLS:
http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html

The changes are:
-there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
-a new contextual keyword `when` is used to add a guard, instead of `&&`
-`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
-total patterns are allowed in `instanceof`
-`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.

Feedback is welcome!

Thanks!

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

Commit messages:
 - Adding a test for a NPE from guards.
 - Cleanup
 - Merge branch 'master' into type-patterns-third
 - Guards should be a property of (pattern) case labels, not cases.
 - Merge branch 'master' into type-patterns-third
 - Adding MatchException.
 - Merge branch 'switch-null' into type-patterns-third
 - Updating null handling.
 - Merge branch 'case-guard' into type-patterns-third
 - Moving guards to cases.
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/d6f01e9d...da8401d4

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282274
  Stats: 824 lines in 49 files changed: 392 ins; 245 del; 187 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From jesper at selskabet.org  Mon Apr 11 18:27:34 2022
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Mon, 11 Apr 2022 20:27:34 +0200
Subject: File name, method name, and line number constants
In-Reply-To: <CFB423B1-0FD9-4A97-8915-20CF00B16463@apache.org>
References: <CFB423B1-0FD9-4A97-8915-20CF00B16463@apache.org>
Message-ID: <AE67989F-3FBC-4BD6-948C-DEF6BC7C80CD@selskabet.org>

Hi Ralph,

If I understand correctly, you?re requesting a mechanism for a kind of compiler-?intrinsic? feature. However, such an optimization can fairly easily be provided today, e.g. using an agent where the calling bytecode is rewritten, perhaps in concert with the dynamic constant features of the JVM.

Adding runtime or language features is expensive in terms of future maintenance - reusing existing facilities is IMHO the preferable approach to solving this kind of problem. There are intrinsics in the JVM (and even in the language) for stuff like MethodHandle, but new features should be saved for the situations where there are no workarounds available and such features would unlock novel uses or long-standing pains of the platform. Project Panama is one such example, I suppose, where a similar agent-based approach wouldn?t cut it, and real JVM-level untrinsics are used instead.

By the way, this list is dedicated to development of the ?javac?-compiler, and not to Java language suggestions as such.

-Jesper

> On 11 Apr 2022, at 10.44, Ralph Goers <rgoers at apache.org> wrote:
> 
> ?Logging frameworks such as Log4j 2 provide the ability to include the caller?s line number, method name, class name, file name, and possibly module name in every log event. Currently, collecting this data requires a call to StackWalker for every event logged. This is very expensive. Since this information could be determined at compile time it seems logical that the compiler could inject it where requested. For example, a logging call like:
> 
> logger.debug(System.currentStackTraceElement(), ?log message?);
> 
> Could have the call to currentStackTraceElement() replaced by the compiler with a constant StackTraceElement containing the correct information. This would result in zero overhead at runtime instead of expensive call we have to perform now. It would have the drawback that uses would have to add that to the method invocation but that is a small price to pay for the efficiency gain.
> 
> Cound this, or something like it, be added?
> 
> Ralph

From naoto at openjdk.java.net  Mon Apr 11 20:29:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 11 Apr 2022 20:29:38 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja or zh_CN
In-Reply-To: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
Message-ID: <i73iYGcTunQ7rK_EtWiIYDRcrGQF_UHcc0cmSvVPNOg=.4252c19e-3c62-4e3c-a54a-85393de12847@github.com>

On Mon, 11 Apr 2022 05:31:49 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> # Summary
> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja or zh_CN.
> 
> # How to reproduce this issue
> 
> $ jdeprscan -J-Duser.language=ja --help
> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>         ... 8 more
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ?Same as above?
> 
> Of course, it works well when the locale is anything other than those locales.
> 
> # Details
> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
> 
> I removed extra single quotes.
> 
> # Test
> It seems there is no test class for it. So I run commands as I mentioned before.
> 
> $ jdeprscan -J-Duser.language=ja --help
> ????: jdeprscan [options] {dir|jar|class} ...
> 
> ?????:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ???API????????????????????????
> ???????????????????????JAR?????
> ?????????????????????????????
> ???????????????????????????????
> ????$????????:
> 
>     java.lang.Thread$State
> 
> --class-path?????????????????????
> ???????????
> 
> --for-removal??????????????????????????API?
> ????????????6?7???8????????????
> 
> --full-version????????????????????????????
> 
> --help (-? -h)?????????????????????????
> 
> --list (-l)?????????API???????????????????????
> ???????JAR??????????????????????
> 
> --release????????????????API?????????Java SE
> ???????????
> 
> --verbose (-v)????????????????????????????????
> 
> --version????????????????????????????????
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ???jdeprscan [options] {dir|jar|class} ...
> 
> ???
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ????????????????? API?
> ???????????????JAR ???
> ????????????????
> ????????????? $ ???
> ?????????
> 
>     java.lang.Thread$State
> 
> --class-path ?????????????
> ?????
> 
> --for-removal ????????????????
> ? API???????? 6?7 ? 8 ?????
> 
> --full-version ???????????????
> 
> --help (-? -h) ????????????
> 
> --list (-l) ?????????? API???????
> ???????????jar ?????
> 
> --release ????????????? API ?
> ? Java SE ????
> 
> --verbose (-v) ????????????????
> 
> --version ???????????????
> 
> $ jdeprscan -J-Duser.language=en --help                    
> Usage: jdeprscan [options] {dir|jar|class} ...
> 
> options:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scans each argument for usages of deprecated APIs. An argument
> may be a directory specifying the root of a package hierarchy,
> a JAR file, a class file, or a class name. The class name must be
> specified using a fully qualified class name using the $ separator
> character for nested classes, for example,
> 
>     java.lang.Thread$State
> 
> The --class-path option provides a search path for resolution
> of dependent classes.
> 
> The --for-removal option limits scanning or listing to APIs that are
> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
> 
> The --full-version option prints out the full version string of the tool.
> 
> The --help (-? -h) option prints out a full help message.
> 
> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
> so no directory, jar, or class arguments should be provided.
> 
> The --release option specifies the Java SE release that provides the set
> of deprecated APIs for scanning.
> 
> The --verbose (-v) option enables additional message output during processing.
> 
> The --version option prints out the abbreviated version string of the tool.

Looks good to me. Would you be able to apply the same fix to German bundle (jdeprscan_de.properties)?

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

PR: https://git.openjdk.java.net/jdk/pull/8174

From cushon at google.com  Mon Apr 11 20:40:55 2022
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 11 Apr 2022 13:40:55 -0700
Subject: Approach for JDK-8225377: type annotations are not visible to
 javac plugins across compilation boundaries
In-Reply-To: <CAL4Qsgv67JiXRiBA+gDC0G0XNka7VGLmKef-DbcHQ0_Mxyy4Ww@mail.gmail.com>
References: <CAL4Qsgv67JiXRiBA+gDC0G0XNka7VGLmKef-DbcHQ0_Mxyy4Ww@mail.gmail.com>
Message-ID: <CAL4QsgvtfJ5GyNkQ_3n=3khv2kTpiqBwmAQrZi1j3nc1wcx5Bw@mail.gmail.com>

Hello again,

I'm inferring that there isn't overwhelming interest in reviewing a fix for
this :)

I'm still interested in whether anyone knows additional history here, or
has ideas about a simpler approach that I might be missing.

We're interested in this because we want to be able to define @Nullable as
a type-use annotation, instead of a declaration annotation. We rely on
annotation processors being able to inspect nullable annotations. Today, if
you define a method `@Nullable String foo();` and load it from the
classpath, an annotation processor can only see the annotation if it is a
declaration annotation on the method element (vs. type-use annotation on
the return type).

Even a limited fix would be helpful here. If the fix didn't cover the full
range of locations that type-use annotations can appear, but only the ones
where either a type use or declaration annotation can appear in source
(method declarations, fields, etc.), that would avoid surprises when
migrating from declaration annotations to type-use annotations.

Any thoughts on this are welcome.

Thanks,
Liam

On Tue, Mar 1, 2022 at 10:36 AM Liam Miller-Cushon <cushon at google.com>
wrote:

> Hello,
>
> I'm interested in trying to help with
> https://bugs.openjdk.java.net/browse/JDK-8225377 (type annotations are
> not visible to javac plugins across compilation boundaries).
>
> The issue described in the bug is that type annotations are not currently
> associated with some TypeMirrors loaded from the classpath. For example,
> TypeMirror#getAnnotationMirrors for the return type of a method does not
> report type annotations if the method was loaded from the classpath, but it
> does work for elements compiled from source in the current compilation.
>
> What I understand so far is:
>
> * the ClassReader reads in the full *TypeAnnotations attributes, including
> type paths
> * it creates a TypeAnnotationCompleter that saves the type annotations to
> the associated Symbol using Symbol#setTypeAttributes
> * the Symbol never associates the type annotations with their
> corresponding types, e.g. a MethodSymbol does not attach annotations to its
> return type
>
> It seems like there's logic missing to interpret the type paths read from
> class files and attach them to the appropriate type model element. This
> would be somewhat similar to the logic in core reflection that handles type
> paths and deals with reporting type annotations on the correct type [1].
>
> I'm wondering if I'm missing something, is there any prior work in javac
> to interpret type paths read from class files? If not, would there be
> interest in accepting that as a contribution? It would add some complexity
> and potential overhead, but I'm not seeing a good alternative to fix
> TypeMirror#getAnnotationMirrors for types read from class files.
>
> [1]
> https://github.com/openjdk/jdk/blob/d983d108c565654e717e2811d88aa94d982da2f5/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java#L194
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220411/8bba09d5/attachment.htm>

From vromero at openjdk.java.net  Mon Apr 11 21:02:45 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 11 Apr 2022 21:02:45 GMT
Subject: Integrated: 8284308: mismatch between key and content in compiler
 error message
In-Reply-To: <BYRk0dMdVuJLrgXO9Hm5sKhl0oS0oW_WMhaUHGfTsls=.d65cc3d4-a5bb-4a9f-9dc3-2ac4fe68f700@github.com>
References: <BYRk0dMdVuJLrgXO9Hm5sKhl0oS0oW_WMhaUHGfTsls=.d65cc3d4-a5bb-4a9f-9dc3-2ac4fe68f700@github.com>
Message-ID: <NZMnZIaFiqIopzi1WhXXZZJOAR0J75czw7A7bU-4YI4=.82527050-2643-4bd5-a97d-081f68c301b6@github.com>

On Mon, 4 Apr 2022 21:35:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This compiler error message:
> 
> compiler.misc.upper.bounds=\
>         lower bounds: {0}
> 
> had a clear mismatch between its key and its contents. It should be:
> 
> compiler.misc.upper.bounds=\
>         upper bounds: {0}
> 
> TIA

This pull request has now been integrated.

Changeset: 4e165f66
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4e165f66a954dd7fab4b6dab584c4da060f6a48e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8284308: mismatch between key and content in compiler error message

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/jdk/pull/8099

From rgoers at apache.org  Mon Apr 11 22:44:43 2022
From: rgoers at apache.org (Ralph Goers)
Date: Tue, 12 Apr 2022 00:44:43 +0200
Subject: File name, method name, and line number constants
In-Reply-To: <AE67989F-3FBC-4BD6-948C-DEF6BC7C80CD@selskabet.org>
References: <CFB423B1-0FD9-4A97-8915-20CF00B16463@apache.org>
 <AE67989F-3FBC-4BD6-948C-DEF6BC7C80CD@selskabet.org>
Message-ID: <68494417-A3F2-4F5E-9A94-A21CA691C998@apache.org>

Yes, I understand this list is for the development of the javac compiler but since what I am asking for would be implemented by the javac compiler it seemed like the right place to start. I am sure that the information I am asking for is not the only information that would be good to have. I?ve often wondered why it doesn?t as it surely must have been considered at some point. 

Although I haven?t looked at using an agent, Log4j already has an annotation processor which I have thought about updating for this. But when I looked at that I didn?t see how it could get any of the information either.

Ralph


> On Apr 11, 2022, at 8:27 PM, Jesper Steen M?ller <jesper at selskabet.org> wrote:
> 
> Hi Ralph,
> 
> If I understand correctly, you?re requesting a mechanism for a kind of compiler-?intrinsic? feature. However, such an optimization can fairly easily be provided today, e.g. using an agent where the calling bytecode is rewritten, perhaps in concert with the dynamic constant features of the JVM.
> 
> Adding runtime or language features is expensive in terms of future maintenance - reusing existing facilities is IMHO the preferable approach to solving this kind of problem. There are intrinsics in the JVM (and even in the language) for stuff like MethodHandle, but new features should be saved for the situations where there are no workarounds available and such features would unlock novel uses or long-standing pains of the platform. Project Panama is one such example, I suppose, where a similar agent-based approach wouldn?t cut it, and real JVM-level untrinsics are used instead.
> 
> By the way, this list is dedicated to development of the ?javac?-compiler, and not to Java language suggestions as such.
> 
> -Jesper
> 
>> On 11 Apr 2022, at 10.44, Ralph Goers <rgoers at apache.org> wrote:
>> 
>> ?Logging frameworks such as Log4j 2 provide the ability to include the caller?s line number, method name, class name, file name, and possibly module name in every log event. Currently, collecting this data requires a call to StackWalker for every event logged. This is very expensive. Since this information could be determined at compile time it seems logical that the compiler could inject it where requested. For example, a logging call like:
>> 
>> logger.debug(System.currentStackTraceElement(), ?log message?);
>> 
>> Could have the call to currentStackTraceElement() replaced by the compiler with a constant StackTraceElement containing the correct information. This would result in zero overhead at runtime instead of expensive call we have to perform now. It would have the drawback that uses would have to add that to the method invocation but that is a small price to pay for the efficiency gain.
>> 
>> Cound this, or something like it, be added?
>> 
>> Ralph


From ksakata at openjdk.java.net  Tue Apr 12 06:36:29 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 12 Apr 2022 06:36:29 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja, zh_CN or de [v2]
In-Reply-To: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
Message-ID: <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>

> # Summary
> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
> 
> # How to reproduce this issue
> 
> $ jdeprscan -J-Duser.language=ja --help
> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>         ... 8 more
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ?Same as above?
> 
> $ jdeprscan -J-Duser.language=de --help
> ?Same as above?
> 
> Of course, it works well when the locale is anything other than those locales.
> 
> # Details
> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
> 
> I removed extra single quotes.
> 
> # Test
> It seems there is no test class for it. So I run commands as I mentioned before.
> 
> $ jdeprscan -J-Duser.language=ja --help
> ????: jdeprscan [options] {dir|jar|class} ...
> 
> ?????:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ???API????????????????????????
> ???????????????????????JAR?????
> ?????????????????????????????
> ???????????????????????????????
> ????$????????:
> 
>     java.lang.Thread$State
> 
> --class-path?????????????????????
> ???????????
> 
> --for-removal??????????????????????????API?
> ????????????6?7???8????????????
> 
> --full-version????????????????????????????
> 
> --help (-? -h)?????????????????????????
> 
> --list (-l)?????????API???????????????????????
> ???????JAR??????????????????????
> 
> --release????????????????API?????????Java SE
> ???????????
> 
> --verbose (-v)????????????????????????????????
> 
> --version????????????????????????????????
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ???jdeprscan [options] {dir|jar|class} ...
> 
> ???
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ????????????????? API?
> ???????????????JAR ???
> ????????????????
> ????????????? $ ???
> ?????????
> 
>     java.lang.Thread$State
> 
> --class-path ?????????????
> ?????
> 
> --for-removal ????????????????
> ? API???????? 6?7 ? 8 ?????
> 
> --full-version ???????????????
> 
> --help (-? -h) ????????????
> 
> --list (-l) ?????????? API???????
> ???????????jar ?????
> 
> --release ????????????? API ?
> ? Java SE ????
> 
> --verbose (-v) ????????????????
> 
> --version ???????????????
> 
> $ jdeprscan -J-Duser.language=de --help
> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
> 
> Optionen:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
> f?r verschachtelte Klassen angegeben werden. Beispiel:
> 
>     java.lang.Thread$State
> 
> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
> von abh?ngigen Klassen.
> 
> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
> 
> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
> 
> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
> 
> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
> 
> Die Option --release gibt das Java SE-Release an, das die Gruppe
> der veralteten APIS zum Scannen liefert.
> 
> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
> 
> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
> 
> $ jdeprscan -J-Duser.language=en --help                    
> Usage: jdeprscan [options] {dir|jar|class} ...
> 
> options:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scans each argument for usages of deprecated APIs. An argument
> may be a directory specifying the root of a package hierarchy,
> a JAR file, a class file, or a class name. The class name must be
> specified using a fully qualified class name using the $ separator
> character for nested classes, for example,
> 
>     java.lang.Thread$State
> 
> The --class-path option provides a search path for resolution
> of dependent classes.
> 
> The --for-removal option limits scanning or listing to APIs that are
> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
> 
> The --full-version option prints out the full version string of the tool.
> 
> The --help (-? -h) option prints out a full help message.
> 
> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
> so no directory, jar, or class arguments should be provided.
> 
> The --release option specifies the Java SE release that provides the set
> of deprecated APIs for scanning.
> 
> The --verbose (-v) option enables additional message output during processing.
> 
> The --version option prints out the abbreviated version string of the tool.

Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary single quotes in the German file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8174/files
  - new: https://git.openjdk.java.net/jdk/pull/8174/files/71e3c897..9cd56ec3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8174&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8174&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8174

From ksakata at openjdk.java.net  Tue Apr 12 06:36:29 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 12 Apr 2022 06:36:29 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja, zh_CN or de
In-Reply-To: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
Message-ID: <MNuy9q7BD3vHwJUFLHJNc5oN8AChaenVeuee4rOVQ4A=.c9160f54-13d5-488d-92ca-6a48ba5bf526@github.com>

On Mon, 11 Apr 2022 05:31:49 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> # Summary
> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
> 
> # How to reproduce this issue
> 
> $ jdeprscan -J-Duser.language=ja --help
> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>         ... 8 more
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ?Same as above?
> 
> $ jdeprscan -J-Duser.language=de --help
> ?Same as above?
> 
> Of course, it works well when the locale is anything other than those locales.
> 
> # Details
> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
> 
> I removed extra single quotes.
> 
> # Test
> It seems there is no test class for it. So I run commands as I mentioned before.
> 
> $ jdeprscan -J-Duser.language=ja --help
> ????: jdeprscan [options] {dir|jar|class} ...
> 
> ?????:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ???API????????????????????????
> ???????????????????????JAR?????
> ?????????????????????????????
> ???????????????????????????????
> ????$????????:
> 
>     java.lang.Thread$State
> 
> --class-path?????????????????????
> ???????????
> 
> --for-removal??????????????????????????API?
> ????????????6?7???8????????????
> 
> --full-version????????????????????????????
> 
> --help (-? -h)?????????????????????????
> 
> --list (-l)?????????API???????????????????????
> ???????JAR??????????????????????
> 
> --release????????????????API?????????Java SE
> ???????????
> 
> --verbose (-v)????????????????????????????????
> 
> --version????????????????????????????????
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ???jdeprscan [options] {dir|jar|class} ...
> 
> ???
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ????????????????? API?
> ???????????????JAR ???
> ????????????????
> ????????????? $ ???
> ?????????
> 
>     java.lang.Thread$State
> 
> --class-path ?????????????
> ?????
> 
> --for-removal ????????????????
> ? API???????? 6?7 ? 8 ?????
> 
> --full-version ???????????????
> 
> --help (-? -h) ????????????
> 
> --list (-l) ?????????? API???????
> ???????????jar ?????
> 
> --release ????????????? API ?
> ? Java SE ????
> 
> --verbose (-v) ????????????????
> 
> --version ???????????????
> 
> $ jdeprscan -J-Duser.language=de --help
> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
> 
> Optionen:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
> f?r verschachtelte Klassen angegeben werden. Beispiel:
> 
>     java.lang.Thread$State
> 
> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
> von abh?ngigen Klassen.
> 
> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
> 
> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
> 
> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
> 
> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
> 
> Die Option --release gibt das Java SE-Release an, das die Gruppe
> der veralteten APIS zum Scannen liefert.
> 
> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
> 
> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
> 
> $ jdeprscan -J-Duser.language=en --help                    
> Usage: jdeprscan [options] {dir|jar|class} ...
> 
> options:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scans each argument for usages of deprecated APIs. An argument
> may be a directory specifying the root of a package hierarchy,
> a JAR file, a class file, or a class name. The class name must be
> specified using a fully qualified class name using the $ separator
> character for nested classes, for example,
> 
>     java.lang.Thread$State
> 
> The --class-path option provides a search path for resolution
> of dependent classes.
> 
> The --for-removal option limits scanning or listing to APIs that are
> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
> 
> The --full-version option prints out the full version string of the tool.
> 
> The --help (-? -h) option prints out a full help message.
> 
> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
> so no directory, jar, or class arguments should be provided.
> 
> The --release option specifies the Java SE release that provides the set
> of deprecated APIs for scanning.
> 
> The --verbose (-v) option enables additional message output during processing.
> 
> The --version option prints out the abbreviated version string of the tool.

Sure! I overlooked that file. I've applied the fix to it. Thank you for your review.

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

PR: https://git.openjdk.java.net/jdk/pull/8174

From jlahoda at openjdk.java.net  Tue Apr 12 09:54:11 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 12 Apr 2022 09:54:11 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v2]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <ixensSemQq77NshdAyzmbfd3eIoBQUa3kr3j5IHq0aI=.6a7b4e9b-f321-4bbc-810d-4b72f34f6812@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

  Fixing tests.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/da8401d4..d7e2eb0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=00-01

  Stats: 10 lines in 5 files changed: 5 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Tue Apr 12 13:18:14 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 12 Apr 2022 13:18:14 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

  Cleanup.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/d7e2eb0a..ef7a7d6a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From prappo at openjdk.java.net  Tue Apr 12 16:28:43 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 12 Apr 2022 16:28:43 GMT
Subject: RFR: JDK-8283714: REDO - Unexpected TypeElement in ANALYZE
 TaskEvent
In-Reply-To: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
References: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
Message-ID: <DhnyFCuCk2xr32z0G5gHwi7a1_9sBNfZzqvhRYhIaNU=.8b6819ca-5902-42fa-a039-8e98bc18ba3f@github.com>

On Mon, 4 Apr 2022 23:46:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is a redo of a recent fix, which passed all tier1 tests but broke "make docs".
> 
> The reason for the crash was a combination of a number of factors, such that fixing any one (or more) would make the problem go away, making it hard(er) to determine the correct path forward.
> 
> 1. In a doc comment in JDK code, the author had mistakenly written a number of tags like `{@link byte}` instead of `{@code byte}` and `{@link byte[]}` instead of `{@code byte[]}`
> 
> 2. `DocTrees.getElement` returns the javac-internal symbol for primitive types (instead of `null`) and the base type for arrays. So for both `{@link byte}` and `{@link byte[]}` the `LinkFactory` was given a javac-internal symbol (instead of null).  Filed as JDK-8284315.
> 
> 3. Thinking the value was a declared type, and so in a named or unnamed package, the `LinkFactory` attempts to create a link based on the package of the value.    The package for the java-internal symbols for primitive type is a special `rootPackage` which has no equivalent in the Language Model world, and which has a `null` owner.
> 
> 4. The new code in `JavacElements.getModuleOf` assumes that (as is generally standard in javac) all symbols have a non-`null` owner, this giving an NPE when called with `rootPackage`.
> 
> So, there are various possible ways to fix this.
> 
> 1. put a broad null check for `sym.owner` in `JavacElements.getModuleOf`
> 2. put a specific check for `rootPackage` in `JavacElements.getMOduleOf`
> 3. fix `DocTrees.getElement` to not return javac-internal symbols
> 4. change javadoc to workaround the issue with `DocTrees.getElement`
> 5. fix the javadoc comments to not use bad forms, like `{@link byte}` etc.
> 
> 1 and 2 would both be atypical idioms in the code.
> 
> 3 is desirable, but may cause additional work/updates/etc. It would be a change to the behavior of a public API, and so compatibility concerns would need to be addressed, although arguably the change in behavior is a bug fix, not a spec change. (The current behavior is under-specified!)
> 
> By itself, 5 would just be ignoring the underlying problem.
> 
> That leaves 4, which is the solution adopted here. It localizes the change/check to javadoc internal code. It is an interim measure until we can fix 3. (JDK-8284315)
> 
> * The javac part of the fix is essentially the same as before (a redundant import has been removed, this time.)  By itself the code was not wrong, when used as intended.
> 
> * `DocTrees.getElement` is called from a single place in javadoc, in `CommentHelper` and so a check is made on the result such that `null` is returned when the result would otherwise not be a declared type.
> 
> * A new (javadoc) test is added to verify the new behavior for `{@link byte}` etc. The prior behavior (even before the original fix) was to display the type in monospace font.  The new behavior is for javadoc to fall back on the recently-new mechanism to display a "invalid tag" block.
> 
> With these fixes, "make docs" works, and does not crash(!) Comparing the result of "make docs" before and after this fix, the only significant differences arise from the 5 bad `{@link ...}` tags in `MemorySegment.java`. These should (separately) be fixed.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 167:

> 165:         }
> 166:         DocTrees doctrees = configuration.docEnv.getDocTrees();
> 167:         // Workaround JDK-8284193

Nit: either split "workaround" or add a preposition ("for"?) before the issue type. It's either a phrasal verb or a noun with a preposition.

Otherwise that phrase reads weird.

test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTagletPrimitive.java line 70:

> 68:         checkExit(Exit.OK);
> 69: 
> 70:         checkOutput("C.html", true,

I presume this run and the run below generate warnings. Should we check for them?

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

PR: https://git.openjdk.java.net/jdk/pull/8101

From naoto at openjdk.java.net  Tue Apr 12 16:53:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Apr 2022 16:53:40 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja, zh_CN or de [v2]
In-Reply-To: <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
 <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>
Message-ID: <_L7WvLhy2DhV6ce-OecIfMsjMdlp5X9Z1OBSjkbdWJE=.1071ee71-d0c0-4cdf-b867-b88312620f7d@github.com>

On Tue, 12 Apr 2022 06:36:29 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> # Summary
>> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
>> 
>> # How to reproduce this issue
>> 
>> $ jdeprscan -J-Duser.language=ja --help
>> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
>> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>>         ... 8 more
>> 
>> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
>> ?Same as above?
>> 
>> $ jdeprscan -J-Duser.language=de --help
>> ?Same as above?
>> 
>> Of course, it works well when the locale is anything other than those locales.
>> 
>> # Details
>> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
>> 
>> I removed extra single quotes.
>> 
>> # Test
>> It seems there is no test class for it. So I run commands as I mentioned before.
>> 
>> $ jdeprscan -J-Duser.language=ja --help
>> ????: jdeprscan [options] {dir|jar|class} ...
>> 
>> ?????:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> ???API????????????????????????
>> ???????????????????????JAR?????
>> ?????????????????????????????
>> ???????????????????????????????
>> ????$????????:
>> 
>>     java.lang.Thread$State
>> 
>> --class-path?????????????????????
>> ???????????
>> 
>> --for-removal??????????????????????????API?
>> ????????????6?7???8????????????
>> 
>> --full-version????????????????????????????
>> 
>> --help (-? -h)?????????????????????????
>> 
>> --list (-l)?????????API???????????????????????
>> ???????JAR??????????????????????
>> 
>> --release????????????????API?????????Java SE
>> ???????????
>> 
>> --verbose (-v)????????????????????????????????
>> 
>> --version????????????????????????????????
>> 
>> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
>> ???jdeprscan [options] {dir|jar|class} ...
>> 
>> ???
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> ????????????????? API?
>> ???????????????JAR ???
>> ????????????????
>> ????????????? $ ???
>> ?????????
>> 
>>     java.lang.Thread$State
>> 
>> --class-path ?????????????
>> ?????
>> 
>> --for-removal ????????????????
>> ? API???????? 6?7 ? 8 ?????
>> 
>> --full-version ???????????????
>> 
>> --help (-? -h) ????????????
>> 
>> --list (-l) ?????????? API???????
>> ???????????jar ?????
>> 
>> --release ????????????? API ?
>> ? Java SE ????
>> 
>> --verbose (-v) ????????????????
>> 
>> --version ???????????????
>> 
>> $ jdeprscan -J-Duser.language=de --help
>> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
>> 
>> Optionen:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
>> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
>> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
>> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
>> f?r verschachtelte Klassen angegeben werden. Beispiel:
>> 
>>     java.lang.Thread$State
>> 
>> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
>> von abh?ngigen Klassen.
>> 
>> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
>> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
>> 
>> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
>> 
>> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
>> 
>> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
>> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
>> 
>> Die Option --release gibt das Java SE-Release an, das die Gruppe
>> der veralteten APIS zum Scannen liefert.
>> 
>> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
>> 
>> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
>> 
>> $ jdeprscan -J-Duser.language=en --help                    
>> Usage: jdeprscan [options] {dir|jar|class} ...
>> 
>> options:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> Scans each argument for usages of deprecated APIs. An argument
>> may be a directory specifying the root of a package hierarchy,
>> a JAR file, a class file, or a class name. The class name must be
>> specified using a fully qualified class name using the $ separator
>> character for nested classes, for example,
>> 
>>     java.lang.Thread$State
>> 
>> The --class-path option provides a search path for resolution
>> of dependent classes.
>> 
>> The --for-removal option limits scanning or listing to APIs that are
>> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
>> 
>> The --full-version option prints out the full version string of the tool.
>> 
>> The --help (-? -h) option prints out a full help message.
>> 
>> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
>> so no directory, jar, or class arguments should be provided.
>> 
>> The --release option specifies the Java SE release that provides the set
>> of deprecated APIs for scanning.
>> 
>> The --verbose (-v) option enables additional message output during processing.
>> 
>> The --version option prints out the abbreviated version string of the tool.
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary single quotes in the German file

LGTM. Thanks for the fix.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8174

From vromero at openjdk.java.net  Tue Apr 12 17:13:59 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 12 Apr 2022 17:13:59 GMT
Subject: RFR: JDK-8283714: REDO - Unexpected TypeElement in ANALYZE
 TaskEvent
In-Reply-To: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
References: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
Message-ID: <KznDdZ-OXQjqb_8bWTKUpen20l3hytEPDLKh_CLVqvY=.bb365551-7f0d-4d0e-aac3-56c250485ecb@github.com>

On Mon, 4 Apr 2022 23:46:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is a redo of a recent fix, which passed all tier1 tests but broke "make docs".
> 
> The reason for the crash was a combination of a number of factors, such that fixing any one (or more) would make the problem go away, making it hard(er) to determine the correct path forward.
> 
> 1. In a doc comment in JDK code, the author had mistakenly written a number of tags like `{@link byte}` instead of `{@code byte}` and `{@link byte[]}` instead of `{@code byte[]}`
> 
> 2. `DocTrees.getElement` returns the javac-internal symbol for primitive types (instead of `null`) and the base type for arrays. So for both `{@link byte}` and `{@link byte[]}` the `LinkFactory` was given a javac-internal symbol (instead of null).  Filed as JDK-8284315.
> 
> 3. Thinking the value was a declared type, and so in a named or unnamed package, the `LinkFactory` attempts to create a link based on the package of the value.    The package for the java-internal symbols for primitive type is a special `rootPackage` which has no equivalent in the Language Model world, and which has a `null` owner.
> 
> 4. The new code in `JavacElements.getModuleOf` assumes that (as is generally standard in javac) all symbols have a non-`null` owner, this giving an NPE when called with `rootPackage`.
> 
> So, there are various possible ways to fix this.
> 
> 1. put a broad null check for `sym.owner` in `JavacElements.getModuleOf`
> 2. put a specific check for `rootPackage` in `JavacElements.getMOduleOf`
> 3. fix `DocTrees.getElement` to not return javac-internal symbols
> 4. change javadoc to workaround the issue with `DocTrees.getElement`
> 5. fix the javadoc comments to not use bad forms, like `{@link byte}` etc.
> 
> 1 and 2 would both be atypical idioms in the code.
> 
> 3 is desirable, but may cause additional work/updates/etc. It would be a change to the behavior of a public API, and so compatibility concerns would need to be addressed, although arguably the change in behavior is a bug fix, not a spec change. (The current behavior is under-specified!)
> 
> By itself, 5 would just be ignoring the underlying problem.
> 
> That leaves 4, which is the solution adopted here. It localizes the change/check to javadoc internal code. It is an interim measure until we can fix 3. (JDK-8284315)
> 
> * The javac part of the fix is essentially the same as before (a redundant import has been removed, this time.)  By itself the code was not wrong, when used as intended.
> 
> * `DocTrees.getElement` is called from a single place in javadoc, in `CommentHelper` and so a check is made on the result such that `null` is returned when the result would otherwise not be a declared type.
> 
> * A new (javadoc) test is added to verify the new behavior for `{@link byte}` etc. The prior behavior (even before the original fix) was to display the type in monospace font.  The new behavior is for javadoc to fall back on the recently-new mechanism to display a "invalid tag" block.
> 
> With these fixes, "make docs" works, and does not crash(!) Comparing the result of "make docs" before and after this fix, the only significant differences arise from the 5 bad `{@link ...}` tags in `MemorySegment.java`. These should (separately) be fixed.

the compiler changes look good to me

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8101

From jlahoda at openjdk.java.net  Tue Apr 12 18:48:59 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 12 Apr 2022 18:48:59 GMT
Subject: RFR: JDK-8283714: REDO - Unexpected TypeElement in ANALYZE
 TaskEvent
In-Reply-To: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
References: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
Message-ID: <svnUQ4qIxuPvb9fKIzCuJzmePrx8nM0c0own3X8mCzg=.8f578b17-9ac5-4c11-aba4-a892a53bee8a@github.com>

On Mon, 4 Apr 2022 23:46:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is a redo of a recent fix, which passed all tier1 tests but broke "make docs".
> 
> The reason for the crash was a combination of a number of factors, such that fixing any one (or more) would make the problem go away, making it hard(er) to determine the correct path forward.
> 
> 1. In a doc comment in JDK code, the author had mistakenly written a number of tags like `{@link byte}` instead of `{@code byte}` and `{@link byte[]}` instead of `{@code byte[]}`
> 
> 2. `DocTrees.getElement` returns the javac-internal symbol for primitive types (instead of `null`) and the base type for arrays. So for both `{@link byte}` and `{@link byte[]}` the `LinkFactory` was given a javac-internal symbol (instead of null).  Filed as JDK-8284315.
> 
> 3. Thinking the value was a declared type, and so in a named or unnamed package, the `LinkFactory` attempts to create a link based on the package of the value.    The package for the java-internal symbols for primitive type is a special `rootPackage` which has no equivalent in the Language Model world, and which has a `null` owner.
> 
> 4. The new code in `JavacElements.getModuleOf` assumes that (as is generally standard in javac) all symbols have a non-`null` owner, this giving an NPE when called with `rootPackage`.
> 
> So, there are various possible ways to fix this.
> 
> 1. put a broad null check for `sym.owner` in `JavacElements.getModuleOf`
> 2. put a specific check for `rootPackage` in `JavacElements.getMOduleOf`
> 3. fix `DocTrees.getElement` to not return javac-internal symbols
> 4. change javadoc to workaround the issue with `DocTrees.getElement`
> 5. fix the javadoc comments to not use bad forms, like `{@link byte}` etc.
> 
> 1 and 2 would both be atypical idioms in the code.
> 
> 3 is desirable, but may cause additional work/updates/etc. It would be a change to the behavior of a public API, and so compatibility concerns would need to be addressed, although arguably the change in behavior is a bug fix, not a spec change. (The current behavior is under-specified!)
> 
> By itself, 5 would just be ignoring the underlying problem.
> 
> That leaves 4, which is the solution adopted here. It localizes the change/check to javadoc internal code. It is an interim measure until we can fix 3. (JDK-8284315)
> 
> * The javac part of the fix is essentially the same as before (a redundant import has been removed, this time.)  By itself the code was not wrong, when used as intended.
> 
> * `DocTrees.getElement` is called from a single place in javadoc, in `CommentHelper` and so a check is made on the result such that `null` is returned when the result would otherwise not be a declared type.
> 
> * A new (javadoc) test is added to verify the new behavior for `{@link byte}` etc. The prior behavior (even before the original fix) was to display the type in monospace font.  The new behavior is for javadoc to fall back on the recently-new mechanism to display a "invalid tag" block.
> 
> With these fixes, "make docs" works, and does not crash(!) Comparing the result of "make docs" before and after this fix, the only significant differences arise from the 5 bad `{@link ...}` tags in `MemorySegment.java`. These should (separately) be fixed.

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8101

From jjg at openjdk.java.net  Tue Apr 12 21:47:50 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 12 Apr 2022 21:47:50 GMT
Subject: RFR: JDK-8283714: REDO - Unexpected TypeElement in ANALYZE
 TaskEvent
In-Reply-To: <DhnyFCuCk2xr32z0G5gHwi7a1_9sBNfZzqvhRYhIaNU=.8b6819ca-5902-42fa-a039-8e98bc18ba3f@github.com>
References: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
 <DhnyFCuCk2xr32z0G5gHwi7a1_9sBNfZzqvhRYhIaNU=.8b6819ca-5902-42fa-a039-8e98bc18ba3f@github.com>
Message-ID: <5a3HlaJDvif3MHmXWlBkgk_filfkdwywxkB9Zny9SzY=.9b9dd5be-f11a-4f7d-8c75-27712923052d@github.com>

On Tue, 12 Apr 2022 16:12:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This is a redo of a recent fix, which passed all tier1 tests but broke "make docs".
>> 
>> The reason for the crash was a combination of a number of factors, such that fixing any one (or more) would make the problem go away, making it hard(er) to determine the correct path forward.
>> 
>> 1. In a doc comment in JDK code, the author had mistakenly written a number of tags like `{@link byte}` instead of `{@code byte}` and `{@link byte[]}` instead of `{@code byte[]}`
>> 
>> 2. `DocTrees.getElement` returns the javac-internal symbol for primitive types (instead of `null`) and the base type for arrays. So for both `{@link byte}` and `{@link byte[]}` the `LinkFactory` was given a javac-internal symbol (instead of null).  Filed as JDK-8284315.
>> 
>> 3. Thinking the value was a declared type, and so in a named or unnamed package, the `LinkFactory` attempts to create a link based on the package of the value.    The package for the java-internal symbols for primitive type is a special `rootPackage` which has no equivalent in the Language Model world, and which has a `null` owner.
>> 
>> 4. The new code in `JavacElements.getModuleOf` assumes that (as is generally standard in javac) all symbols have a non-`null` owner, this giving an NPE when called with `rootPackage`.
>> 
>> So, there are various possible ways to fix this.
>> 
>> 1. put a broad null check for `sym.owner` in `JavacElements.getModuleOf`
>> 2. put a specific check for `rootPackage` in `JavacElements.getMOduleOf`
>> 3. fix `DocTrees.getElement` to not return javac-internal symbols
>> 4. change javadoc to workaround the issue with `DocTrees.getElement`
>> 5. fix the javadoc comments to not use bad forms, like `{@link byte}` etc.
>> 
>> 1 and 2 would both be atypical idioms in the code.
>> 
>> 3 is desirable, but may cause additional work/updates/etc. It would be a change to the behavior of a public API, and so compatibility concerns would need to be addressed, although arguably the change in behavior is a bug fix, not a spec change. (The current behavior is under-specified!)
>> 
>> By itself, 5 would just be ignoring the underlying problem.
>> 
>> That leaves 4, which is the solution adopted here. It localizes the change/check to javadoc internal code. It is an interim measure until we can fix 3. (JDK-8284315)
>> 
>> * The javac part of the fix is essentially the same as before (a redundant import has been removed, this time.)  By itself the code was not wrong, when used as intended.
>> 
>> * `DocTrees.getElement` is called from a single place in javadoc, in `CommentHelper` and so a check is made on the result such that `null` is returned when the result would otherwise not be a declared type.
>> 
>> * A new (javadoc) test is added to verify the new behavior for `{@link byte}` etc. The prior behavior (even before the original fix) was to display the type in monospace font.  The new behavior is for javadoc to fall back on the recently-new mechanism to display a "invalid tag" block.
>> 
>> With these fixes, "make docs" works, and does not crash(!) Comparing the result of "make docs" before and after this fix, the only significant differences arise from the 5 bad `{@link ...}` tags in `MemorySegment.java`. These should (separately) be fixed.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 167:
> 
>> 165:         }
>> 166:         DocTrees doctrees = configuration.docEnv.getDocTrees();
>> 167:         // Workaround JDK-8284193
> 
> Nit: either split "workaround" or add a preposition ("for"?) before the issue type. It's either a phrasal verb or a noun with a preposition.
> 
> Otherwise that phrase reads weird.

done

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

PR: https://git.openjdk.java.net/jdk/pull/8101

From jjg at openjdk.java.net  Tue Apr 12 21:57:33 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 12 Apr 2022 21:57:33 GMT
Subject: RFR: JDK-8283714: REDO - Unexpected TypeElement in ANALYZE
 TaskEvent [v2]
In-Reply-To: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
References: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
Message-ID: <h4P_GlWWfGGBfEh6ebcvNHm0ovPc3vuIFh6SWK9VafA=.f777bad3-cdea-478e-a4a7-065f56c0217c@github.com>

> This is a redo of a recent fix, which passed all tier1 tests but broke "make docs".
> 
> The reason for the crash was a combination of a number of factors, such that fixing any one (or more) would make the problem go away, making it hard(er) to determine the correct path forward.
> 
> 1. In a doc comment in JDK code, the author had mistakenly written a number of tags like `{@link byte}` instead of `{@code byte}` and `{@link byte[]}` instead of `{@code byte[]}`
> 
> 2. `DocTrees.getElement` returns the javac-internal symbol for primitive types (instead of `null`) and the base type for arrays. So for both `{@link byte}` and `{@link byte[]}` the `LinkFactory` was given a javac-internal symbol (instead of null).  Filed as JDK-8284315.
> 
> 3. Thinking the value was a declared type, and so in a named or unnamed package, the `LinkFactory` attempts to create a link based on the package of the value.    The package for the java-internal symbols for primitive type is a special `rootPackage` which has no equivalent in the Language Model world, and which has a `null` owner.
> 
> 4. The new code in `JavacElements.getModuleOf` assumes that (as is generally standard in javac) all symbols have a non-`null` owner, this giving an NPE when called with `rootPackage`.
> 
> So, there are various possible ways to fix this.
> 
> 1. put a broad null check for `sym.owner` in `JavacElements.getModuleOf`
> 2. put a specific check for `rootPackage` in `JavacElements.getMOduleOf`
> 3. fix `DocTrees.getElement` to not return javac-internal symbols
> 4. change javadoc to workaround the issue with `DocTrees.getElement`
> 5. fix the javadoc comments to not use bad forms, like `{@link byte}` etc.
> 
> 1 and 2 would both be atypical idioms in the code.
> 
> 3 is desirable, but may cause additional work/updates/etc. It would be a change to the behavior of a public API, and so compatibility concerns would need to be addressed, although arguably the change in behavior is a bug fix, not a spec change. (The current behavior is under-specified!)
> 
> By itself, 5 would just be ignoring the underlying problem.
> 
> That leaves 4, which is the solution adopted here. It localizes the change/check to javadoc internal code. It is an interim measure until we can fix 3. (JDK-8284315)
> 
> * The javac part of the fix is essentially the same as before (a redundant import has been removed, this time.)  By itself the code was not wrong, when used as intended.
> 
> * `DocTrees.getElement` is called from a single place in javadoc, in `CommentHelper` and so a check is made on the result such that `null` is returned when the result would otherwise not be a declared type.
> 
> * A new (javadoc) test is added to verify the new behavior for `{@link byte}` etc. The prior behavior (even before the original fix) was to display the type in monospace font.  The new behavior is for javadoc to fall back on the recently-new mechanism to display a "invalid tag" block.
> 
> With these fixes, "make docs" works, and does not crash(!) Comparing the result of "make docs" before and after this fix, the only significant differences arise from the 5 bad `{@link ...}` tags in `MemorySegment.java`. These should (separately) be fixed.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8101/files
  - new: https://git.openjdk.java.net/jdk/pull/8101/files/bbec4f32..a8c40a4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8101&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8101&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8101

From prappo at openjdk.java.net  Tue Apr 12 22:03:22 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 12 Apr 2022 22:03:22 GMT
Subject: RFR: JDK-8283714: REDO - Unexpected TypeElement in ANALYZE
 TaskEvent [v2]
In-Reply-To: <h4P_GlWWfGGBfEh6ebcvNHm0ovPc3vuIFh6SWK9VafA=.f777bad3-cdea-478e-a4a7-065f56c0217c@github.com>
References: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
 <h4P_GlWWfGGBfEh6ebcvNHm0ovPc3vuIFh6SWK9VafA=.f777bad3-cdea-478e-a4a7-065f56c0217c@github.com>
Message-ID: <Tpmxq-lIgepBaix27r1OVcyTlrktNKNWbPl99Hr8XWA=.5ea53445-6fac-47a5-8c9a-540897f651b8@github.com>

On Tue, 12 Apr 2022 21:57:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is a redo of a recent fix, which passed all tier1 tests but broke "make docs".
>> 
>> The reason for the crash was a combination of a number of factors, such that fixing any one (or more) would make the problem go away, making it hard(er) to determine the correct path forward.
>> 
>> 1. In a doc comment in JDK code, the author had mistakenly written a number of tags like `{@link byte}` instead of `{@code byte}` and `{@link byte[]}` instead of `{@code byte[]}`
>> 
>> 2. `DocTrees.getElement` returns the javac-internal symbol for primitive types (instead of `null`) and the base type for arrays. So for both `{@link byte}` and `{@link byte[]}` the `LinkFactory` was given a javac-internal symbol (instead of null).  Filed as JDK-8284315.
>> 
>> 3. Thinking the value was a declared type, and so in a named or unnamed package, the `LinkFactory` attempts to create a link based on the package of the value.    The package for the java-internal symbols for primitive type is a special `rootPackage` which has no equivalent in the Language Model world, and which has a `null` owner.
>> 
>> 4. The new code in `JavacElements.getModuleOf` assumes that (as is generally standard in javac) all symbols have a non-`null` owner, this giving an NPE when called with `rootPackage`.
>> 
>> So, there are various possible ways to fix this.
>> 
>> 1. put a broad null check for `sym.owner` in `JavacElements.getModuleOf`
>> 2. put a specific check for `rootPackage` in `JavacElements.getMOduleOf`
>> 3. fix `DocTrees.getElement` to not return javac-internal symbols
>> 4. change javadoc to workaround the issue with `DocTrees.getElement`
>> 5. fix the javadoc comments to not use bad forms, like `{@link byte}` etc.
>> 
>> 1 and 2 would both be atypical idioms in the code.
>> 
>> 3 is desirable, but may cause additional work/updates/etc. It would be a change to the behavior of a public API, and so compatibility concerns would need to be addressed, although arguably the change in behavior is a bug fix, not a spec change. (The current behavior is under-specified!)
>> 
>> By itself, 5 would just be ignoring the underlying problem.
>> 
>> That leaves 4, which is the solution adopted here. It localizes the change/check to javadoc internal code. It is an interim measure until we can fix 3. (JDK-8284315)
>> 
>> * The javac part of the fix is essentially the same as before (a redundant import has been removed, this time.)  By itself the code was not wrong, when used as intended.
>> 
>> * `DocTrees.getElement` is called from a single place in javadoc, in `CommentHelper` and so a check is made on the result such that `null` is returned when the result would otherwise not be a declared type.
>> 
>> * A new (javadoc) test is added to verify the new behavior for `{@link byte}` etc. The prior behavior (even before the original fix) was to display the type in monospace font.  The new behavior is for javadoc to fall back on the recently-new mechanism to display a "invalid tag" block.
>> 
>> With these fixes, "make docs" works, and does not crash(!) Comparing the result of "make docs" before and after this fix, the only significant differences arise from the 5 bad `{@link ...}` tags in `MemorySegment.java`. These should (separately) be fixed.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by prappo (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8101

From jjg at openjdk.java.net  Tue Apr 12 23:37:27 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 12 Apr 2022 23:37:27 GMT
Subject: Integrated: JDK-8283714: REDO - Unexpected TypeElement in ANALYZE
 TaskEvent
In-Reply-To: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
References: <qD-j6jPWrBf3KrW-DfQB2HqA2LYLfOmpeHq9InPl-QQ=.2f0a2366-fa24-42e8-93b4-57776d86370a@github.com>
Message-ID: <YdeRS4I6qDs-paVpLwGGVOhsX908X9KmRxm8ZawGerc=.93b4971e-898a-41b5-8ee8-6c66d7ef6e37@github.com>

On Mon, 4 Apr 2022 23:46:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is a redo of a recent fix, which passed all tier1 tests but broke "make docs".
> 
> The reason for the crash was a combination of a number of factors, such that fixing any one (or more) would make the problem go away, making it hard(er) to determine the correct path forward.
> 
> 1. In a doc comment in JDK code, the author had mistakenly written a number of tags like `{@link byte}` instead of `{@code byte}` and `{@link byte[]}` instead of `{@code byte[]}`
> 
> 2. `DocTrees.getElement` returns the javac-internal symbol for primitive types (instead of `null`) and the base type for arrays. So for both `{@link byte}` and `{@link byte[]}` the `LinkFactory` was given a javac-internal symbol (instead of null).  Filed as JDK-8284315.
> 
> 3. Thinking the value was a declared type, and so in a named or unnamed package, the `LinkFactory` attempts to create a link based on the package of the value.    The package for the java-internal symbols for primitive type is a special `rootPackage` which has no equivalent in the Language Model world, and which has a `null` owner.
> 
> 4. The new code in `JavacElements.getModuleOf` assumes that (as is generally standard in javac) all symbols have a non-`null` owner, this giving an NPE when called with `rootPackage`.
> 
> So, there are various possible ways to fix this.
> 
> 1. put a broad null check for `sym.owner` in `JavacElements.getModuleOf`
> 2. put a specific check for `rootPackage` in `JavacElements.getMOduleOf`
> 3. fix `DocTrees.getElement` to not return javac-internal symbols
> 4. change javadoc to workaround the issue with `DocTrees.getElement`
> 5. fix the javadoc comments to not use bad forms, like `{@link byte}` etc.
> 
> 1 and 2 would both be atypical idioms in the code.
> 
> 3 is desirable, but may cause additional work/updates/etc. It would be a change to the behavior of a public API, and so compatibility concerns would need to be addressed, although arguably the change in behavior is a bug fix, not a spec change. (The current behavior is under-specified!)
> 
> By itself, 5 would just be ignoring the underlying problem.
> 
> That leaves 4, which is the solution adopted here. It localizes the change/check to javadoc internal code. It is an interim measure until we can fix 3. (JDK-8284315)
> 
> * The javac part of the fix is essentially the same as before (a redundant import has been removed, this time.)  By itself the code was not wrong, when used as intended.
> 
> * `DocTrees.getElement` is called from a single place in javadoc, in `CommentHelper` and so a check is made on the result such that `null` is returned when the result would otherwise not be a declared type.
> 
> * A new (javadoc) test is added to verify the new behavior for `{@link byte}` etc. The prior behavior (even before the original fix) was to display the type in monospace font.  The new behavior is for javadoc to fall back on the recently-new mechanism to display a "invalid tag" block.
> 
> With these fixes, "make docs" works, and does not crash(!) Comparing the result of "make docs" before and after this fix, the only significant differences arise from the 5 bad `{@link ...}` tags in `MemorySegment.java`. These should (separately) be fixed.

This pull request has now been integrated.

Changeset: 7920e8ba
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7920e8ba42a857d8a1537d46eafa3f0712ff2259
Stats:     328 lines in 5 files changed: 318 ins; 2 del; 8 mod

8283714: REDO - Unexpected TypeElement in ANALYZE TaskEvent
8284030: Standard Doclet should not attempt to link to primitive types

Reviewed-by: vromero, jlahoda, prappo

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

PR: https://git.openjdk.java.net/jdk/pull/8101

From duke at openjdk.java.net  Wed Apr 13 02:54:23 2022
From: duke at openjdk.java.net (Vikey Chen)
Date: Wed, 13 Apr 2022 02:54:23 GMT
Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v2]
In-Reply-To: <xMAN7VGSYwypbCHJfPmujPvFvaH-cfHsUXLH4RGj9ZE=.753f6353-6e38-440e-adf2-bff9adc3c90c@github.com>
References: <ptah2PBYatKtfv5rLFzaPP3rWqqPIz0cShcZHDjv3hg=.bd8d63bd-681e-4787-b3b4-d542233be781@github.com>
 <w4nJAxEkbFQ-LD20D7cm-KWV6L6pv0alU-IW7p8VfUs=.2085986b-901e-4173-9c89-2b5d7c6ac74e@github.com>
 <tAOCiNKgXhe6HNu-uNb2baZSl2-MLKekJNb89drRGO0=.650c16dd-9167-4717-97f3-07157fdfa61c@github.com>
 <xMAN7VGSYwypbCHJfPmujPvFvaH-cfHsUXLH4RGj9ZE=.753f6353-6e38-440e-adf2-bff9adc3c90c@github.com>
Message-ID: <_W7-OxLSZMu7_izcQAWh2DQTerx0lvm7OPr4vk7QtXI=.f940e458-19d8-4928-b9b6-6922b804fe13@github.com>

On Mon, 28 Mar 2022 17:11:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the longer term, I think its worth considering implementing LC_ALL as an override. I created an enhancement request for purposes of discussion.
>> [JDK-8283697](https://bugs.openjdk.java.net/browse/JDK-8283697) On macOS, the locale cannot be set using LC_ALL environment value
>> 
>> Jtreg does propagate LC_ALL to the subprocesses it spawns and it is documented.
>> So I'm not sure an immediate fix is necessary if the manual workaround (changing macOs preferences)
>> is suitable for a couple of weeks.
>
>> In the longer term, I think its worth considering implementing LC_ALL as an override. I created an enhancement request for purposes of discussion. [JDK-8283697](https://bugs.openjdk.java.net/browse/JDK-8283697) On macOS, the locale cannot be set using LC_ALL environment value
>> 
>> Jtreg does propagate LC_ALL to the subprocesses it spawns and it is documented. So I'm not sure an immediate fix is necessary if the manual workaround (changing macOs preferences) is suitable for a couple of weeks.
> 
> Roger, do you plan to implement the LC_ALL fix shortly? If so, that may make this PR unnecessary.

@iklam @dholmes-ora Can you please sponsor this PR or review the library version, since 
 https://bugs.openjdk.java.net/browse/JDK-8283697
> the Posix shell variables LANG, and LC_* on macOs do not provide the same information for region and variant that are provided by the Core Foundation locale settings.
And the timing of changes made via the Control Panel is different

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

PR: https://git.openjdk.java.net/jdk/pull/7924

From iklam at openjdk.java.net  Wed Apr 13 05:15:12 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 13 Apr 2022 05:15:12 GMT
Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v4]
In-Reply-To: <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com>
References: <ptah2PBYatKtfv5rLFzaPP3rWqqPIz0cShcZHDjv3hg=.bd8d63bd-681e-4787-b3b4-d542233be781@github.com>
 <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com>
Message-ID: <L39TXBLxTS41EQIASIhfyXOjkBSJQmiZ4X4e8At41Ko=.208930d1-901c-4bbd-af8e-5055423318e8@github.com>

On Mon, 28 Mar 2022 17:00:39 GMT, Vikey Chen <duke at openjdk.java.net> wrote:

>> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html
>>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases.
>> 
>> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced.
>> 
>> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java
>> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java
>> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java
>> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java
>> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java
>> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java
>> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java
>> test/langtools/tools/javac/platform/PlatformProviderTest.java
>> test/langtools/tools/jdeps/MultiReleaseJar.java
>
> Vikey Chen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Locale.ENGLISH to Locale.US

I can sponsor this PR but I think we need two reviewers.

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

PR: https://git.openjdk.java.net/jdk/pull/7924

From duke at openjdk.java.net  Wed Apr 13 05:44:13 2022
From: duke at openjdk.java.net (Vikey Chen)
Date: Wed, 13 Apr 2022 05:44:13 GMT
Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v4]
In-Reply-To: <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com>
References: <ptah2PBYatKtfv5rLFzaPP3rWqqPIz0cShcZHDjv3hg=.bd8d63bd-681e-4787-b3b4-d542233be781@github.com>
 <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com>
Message-ID: <gz8hwBWVN-m5X6MRH1uaFklVPHWAHpAm59gHmL6IDj0=.f527a156-779f-4141-8908-5edbad83f148@github.com>

On Mon, 28 Mar 2022 17:00:39 GMT, Vikey Chen <duke at openjdk.java.net> wrote:

>> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html
>>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases.
>> 
>> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced.
>> 
>> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java
>> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java
>> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java
>> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java
>> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java
>> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java
>> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java
>> test/langtools/tools/javac/platform/PlatformProviderTest.java
>> test/langtools/tools/jdeps/MultiReleaseJar.java
>
> Vikey Chen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Locale.ENGLISH to Locale.US

Thanks for that and let's wait for more reviewers.

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

PR: https://git.openjdk.java.net/jdk/pull/7924

From duke at openjdk.java.net  Wed Apr 13 12:50:17 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 13 Apr 2022 12:50:17 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <kZ3T_UtfN2zEQ39Qbade8R12pRbhoMmTaxVmam-omrs=.dfcefb64-ae82-4c39-891d-cd487998a657@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 190:

> 188:             case CASE_NULL -> true;
> 189:             case PATTERN_SWITCH -> true;
> 190:             case TOTAL_PATTERN_IN_INSTACEOF -> true;

small typo in `INSTANCEOF`

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Thu Apr 14 02:10:13 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 14 Apr 2022 02:10:13 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <oYmclgQ1fYcZTautz92dpD-XsnP69uLmHItYoAuF0cs=.318afb6b-2c77-4de5-87f0-382d32045ad7@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 242:

> 240:         PATTERN_SWITCH(JDK17, Fragments.FeaturePatternSwitch, DiagKind.PLURAL),
> 241:         REDUNDANT_STRICTFP(JDK17),
> 242:         TOTAL_PATTERN_IN_INSTACEOF(JDK17, Fragments.FeatureTotalPatternsInInstanceof, DiagKind.PLURAL),

shouldn't be JDK19?

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From duke at openjdk.java.net  Thu Apr 14 08:53:10 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 14 Apr 2022 08:53:10 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <wcUy3a_vA3YqAq5bK1O_SwSX_GopTTF5RFJEdrzPdwc=.f7653bbe-7d47-4390-9817-84ab5bd22840@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

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

> 175:         allowPatternSwitch = (preview.isEnabled() || !preview.isPreview(Feature.PATTERN_SWITCH)) &&
> 176:                              Feature.PATTERN_SWITCH.allowedInSource(source);
> 177:         allowTotalPatternsInstance = (preview.isEnabled() || !preview.isPreview(Feature.TOTAL_PATTERN_IN_INSTACEOF)) &&

BTW, do we need to rename total -> unconditional with the recent update in the spec?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1349:

> 1347:     public static PatternPrimaryType primaryPatternType(JCTree pat) {
> 1348:         return switch (pat.getTag()) {
> 1349:             case BINDINGPATTERN -> new PatternPrimaryType(((JCBindingPattern) pat).type);

Cast may be redundant here since the signature of primaryPatternType changed to access JCTrees

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1377:

> 1375:         }
> 1376:         JCExpression guard = ((JCPattern) cse).guard;
> 1377:         if (guard != null && guard.type.hasTag(BOOLEAN)) {

In the spec we see the following:

> A pattern case element is said to be unrefined if either (i) it has no associated when expression, or (ii) it has an associated when expression that is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with value true. A case element is unrefined if it is not a pattern case element or it is an unrefined pattern case element.

However, in the definition of `unconditional` I don't see the part for the constant expression.

I wonder if the spec should be updated or the code at this point

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From ihse at openjdk.java.net  Thu Apr 14 16:12:27 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 16:12:27 GMT
Subject: RFR: 8284891: Fix typos in build system files
Message-ID: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>

I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.

(Due to false positives this can unfortunately not be run automatically) 

Most of the fixes are in comments. A few are in messages aimed at the user.

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

Commit messages:
 - 8284891: Fix typos in build system files

Changes: https://git.openjdk.java.net/jdk/pull/8246/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8246&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284891
  Stats: 72 lines in 46 files changed: 0 ins; 0 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8246.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8246/head:pull/8246

PR: https://git.openjdk.java.net/jdk/pull/8246

From erikj at openjdk.java.net  Thu Apr 14 16:29:40 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 14 Apr 2022 16:29:40 GMT
Subject: RFR: 8284891: Fix typos in build system files
In-Reply-To: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
References: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
Message-ID: <eOghGOYfVNtq52tpdDhCbiKEXTUC49ROtX8_2BfvTV8=.e21f3899-eab3-4c74-8328-e2e5ca85102f@github.com>

On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> Most of the fixes are in comments. A few are in messages aimed at the user.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8246

From ihse at openjdk.java.net  Thu Apr 14 19:37:33 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 19:37:33 GMT
Subject: Integrated: 8284891: Fix typos in build system files
In-Reply-To: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
References: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
Message-ID: <2mF5V7umZUZe-exsy8TAj69oQs5CZ1A41lGknDaoNVc=.bf65fd9f-8851-4626-8bd1-6f23fef1e945@github.com>

On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> Most of the fixes are in comments. A few are in messages aimed at the user.

This pull request has now been integrated.

Changeset: 160eb2bd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/160eb2bd392fea29dd690ee9781174d14dc0b659
Stats:     72 lines in 46 files changed: 0 ins; 0 del; 72 mod

8284891: Fix typos in build system files

Reviewed-by: erikj

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

PR: https://git.openjdk.java.net/jdk/pull/8246

From ihse at openjdk.java.net  Thu Apr 14 20:23:01 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 20:23:01 GMT
Subject: RFR: 8284894: Fix typos in langtools
Message-ID: <Y-GcOE53FJZ2jnP5gH8dP6Iv_Ex3zjh8Qx19mBjUDSY=.db8beb26-e74e-4bda-bbe7-c1266a336adc@github.com>

I ran `codespell` on the langtools directories, and accepted those changes where it indeed discovered real typos.

(Due to false positives this can unfortunately not be run automatically)

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

Commit messages:
 - 8284894: Fix typos in langtools

Changes: https://git.openjdk.java.net/jdk/pull/8251/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8251&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284894
  Stats: 17 lines in 10 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8251.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8251/head:pull/8251

PR: https://git.openjdk.java.net/jdk/pull/8251

From jjg at openjdk.java.net  Thu Apr 14 21:04:24 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 14 Apr 2022 21:04:24 GMT
Subject: RFR: 8284894: Fix typos in langtools
In-Reply-To: <Y-GcOE53FJZ2jnP5gH8dP6Iv_Ex3zjh8Qx19mBjUDSY=.db8beb26-e74e-4bda-bbe7-c1266a336adc@github.com>
References: <Y-GcOE53FJZ2jnP5gH8dP6Iv_Ex3zjh8Qx19mBjUDSY=.db8beb26-e74e-4bda-bbe7-c1266a336adc@github.com>
Message-ID: <dVLx5NCW96CTM8siWW5PIn1krTq1Nzgirej0D3L2GKc=.b1eb63f5-b56d-4c83-8d56-5d39c602583b@github.com>

On Thu, 14 Apr 2022 19:57:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the langtools directories, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically)

Looks innocuous enough to me

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8251

From ihse at openjdk.java.net  Thu Apr 14 21:45:41 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 21:45:41 GMT
Subject: Integrated: 8284894: Fix typos in langtools
In-Reply-To: <Y-GcOE53FJZ2jnP5gH8dP6Iv_Ex3zjh8Qx19mBjUDSY=.db8beb26-e74e-4bda-bbe7-c1266a336adc@github.com>
References: <Y-GcOE53FJZ2jnP5gH8dP6Iv_Ex3zjh8Qx19mBjUDSY=.db8beb26-e74e-4bda-bbe7-c1266a336adc@github.com>
Message-ID: <mwvUXa3tEgAy_ex9Ac6ElbeU0fAI5BapUv2ZnTzu99Q=.67e1cab8-a2ca-477f-b82b-f8c220731c43@github.com>

On Thu, 14 Apr 2022 19:57:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the langtools directories, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically)

This pull request has now been integrated.

Changeset: 3084921d
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3084921d7a67c470d1e2bb0ab51100bec455200e
Stats:     17 lines in 10 files changed: 0 ins; 0 del; 17 mod

8284894: Fix typos in langtools

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk/pull/8251

From vromero at openjdk.java.net  Fri Apr 15 03:56:42 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 15 Apr 2022 03:56:42 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <wcUy3a_vA3YqAq5bK1O_SwSX_GopTTF5RFJEdrzPdwc=.f7653bbe-7d47-4390-9817-84ab5bd22840@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
 <wcUy3a_vA3YqAq5bK1O_SwSX_GopTTF5RFJEdrzPdwc=.f7653bbe-7d47-4390-9817-84ab5bd22840@github.com>
Message-ID: <oEN8DKXMf49vZ2Iwxvrf-YvsF9gdEtqqHbn59hByON0=.9b020f80-1c50-4715-8448-d802e9a3b662@github.com>

On Thu, 14 Apr 2022 08:46:50 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1377:
> 
>> 1375:         }
>> 1376:         JCExpression guard = ((JCPattern) cse).guard;
>> 1377:         if (guard != null && guard.type.hasTag(BOOLEAN)) {
> 
> In the spec we see the following:
> 
>> A pattern case element is said to be unrefined if either (i) it has no associated when expression, or (ii) it has an associated when expression that is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with value true. A case element is unrefined if it is not a pattern case element or it is an unrefined pattern case element.
> 
> However, in the definition of `unconditional` I don't see the part for the constant expression.
> 
> I wonder if the spec should be updated or the code at this point

the code below checks that the guard is boolean constant `true`, this is the way the compiler can do that, a constant can be retrieved using the `constValue` method

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Fri Apr 15 15:40:41 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 15 Apr 2022 15:40:41 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <JozJia5Wjs5vWHG7hvtIXsw2GkAUFkmenl9Hye1SuAY=.894034f5-4178-4e46-bd76-c3c0c3b0a268@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

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

> 1777:                         //binding pattern
> 1778:                         attribExpr(pat, switchEnv);
> 1779:                         var primary = TreeInfo.primaryPatternType(pat);

general comment: the handleSwitch method is getting more and more complex, please consider refactoring it, probably splitting it, for example different subrutines handling different case kinds. Of course this probably should be done as a separate effort.

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From mcimadamore at openjdk.java.net  Fri Apr 15 16:06:40 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 15 Apr 2022 16:06:40 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <itlvM9hgIlX8qMNe2ZeH_FNryI_UZRekfpmMXApdoLo=.79784ddc-d45f-43e6-ae49-13f66d814714@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

Looks good - I like how moving the guard from pattern to an expression inside a switch made the code simpler to reason about, and also simplified the compiler API. I left some comments in the javadoc of MatchException.

src/java.base/share/classes/java/lang/MatchException.java line 33:

> 31:  * Thrown to indicate an unexpected failure in pattern matching.
> 32:  *
> 33:  * MatchException may be thrown when an exhaustive pattern matching language construct

Maybe wrap with `{@code}`

src/java.base/share/classes/java/lang/MatchException.java line 34:

> 32:  *
> 33:  * MatchException may be thrown when an exhaustive pattern matching language construct
> 34:  * (such as a switch expression) encounters a match target that does not match any of the provided

Is the term "match target" defined somewhere? In general, it would be good quoting relevant sections of the JLS, and using consistent terminology

src/java.base/share/classes/java/lang/MatchException.java line 37:

> 35:  * patterns at runtime.  This can currently arise from the following case:
> 36:  * <ul>
> 37:  *     <li>Separate compilation anomalies, where a sealed interface has a different

Why a list if there's only one case? I know we have plans to expand this to cover nulls in records patterns, but right now the javadoc should stand on its own

src/java.base/share/classes/java/lang/MatchException.java line 52:

> 50: 
> 51:     /**
> 52:      * Constructs an {@code MatchException} with no detail  message.

double space before "message" ?

src/java.base/share/classes/java/lang/MatchException.java line 73:

> 71:      *
> 72:      * @param  cause the cause (which is saved for later retrieval by the
> 73:      *         {@link #getCause()} method).  (A {@code null} value is

double space before "(A" ?

src/java.base/share/classes/java/lang/MatchException.java line 88:

> 86:      *         by the {@link #getMessage()} method).
> 87:      * @param  cause the cause (which is saved for later retrieval by the
> 88:      *         {@link #getCause()} method).  (A {@code null} value is

Same here, double space before "(A"

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Fri Apr 15 16:16:42 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 15 Apr 2022 16:16:42 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <MBjkwo2rOCJRGMm1xXhCBIDCFWCYjXhklP2-5BFg0-k=.e996902b-b0ef-4bf9-bf84-30ac5d3deb39@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

the patch doesn't apply cleanly on the master repo probably need to rebase?

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From prappo at openjdk.java.net  Fri Apr 15 17:08:10 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 15 Apr 2022 17:08:10 GMT
Subject: RFR: 8284908: Refine diagnostic positions for DCErroneous
Message-ID: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>

Before:

Standard Doclet version 18+36-2087
Building tree for all the packages and classes...
Generating /tmp/whatever/ExampleDiagnostics.html...
ExampleDiagnostics.java:5: error: unexpected content
     * {@docRoot a}
       ^
ExampleDiagnostics.java:11: error: unexpected content
     * {@inheritDoc a}
       ^
ExampleDiagnostics.java:17: error: '>' expected
     * @param <T param
                     ^

After:

Standard Doclet version 19-internal-2022-04-07-1105474.pavelrappo...
Building tree for all the packages and classes...
Generating /tmp/whatever/ExampleDiagnostics.html...
ExampleDiagnostics.java:5: error: unexpected content
     * {@docRoot a}
                 ^
ExampleDiagnostics.java:11: error: unexpected content
     * {@inheritDoc a}
                    ^
ExampleDiagnostics.java:17: error: '>' expected
     * @param <T param
                ^

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

Commit messages:
 - Update copyright years
 - Specify preferred diagnostic positions
 - Print prefPos in header if prefPos is defined

Changes: https://git.openjdk.java.net/jdk/pull/8264/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8264&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284908
  Stats: 67 lines in 14 files changed: 19 ins; 0 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8264.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8264/head:pull/8264

PR: https://git.openjdk.java.net/jdk/pull/8264

From prappo at openjdk.java.net  Fri Apr 15 17:15:36 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 15 Apr 2022 17:15:36 GMT
Subject: RFR: 8284908: Refine diagnostic positions for DCErroneous
In-Reply-To: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
References: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
Message-ID: <4NfwLB60Rt77m7C2krMIT2ggOP_KAYOEDgQDEc3ETis=.32b471ce-d871-4a69-9dd6-bd36c8723df4@github.com>

On Fri, 15 Apr 2022 16:58:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Before:
> 
> Standard Doclet version 18+36-2087
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>        ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>        ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                      ^
> 
> After:
> 
> Standard Doclet version 19-internal-2022-04-07-1105474.pavelrappo...
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>                  ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>                     ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                 ^

A drive-by observation: shouldn't we allow whitespace in between the type variable and the closing `>`?

Currently, this is valid:

@param < T> param

while this is not:

@param <T > param


If we decide to allow whitespace in between the type variable and the closing `>`, it should be done in a separate PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8264

From darcy at openjdk.java.net  Fri Apr 15 20:07:01 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 15 Apr 2022 20:07:01 GMT
Subject: RFR: JDK-8284923: Update description of SourceVersion.RELEASE_18
Message-ID: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>

The description of SourceVersion.RELEASE_18 does not explicitly state what language changes are present, or not present in the release.

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

Commit messages:
 - JDK-8284923: Update description of SourceVersion.RELEASE_18

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

PR: https://git.openjdk.java.net/jdk/pull/8268

From duke at openjdk.java.net  Fri Apr 15 22:03:37 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 15 Apr 2022 22:03:37 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <HhAOfPXwbrCbH6QmzVxsH1jcxBLWplHew8DXEDAnuLs=.33ea6288-f2b2-4423-986c-2da5b1337563@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

`java.lang.MatchException` should?probably also?be?thrown by?non?`enum` enhanced?`switch`?statements[^1], to?match non?`enum` `switch`?expressions[^2].

[^1]: https://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html#jls-14.11.3
[^2]: https://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html#jls-15.28.2

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From darcy at openjdk.java.net  Sat Apr 16 23:04:08 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 16 Apr 2022 23:04:08 GMT
Subject: RFR: JDK-8284928: Add links from SourceVersion to specific JLS
 versions
Message-ID: <IVfJ1r33aOBFptaRRhUU7XxuadpI8KxvuTq2VwmJC4w=.0062fe30-851f-4405-afa5-c6bca622f302@github.com>

As a convenience to readers, add links from the SourceVersion constants to the particular JLS release they correspond to.

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

Commit messages:
 - JDK-8284928: Add links from SourceVersion to specific JLS versions

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

PR: https://git.openjdk.java.net/jdk/pull/8275

From iris at openjdk.java.net  Sun Apr 17 01:54:37 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Sun, 17 Apr 2022 01:54:37 GMT
Subject: RFR: JDK-8284928: Add links from SourceVersion to specific JLS
 versions
In-Reply-To: <IVfJ1r33aOBFptaRRhUU7XxuadpI8KxvuTq2VwmJC4w=.0062fe30-851f-4405-afa5-c6bca622f302@github.com>
References: <IVfJ1r33aOBFptaRRhUU7XxuadpI8KxvuTq2VwmJC4w=.0062fe30-851f-4405-afa5-c6bca622f302@github.com>
Message-ID: <NOb3bag1sPdZMRb4TVQg1Hd-cFfo4qtS-X6thtBn5h0=.1b9afdd6-a90d-48a0-a10c-9391d65f97fd@github.com>

On Sat, 16 Apr 2022 22:57:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As a convenience to readers, add links from the SourceVersion constants to the particular JLS release they correspond to.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8275

From jjg at openjdk.java.net  Sun Apr 17 15:36:40 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 17 Apr 2022 15:36:40 GMT
Subject: RFR: JDK-8284923: Update description of SourceVersion.RELEASE_18
In-Reply-To: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>
References: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>
Message-ID: <9fZsrg0Wo3UpMkvIaRL1yTdm1fFebg-3Wguux9Exd3E=.9925d844-8644-4503-8ba3-a5e19e09509f@github.com>

On Fri, 15 Apr 2022 20:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The description of SourceVersion.RELEASE_18 does not explicitly state what language changes are present, or not present in the release.

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8268

From iris at openjdk.java.net  Sun Apr 17 23:32:38 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Sun, 17 Apr 2022 23:32:38 GMT
Subject: RFR: JDK-8284923: Update description of SourceVersion.RELEASE_18
In-Reply-To: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>
References: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>
Message-ID: <1nY5yknObUIYKXoQp19DaujoYJWRLWLEXplgnpZrVXs=.54b04fa6-4d80-4d01-98d3-3e65fae5bce6@github.com>

On Fri, 15 Apr 2022 20:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The description of SourceVersion.RELEASE_18 does not explicitly state what language changes are present, or not present in the release.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8268

From ksakata at openjdk.java.net  Mon Apr 18 12:55:40 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Mon, 18 Apr 2022 12:55:40 GMT
Subject: Integrated: 8283870: jdeprscan --help causes an exception when the
 locale is ja, zh_CN or de
In-Reply-To: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
Message-ID: <6_nPszRY-p_fncjw61Rb54xsCl5i6y6YfOd65V-GYDQ=.5985730a-b6af-4771-a71b-0c3254757780@github.com>

On Mon, 11 Apr 2022 05:31:49 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> # Summary
> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
> 
> # How to reproduce this issue
> 
> $ jdeprscan -J-Duser.language=ja --help
> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>         ... 8 more
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ?Same as above?
> 
> $ jdeprscan -J-Duser.language=de --help
> ?Same as above?
> 
> Of course, it works well when the locale is anything other than those locales.
> 
> # Details
> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
> 
> I removed extra single quotes.
> 
> # Test
> It seems there is no test class for it. So I run commands as I mentioned before.
> 
> $ jdeprscan -J-Duser.language=ja --help
> ????: jdeprscan [options] {dir|jar|class} ...
> 
> ?????:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ???API????????????????????????
> ???????????????????????JAR?????
> ?????????????????????????????
> ???????????????????????????????
> ????$????????:
> 
>     java.lang.Thread$State
> 
> --class-path?????????????????????
> ???????????
> 
> --for-removal??????????????????????????API?
> ????????????6?7???8????????????
> 
> --full-version????????????????????????????
> 
> --help (-? -h)?????????????????????????
> 
> --list (-l)?????????API???????????????????????
> ???????JAR??????????????????????
> 
> --release????????????????API?????????Java SE
> ???????????
> 
> --verbose (-v)????????????????????????????????
> 
> --version????????????????????????????????
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ???jdeprscan [options] {dir|jar|class} ...
> 
> ???
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ????????????????? API?
> ???????????????JAR ???
> ????????????????
> ????????????? $ ???
> ?????????
> 
>     java.lang.Thread$State
> 
> --class-path ?????????????
> ?????
> 
> --for-removal ????????????????
> ? API???????? 6?7 ? 8 ?????
> 
> --full-version ???????????????
> 
> --help (-? -h) ????????????
> 
> --list (-l) ?????????? API???????
> ???????????jar ?????
> 
> --release ????????????? API ?
> ? Java SE ????
> 
> --verbose (-v) ????????????????
> 
> --version ???????????????
> 
> $ jdeprscan -J-Duser.language=de --help
> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
> 
> Optionen:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
> f?r verschachtelte Klassen angegeben werden. Beispiel:
> 
>     java.lang.Thread$State
> 
> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
> von abh?ngigen Klassen.
> 
> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
> 
> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
> 
> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
> 
> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
> 
> Die Option --release gibt das Java SE-Release an, das die Gruppe
> der veralteten APIS zum Scannen liefert.
> 
> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
> 
> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
> 
> $ jdeprscan -J-Duser.language=en --help                    
> Usage: jdeprscan [options] {dir|jar|class} ...
> 
> options:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scans each argument for usages of deprecated APIs. An argument
> may be a directory specifying the root of a package hierarchy,
> a JAR file, a class file, or a class name. The class name must be
> specified using a fully qualified class name using the $ separator
> character for nested classes, for example,
> 
>     java.lang.Thread$State
> 
> The --class-path option provides a search path for resolution
> of dependent classes.
> 
> The --for-removal option limits scanning or listing to APIs that are
> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
> 
> The --full-version option prints out the full version string of the tool.
> 
> The --help (-? -h) option prints out a full help message.
> 
> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
> so no directory, jar, or class arguments should be provided.
> 
> The --release option specifies the Java SE release that provides the set
> of deprecated APIs for scanning.
> 
> The --verbose (-v) option enables additional message output during processing.
> 
> The --version option prints out the abbreviated version string of the tool.

This pull request has now been integrated.

Changeset: ef25e189
Author:    Koichi Sakata <ksakata at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ef25e189c7f987b6c7b049ce481ee832cc7f70aa
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8283870: jdeprscan --help causes an exception when the locale is ja, zh_CN or de

Reviewed-by: naoto

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

PR: https://git.openjdk.java.net/jdk/pull/8174

From darcy at openjdk.java.net  Mon Apr 18 16:49:30 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 18 Apr 2022 16:49:30 GMT
Subject: RFR: JDK-8284923: Update description of SourceVersion.RELEASE_18
In-Reply-To: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>
References: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>
Message-ID: <UXoXFEfGbozrmSlIrewQwja8Q_Qdu7OJZn5cOF9XUdo=.ac909a86-4d9c-47d8-bfc7-769bc0c3b76e@github.com>

On Fri, 15 Apr 2022 20:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The description of SourceVersion.RELEASE_18 does not explicitly state what language changes are present, or not present in the release.

FYI, I've filed

JDK-8284966: Update SourceVersion.RELEASE_19 description for language changes

as a reminder to handle the analogous situation for 19 later in the release.

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

PR: https://git.openjdk.java.net/jdk/pull/8268

From darcy at openjdk.java.net  Mon Apr 18 17:21:43 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 18 Apr 2022 17:21:43 GMT
Subject: Integrated: JDK-8284923: Update description of
 SourceVersion.RELEASE_18
In-Reply-To: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>
References: <M3STKbqu4czzLA9l76oT3gyU8ifN1n56Y2c_aRvn_5A=.41b102ee-1a15-4555-99c3-9effad467e10@github.com>
Message-ID: <QlgUKEajB-voDe739pfTQ-MyW-keIBA1YFl4xwwgKMY=.e6fad3ef-39bc-4a4b-b473-357953767cb5@github.com>

On Fri, 15 Apr 2022 20:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The description of SourceVersion.RELEASE_18 does not explicitly state what language changes are present, or not present in the release.

This pull request has now been integrated.

Changeset: 6e36c455
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6e36c4550a5729280c8e18aea6754004a0c11ce2
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8284923: Update description of SourceVersion.RELEASE_18

Reviewed-by: jjg, iris

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

PR: https://git.openjdk.java.net/jdk/pull/8268

From jlahoda at openjdk.java.net  Mon Apr 18 17:27:30 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 18 Apr 2022 17:27:30 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v4]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <-R33j4QSbzRESFk8uh-J0EIgN15g4bqqt59oLXK5ddY=.bcdda047-e3ff-4c5e-ac6e-fcdfb0b939e0@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

  Adjusting to review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/ef7a7d6a..311d68a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=02-03

  Stats: 27 lines in 6 files changed: 1 ins; 0 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Mon Apr 18 17:27:30 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 18 Apr 2022 17:27:30 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <d8f-1gDXt_jB7QFopFkl6m8n686V7rSW-XwPtq0Wrzk=.63fd1729-5258-480a-a409-acdb6cae7033@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

Thanks for the comments so far. I've reflected most of them here:
https://github.com/openjdk/jdk/pull/8182/commits/311d68a60200dc4d9928e5ea2854c22fbcf68596
please let me know what you think!

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Mon Apr 18 17:27:31 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 18 Apr 2022 17:27:31 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <JozJia5Wjs5vWHG7hvtIXsw2GkAUFkmenl9Hye1SuAY=.894034f5-4178-4e46-bd76-c3c0c3b0a268@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
 <JozJia5Wjs5vWHG7hvtIXsw2GkAUFkmenl9Hye1SuAY=.894034f5-4178-4e46-bd76-c3c0c3b0a268@github.com>
Message-ID: <DADSwLVC8niNxSxBU7guAxmA_H-jWR44HEIPDrlcpKo=.7a6b084c-35d2-4cc7-8ae5-61c1f472c79e@github.com>

On Fri, 15 Apr 2022 15:36:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1779:
> 
>> 1777:                         //binding pattern
>> 1778:                         attribExpr(pat, switchEnv);
>> 1779:                         var primary = TreeInfo.primaryPatternType(pat);
> 
> general comment: the handleSwitch method is getting more and more complex, please consider refactoring it, probably splitting it, for example different subrutines handling different case kinds. Of course this probably should be done as a separate effort.

Thanks for the comment. I agree the method is fairly complex, but it is also a bit difficult to disentangle into separate methods. We've separated some of the checks to `Check.checkSwitchCaseStructure` before. I'll try to think of splitting it more, but I am not sure where that will lead.

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From darcy at openjdk.java.net  Mon Apr 18 17:40:37 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 18 Apr 2022 17:40:37 GMT
Subject: RFR: JDK-8284928: Add links from SourceVersion to specific JLS
 versions [v2]
In-Reply-To: <IVfJ1r33aOBFptaRRhUU7XxuadpI8KxvuTq2VwmJC4w=.0062fe30-851f-4405-afa5-c6bca622f302@github.com>
References: <IVfJ1r33aOBFptaRRhUU7XxuadpI8KxvuTq2VwmJC4w=.0062fe30-851f-4405-afa5-c6bca622f302@github.com>
Message-ID: <ke_tCjH14jSXk4P3wrn8fpnWEKKG0EYv_TRB9gA8ZeA=.083ea300-1fd8-4e36-bda5-8c86b5b7804e@github.com>

> As a convenience to readers, add links from the SourceVersion constants to the particular JLS release they correspond to.

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

 - Merge branch 'master' into JDK-8284928
 - JDK-8284928: Add links from SourceVersion to specific JLS versions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8275/files
  - new: https://git.openjdk.java.net/jdk/pull/8275/files/08577a28..984ae7da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8275&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8275&range=00-01

  Stats: 122 lines in 12 files changed: 55 ins; 17 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8275/head:pull/8275

PR: https://git.openjdk.java.net/jdk/pull/8275

From darcy at openjdk.java.net  Mon Apr 18 17:46:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 18 Apr 2022 17:46:44 GMT
Subject: RFR: JDK-8284928: Add links from SourceVersion to specific JLS
 versions [v2]
In-Reply-To: <ke_tCjH14jSXk4P3wrn8fpnWEKKG0EYv_TRB9gA8ZeA=.083ea300-1fd8-4e36-bda5-8c86b5b7804e@github.com>
References: <IVfJ1r33aOBFptaRRhUU7XxuadpI8KxvuTq2VwmJC4w=.0062fe30-851f-4405-afa5-c6bca622f302@github.com>
 <ke_tCjH14jSXk4P3wrn8fpnWEKKG0EYv_TRB9gA8ZeA=.083ea300-1fd8-4e36-bda5-8c86b5b7804e@github.com>
Message-ID: <VDLOCl5uNeeEcBnOee8V6AbKBQewQEbG3Fi_YdFKG6Y=.1c9137d4-c235-442b-ad01-cd057ecfafa2@github.com>

On Mon, 18 Apr 2022 17:40:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> As a convenience to readers, add links from the SourceVersion constants to the particular JLS release they correspond to.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8284928
>  - JDK-8284928: Add links from SourceVersion to specific JLS versions

(The link to a new JLS is only added at the end of a release so I didn't add a link to JLS 19 now since it would be a dead link.)

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

PR: https://git.openjdk.java.net/jdk/pull/8275

From darcy at openjdk.java.net  Mon Apr 18 17:46:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 18 Apr 2022 17:46:45 GMT
Subject: Integrated: JDK-8284928: Add links from SourceVersion to specific JLS
 versions
In-Reply-To: <IVfJ1r33aOBFptaRRhUU7XxuadpI8KxvuTq2VwmJC4w=.0062fe30-851f-4405-afa5-c6bca622f302@github.com>
References: <IVfJ1r33aOBFptaRRhUU7XxuadpI8KxvuTq2VwmJC4w=.0062fe30-851f-4405-afa5-c6bca622f302@github.com>
Message-ID: <HJrHev67VtDAJXyZSwRsaRb3kmmW46-bRJnZDb739Ac=.13eb1a56-be49-4587-89ac-2580ad165841@github.com>

On Sat, 16 Apr 2022 22:57:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As a convenience to readers, add links from the SourceVersion constants to the particular JLS release they correspond to.

This pull request has now been integrated.

Changeset: ffdeb320
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ffdeb32062d510c291e1a89031bed626ee892537
Stats:     52 lines in 1 file changed: 52 ins; 0 del; 0 mod

8284928: Add links from SourceVersion to specific JLS versions

Reviewed-by: iris

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

PR: https://git.openjdk.java.net/jdk/pull/8275

From cushon at openjdk.java.net  Mon Apr 18 18:18:30 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 18 Apr 2022 18:18:30 GMT
Subject: RFR: 8284220: TypeMirror#toString omits enclosing class names
 after JDK-8281238 [v4]
In-Reply-To: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
References: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
Message-ID: <ZFhQguj5fOG0aAI1E7XbI8ia90SNLIPDsGy-sQA7nX4=.75d78a52-9f55-420c-8df9-dc9f2de7d5b4@github.com>

> Please consider this fix for https://bugs.openjdk.java.net/browse/JDK-8284220, which updates `ClassType#toString` to include enclosing class names when type annotations are present.
> 
> For example, `java.util. at A Map.Entry<?,?>` is now printed as `java.util. at A Map.Entry<?,?>`, instead of `java.util. at A Entry<?,?>` (note the missing `Map`).

Liam Miller-Cushon 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 'openjdk:master' into JDK-8284220
 - Refactor test based on review feedback
 - 8284220: TypeMirror#toString omits enclosing class names after JDK-8281238

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8084/files
  - new: https://git.openjdk.java.net/jdk/pull/8084/files/10efb57f..cc0531fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8084&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8084&range=02-03

  Stats: 164759 lines in 2023 files changed: 118601 ins; 10402 del; 35756 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8084.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8084/head:pull/8084

PR: https://git.openjdk.java.net/jdk/pull/8084

From ksakata at openjdk.java.net  Tue Apr 19 03:42:27 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 19 Apr 2022 03:42:27 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja, zh_CN or de [v2]
In-Reply-To: <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
 <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>
Message-ID: <e4bEVxoUnJZFBq9oa4_21zn6QtIEawId2gaYcbTXY3E=.695deb39-8786-4875-93ad-aa0ef5693c8f@github.com>

On Tue, 12 Apr 2022 06:36:29 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> # Summary
>> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
>> 
>> # How to reproduce this issue
>> 
>> $ jdeprscan -J-Duser.language=ja --help
>> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
>> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>>         ... 8 more
>> 
>> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
>> ?Same as above?
>> 
>> $ jdeprscan -J-Duser.language=de --help
>> ?Same as above?
>> 
>> Of course, it works well when the locale is anything other than those locales.
>> 
>> # Details
>> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
>> 
>> I removed extra single quotes.
>> 
>> # Test
>> It seems there is no test class for it. So I run commands as I mentioned before.
>> 
>> $ jdeprscan -J-Duser.language=ja --help
>> ????: jdeprscan [options] {dir|jar|class} ...
>> 
>> ?????:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> ???API????????????????????????
>> ???????????????????????JAR?????
>> ?????????????????????????????
>> ???????????????????????????????
>> ????$????????:
>> 
>>     java.lang.Thread$State
>> 
>> --class-path?????????????????????
>> ???????????
>> 
>> --for-removal??????????????????????????API?
>> ????????????6?7???8????????????
>> 
>> --full-version????????????????????????????
>> 
>> --help (-? -h)?????????????????????????
>> 
>> --list (-l)?????????API???????????????????????
>> ???????JAR??????????????????????
>> 
>> --release????????????????API?????????Java SE
>> ???????????
>> 
>> --verbose (-v)????????????????????????????????
>> 
>> --version????????????????????????????????
>> 
>> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
>> ???jdeprscan [options] {dir|jar|class} ...
>> 
>> ???
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> ????????????????? API?
>> ???????????????JAR ???
>> ????????????????
>> ????????????? $ ???
>> ?????????
>> 
>>     java.lang.Thread$State
>> 
>> --class-path ?????????????
>> ?????
>> 
>> --for-removal ????????????????
>> ? API???????? 6?7 ? 8 ?????
>> 
>> --full-version ???????????????
>> 
>> --help (-? -h) ????????????
>> 
>> --list (-l) ?????????? API???????
>> ???????????jar ?????
>> 
>> --release ????????????? API ?
>> ? Java SE ????
>> 
>> --verbose (-v) ????????????????
>> 
>> --version ???????????????
>> 
>> $ jdeprscan -J-Duser.language=de --help
>> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
>> 
>> Optionen:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
>> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
>> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
>> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
>> f?r verschachtelte Klassen angegeben werden. Beispiel:
>> 
>>     java.lang.Thread$State
>> 
>> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
>> von abh?ngigen Klassen.
>> 
>> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
>> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
>> 
>> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
>> 
>> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
>> 
>> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
>> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
>> 
>> Die Option --release gibt das Java SE-Release an, das die Gruppe
>> der veralteten APIS zum Scannen liefert.
>> 
>> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
>> 
>> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
>> 
>> $ jdeprscan -J-Duser.language=en --help                    
>> Usage: jdeprscan [options] {dir|jar|class} ...
>> 
>> options:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> Scans each argument for usages of deprecated APIs. An argument
>> may be a directory specifying the root of a package hierarchy,
>> a JAR file, a class file, or a class name. The class name must be
>> specified using a fully qualified class name using the $ separator
>> character for nested classes, for example,
>> 
>>     java.lang.Thread$State
>> 
>> The --class-path option provides a search path for resolution
>> of dependent classes.
>> 
>> The --for-removal option limits scanning or listing to APIs that are
>> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
>> 
>> The --full-version option prints out the full version string of the tool.
>> 
>> The --help (-? -h) option prints out a full help message.
>> 
>> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
>> so no directory, jar, or class arguments should be provided.
>> 
>> The --release option specifies the Java SE release that provides the set
>> of deprecated APIs for scanning.
>> 
>> The --verbose (-v) option enables additional message output during processing.
>> 
>> The --version option prints out the abbreviated version string of the tool.
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary single quotes in the German file

Thank you for sponsoring, Naoto.

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

PR: https://git.openjdk.java.net/jdk/pull/8174

From cushon at openjdk.java.net  Tue Apr 19 16:39:23 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 19 Apr 2022 16:39:23 GMT
Subject: RFR: 8284220: TypeMirror#toString omits enclosing class names
 after JDK-8281238 [v2]
In-Reply-To: <y-XK3vcJAzLktFQN94N-HoTS8Q5KYwDYWsxhbqN3Ero=.6b206236-8863-410f-8d8b-52cf4596ec53@github.com>
References: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
 <Xt1oOBXHZoemAblQoy-5mrIn29Ci3tMSkrmeSfRFpQw=.2bbf6321-248d-4c48-b939-1d371604dea0@github.com>
 <y-XK3vcJAzLktFQN94N-HoTS8Q5KYwDYWsxhbqN3Ero=.6b206236-8863-410f-8d8b-52cf4596ec53@github.com>
Message-ID: <oBaT3UMar6aRbEt2AKwxeZh2htb80erCCIGRSEmYKq0=.3d1f2766-2c2f-488b-b237-9738f2b5451c@github.com>

On Mon, 4 Apr 2022 18:22:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Liam Miller-Cushon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8284220: TypeMirror#toString omits enclosing class names after JDK-8281238
>
> test/langtools/tools/javac/tree/NestedTypeToString.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: /*
> 
> The fix for JDK-8281238 required several existing tests to be updated, so it did not have a dedicated test written for it. For this follow-on fix, if the test is going to use an annotation processor, which is quite reasonable, I suggest:
> * placing the test somewhere under test/langtools/tools/javac/processing/model
> *  subclassing JavacTestingAbstractProcessor
> *  using string-valued annotations to hold the expected result and checking them in the process method
> 
> There are other tests using processor following this model under test/langtools/tools/javac/processing/model.

@jddarcy is there any other feedback I can address?

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

PR: https://git.openjdk.java.net/jdk/pull/8084

From jlahoda at openjdk.java.net  Tue Apr 19 18:47:16 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 19 Apr 2022 18:47:16 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

  Cleanup - more total -> unconditional pattern renaming.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/311d68a6..dc001541

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Wed Apr 20 14:54:28 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 20 Apr 2022 14:54:28 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
Message-ID: <bbg-44aXfR92Yb5TiPjNVX8of7_ojMRWFhFGMRpTt2U=.6157ad9c-5370-4f07-9eae-8c3439460490@github.com>

On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup - more total -> unconditional pattern renaming.

nit: just ran langtools tests as part of my routine and these seem to be failing, CheckExamples.java due to:
test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java and
test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java

and this one too:
test/langtools/tools/javac/patterns/InstanceofTotalPattern.java (seems to be a golden file issue)

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Wed Apr 20 15:37:28 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 20 Apr 2022 15:37:28 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
Message-ID: <kRIP4DuRuPFxvGGHNRYrVvZ_w1E104zlFIwbNRnIcJ0=.427ef7ac-7bc7-4bcf-abc0-fc959dd0b776@github.com>

On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup - more total -> unconditional pattern renaming.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 2:

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

typo: `20222` instead of `2022`

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Wed Apr 20 17:13:41 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 20 Apr 2022 17:13:41 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
Message-ID: <ZY82MogWcdxTCmL8iecfLJagbR9XGGz6uIO1xY88c3g=.65814a1b-4063-4793-9502-41eb9030681e@github.com>

On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup - more total -> unconditional pattern renaming.

I don't have any other comments, looks good

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8182

From cushon at openjdk.java.net  Wed Apr 20 18:13:29 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 20 Apr 2022 18:13:29 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <w6HBMP61QYXtHRzUVK4X8_IXAr9u_93iUn3uUU6j4RU=.b24d5e0e-77b5-4247-ab1a-be763414e61a@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <zUAsR6AdXsnGlIcpAmqxSZ-vXa-6nydLzr_lg29CIgM=.2168ec52-b171-4bf4-a034-b64936db2eae@github.com>
 <w6HBMP61QYXtHRzUVK4X8_IXAr9u_93iUn3uUU6j4RU=.b24d5e0e-77b5-4247-ab1a-be763414e61a@github.com>
Message-ID: <l0zKJeNJewXyRRt6ce1DBjc-Ie6sPFpMt8fnCNDAMxE=.26374618-9d98-4b1b-9b46-fabe428d615b@github.com>

On Mon, 4 Apr 2022 08:32:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I did some testing with the real builds that I minimized for the repro in JDK-8282080 and everything looks good to me. Thanks!
>
> @cushon - thanks for testing!

@lahodaj did you run into any blockers for this, or is it just waiting for an official review?

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From jlahoda at openjdk.java.net  Wed Apr 20 20:40:29 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 20 Apr 2022 20:40:29 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <bbg-44aXfR92Yb5TiPjNVX8of7_ojMRWFhFGMRpTt2U=.6157ad9c-5370-4f07-9eae-8c3439460490@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
 <bbg-44aXfR92Yb5TiPjNVX8of7_ojMRWFhFGMRpTt2U=.6157ad9c-5370-4f07-9eae-8c3439460490@github.com>
Message-ID: <TNWbdN07GHTzgZlV0DbxNY5fLSSMQrxzqaqEEVn1EqM=.b98007e6-b6e8-4e9a-860d-91ffb8eab7f4@github.com>

On Wed, 20 Apr 2022 14:50:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> nit: just ran langtools tests as part of my routine and these seem to be failing, `CheckExamples.java` due to:
> 
> ```
> test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java and
> test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java
> ```
> 
> and this one too:
> 
> ```
> test/langtools/tools/javac/patterns/InstanceofTotalPattern.java (seems to be a golden file issue)
> ```

Thanks for checking and sorry for that. Will fix in next update.

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From jjg at openjdk.java.net  Wed Apr 20 21:50:42 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 20 Apr 2022 21:50:42 GMT
Subject: RFR: 8284908: Refine diagnostic positions for DCErroneous
In-Reply-To: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
References: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
Message-ID: <mH73GMN7YQ4RRmdbFHISzG1sMmFT99-42yvHMRkMaZE=.a619e039-0901-4e55-9f5d-df85962c1dfc@github.com>

On Fri, 15 Apr 2022 16:58:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Before:
> 
> Standard Doclet version 18+36-2087
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>        ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>        ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                      ^
> 
> After:
> 
> Standard Doclet version 19-internal-2022-04-07-1105474.pavelrappo...
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>                  ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>                     ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                 ^

Looks generally good for me. One small suggestion in the base `DocCommentTester` class

test/langtools/tools/javac/doctree/DocCommentTester.java line 732:

> 730:                 var n = (DCTree) node;
> 731:                 out.println(simpleClassName(node) + "[" + node.getKind() + ", pos:" + n.pos +
> 732:                         (n.getPreferredPosition() > n.pos ? ", prefPos:" + n.getPreferredPosition() : ""));

Being paranoid, I suggest using `!=` instead of `>`

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8264

From prappo at openjdk.java.net  Wed Apr 20 22:35:06 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 20 Apr 2022 22:35:06 GMT
Subject: RFR: 8284908: Refine diagnostic positions for DCErroneous [v2]
In-Reply-To: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
References: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
Message-ID: <VLts9GX28x7xhRir-umCNiOqA6wcRJ2HGD9kNSB-Tjk=.997c026a-8fda-4154-ad9d-0e34dc3d3384@github.com>

> Before:
> 
> Standard Doclet version 18+36-2087
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>        ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>        ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                      ^
> 
> After:
> 
> Standard Doclet version 19-internal-2022-04-07-1105474.pavelrappo...
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>                  ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>                     ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                 ^

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

  Address feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8264/files
  - new: https://git.openjdk.java.net/jdk/pull/8264/files/9bcb0a22..7bce75a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8264&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8264&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8264

From prappo at openjdk.java.net  Wed Apr 20 22:35:07 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 20 Apr 2022 22:35:07 GMT
Subject: RFR: 8284908: Refine diagnostic positions for DCErroneous [v2]
In-Reply-To: <mH73GMN7YQ4RRmdbFHISzG1sMmFT99-42yvHMRkMaZE=.a619e039-0901-4e55-9f5d-df85962c1dfc@github.com>
References: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
 <mH73GMN7YQ4RRmdbFHISzG1sMmFT99-42yvHMRkMaZE=.a619e039-0901-4e55-9f5d-df85962c1dfc@github.com>
Message-ID: <kLHEahj_RfJJHcLaacOC-R-E6GH5SB_oy7z1pMPrLJA=.11af281c-816d-43f3-ad30-1f20cc8fca4d@github.com>

On Wed, 20 Apr 2022 21:45:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> test/langtools/tools/javac/doctree/DocCommentTester.java line 732:
> 
>> 730:                 var n = (DCTree) node;
>> 731:                 out.println(simpleClassName(node) + "[" + node.getKind() + ", pos:" + n.pos +
>> 732:                         (n.getPreferredPosition() > n.pos ? ", prefPos:" + n.getPreferredPosition() : ""));
> 
> Being paranoid, I suggest using `!=` instead of `>`

If this suggestion of yours passes tests, I will integrate it.

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

PR: https://git.openjdk.java.net/jdk/pull/8264

From prappo at openjdk.java.net  Wed Apr 20 22:56:25 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 20 Apr 2022 22:56:25 GMT
Subject: RFR: 8284908: Refine diagnostic positions for DCErroneous [v3]
In-Reply-To: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
References: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
Message-ID: <lhb3deF6yoefawus3POzg0RsCkEt3t973Y2wG9gMZQk=.147e19ca-de44-402b-9a0f-64aecb6e3b2c@github.com>

> Before:
> 
> Standard Doclet version 18+36-2087
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>        ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>        ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                      ^
> 
> After:
> 
> Standard Doclet version 19-internal-2022-04-07-1105474.pavelrappo...
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>                  ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>                     ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                 ^

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

 - Merge branch 'master' into 8284908
 - Address feedback
 - Update copyright years
 - Specify preferred diagnostic positions
 - Print prefPos in header if prefPos is defined
   
   This is a test only change.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8264/files
  - new: https://git.openjdk.java.net/jdk/pull/8264/files/7bce75a6..7b66b3d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8264&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8264&range=01-02

  Stats: 13184 lines in 918 files changed: 7976 ins; 2097 del; 3111 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8264.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8264/head:pull/8264

PR: https://git.openjdk.java.net/jdk/pull/8264

From prappo at openjdk.java.net  Thu Apr 21 09:01:30 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 21 Apr 2022 09:01:30 GMT
Subject: Integrated: 8284908: Refine diagnostic positions for DCErroneous
In-Reply-To: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
References: <oFIKVT5M25AZWxG2c0JmRAdMBura-zvcyS5s86Lld7Q=.808ee5ab-7102-49b6-bb9a-e92f13b765c8@github.com>
Message-ID: <6Z0PXqS_J6eIwwEyB1xaiyjU86VNNMD5UrMNOe9NiT4=.88b6a019-b83c-4f68-8109-a54f08859d61@github.com>

On Fri, 15 Apr 2022 16:58:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Before:
> 
> Standard Doclet version 18+36-2087
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>        ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>        ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                      ^
> 
> After:
> 
> Standard Doclet version 19-internal-2022-04-07-1105474.pavelrappo...
> Building tree for all the packages and classes...
> Generating /tmp/whatever/ExampleDiagnostics.html...
> ExampleDiagnostics.java:5: error: unexpected content
>      * {@docRoot a}
>                  ^
> ExampleDiagnostics.java:11: error: unexpected content
>      * {@inheritDoc a}
>                     ^
> ExampleDiagnostics.java:17: error: '>' expected
>      * @param <T param
>                 ^

This pull request has now been integrated.

Changeset: d6b5a635
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6b5a6357710598be225e67f82e6e0c1bed2d62f
Stats:     67 lines in 14 files changed: 19 ins; 0 del; 48 mod

8284908: Refine diagnostic positions for DCErroneous

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk/pull/8264

From jlahoda at openjdk.java.net  Thu Apr 21 09:15:15 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 21 Apr 2022 09:15:15 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v6]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <APfqAZKHwb4CmwLKRZdxT0LroJ2qpSNLCJILIMrcqQU=.8aa5b38a-7946-432a-9adb-40a19b5f2ec5@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

  Cleanup, fixing tests.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/dc001541..76f2d05c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/8182

From duke at openjdk.java.net  Thu Apr 21 12:53:26 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 21 Apr 2022 12:53:26 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v6]
In-Reply-To: <APfqAZKHwb4CmwLKRZdxT0LroJ2qpSNLCJILIMrcqQU=.8aa5b38a-7946-432a-9adb-40a19b5f2ec5@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <APfqAZKHwb4CmwLKRZdxT0LroJ2qpSNLCJILIMrcqQU=.8aa5b38a-7946-432a-9adb-40a19b5f2ec5@github.com>
Message-ID: <oWEFE8GKiVUQf6lHxEIZe22ra6BnRbXF_UG-s7f3fks=.abfd1eaa-3952-4040-8620-2fc2dc2005a7@github.com>

On Thu, 21 Apr 2022 09:15:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup, fixing tests.

LGTM

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

Marked as reviewed by biboudis at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Thu Apr 21 16:16:47 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 21 Apr 2022 16:16:47 GMT
Subject: RFR: 8282823: javac should constrain more uses of preview APIs
 [v3]
In-Reply-To: <rRaOVobbfrkP_ztniSfPMAUtOZkxCqeJLKyLycn4Kzs=.29d8f3a5-a52f-41be-8522-1d72f9d76726@github.com>
References: <rRaOVobbfrkP_ztniSfPMAUtOZkxCqeJLKyLycn4Kzs=.29d8f3a5-a52f-41be-8522-1d72f9d76726@github.com>
Message-ID: <qK9cca_1sqPgQe9a1asg1PpFe4K7ftBftIDPOBt4xCk=.6f12ddc4-1b58-4a41-8c6a-219c4bb3a32d@github.com>

> Consider a class or interface with a method marked as preview. Subclassing the class or implementing the interface by itself should not cause a preview error/warning (as that would be problematic for Loom), but overriding the method should produce a preview error/warning.
> 
> This patch adds the error/warning in case a preview method is overridden.

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

 - Improving comment, adding more tests.
 - Merge branch 'master' into JDK-8282823
 - Only produce preview warnings for immediate overriders of preview methods.
 - Improving test.
 - 8282823: javac should constrain more uses of preview APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7774/files
  - new: https://git.openjdk.java.net/jdk/pull/7774/files/3b8ac122..bab0404f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7774&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7774&range=01-02

  Stats: 166962 lines in 2682 files changed: 120988 ins; 33811 del; 12163 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7774.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7774/head:pull/7774

PR: https://git.openjdk.java.net/jdk/pull/7774

From prappo at openjdk.java.net  Thu Apr 21 19:35:56 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 21 Apr 2022 19:35:56 GMT
Subject: RFR: 8285396: Do not fill in the stacktrace of an internal exception
Message-ID: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>

Sometimes an exception is retrofitted into control flow to interrupt it in a way that it wasn't originally designed to be interrupted. Such an exception is an implementation detail. Once the exception is caught internally, it is discarded.

An exception has a stacktrace. Filling in a stacktrace is not free. Filling in a stacktrace that won't be used seems like a waste.

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

Commit messages:
 - Update copyright years
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8347/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8347&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285396
  Stats: 15 lines in 6 files changed: 4 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8347.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8347/head:pull/8347

PR: https://git.openjdk.java.net/jdk/pull/8347

From jjg at openjdk.java.net  Thu Apr 21 20:37:24 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 21 Apr 2022 20:37:24 GMT
Subject: RFR: 8285396: Do not fill in the stacktrace of an internal
 exception
In-Reply-To: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
References: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
Message-ID: <jqo8jldtRJ9qgMcZNkIVcKdQIBkHlrTsA1A-fIneamw=.cf82b271-8070-439f-b447-828aac0bb8d9@github.com>

On Thu, 21 Apr 2022 19:28:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Sometimes an exception is retrofitted into control flow to interrupt it in a way that it wasn't originally designed to be interrupted. Such an exception is an implementation detail. Once the exception is caught internally, it is discarded.
> 
> An exception has a stacktrace. Filling in a stacktrace is not free. Filling in a stacktrace that won't be used seems like a waste.

The changes for the `UncheckedIOException` wrappers look OK, but might be even better if the code properly unwrapped the wrapper and simply rethrew the underlying cause. For example,

replace 

        } catch (UncheckedIOException ex) {
            throw new IOException(ex.getMessage(), ex);

with

        } catch (UncheckedIOException ex) {
            throw ex.getCause();
```            


For the `TreePath` and `DocTreePath` `Result` exceptions, a better solution would be to add an opt-in short-circuiting mechanism info the scanner's `scanAndReduce` method, to avoid calling additional calls of `scan` once some condition has been met, like a non-null result.  This would completely avoid the need to throw an exception.

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

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8347

From prappo at openjdk.java.net  Thu Apr 21 22:14:27 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 21 Apr 2022 22:14:27 GMT
Subject: RFR: 8285396: Do not fill in the stacktrace of an internal
 exception
In-Reply-To: <jqo8jldtRJ9qgMcZNkIVcKdQIBkHlrTsA1A-fIneamw=.cf82b271-8070-439f-b447-828aac0bb8d9@github.com>
References: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
 <jqo8jldtRJ9qgMcZNkIVcKdQIBkHlrTsA1A-fIneamw=.cf82b271-8070-439f-b447-828aac0bb8d9@github.com>
Message-ID: <_9K5xdhsNavR4L-fOFRWim_ve_KQOivBOFz4Me09U1A=.e451940a-4c6c-4ace-9974-6c82c46157c1@github.com>

On Thu, 21 Apr 2022 20:34:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The changes for the `UncheckedIOException` wrappers look OK, but might be even better if the code properly unwrapped the wrapper and simply rethrew the underlying cause. For example,
> 
> replace
> 
> ```
>         } catch (UncheckedIOException ex) {
>             throw new IOException(ex.getMessage(), ex);
> ```
> 
> with
> 
> ```
>         } catch (UncheckedIOException ex) {
>             throw ex.getCause();
> ```
> 

Sounds reasonable; I'll have a look at it.

> For the `TreePath` and `DocTreePath` `Result` exceptions, a better solution would be to add an opt-in short-circuiting mechanism info the scanner's `scanAndReduce` method, to avoid calling additional calls of `scan` once some condition has been met, like a non-null result. This would completely avoid the need to throw an exception.

I think that we discussed (some of) that before in the comment section of another issue: JDK-8267690. You might want to re-read it.

What this PR proposes is to apply a band-aid until we're ready to treat the issue properly. The treatment you are suggesting is proper, but heavyweight in terms of the process: it involves an API change, which requires a CSR.

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

PR: https://git.openjdk.java.net/jdk/pull/8347

From prappo at openjdk.java.net  Thu Apr 21 23:28:16 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 21 Apr 2022 23:28:16 GMT
Subject: RFR: 8285396: Do not fill in the stacktrace of an internal
 exception [v2]
In-Reply-To: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
References: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
Message-ID: <El8_7AJNEiUkhWZYnoWt4rzB2AEcwOiUJCjl21w5VDY=.d5951b10-4eb9-4277-aeeb-e49cee4a0c17@github.com>

> Sometimes an exception is retrofitted into control flow to interrupt it in a way that it wasn't originally designed to be interrupted. Such an exception is an implementation detail. Once the exception is caught internally, it is discarded.
> 
> An exception has a stacktrace. Filling in a stacktrace is not free. Filling in a stacktrace that won't be used seems like a waste.

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

  Address feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8347/files
  - new: https://git.openjdk.java.net/jdk/pull/8347/files/1c69f0aa..a42a6626

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8347&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8347&range=00-01

  Stats: 17 lines in 2 files changed: 1 ins; 16 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8347.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8347/head:pull/8347

PR: https://git.openjdk.java.net/jdk/pull/8347

From prappo at openjdk.java.net  Thu Apr 21 23:28:16 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 21 Apr 2022 23:28:16 GMT
Subject: RFR: 8285396: Do not fill in the stacktrace of an internal
 exception [v2]
In-Reply-To: <_9K5xdhsNavR4L-fOFRWim_ve_KQOivBOFz4Me09U1A=.e451940a-4c6c-4ace-9974-6c82c46157c1@github.com>
References: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
 <jqo8jldtRJ9qgMcZNkIVcKdQIBkHlrTsA1A-fIneamw=.cf82b271-8070-439f-b447-828aac0bb8d9@github.com>
 <_9K5xdhsNavR4L-fOFRWim_ve_KQOivBOFz4Me09U1A=.e451940a-4c6c-4ace-9974-6c82c46157c1@github.com>
Message-ID: <SvBQJK7B_3S7_KeKZWkTwxmyEvwQU-nzMSWksnwpybQ=.90f717bf-9ae5-48c3-839b-5c1562849514@github.com>

On Thu, 21 Apr 2022 22:10:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> The changes for the `UncheckedIOException` wrappers look OK, but might be even better if the code properly unwrapped the wrapper and simply rethrew the underlying cause. For example,
> 
> replace
> 
> ```
>         } catch (UncheckedIOException ex) {
>             throw new IOException(ex.getMessage(), ex);
> ```
> 
> with
> 
> ```
>         } catch (UncheckedIOException ex) {
>             throw ex.getCause();
> ```

Thanks for directing my attention to these two exceptions! I think I lost my marbles for a good few minutes when decided to change them like that. I must've been thinking about something else.

Those two exceptions are used as intended: for exceptional circumstances. So their stacktraces have diagnostic value. I don't think we should re-throw the cause, because the stacktrace might look confusing.

The only thing we could improve here is to replace ad-hoc `UncheckedIOException` with standard `java.io.UncheckedIOException`, which appeared much later in the codebase. Please have a look at a42a66268f9d2175d212e6a5cba52fd11ec5332b and tell me what you think.

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

PR: https://git.openjdk.java.net/jdk/pull/8347

From jjg at openjdk.java.net  Fri Apr 22 19:17:56 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 22 Apr 2022 19:17:56 GMT
Subject: RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing an
 exception
Message-ID: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>

Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.

The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any addition scanning.

It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.

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

Commit messages:
 - minor tweak when scanning lists
 - JDK-8267690: Revisit (Doc)Tree search implemented by throwing an exception

Changes: https://git.openjdk.java.net/jdk/pull/8369/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8369&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267690
  Stats: 69 lines in 2 files changed: 26 ins; 9 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8369.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8369/head:pull/8369

PR: https://git.openjdk.java.net/jdk/pull/8369

From duke at openjdk.java.net  Fri Apr 22 21:05:34 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 22 Apr 2022 21:05:34 GMT
Subject: Withdrawn: 8178701: Compile error with switch statement on protected
 enum defined in parent inner class
In-Reply-To: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
References: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
Message-ID: <Qa6u9EXhoCkaFF4rRRU6MFLg3Wz9n24T8JW2yrY5U0M=.c8b32fd3-778d-4b1a-af77-4dbf73092401@github.com>

On Fri, 25 Feb 2022 12:32:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following code in two packages:
> 
> package foo;
> 
> import bar.D.E;
> 
> public class A {
> 
>     public static class B {
> 
>         protected enum C {
>             X, Y, Z
>         }
>     }
> 
>     public static void main(String... args) {
>         new E().run(B.C.X);
>     }
> }
> 
> 
> 
> package bar;
> 
> import foo.A.B;
> 
> public class D {
> 
>     public static class E extends B {
> 
>         public void run(C arg) {
>             switch (arg) {
>                 default:
>                     System.out.println("OK");
>             }
>         }
>     }
> }
> 
> 
> Accessing `foo.A.B.C` in `bar.D.E` is OK, as it is accessible through the `E`'s superclass. But, for the `switch`, javac creates a map (array) from runtime ordinals of constants of `E` to compile-time positions. But, this mapping is in a different class that does not extend `B`, so internal method lookups fail for it, as the methods are not accessible per Java rules.
> 
> But, at runtime, the enum class is effectively public, so I think it is possible to ignore the protected access rules and accept the method invocations while generatting the mapping code, which is what this patch is trying to do.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/7621

From vromero at openjdk.java.net  Fri Apr 22 21:14:26 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 22 Apr 2022 21:14:26 GMT
Subject: RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing
 an exception
In-Reply-To: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
References: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
Message-ID: <8A_e3LsfHeN6Bhxlexhv_6il-Oo_94zsOuZO6E6yogE=.287b5be3-80ad-431c-bb36-baa9a894017d@github.com>

On Fri, 22 Apr 2022 19:10:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.
> 
> The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any addition scanning.
> 
> It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8369

From jjg at openjdk.java.net  Sat Apr 23 17:09:58 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 23 Apr 2022 17:09:58 GMT
Subject: RFR: JDK-8284994: -Xdoclint:all returns warning for records,
 even when documented properly
Message-ID: <OleWfVmNnNng6gEDQr1SidueoEIXUKGxW6UmZOOpWWo=.954bfe3b-5d84-4e7d-b491-942b1e0ee8cc@github.com>

Please review a small fix to address issues with records in DocLint when invoked from javac.

In the course of this work, it was observed that DocLint does not check for `@param` tags for type parameters on a class or interface declaration. Fixing that uncovers issues in the JDK API documentation, so that part of the fix is disabled for now, and a followup bug has been filed. [JDK-8285496](https://bugs.openjdk.java.net/browse/JDK-8285496)

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

Commit messages:
 - JDK-8284994: -Xdoclint:all returns warning for records, even when documented properly

Changes: https://git.openjdk.java.net/jdk/pull/8375/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8375&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284994
  Stats: 88 lines in 5 files changed: 69 ins; 1 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8375.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8375/head:pull/8375

PR: https://git.openjdk.java.net/jdk/pull/8375

From jlahoda at openjdk.java.net  Mon Apr 25 09:14:39 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 25 Apr 2022 09:14:39 GMT
Subject: Integrated: 8282823: javac should constrain more uses of preview APIs
In-Reply-To: <rRaOVobbfrkP_ztniSfPMAUtOZkxCqeJLKyLycn4Kzs=.29d8f3a5-a52f-41be-8522-1d72f9d76726@github.com>
References: <rRaOVobbfrkP_ztniSfPMAUtOZkxCqeJLKyLycn4Kzs=.29d8f3a5-a52f-41be-8522-1d72f9d76726@github.com>
Message-ID: <Xwq1FNfFBIub0MAseu6e0TTvC7_2mVRxroKxLxji_0Y=.9c6024ac-ca2d-43ba-9c05-ad46baff957c@github.com>

On Thu, 10 Mar 2022 12:28:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a class or interface with a method marked as preview. Subclassing the class or implementing the interface by itself should not cause a preview error/warning (as that would be problematic for Loom), but overriding the method should produce a preview error/warning.
> 
> This patch adds the error/warning in case a preview method is overridden.

This pull request has now been integrated.

Changeset: 4c22a9bc
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4c22a9bcf9a694f7a08e0e8fa8eb5e915095cec6
Stats:     508 lines in 3 files changed: 507 ins; 1 del; 0 mod

8282823: javac should constrain more uses of preview APIs

Reviewed-by: jlaskey, mcimadamore, vromero

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

PR: https://git.openjdk.java.net/jdk/pull/7774

From prappo at openjdk.java.net  Mon Apr 25 15:59:50 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 25 Apr 2022 15:59:50 GMT
Subject: RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing
 an exception
In-Reply-To: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
References: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
Message-ID: <QwVLOueIlRsOjV-Qr9mHHs4M_8TVkcRdsrkGJNXSAOk=.b85ebf19-0ea9-4e9e-af12-e2f4a22b2dc2@github.com>

On Fri, 22 Apr 2022 19:10:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.
> 
> The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any addition scanning.
> 
> It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.

You are not changing `(Doc)TreeScanner` API, but fixing this pair of internal `(Doc)TreePathScanner` subclasses; okay.

I think that your suggestion goes the extra mile as opposed to a more succinct suggestion by Jan [^1]. In particular, you avoid creating unnecessary `(Doc)TreePath` objects and calling `reduce`.

Could you have a look at other cases where we use `(Doc)TreeScanner` for search? For example:

  * com.sun.tools.javac.tree.TreeInfo#pathFor
  * com.sun.tools.javac.tree.TreeInfo#containsTypeAnnotation
  * jdk.jshell.ExpressionToTypeInfo#findExpressionPath
  
Maybe there's more. Is it possible to use your code there too? It would be good!

[^1]: https://bugs.openjdk.java.net/browse/JDK-8267690?focusedCommentId=14448893&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14448893

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

PR: https://git.openjdk.java.net/jdk/pull/8369

From prappo at openjdk.java.net  Mon Apr 25 16:27:27 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 25 Apr 2022 16:27:27 GMT
Subject: RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing
 an exception
In-Reply-To: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
References: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
Message-ID: <YmUFK7G3qmhMUpvgEDBMVL6bhSrtjQxiFiXRnKtz2LY=.2ea8acea-7d81-4b39-9089-267bfcf15847@github.com>

On Fri, 22 Apr 2022 19:10:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.
> 
> The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any addition scanning.
> 
> It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.

I think I'm mistaken: your version does all these things I thought it wasn't doing. What's the difference between it and Jan's version? Is it more responsive wrt termination when the target node is found?

src/jdk.compiler/share/classes/com/sun/source/util/TreePath.java line 69:

> 67: 
> 68:             @Override
> 69:             public TreePath scan(TreePath path, Tree docTree) {

The second parameter has nothing to do with `DocTree`. Copy-paste?

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

PR: https://git.openjdk.java.net/jdk/pull/8369

From vromero at openjdk.java.net  Mon Apr 25 16:45:21 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 25 Apr 2022 16:45:21 GMT
Subject: RFR: JDK-8284994: -Xdoclint:all returns warning for records,
 even when documented properly
In-Reply-To: <OleWfVmNnNng6gEDQr1SidueoEIXUKGxW6UmZOOpWWo=.954bfe3b-5d84-4e7d-b491-942b1e0ee8cc@github.com>
References: <OleWfVmNnNng6gEDQr1SidueoEIXUKGxW6UmZOOpWWo=.954bfe3b-5d84-4e7d-b491-942b1e0ee8cc@github.com>
Message-ID: <C_JIbBUjSI_YCyu5gDGsQZH364drqifpw3AX_odGIyw=.c1664668-906c-4b0d-b818-a3b5adaf4a53@github.com>

On Sat, 23 Apr 2022 17:03:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small fix to address issues with records in DocLint when invoked from javac. Bottom line, record components or their fields should never have direct documentation comments (and so the absence of comments should not be reported as "missing") ... they should be documented with `@param` tags in the doc comment for the record itself.
> 
> In the course of this work, it was observed that DocLint does not check for `@param` tags for type parameters on a class or interface declaration. Fixing that uncovers issues in the JDK API documentation, so that part of the fix is disabled for now, and a followup bug has been filed. [JDK-8285496](https://bugs.openjdk.java.net/browse/JDK-8285496)

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8375

From jjg at openjdk.java.net  Mon Apr 25 18:41:16 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 25 Apr 2022 18:41:16 GMT
Subject: RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing
 an exception
In-Reply-To: <YmUFK7G3qmhMUpvgEDBMVL6bhSrtjQxiFiXRnKtz2LY=.2ea8acea-7d81-4b39-9089-267bfcf15847@github.com>
References: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
 <YmUFK7G3qmhMUpvgEDBMVL6bhSrtjQxiFiXRnKtz2LY=.2ea8acea-7d81-4b39-9089-267bfcf15847@github.com>
Message-ID: <3i-iu5LQ9sXfBA7uLnCW55_MC7DjApf4njl6iblXgHY=.e6dc6a94-7eef-43cf-a330-20c8efb58b0c@github.com>

On Mon, 25 Apr 2022 16:21:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I think I'm mistaken: your version does all these things I thought it wasn't doing. What's the difference between it and Jan's version? Is it more responsive wrt termination when the target node is found?

I didn't know/check Jan's version. If there's an equivalent version, I'm OK to share authorship credits, but not fussed either way.

> src/jdk.compiler/share/classes/com/sun/source/util/TreePath.java line 69:
> 
>> 67: 
>> 68:             @Override
>> 69:             public TreePath scan(TreePath path, Tree docTree) {
> 
> The second parameter has nothing to do with `DocTree`. Copy-paste?

good catch; thanks. copy-paste error; will fix

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

PR: https://git.openjdk.java.net/jdk/pull/8369

From vromero at openjdk.java.net  Mon Apr 25 18:57:26 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 25 Apr 2022 18:57:26 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
Message-ID: <0nxKrOBqRfPWQiMI0t0K-iDtW4E3a8NqknV1ZbQmtH4=.1e058ff0-7d99-41ac-adb8-f33285469603@github.com>

On Thu, 31 Mar 2022 08:13:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
> 
> interface I {}
> 
> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
> 
> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
> 
> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.

not sure I get all the context here, why shouldn't we do the same for serialization that we are doing for non serialized classes? Is this because of some specified behavior probably on the serialization spec?

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From jjg at openjdk.java.net  Mon Apr 25 19:03:35 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 25 Apr 2022 19:03:35 GMT
Subject: RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing
 an exception [v2]
In-Reply-To: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
References: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
Message-ID: <U7j0yDu_h8Z0EHaFp67lqVhhmOB0yOTVWP-DkpKrAlw=.1bcf7bf5-06c4-4fa7-93e4-cc958a75ff7f@github.com>

> Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.
> 
> The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any addition scanning.
> 
> It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  improve parameter naming for internal `PathFinder` classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8369/files
  - new: https://git.openjdk.java.net/jdk/pull/8369/files/32aab7f0..0858b41f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8369&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8369&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8369

From jlahoda at openjdk.java.net  Mon Apr 25 20:12:34 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 25 Apr 2022 20:12:34 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <0nxKrOBqRfPWQiMI0t0K-iDtW4E3a8NqknV1ZbQmtH4=.1e058ff0-7d99-41ac-adb8-f33285469603@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <0nxKrOBqRfPWQiMI0t0K-iDtW4E3a8NqknV1ZbQmtH4=.1e058ff0-7d99-41ac-adb8-f33285469603@github.com>
Message-ID: <QWU4JoYLqYU9swPD29ZGAm8XT8V--t2uTteQloNRrUE=.6e5d193a-216f-436b-959c-5b449ca415a3@github.com>

On Mon, 25 Apr 2022 18:53:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> not sure I get all the context here, why shouldn't we do the same for serialization that we are doing for non serialized classes? Is this because of some specified behavior probably on the serialization spec?

This problem only occurs for serialized method references. Basically, javac will generate a reference to something like `I::hashCode`. At runtime, this will get converted to `Object::hashCode`, and that is then serialized. During deserialization, the deserialization code generated by javac will expect `I::hashCode`, but will get `Object::hashCode` from the serialized data, and the deserialization will fail. All this patch is trying to do is to generated the deserialization code in a way where it expects `Object::hashCode` - which is what is currently part of the serialized data. The only change is that before [JDK-8272564](https://bugs.openjdk.java.net/browse/JDK-8272564), the generated deserialization code expected `Object::hashCode`, while it currently expects `I::hashCode`, and this patch proposes to change that back to `Object::hashCode`.

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From vromero at openjdk.java.net  Mon Apr 25 20:20:22 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 25 Apr 2022 20:20:22 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <QWU4JoYLqYU9swPD29ZGAm8XT8V--t2uTteQloNRrUE=.6e5d193a-216f-436b-959c-5b449ca415a3@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <0nxKrOBqRfPWQiMI0t0K-iDtW4E3a8NqknV1ZbQmtH4=.1e058ff0-7d99-41ac-adb8-f33285469603@github.com>
 <QWU4JoYLqYU9swPD29ZGAm8XT8V--t2uTteQloNRrUE=.6e5d193a-216f-436b-959c-5b449ca415a3@github.com>
Message-ID: <6Dr7wZ-5Oe0QEIhXcwMV-pd75o6Uva973KL61y0fJB4=.22cedf4e-3e15-417e-9027-38e3d0d16240@github.com>

On Mon, 25 Apr 2022 20:08:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> At runtime, this will get converted to `Object::hashCode`

and why is this converted to `Object::hashCode`? is this specified somewhere or it is an unspecified behavior

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From prappo at openjdk.java.net  Mon Apr 25 20:20:35 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 25 Apr 2022 20:20:35 GMT
Subject: RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing
 an exception [v2]
In-Reply-To: <U7j0yDu_h8Z0EHaFp67lqVhhmOB0yOTVWP-DkpKrAlw=.1bcf7bf5-06c4-4fa7-93e4-cc958a75ff7f@github.com>
References: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
 <U7j0yDu_h8Z0EHaFp67lqVhhmOB0yOTVWP-DkpKrAlw=.1bcf7bf5-06c4-4fa7-93e4-cc958a75ff7f@github.com>
Message-ID: <3sebXL5sYkIRSbK-ss9gljQv53y34F1GhAM6C09azrI=.e22caf22-accf-45d3-b673-8893e0614b36@github.com>

On Mon, 25 Apr 2022 19:03:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.
>> 
>> The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any addition scanning.
>> 
>> It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve parameter naming for internal `PathFinder` classes

Marked as reviewed by prappo (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8369

From jjg at openjdk.java.net  Mon Apr 25 20:44:06 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 25 Apr 2022 20:44:06 GMT
Subject: RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing
 an exception [v2]
In-Reply-To: <U7j0yDu_h8Z0EHaFp67lqVhhmOB0yOTVWP-DkpKrAlw=.1bcf7bf5-06c4-4fa7-93e4-cc958a75ff7f@github.com>
References: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
 <U7j0yDu_h8Z0EHaFp67lqVhhmOB0yOTVWP-DkpKrAlw=.1bcf7bf5-06c4-4fa7-93e4-cc958a75ff7f@github.com>
Message-ID: <9mHvpcNHXoUh2o7FRoQKiMsDLLTRq8YjyBUvpXfN0es=.1b807fa2-12ab-46f7-9297-45dc46a7817a@github.com>

On Mon, 25 Apr 2022 19:03:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.
>> 
>> The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any additional scanning.
>> 
>> It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve parameter naming for internal `PathFinder` classes

Thanks for the references to other candidates.

* com.sun.tools.javac.tree.TreeInfo#pathFor seems to be dead code

* com.sun.tools.javac.tree.TreeInfo#containsTypeAnnotation not a path finder, and looks like only called on small trees

* jdk.jshell.ExpressionToTypeInfo#findExpressionPath does seem to be another candidate for this work, but could/should be done separately

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

PR: https://git.openjdk.java.net/jdk/pull/8369

From prappo at openjdk.java.net  Mon Apr 25 20:45:57 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 25 Apr 2022 20:45:57 GMT
Subject: RFR: 8285396: Do not fill in the stacktrace of an internal
 exception [v2]
In-Reply-To: <El8_7AJNEiUkhWZYnoWt4rzB2AEcwOiUJCjl21w5VDY=.d5951b10-4eb9-4277-aeeb-e49cee4a0c17@github.com>
References: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
 <El8_7AJNEiUkhWZYnoWt4rzB2AEcwOiUJCjl21w5VDY=.d5951b10-4eb9-4277-aeeb-e49cee4a0c17@github.com>
Message-ID: <2WpSRxB0LRATLpvvrHT5McWaHa2e19_wxeDccoemlYA=.6a03b909-eab2-4e30-bb60-bbfb520f78fb@github.com>

On Thu, 21 Apr 2022 23:28:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Sometimes an exception is retrofitted into control flow to interrupt it in a way that it wasn't originally designed to be interrupted. Such an exception is an implementation detail. Once the exception is caught internally, it is discarded.
>> 
>> An exception has a stacktrace. Filling in a stacktrace is not free. Filling in a stacktrace that won't be used seems like a waste.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

I'm closing this PR because we decided to address the stacktrace issue by getting rid of exceptions altogether in another PR: https://github.com/openjdk/jdk/pull/8369. However, I will file an issue to retrofit `(Doc)Pretty` with `java.io.UncheckedIOException`.

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

PR: https://git.openjdk.java.net/jdk/pull/8347

From prappo at openjdk.java.net  Mon Apr 25 20:45:58 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 25 Apr 2022 20:45:58 GMT
Subject: Withdrawn: 8285396: Do not fill in the stacktrace of an internal
 exception
In-Reply-To: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
References: <bmTznd5SsOZNnnKN6JhO98fTXcl1Zh9BOj7rCC9aL3Q=.777ec584-806c-4adb-918c-2e1ede0fe405@github.com>
Message-ID: <q_UjCKiYcAbziAWd30tWeiZHIj3WRzW1ucaC6IrInj4=.84f9ab12-ec23-4659-b702-b10d8764e29e@github.com>

On Thu, 21 Apr 2022 19:28:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Sometimes an exception is retrofitted into control flow to interrupt it in a way that it wasn't originally designed to be interrupted. Such an exception is an implementation detail. Once the exception is caught internally, it is discarded.
> 
> An exception has a stacktrace. Filling in a stacktrace is not free. Filling in a stacktrace that won't be used seems like a waste.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8347

From jlahoda at openjdk.java.net  Mon Apr 25 20:55:57 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 25 Apr 2022 20:55:57 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <6Dr7wZ-5Oe0QEIhXcwMV-pd75o6Uva973KL61y0fJB4=.22cedf4e-3e15-417e-9027-38e3d0d16240@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <0nxKrOBqRfPWQiMI0t0K-iDtW4E3a8NqknV1ZbQmtH4=.1e058ff0-7d99-41ac-adb8-f33285469603@github.com>
 <QWU4JoYLqYU9swPD29ZGAm8XT8V--t2uTteQloNRrUE=.6e5d193a-216f-436b-959c-5b449ca415a3@github.com>
 <6Dr7wZ-5Oe0QEIhXcwMV-pd75o6Uva973KL61y0fJB4=.22cedf4e-3e15-417e-9027-38e3d0d16240@github.com>
Message-ID: <HCuPJl-gm668MpTmMSaTZZIrnTV0LfNbHVrZRNskNc4=.6c8813be-7f0a-4810-8de5-ce3dce3743b3@github.com>

On Mon, 25 Apr 2022 20:16:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > At runtime, this will get converted to `Object::hashCode`
> 
> and why is this converted to `Object::hashCode`? is this specified somewhere or it is an unspecified behavior

I don't know if it is specified somewhere - the runtime (before `LambdaMetafactory` is called) is doing that. But, I don't think it is easy to change, as that would likely have notable compatibility consequences.

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From jjg at openjdk.java.net  Mon Apr 25 20:58:57 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 25 Apr 2022 20:58:57 GMT
Subject: Integrated: JDK-8267690: Revisit (Doc)Tree search implemented by
 throwing an exception
In-Reply-To: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
References: <aYd6KiiB0p9t18Vnv31uiK-l9K3GiGIQAsWsNzt6ERs=.bcd6ad93-9950-4650-b15e-718209464181@github.com>
Message-ID: <-eauqJZa9_pgT1D-tQW1WK7jzlvaUHWWwOMTNs0LaRY=.68563775-354c-4d90-a071-18439560e424@github.com>

On Fri, 22 Apr 2022 19:10:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.
> 
> The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any additional scanning.
> 
> It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.

This pull request has now been integrated.

Changeset: 80a7f7be
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/80a7f7becfc362fc3918a2442aea912533373c26
Stats:     69 lines in 2 files changed: 26 ins; 9 del; 34 mod

8267690: Revisit (Doc)Tree search implemented by throwing an exception

Reviewed-by: vromero, prappo

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

PR: https://git.openjdk.java.net/jdk/pull/8369

From prappo at openjdk.java.net  Mon Apr 25 21:22:11 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 25 Apr 2022 21:22:11 GMT
Subject: RFR: 8285611: Retrofit (Doc)Pretty with java.io.UncheckedIOException
Message-ID: <3H9OfrUvX3GdRWQTvO1a9Yb5q00-Yk2tEPAlZrR2g44=.90632acf-43ba-4f6d-8e1a-bc7501cf8337@github.com>

Standard `java.io.UncheckedIOException` is more convenient than older ad-hoc `com.sun.tools.javac.tree.(Doc)Pretty.UncheckedIOException`.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8387/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8387&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285611
  Stats: 20 lines in 2 files changed: 1 ins; 16 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8387.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8387/head:pull/8387

PR: https://git.openjdk.java.net/jdk/pull/8387

From jjg at openjdk.java.net  Mon Apr 25 22:45:18 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 25 Apr 2022 22:45:18 GMT
Subject: RFR: 8285611: Retrofit (Doc)Pretty with
 java.io.UncheckedIOException
In-Reply-To: <3H9OfrUvX3GdRWQTvO1a9Yb5q00-Yk2tEPAlZrR2g44=.90632acf-43ba-4f6d-8e1a-bc7501cf8337@github.com>
References: <3H9OfrUvX3GdRWQTvO1a9Yb5q00-Yk2tEPAlZrR2g44=.90632acf-43ba-4f6d-8e1a-bc7501cf8337@github.com>
Message-ID: <ixCduiX8cevSeb9UWQqTOcjU3B1w2T_J8fIj6lPrcks=.841e1a72-14ea-48a8-aaa0-a49b2d807251@github.com>

On Mon, 25 Apr 2022 21:01:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Standard `java.io.UncheckedIOException` is more convenient than older ad-hoc `com.sun.tools.javac.tree.(Doc)Pretty.UncheckedIOException`.

1. To be clear, this is more than just substitution of an equivalent exception: there's a minor change in behavior with respect to the resulting exception that is thrown (i.e. the original.) People may wonder, how did the exception escape, but then again, anyone handling it ought to know.

2. Do you want to avoid filling in the stack trace, since the unchecked exception is transient?  Maybe it's not important, since this code path is almost never taken.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8387

From jjg at openjdk.java.net  Tue Apr 26 00:19:23 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 26 Apr 2022 00:19:23 GMT
Subject: RFR: JDK-8285610: TreeInfo.pathFor and its uses appear to be dead code
Message-ID: <NTIfhgemiSAQPzxwWkcPRSC1tfErg22tnCEL_Vv9on0=.be185581-8096-40c8-9b3d-ff4c700455cf@github.com>

Please review a trivial change to remove some unused/dead code. 

All tier1 tests pass.

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

Commit messages:
 - JDK-8285610: TreeInfo.pathFor and its uses appear to be dead code

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

PR: https://git.openjdk.java.net/jdk/pull/8393

From vromero at openjdk.java.net  Tue Apr 26 02:22:55 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 26 Apr 2022 02:22:55 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
Message-ID: <VjGgZ1E9NKDeRHPoEoAEZTM4pRLWEcX6FhiHrTdRV-4=.8a368449-5989-4995-aabb-6e8060781890@github.com>

On Thu, 31 Mar 2022 08:13:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
> 
> interface I {}
> 
> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
> 
> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
> 
> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.

Marked as reviewed by vromero (Reviewer).

I see, I'm OK with this change but I think that going forward, as a follow-up, we should investigate if it makes sense unifying the compiler's approach in this area

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From darcy at openjdk.java.net  Tue Apr 26 04:41:00 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 26 Apr 2022 04:41:00 GMT
Subject: RFR: 8284220: TypeMirror#toString omits enclosing class names
 after JDK-8281238 [v4]
In-Reply-To: <ZFhQguj5fOG0aAI1E7XbI8ia90SNLIPDsGy-sQA7nX4=.75d78a52-9f55-420c-8df9-dc9f2de7d5b4@github.com>
References: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
 <ZFhQguj5fOG0aAI1E7XbI8ia90SNLIPDsGy-sQA7nX4=.75d78a52-9f55-420c-8df9-dc9f2de7d5b4@github.com>
Message-ID: <306cwvfBgH3I3jOXI_uQXixbvcKw-0Iw2vigNSRPUZA=.08c9b36c-6754-4c9f-a611-4a4fdd95567e@github.com>

On Mon, 18 Apr 2022 18:18:30 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.java.net/browse/JDK-8284220, which updates `ClassType#toString` to include enclosing class names when type annotations are present.
>> 
>> For example, `java.util. at A Map.Entry<?,?>` is now printed as `java.util. at A Map.Entry<?,?>`, instead of `java.util. at A Entry<?,?>` (note the missing `Map`).
>
> Liam Miller-Cushon 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 'openjdk:master' into JDK-8284220
>  - Refactor test based on review feedback
>  - 8284220: TypeMirror#toString omits enclosing class names after JDK-8281238

Marked as reviewed by darcy (Reviewer).

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

> 1044:                         buf.append(".");
> 1045:                     }
> 1046:                     ListBuffer<Name> names = new ListBuffer<>();

There may be a more idiomataic way to javac to construct this string, but offhand I don't know what it is.

test/langtools/tools/javac/processing/model/type/AnnotatedTypeToString/AnnotatedTypeToString.java line 1:

> 1: /*

>From personal experience with similar tests, they can look obscure when revisting them months in the future. I suggest putting a sentence or two description of what the test is trying to do. Also, if all the types can fit in one file, that can be easier to understand.

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

PR: https://git.openjdk.java.net/jdk/pull/8084

From prappo at openjdk.java.net  Tue Apr 26 07:51:54 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 26 Apr 2022 07:51:54 GMT
Subject: Integrated: 8285611: Retrofit (Doc)Pretty with
 java.io.UncheckedIOException
In-Reply-To: <3H9OfrUvX3GdRWQTvO1a9Yb5q00-Yk2tEPAlZrR2g44=.90632acf-43ba-4f6d-8e1a-bc7501cf8337@github.com>
References: <3H9OfrUvX3GdRWQTvO1a9Yb5q00-Yk2tEPAlZrR2g44=.90632acf-43ba-4f6d-8e1a-bc7501cf8337@github.com>
Message-ID: <W9x6m3JL52kQVGj-rN11vCLEiDJC0UnLYAaVzr44X3E=.f9dec9b2-4b04-48aa-a84c-8fbf34201bd1@github.com>

On Mon, 25 Apr 2022 21:01:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Standard `java.io.UncheckedIOException` is more convenient than older ad-hoc `com.sun.tools.javac.tree.(Doc)Pretty.UncheckedIOException`.

This pull request has now been integrated.

Changeset: e333cd33
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e333cd33d17721bd762bfa10db1899a391556011
Stats:     20 lines in 2 files changed: 1 ins; 16 del; 3 mod

8285611: Retrofit (Doc)Pretty with java.io.UncheckedIOException

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk/pull/8387

From prappo at openjdk.java.net  Tue Apr 26 08:13:45 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 26 Apr 2022 08:13:45 GMT
Subject: RFR: 8285611: Retrofit (Doc)Pretty with
 java.io.UncheckedIOException
In-Reply-To: <3H9OfrUvX3GdRWQTvO1a9Yb5q00-Yk2tEPAlZrR2g44=.90632acf-43ba-4f6d-8e1a-bc7501cf8337@github.com>
References: <3H9OfrUvX3GdRWQTvO1a9Yb5q00-Yk2tEPAlZrR2g44=.90632acf-43ba-4f6d-8e1a-bc7501cf8337@github.com>
Message-ID: <t14PWRT7wY-6T4GAcPu6ah2B_zmjwYujc2A6u2l7PXs=.313bf50d-926d-48de-9bb7-c2b1431af5b4@github.com>

On Mon, 25 Apr 2022 21:01:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Standard `java.io.UncheckedIOException` is more convenient than older ad-hoc `com.sun.tools.javac.tree.(Doc)Pretty.UncheckedIOException`.

Addressing your earlier points after integration.

> 1. To be clear, this is more than just substitution of an equivalent exception: there's a minor change in behavior with respect to the resulting exception that is thrown (i.e. the original.) People may wonder, how did the exception escape, but then again, anyone handling it ought to know.

Right; however, all the important information is still on the stack.

> 2. Do you want to avoid filling in the stack trace, since the unchecked exception is transient?  Maybe it's not important, since this code path is almost never taken.

I wouldn't bother; these exceptions don't warrant any future head-scratching.

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

PR: https://git.openjdk.java.net/jdk/pull/8387

From jjg at openjdk.java.net  Tue Apr 26 15:45:47 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 26 Apr 2022 15:45:47 GMT
Subject: Integrated: JDK-8284994: -Xdoclint:all returns warning for records,
 even when documented properly
In-Reply-To: <OleWfVmNnNng6gEDQr1SidueoEIXUKGxW6UmZOOpWWo=.954bfe3b-5d84-4e7d-b491-942b1e0ee8cc@github.com>
References: <OleWfVmNnNng6gEDQr1SidueoEIXUKGxW6UmZOOpWWo=.954bfe3b-5d84-4e7d-b491-942b1e0ee8cc@github.com>
Message-ID: <59va0IhdNsFmUpgvf7c43KBUTEQHiy7kP8hms2PtJec=.158ce925-8160-4b03-bdd8-085942b32205@github.com>

On Sat, 23 Apr 2022 17:03:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small fix to address issues with records in DocLint when invoked from javac. Bottom line, record components or their fields should never have direct documentation comments (and so the absence of comments should not be reported as "missing") ... they should be documented with `@param` tags in the doc comment for the record itself.
> 
> In the course of this work, it was observed that DocLint does not check for `@param` tags for type parameters on a class or interface declaration. Fixing that uncovers issues in the JDK API documentation, so that part of the fix is disabled for now, and a followup bug has been filed. [JDK-8285496](https://bugs.openjdk.java.net/browse/JDK-8285496)

This pull request has now been integrated.

Changeset: 20a132d4
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/20a132d460bc34fbf59774bc7493d93472b7d52a
Stats:     88 lines in 5 files changed: 69 ins; 1 del; 18 mod

8284994: -Xdoclint:all returns warning for records, even when documented properly

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8375

From cushon at openjdk.java.net  Tue Apr 26 17:11:42 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 26 Apr 2022 17:11:42 GMT
Subject: RFR: 8284220: TypeMirror#toString omits enclosing class names
 after JDK-8281238 [v5]
In-Reply-To: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
References: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
Message-ID: <KXHVndziow1Eu7qSSGgYi3ZWm676HK8my2KP6OmMJxg=.c4e374fd-d548-4065-953f-8eb30639ccea@github.com>

> Please consider this fix for https://bugs.openjdk.java.net/browse/JDK-8284220, which updates `ClassType#toString` to include enclosing class names when type annotations are present.
> 
> For example, `java.util. at A Map.Entry<?,?>` is now printed as `java.util. at A Map.Entry<?,?>`, instead of `java.util. at A Entry<?,?>` (note the missing `Map`).

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

 - Merge branch 'master' into JDK-8284220
 - Add more documentation to test
 - Merge branch 'openjdk:master' into JDK-8284220
 - Refactor test based on review feedback
 - 8284220: TypeMirror#toString omits enclosing class names after JDK-8281238

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8084/files
  - new: https://git.openjdk.java.net/jdk/pull/8084/files/cc0531fb..67103c77

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8084&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8084&range=03-04

  Stats: 19355 lines in 1068 files changed: 12067 ins; 2824 del; 4464 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8084.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8084/head:pull/8084

PR: https://git.openjdk.java.net/jdk/pull/8084

From cushon at openjdk.java.net  Tue Apr 26 17:11:46 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 26 Apr 2022 17:11:46 GMT
Subject: RFR: 8284220: TypeMirror#toString omits enclosing class names
 after JDK-8281238 [v4]
In-Reply-To: <306cwvfBgH3I3jOXI_uQXixbvcKw-0Iw2vigNSRPUZA=.08c9b36c-6754-4c9f-a611-4a4fdd95567e@github.com>
References: <uEfJ1fy1y7v4ztvsmrgmzFGQ9QsR5L0HIEtY09NNXOI=.1f08f114-1e7b-4838-8bdf-d7ae44ef6b2b@github.com>
 <ZFhQguj5fOG0aAI1E7XbI8ia90SNLIPDsGy-sQA7nX4=.75d78a52-9f55-420c-8df9-dc9f2de7d5b4@github.com>
 <306cwvfBgH3I3jOXI_uQXixbvcKw-0Iw2vigNSRPUZA=.08c9b36c-6754-4c9f-a611-4a4fdd95567e@github.com>
Message-ID: <QNIEeGSA75JKnPZE95_fzLYjioFddxggq1xfqEqM9yw=.9bf05ffe-3c05-454b-b2e3-ac90053756ef@github.com>

On Tue, 26 Apr 2022 04:35:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Liam Miller-Cushon 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 'openjdk:master' into JDK-8284220
>>  - Refactor test based on review feedback
>>  - 8284220: TypeMirror#toString omits enclosing class names after JDK-8281238
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1046:
> 
>> 1044:                         buf.append(".");
>> 1045:                     }
>> 1046:                     ListBuffer<Name> names = new ListBuffer<>();
> 
> There may be a more idiomataic way to javac to construct this string, but offhand I don't know what it is.

I made this as idiomatic as I could, I think part of the issue here is that that the pretty-printing logic is operating on names at a slightly lower level than we normally do, so the existing ways of getting simple or qualified names aren't sufficient. Suggestions are welcome if you think of a way to clean this up at all.

> test/langtools/tools/javac/processing/model/type/AnnotatedTypeToString/AnnotatedTypeToString.java line 1:
> 
>> 1: /*
> 
> From personal experience with similar tests, they can look obscure when revisting them months in the future. I suggest putting a sentence or two description of what the test is trying to do. Also, if all the types can fit in one file, that can be easier to understand.

Thanks, I added some more context to the test `@summary` and also added javadoc on the processor, suggestions for additional documentation improvements are welcome.

> if all the types can fit in one file, that can be easier to understand.

I considered that, but `JavacTestingAbstractProcessor` is in the default packages, and I want the test to exercise printing types that are not in the default package, so I don't see a good way to put everything in the same file.

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

PR: https://git.openjdk.java.net/jdk/pull/8084

From vromero at openjdk.java.net  Tue Apr 26 18:13:55 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 26 Apr 2022 18:13:55 GMT
Subject: RFR: 8284283: javac crashes when several transitive supertypes are
 missing
In-Reply-To: <HfpXfqSDX1fqsrCVgYrjyBvVLhyNk_k2dWcLjpHC0g4=.2cfca39d-d7c3-4366-938a-858f36a0b06f@github.com>
References: <HfpXfqSDX1fqsrCVgYrjyBvVLhyNk_k2dWcLjpHC0g4=.2cfca39d-d7c3-4366-938a-858f36a0b06f@github.com>
Message-ID: <ayri9MdXInDztCXSKMnS0XIslqur5wSizhyKvKF0TXg=.aa9be9ef-74c7-48c0-943b-351fc238f879@github.com>

On Mon, 4 Apr 2022 20:24:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this testcase:
> 
> ---Lib.java
> package lib;
> public class Lib implements A, B {}
> interface A {}
> interface B {}
> ---Test.java
> public class Test<E> extends lib.Lib {}
> ---
> 
> $ javac -d out Lib.java
> $ rm out/lib/A.class out/lib/B.class
> $ javac -classpath out -XDdev Test.java
> Test.java:1: error: cannot access A
> public class Test<E> extends lib.Lib {}
>        ^
>   class file for lib.A not found
> 1 error
> An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com/) after checking the Bug Database (http://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.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.hasTag(com.sun.tools.javac.code.TypeTag)" because the return value of "com.sun.tools.javac.code.Type$TypeVar.getUpperBound()" is null
>         at jdk.compiler/com.sun.tools.javac.code.Types.getBounds(Types.java:2732)
> ....
> 
> 
> The reason for the cache is insufficient error recovery - when the missing class `A` and `B` are encountered, the processing in `TypeEnter` (`TypeEnter.HierarchyPhase` for `A` and `TypeEnter.HeaderPhase` for `B`) is interrupted, and the rest of the processing is skipped to the end of the phase, leaving unprocessed tree, which ultimately leads to the exception.
> 
> The proposed patch is to enhance the error recovery, catch the `CompletionFailure` for the missing classes sooner, and let the rest of the `TypeEnter` processing finish normally.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8095

From jlahoda at openjdk.java.net  Tue Apr 26 19:30:32 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 26 Apr 2022 19:30:32 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v7]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <iuX8CUmNyg1ZsRXBM78U4NZ3bE_uRsY_V204tb1HykA=.e44660c8-666a-4706-825e-8eb55e702d0c@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

 - Reference-type pattern is not applicable at a selector of a primitive type - fixing.
 - Merge branch 'master' into type-patterns-third
 - Cleanup, fixing tests.
 - Cleanup - more total -> unconditional pattern renaming.
 - Adjusting to review feedback.
 - Cleanup.
 - Fixing tests.
 - Adding a test for a NPE from guards.
 - Cleanup
 - Merge branch 'master' into type-patterns-third
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/82f0ac02...9f290cd2

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

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=06
  Stats: 888 lines in 52 files changed: 453 ins; 244 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Tue Apr 26 22:05:30 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 26 Apr 2022 22:05:30 GMT
Subject: RFR: 8178701: Compile error with switch statement on protected
 enum defined in parent inner class
In-Reply-To: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
References: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>
Message-ID: <_QPnXlLMYjxFttIhbu0rqs_5E6Q2toDWRCdsUGYJzQI=.fd6aa203-ef2c-479d-96e0-92eca619ed4e@github.com>

On Fri, 25 Feb 2022 12:32:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following code in two packages:
> 
> package foo;
> 
> import bar.D.E;
> 
> public class A {
> 
>     public static class B {
> 
>         protected enum C {
>             X, Y, Z
>         }
>     }
> 
>     public static void main(String... args) {
>         new E().run(B.C.X);
>     }
> }
> 
> 
> 
> package bar;
> 
> import foo.A.B;
> 
> public class D {
> 
>     public static class E extends B {
> 
>         public void run(C arg) {
>             switch (arg) {
>                 default:
>                     System.out.println("OK");
>             }
>         }
>     }
> }
> 
> 
> Accessing `foo.A.B.C` in `bar.D.E` is OK, as it is accessible through the `E`'s superclass. But, for the `switch`, javac creates a map (array) from runtime ordinals of constants of `E` to compile-time positions. But, this mapping is in a different class that does not extend `B`, so internal method lookups fail for it, as the methods are not accessible per Java rules.
> 
> But, at runtime, the enum class is effectively public, so I think it is possible to ignore the protected access rules and accept the method invocations while generatting the mapping code, which is what this patch is trying to do.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7621

From darcy at openjdk.java.net  Wed Apr 27 01:35:23 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 01:35:23 GMT
Subject: RFR: JDK-8285688: Add links to JEPs and JSRs to SourceVersion
Message-ID: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>

To provide more context to readers about the development of the language, add to the enum constants in SourceVersion @see links to the JEPs and JSRs that added features to a release.

(For now, have left out @see links to preview features.)

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

Commit messages:
 - JDK-8285688: Add links to JEPs and JSRs to SourceVersion

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

PR: https://git.openjdk.java.net/jdk/pull/8413

From vromero at openjdk.java.net  Wed Apr 27 02:11:35 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 27 Apr 2022 02:11:35 GMT
Subject: RFR: JDK-8285688: Add links to JEPs and JSRs to SourceVersion
In-Reply-To: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
References: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
Message-ID: <3O50SLPG2nlHjPwr4nnMrhsFhrb448d7IZVPN6PoUxQ=.e76d8180-3ef5-4bcf-83ea-92752b37cd64@github.com>

On Wed, 27 Apr 2022 01:28:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To provide more context to readers about the development of the language, add to the enum constants in SourceVersion @see links to the JEPs and JSRs that added features to a release.
> 
> (For now, have left out @see links to preview features.)

looks good

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8413

From vromero at openjdk.java.net  Wed Apr 27 02:25:39 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 27 Apr 2022 02:25:39 GMT
Subject: RFR: JDK-8285610: TreeInfo.pathFor and its uses appear to be dead
 code
In-Reply-To: <NTIfhgemiSAQPzxwWkcPRSC1tfErg22tnCEL_Vv9on0=.be185581-8096-40c8-9b3d-ff4c700455cf@github.com>
References: <NTIfhgemiSAQPzxwWkcPRSC1tfErg22tnCEL_Vv9on0=.be185581-8096-40c8-9b3d-ff4c700455cf@github.com>
Message-ID: <h_2_yoZl4ucoZ4UiXcG2xP0xEl7tr3-xvnAYyPGY6SA=.e48b95f5-e2db-468b-808a-ef5b5ff4d154@github.com>

On Tue, 26 Apr 2022 00:12:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial change to remove some unused/dead code. 
> 
> All tier1 tests pass.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8393

From darcy at openjdk.java.net  Wed Apr 27 04:36:31 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 04:36:31 GMT
Subject: RFR: JDK-8285688: Add links to JEPs and JSRs to SourceVersion [v2]
In-Reply-To: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
References: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
Message-ID: <n0MvyDim80ZbKT3D4Sy06VFtDahEdth8sdBf25huYGM=.16fffd9a-c681-43f8-ac61-940acef889c1@github.com>

> To provide more context to readers about the development of the language, add to the enum constants in SourceVersion @see links to the JEPs and JSRs that added features to a release.
> 
> (For now, have left out @see links to preview features.)

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

  Fix title of JSR 201.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8413/files
  - new: https://git.openjdk.java.net/jdk/pull/8413/files/4d0f0829..39c1b70e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8413&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8413&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8413

From sadayapalam at openjdk.java.net  Wed Apr 27 06:00:12 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 27 Apr 2022 06:00:12 GMT
Subject: RFR: 8155701: The compiler fails with an AssertionError: typeSig ERROR
Message-ID: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>

Make sure javac issues suitable diagnostics for types not found in the class path

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

Commit messages:
 - 8155701: The compiler fails with an AssertionError: typeSig ERROR

Changes: https://git.openjdk.java.net/jdk/pull/8414/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8414&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8155701
  Stats: 119 lines in 2 files changed: 116 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8414.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8414/head:pull/8414

PR: https://git.openjdk.java.net/jdk/pull/8414

From sadayapalam at openjdk.java.net  Wed Apr 27 06:20:37 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 27 Apr 2022 06:20:37 GMT
Subject: RFR: 8155701: The compiler fails with an AssertionError: typeSig
 ERROR
In-Reply-To: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>
References: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>
Message-ID: <9Usj-cQGdeke2gTZVC1-y6Ga0pWtND7pjlOwmLIFWqs=.2033b5d1-ada0-4cb8-bc2c-997d14cd9979@github.com>

On Wed, 27 Apr 2022 05:51:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Make sure javac issues suitable diagnostics for types not found in the class path

Notes for the reviewer(s):

Consider: 

Class Foo from Foo.java refers to an annotation type @edu.umd.cs.findbugs.annotations.SuppressWarnings properly found on the class path. Foo.java is well formed and is compiled properly into Foo.class

Class Bar from Bar.java compiled separately refers to both class Foo and the annotation @edu.umd.cs.findbugs.annotations.SuppressWarnings BUT has only Foo.class on its class path.

While compiling Bar.java, the reference to Foo causes the class file Foo.class to be read in. The class Foo is found to refer to the annotation type @edu.umd.cs.findbugs.annotations.SuppressWarnings which is not on the current class path and so results in a CompletionFailure. This completion failure is not surfaced (see com.sun.tools.javac.jvm.ClassReader.AnnotationDeproxy#findAccessMethod) as an error - a lint diagnostics get issued if line mode includes class file sanity checks - instead we simply tag the type of the ClassSymbol corresponding to  @edu.umd.cs.findbugs.annotations.SuppressWarnings  as an ErrorType.

Subsequently when we look up the type @edu.umd.cs.findbugs.annotations.SuppressWarnings when Bar.java itself references it, we end up retrieving this stub symbol from the symbol table. 

The fact that @edu.umd.cs.findbugs.annotations.SuppressWarnings  is not on the class path while compiling Bar.java that references this missing type should result in a compilation error for the type not found. Instead we find the stub symbol, not recognize that as a place holder for a missing type and proceed further in the compilation pipeline.

This results in an assertion failure during code generation phase - which should never have been entered in the first place.

The fix is to recognize this scenario and return a typeNotFound error symbol rather than the stub symbol

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

PR: https://git.openjdk.java.net/jdk/pull/8414

From duke at openjdk.java.net  Wed Apr 27 09:07:04 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Wed, 27 Apr 2022 09:07:04 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language
Message-ID: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>

When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.

Would you please review this fix?

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

Commit messages:
 - 8238373: Punctuation should be same in jlink help usage on Japanese language

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

PR: https://git.openjdk.java.net/jdk/pull/8417

From naoto at openjdk.java.net  Wed Apr 27 16:44:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Apr 2022 16:44:45 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language
In-Reply-To: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
Message-ID: <rV9tqb5vwiaJb5Ac52dQmc3QsjJivKXypIXWbofNIls=.15a473d5-09ea-4184-aab5-15d6ce243ac1@github.com>

On Wed, 27 Apr 2022 08:59:20 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
> As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
> Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.
> 
> Would you please review this fix?

Looks fine to me. Nit: please modify the copyright years for `javap` properties files, as you modified the base (`javap.properties`) file.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8417

From jjg at openjdk.java.net  Wed Apr 27 17:28:41 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 27 Apr 2022 17:28:41 GMT
Subject: RFR: JDK-8285688: Add links to JEPs and JSRs to SourceVersion [v2]
In-Reply-To: <n0MvyDim80ZbKT3D4Sy06VFtDahEdth8sdBf25huYGM=.16fffd9a-c681-43f8-ac61-940acef889c1@github.com>
References: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
 <n0MvyDim80ZbKT3D4Sy06VFtDahEdth8sdBf25huYGM=.16fffd9a-c681-43f8-ac61-940acef889c1@github.com>
Message-ID: <Kn49HIZ1Eaj-8o4M48VlTLMTfUKpgjgwwnEveZv0iKE=.6550a9e5-0db2-475a-9a9a-1a9ff2ee17b5@github.com>

On Wed, 27 Apr 2022 04:36:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To provide more context to readers about the development of the language, add to the enum constants in SourceVersion @see links to the JEPs and JSRs that added features to a release.
>> 
>> (For now, have left out @see links to preview features.)
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix title of JSR 201.

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8413

From vromero at openjdk.java.net  Wed Apr 27 17:33:43 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 27 Apr 2022 17:33:43 GMT
Subject: RFR: 8155701: The compiler fails with an AssertionError: typeSig
 ERROR
In-Reply-To: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>
References: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>
Message-ID: <zDKTAY0arUUV3blaYLWcy9SacpVoRtIz3GvKTuvrIN0=.d127122f-c557-4f98-a4c9-4ed45cbbdfa6@github.com>

On Wed, 27 Apr 2022 05:51:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Make sure javac issues suitable diagnostics for types not found in the class path

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8414

From jjg at openjdk.java.net  Wed Apr 27 21:23:05 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 27 Apr 2022 21:23:05 GMT
Subject: RFR: JDK-8285756: clean up use of bad arguments for `@clean` in
 langtools tests
Message-ID: <rza3crB5ChYH9y16PyBOF-Mw3fxBH2NFAfM3VOfEPOI=.7795f51c-6154-4771-806b-be6f9b1bf316@github.com>

Please review a trivial test fix to fix some bad/unsupported forms of `@clean` tags in some java tests.

Previously, these bad args were not detected and effectively had no effect.  Now, an upcoming new jtreg version will detect and give errors for these forms.

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

Commit messages:
 - JDK-8285756: clean up use of bad arguments for `@clean` in langtools tests

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

PR: https://git.openjdk.java.net/jdk/pull/8435

From darcy at openjdk.java.net  Wed Apr 27 21:30:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 21:30:40 GMT
Subject: RFR: JDK-8285756: clean up use of bad arguments for `@clean` in
 langtools tests
In-Reply-To: <rza3crB5ChYH9y16PyBOF-Mw3fxBH2NFAfM3VOfEPOI=.7795f51c-6154-4771-806b-be6f9b1bf316@github.com>
References: <rza3crB5ChYH9y16PyBOF-Mw3fxBH2NFAfM3VOfEPOI=.7795f51c-6154-4771-806b-be6f9b1bf316@github.com>
Message-ID: <G6vbygE42DUHG6omYNlo2Q282l7gCwKR9U5m0OdssLs=.022a2ebc-54dc-4728-ae35-9b4b528be8a0@github.com>

On Wed, 27 Apr 2022 21:15:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial test fix to fix some bad/unsupported forms of `@clean` tags in some java tests.
> 
> Previously, these bad args were not detected and effectively had no effect.  Now, an upcoming new jtreg version will detect and give errors for these forms.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8435

From jjg at openjdk.java.net  Wed Apr 27 22:26:45 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 27 Apr 2022 22:26:45 GMT
Subject: Integrated: JDK-8285756: clean up use of bad arguments for `@clean` in
 langtools tests
In-Reply-To: <rza3crB5ChYH9y16PyBOF-Mw3fxBH2NFAfM3VOfEPOI=.7795f51c-6154-4771-806b-be6f9b1bf316@github.com>
References: <rza3crB5ChYH9y16PyBOF-Mw3fxBH2NFAfM3VOfEPOI=.7795f51c-6154-4771-806b-be6f9b1bf316@github.com>
Message-ID: <uyKQXJkkpbGa2Cw8BqCZGTT-H0iEOPN_QqWu37n34XY=.21516c8f-871f-4695-af65-6dd4444ec889@github.com>

On Wed, 27 Apr 2022 21:15:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial test fix to fix some bad/unsupported forms of `@clean` tags in some java tests.
> 
> Previously, these bad args were not detected and effectively had no effect.  Now, an upcoming new jtreg version will detect and give errors for these forms.

This pull request has now been integrated.

Changeset: 3312d8c6
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3312d8c620003125a88540fd5b2bacff34732ade
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8285756: clean up use of bad arguments for `@clean` in langtools tests

Reviewed-by: darcy

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

PR: https://git.openjdk.java.net/jdk/pull/8435

From jjg at openjdk.java.net  Wed Apr 27 22:33:00 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 27 Apr 2022 22:33:00 GMT
Subject: RFR: JDK-8195589: T6587786.java failed after JDK-8189997
Message-ID: <jnaWevjX7pOiUVB7iQxEd6YsI_2vmsU83wcrH2YsP8Y=.2b5e4e49-0407-438e-8601-5d73a24191a1@github.com>

Please review a fix for a javap test, removing it from the problem list.

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

Commit messages:
 - JDK-8195589: T6587786.java failed after JDK-8189997

Changes: https://git.openjdk.java.net/jdk/pull/8436/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8436&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8195589
  Stats: 11 lines in 2 files changed: 3 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8436.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8436/head:pull/8436

PR: https://git.openjdk.java.net/jdk/pull/8436

From iris at openjdk.java.net  Thu Apr 28 00:46:34 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 28 Apr 2022 00:46:34 GMT
Subject: RFR: JDK-8195589: T6587786.java failed after JDK-8189997
In-Reply-To: <jnaWevjX7pOiUVB7iQxEd6YsI_2vmsU83wcrH2YsP8Y=.2b5e4e49-0407-438e-8601-5d73a24191a1@github.com>
References: <jnaWevjX7pOiUVB7iQxEd6YsI_2vmsU83wcrH2YsP8Y=.2b5e4e49-0407-438e-8601-5d73a24191a1@github.com>
Message-ID: <2ipjAohSODdJSNpmiKxgyAegTDpH6I01FyZFZL0Wg0o=.9ad2f1dc-c8d3-489a-bd3f-2423355f10fd@github.com>

On Wed, 27 Apr 2022 22:07:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix for a javap test, removing it from the problem list.

Alternate files look good (and hopefully stable).

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8436

From duke at openjdk.java.net  Thu Apr 28 01:12:43 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Thu, 28 Apr 2022 01:12:43 GMT
Subject: RFR: 8282149: Some -Xlint keys are missing in javac man page
In-Reply-To: <O5B_IK-miHHwcFl6T8Td-ait-36v5QRZA1cw_bOldjM=.a26b960c-0f0d-4542-8098-860b96dee038@github.com>
References: <O5B_IK-miHHwcFl6T8Td-ait-36v5QRZA1cw_bOldjM=.a26b960c-0f0d-4542-8098-860b96dee038@github.com>
Message-ID: <JbwMW1O_eV_laudIhXkWcc_RcKDCf9bpzC83EqYZn6g=.1901afa6-ae53-452a-9a2b-cb95234c277e@github.com>

On Sat, 26 Mar 2022 14:33:57 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

> Adds all the XLint options that were noted as missing in the man page by the issue.

.

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

PR: https://git.openjdk.java.net/jdk/pull/7971

From jjg at openjdk.java.net  Thu Apr 28 03:05:44 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 28 Apr 2022 03:05:44 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec
 documents referenced from javadocs (OEM spec)
Message-ID: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>

Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

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

Commit messages:
 - fix whitespace and position of HtmlStyle.refList
 - fix whitespace
 - JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)

Changes: https://git.openjdk.java.net/jdk/pull/8439/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8439&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6251738
  Stats: 1539 lines in 41 files changed: 1506 ins; 3 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8439/head:pull/8439

PR: https://git.openjdk.java.net/jdk/pull/8439

From mcimadamore at openjdk.java.net  Thu Apr 28 10:37:41 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 28 Apr 2022 10:37:41 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
Message-ID: <HHbcxYdhhSpkiSgTdErAFvkxMkndJddwAu-iEd1U7Cw=.21fd0ffd-6c96-4238-98be-1259bfa6983a@github.com>

On Thu, 31 Mar 2022 08:13:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
> 
> interface I {}
> 
> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
> 
> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
> 
> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 758:

> 756:         String functionalInterfaceMethodName = samSym.getSimpleName().toString();
> 757:         String functionalInterfaceMethodSignature = typeSig(types.erasure(samSym.type));
> 758:         if ((refSym.flags_field & OBJECT_METHOD_IN_INTERFACE) != 0) {

Instead of using a new flag, can we use the base symbol and check if its owner is Object?

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From duke at openjdk.java.net  Thu Apr 28 10:57:03 2022
From: duke at openjdk.java.net (Halil =?UTF-8?B?xLBicmFoaW0=?= =?UTF-8?B?IA==?= =?UTF-8?B?xZ5lbmVy?=)
Date: Thu, 28 Apr 2022 10:57:03 GMT
Subject: RFR: 8277106: Cannot compile certain sources with --release [v2]
In-Reply-To: <MQVDBepdT7ERVh9Sm5J4zs_HWU8ML7ilXdGjuByQXkc=.0ab20f79-97e0-4c29-bf66-1e2541ef0a61@github.com>
References: <odlB8AnorK8G0yObERVlte45rD4K5xWCkhB3Uwl26cc=.710db6d4-9d5b-423a-bf60-b82d7db39ab1@github.com>
 <MQVDBepdT7ERVh9Sm5J4zs_HWU8ML7ilXdGjuByQXkc=.0ab20f79-97e0-4c29-bf66-1e2541ef0a61@github.com>
Message-ID: <H_g09WISbe_ie5sro9_yaGn15xDh_u5_C3RlMHerE08=.491d70a7-f2ac-4e33-af0f-e4766c4d5649@github.com>

On Tue, 7 Dec 2021 14:01:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> While working on JDK-8277105[1], it turned out the historical data in `ct.sym` are not quite right in two directions:
>> a) some API classes extend classes from non-exported packages (often from the `java.base` module). Examples include `jdk.jfr.Event` which extends `jdk.internal.event.Event`. As the current `ct.sym` data do not keep classes from non-exported packages, compilation against these classes fails.
>> b) permitted subtypes may include classes from non-exported packages, and these are needed to properly determine validity of casts and pattern matching switches. But these classes are not kept in the `ct.sym`, and hence the behavior of the casts may be incorrect. (Although I am no aware of any cases where an actual problem would arise with the current APIs.)
>> 
>> The proposed solution is to keep a certain amount of classes from non-exported packages in the historical record, specifically classes that are either extended by a class in an exported package. This solves the problem a). Solution for problem b) will be separate.
>> 
>> The first occurrence of a) I was able to find was in JDK 11, so this patch also fixes the historical record till JDK 11.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8277105
>
> 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:
> 
>  - Removing aspects related to sealed classes.
>  - Merge branch 'master' into JDK-8277106
>  - 8277106: Cannot compile certain sources with --release

@lahodaj - this may not be the right place to ask this question, but will this fix be backported to 17? I am getting the same `class file for jdk.internal.event.Event not found` error with JDK 17.0.3.

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

PR: https://git.openjdk.java.net/jdk/pull/6417

From mcimadamore at openjdk.java.net  Thu Apr 28 11:10:50 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 28 Apr 2022 11:10:50 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
Message-ID: <5w905fYBZbfwdzJrOES5e6KRP0L8Bw55xG5LPmCp7Rg=.9708dda1-ee70-4d1d-a89e-8bd67c242a08@github.com>

On Thu, 31 Mar 2022 08:13:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
> 
> interface I {}
> 
> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
> 
> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
> 
> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.

I have to admit I'm a bit worried about the impact of the original fix (JDK-8272564). Object methods are special cases on many occasions - one I recall on top of my head is in Gen::binaryQualifier:


        // leave alone methods inherited from Object
        // JLS 13.1.
        if (sym.owner == syms.objectType.tsym)
            return sym;


That is, when emitting an `invokevirtual`, if the source code says `X::toString`, the bytecode should still say `Object::toString`, as per JLS, as shown below (this is a quote from 13.1):


Given a method invocation expression or a method reference expression in a class or interface C, referencing a method named m declared (or implicitly declared ([?9.2](https://docs.oracle.com/javase/specs/jls/se18/html/jls-9.html#jls-9.2))) in a (possibly distinct) class or interface D, we define the qualifying class or interface of the method invocation as follows:

    If D is Object then the qualifying class or interface of the method invocation is Object.


Consider this simple example:


interface A { }

class Test {
   void test(A a) {
      a.toString();
   }
}


Before the fix, the javap output for `test` was like this:


void test(A);
    descriptor: (LA;)V
    flags: (0x0000)
    Code:
      stack=1, locals=2, args_size=2
         0: aload_1
         1: invokevirtual #2                  // Method java/lang/Object.toString:()Ljava/lang/String;
         4: pop
         5: return


But now, we get this instead:


void test(A);
    descriptor: (LA;)V
    flags: (0x0000)
    Code:
      stack=1, locals=2, args_size=2
         0: aload_1
         1: invokeinterface #7,  1            // InterfaceMethod A.toString:()Ljava/lang/String;
         6: pop
         7: return


This seems to be in clear violation of what the JLS says. So, I think JDK-8272564 should be either reverted or amended to restore compliance. There is a risk that, in doing point fixes (like in this PR, or additionally addressing the issue in `Gen::binaryQualifier`) we go down a whack-a-mole path.

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From mcimadamore at openjdk.java.net  Thu Apr 28 11:25:50 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 28 Apr 2022 11:25:50 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
Message-ID: <VY4hRjj0bDgit0ofO8w4N9EhkEy_fnVohECrzziGdw0=.abab306b-1ca5-499e-979e-dfdc78e158ba@github.com>

On Thu, 31 Mar 2022 08:13:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
> 
> interface I {}
> 
> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
> 
> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
> 
> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.

Actually, my reading of the JLS is incorrect. JLS says that the type of the binary qualifier is the type of the class in which the method has been declared, either explicitly, or implicitly. For interfaces, Object methods are declared implicitly by the interface, so it would seem that the type of the binary qualifier in this case is indeed the interface type, and that JDK-8272564 rectified that issue.

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From mcimadamore at openjdk.java.net  Thu Apr 28 11:52:48 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 28 Apr 2022 11:52:48 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <VY4hRjj0bDgit0ofO8w4N9EhkEy_fnVohECrzziGdw0=.abab306b-1ca5-499e-979e-dfdc78e158ba@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <VY4hRjj0bDgit0ofO8w4N9EhkEy_fnVohECrzziGdw0=.abab306b-1ca5-499e-979e-dfdc78e158ba@github.com>
Message-ID: <op-U-MSFdq0UsRzIB0uUj3gikE74fuWAPNjSw9fG5fk=.b83b36c6-93aa-4b2d-86ea-e4fbf40aafab@github.com>

On Thu, 28 Apr 2022 11:22:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Actually, my reading of the JLS is incorrect. JLS says that the type of the binary qualifier is the type of the class in which the method has been declared, either explicitly, or implicitly. For interfaces, Object methods are declared implicitly by the interface, so it would seem that the type of the binary qualifier in this case is indeed the interface type, and that JDK-8272564 rectified that issue.

This is related:
https://bugs.openjdk.java.net/browse/JDK-8022095

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From mcimadamore at openjdk.java.net  Thu Apr 28 11:56:45 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 28 Apr 2022 11:56:45 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces
In-Reply-To: <op-U-MSFdq0UsRzIB0uUj3gikE74fuWAPNjSw9fG5fk=.b83b36c6-93aa-4b2d-86ea-e4fbf40aafab@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <VY4hRjj0bDgit0ofO8w4N9EhkEy_fnVohECrzziGdw0=.abab306b-1ca5-499e-979e-dfdc78e158ba@github.com>
 <op-U-MSFdq0UsRzIB0uUj3gikE74fuWAPNjSw9fG5fk=.b83b36c6-93aa-4b2d-86ea-e4fbf40aafab@github.com>
Message-ID: <vFYnW1ElcOZnBJiUxW1XK-Uclw0qhET9-QWIRtzgKDQ=.167dc100-bdd9-417d-9ba3-636b1ffbb1ad@github.com>

On Thu, 28 Apr 2022 11:48:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is related:
> https://bugs.openjdk.java.net/browse/JDK-8022095

>From this, it can be deduced that the behavior if javac preferring invokevirtual to invokeinterface was surprising, but ultimately compliant with the spec (as the rules for BC for method calls are more flexible than those for field access). All this to say that the compiler is free to emit `Object::toString` or `I::toString` more or less as it pleases.

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From jlahoda at openjdk.java.net  Thu Apr 28 14:45:29 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 28 Apr 2022 14:45:29 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v8]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <qW_cfdlzZbZGgZ9TFRqQs8bUPmGL8gJ5QMelV52ksfA=.8b9b34e4-67f9-48d4-ab03-7a2c331e82a1@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

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

 - Reducing MatchException constructors.
 - Merge branch 'master' into type-patterns-third
 - Reference-type pattern is not applicable at a selector of a primitive type - fixing.
 - Merge branch 'master' into type-patterns-third
 - Cleanup, fixing tests.
 - Cleanup - more total -> unconditional pattern renaming.
 - Adjusting to review feedback.
 - Cleanup.
 - Fixing tests.
 - Adding a test for a NPE from guards.
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/4919525d...115605ae

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

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=07
  Stats: 860 lines in 52 files changed: 424 ins; 244 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Thu Apr 28 15:34:44 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 28 Apr 2022 15:34:44 GMT
Subject: RFR: JDK-8195589: T6587786.java failed after JDK-8189997
In-Reply-To: <jnaWevjX7pOiUVB7iQxEd6YsI_2vmsU83wcrH2YsP8Y=.2b5e4e49-0407-438e-8601-5d73a24191a1@github.com>
References: <jnaWevjX7pOiUVB7iQxEd6YsI_2vmsU83wcrH2YsP8Y=.2b5e4e49-0407-438e-8601-5d73a24191a1@github.com>
Message-ID: <bfOBR2HZmuRLHFZh5vqxJQJ3EMiN7VnxF0lpeeLp3O8=.50162eb5-4521-4870-8aef-af1d5c2babac@github.com>

On Wed, 27 Apr 2022 22:07:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix for a javap test, removing it from the problem list.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8436

From jlahoda at openjdk.java.net  Thu Apr 28 18:36:48 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 28 Apr 2022 18:36:48 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces [v2]
In-Reply-To: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
Message-ID: <NANBTC8SHjxN4oFJ5rPMIQgBOYeU37FqMPuWEDJx3q8=.2b9936ad-bdf2-4bcc-bb3f-3f1321595594@github.com>

> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
> 
> interface I {}
> 
> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
> 
> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
> 
> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.

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

  Avoiding a use of a new flag to determine Object methods copied to interfaces.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8054/files
  - new: https://git.openjdk.java.net/jdk/pull/8054/files/72281286..7bf7fedb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8054&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8054&range=00-01

  Stats: 11 lines in 3 files changed: 2 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8054.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8054/head:pull/8054

PR: https://git.openjdk.java.net/jdk/pull/8054

From jlahoda at openjdk.java.net  Thu Apr 28 18:36:51 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 28 Apr 2022 18:36:51 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces [v2]
In-Reply-To: <HHbcxYdhhSpkiSgTdErAFvkxMkndJddwAu-iEd1U7Cw=.21fd0ffd-6c96-4238-98be-1259bfa6983a@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <HHbcxYdhhSpkiSgTdErAFvkxMkndJddwAu-iEd1U7Cw=.21fd0ffd-6c96-4238-98be-1259bfa6983a@github.com>
Message-ID: <YTYsGXuy0Qwm-Zi4bQmvHJoBGHO7cmTM35jYkNcnRHE=.7ff278de-05df-48fc-9315-41e660078890@github.com>

On Thu, 28 Apr 2022 10:33:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoiding a use of a new flag to determine Object methods copied to interfaces.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 758:
> 
>> 756:         String functionalInterfaceMethodName = samSym.getSimpleName().toString();
>> 757:         String functionalInterfaceMethodSignature = typeSig(types.erasure(samSym.type));
>> 758:         if ((refSym.flags_field & OBJECT_METHOD_IN_INTERFACE) != 0) {
> 
> Instead of using a new flag, can we use the base symbol and check if its owner is Object?

Thanks for the comment. Yes, that is possible:
https://github.com/openjdk/jdk/pull/8054/commits/7bf7fedbf122717bdcc13d5ec4fc821590b8e82a

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

PR: https://git.openjdk.java.net/jdk/pull/8054

From jjg at openjdk.java.net  Thu Apr 28 22:40:15 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 28 Apr 2022 22:40:15 GMT
Subject: RFR: JDK-8285496: DocLint does not check for missing `@param` tags for
 type parameters on classes and interfaces
Message-ID: <NFKtrWtv5ec0harQWE8AN478Xbj8Y1SbdbFvTs8iZgk=.33fce096-c044-4cd3-9a57-4559f67040b3@github.com>

Please review a trivial update for doclint, to check for `@param` tags for type parameters of classes and interfaces.

The bug was discovered recently, while making an update for record components, but this part of the fix was effectively blocked by the presence of missing tags in API documentation.

As well as a minor update to an existing test, the change has been tested by running `make docs`, `make docs-javase` and `make docs-reference`, all of which succeed without any warnings about missing tags.

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

Commit messages:
 - JDK-8285496: DocLint does not check for missing `@param` tags for type parameters on classes and interfaces

Changes: https://git.openjdk.java.net/jdk/pull/8458/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8458&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285496
  Stats: 9 lines in 3 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8458.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8458/head:pull/8458

PR: https://git.openjdk.java.net/jdk/pull/8458

From darcy at openjdk.java.net  Thu Apr 28 23:15:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 23:15:42 GMT
Subject: RFR: JDK-8285496: DocLint does not check for missing `@param` tags
 for type parameters on classes and interfaces
In-Reply-To: <NFKtrWtv5ec0harQWE8AN478Xbj8Y1SbdbFvTs8iZgk=.33fce096-c044-4cd3-9a57-4559f67040b3@github.com>
References: <NFKtrWtv5ec0harQWE8AN478Xbj8Y1SbdbFvTs8iZgk=.33fce096-c044-4cd3-9a57-4559f67040b3@github.com>
Message-ID: <EV-ubdgMVa4tZyEh0M7B3aAQmXCcZDR1chm1_11Ybr4=.89e9a441-380f-4d58-9c9b-e5c05c6ca0d6@github.com>

On Thu, 28 Apr 2022 22:32:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update for doclint, to check for `@param` tags for type parameters of classes and interfaces.
> 
> The bug was discovered recently, while making an update for record components, but this part of the fix was effectively blocked by the presence of missing tags in API documentation.
> 
> As well as a minor update to an existing test, the change has been tested by running `make docs`, `make docs-javase` and `make docs-reference`, all of which succeed without any warnings about missing tags.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8458

From iris at openjdk.java.net  Fri Apr 29 00:36:44 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 29 Apr 2022 00:36:44 GMT
Subject: RFR: JDK-8285688: Add links to JEPs and JSRs to SourceVersion [v2]
In-Reply-To: <n0MvyDim80ZbKT3D4Sy06VFtDahEdth8sdBf25huYGM=.16fffd9a-c681-43f8-ac61-940acef889c1@github.com>
References: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
 <n0MvyDim80ZbKT3D4Sy06VFtDahEdth8sdBf25huYGM=.16fffd9a-c681-43f8-ac61-940acef889c1@github.com>
Message-ID: <MUdIA4clj7JTn5ksbw6M50N6D40Xf-JWY3HH9-A9k3w=.105cb30d-3322-440c-bb58-b828443b4642@github.com>

On Wed, 27 Apr 2022 04:36:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To provide more context to readers about the development of the language, add to the enum constants in SourceVersion @see links to the JEPs and JSRs that added features to a release.
>> 
>> (For now, have left out @see links to preview features.)
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix title of JSR 201.

Marked as reviewed by iris (Reviewer).

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 196:

> 194:      * @see <a href="https://jcp.org/en/jsr/detail?id=376">
> 195:      * JSR 376: Java&trade; Platform Module System</a>
> 196:      * @see <a href="http://openjdk.java.net/jeps/213">

Recommend you use "https" instead of "http" protocol for all JEP references.

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

PR: https://git.openjdk.java.net/jdk/pull/8413

From iris at openjdk.java.net  Fri Apr 29 00:36:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 29 Apr 2022 00:36:50 GMT
Subject: RFR: JDK-8285496: DocLint does not check for missing `@param` tags
 for type parameters on classes and interfaces
In-Reply-To: <NFKtrWtv5ec0harQWE8AN478Xbj8Y1SbdbFvTs8iZgk=.33fce096-c044-4cd3-9a57-4559f67040b3@github.com>
References: <NFKtrWtv5ec0harQWE8AN478Xbj8Y1SbdbFvTs8iZgk=.33fce096-c044-4cd3-9a57-4559f67040b3@github.com>
Message-ID: <X3keLNtnrxtH_k5JU3hhHMiS2pMNT1kBpl1Yt-XsIsQ=.6dbf001c-4c17-4142-a702-1019e3817f01@github.com>

On Thu, 28 Apr 2022 22:32:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update for doclint, to check for `@param` tags for type parameters of classes and interfaces.
> 
> The bug was discovered recently, while making an update for record components, but this part of the fix was effectively blocked by the presence of missing tags in API documentation.
> 
> As well as a minor update to an existing test, the change has been tested by running `make docs`, `make docs-javase` and `make docs-reference`, all of which succeed without any warnings about missing tags.

This follow-on for 8284994 looks good.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8458

From jjg at openjdk.java.net  Fri Apr 29 00:36:51 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 29 Apr 2022 00:36:51 GMT
Subject: Integrated: JDK-8285496: DocLint does not check for missing `@param`
 tags for type parameters on classes and interfaces
In-Reply-To: <NFKtrWtv5ec0harQWE8AN478Xbj8Y1SbdbFvTs8iZgk=.33fce096-c044-4cd3-9a57-4559f67040b3@github.com>
References: <NFKtrWtv5ec0harQWE8AN478Xbj8Y1SbdbFvTs8iZgk=.33fce096-c044-4cd3-9a57-4559f67040b3@github.com>
Message-ID: <qYlkj_aO0YfClWm-vHfB19aq2PTJJ1dWCDJLSQfWWlY=.79ee269c-842b-4cb2-b4ef-f6267f39597a@github.com>

On Thu, 28 Apr 2022 22:32:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update for doclint, to check for `@param` tags for type parameters of classes and interfaces.
> 
> The bug was discovered recently, while making an update for record components, but this part of the fix was effectively blocked by the presence of missing tags in API documentation.
> 
> As well as a minor update to an existing test, the change has been tested by running `make docs`, `make docs-javase` and `make docs-reference`, all of which succeed without any warnings about missing tags.

This pull request has now been integrated.

Changeset: 81902179
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8190217971cdda5e8d11a74f43b8b53db2f0017b
Stats:     9 lines in 3 files changed: 6 ins; 0 del; 3 mod

8285496: DocLint does not check for missing `@param` tags for type parameters on classes and interfaces

Reviewed-by: darcy, iris

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

PR: https://git.openjdk.java.net/jdk/pull/8458

From jjg at openjdk.java.net  Fri Apr 29 00:38:47 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 29 Apr 2022 00:38:47 GMT
Subject: Integrated: JDK-8195589: T6587786.java failed after JDK-8189997
In-Reply-To: <jnaWevjX7pOiUVB7iQxEd6YsI_2vmsU83wcrH2YsP8Y=.2b5e4e49-0407-438e-8601-5d73a24191a1@github.com>
References: <jnaWevjX7pOiUVB7iQxEd6YsI_2vmsU83wcrH2YsP8Y=.2b5e4e49-0407-438e-8601-5d73a24191a1@github.com>
Message-ID: <iyQg04JXk8XBKa01ytOFmK71KItnpYqPfw3urSZ8eN0=.2ac77d62-3722-4a9f-8ace-f2f171f1be52@github.com>

On Wed, 27 Apr 2022 22:07:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix for a javap test, removing it from the problem list.

This pull request has now been integrated.

Changeset: 21b62fef
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/21b62fef335aa981a239415532fa8b804fb5676d
Stats:     11 lines in 2 files changed: 3 ins; 1 del; 7 mod

8195589: T6587786.java failed after JDK-8189997

Reviewed-by: iris, vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8436

From jjg at openjdk.java.net  Fri Apr 29 00:38:49 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 29 Apr 2022 00:38:49 GMT
Subject: Integrated: JDK-8285610: TreeInfo.pathFor and its uses appear to be
 dead code
In-Reply-To: <NTIfhgemiSAQPzxwWkcPRSC1tfErg22tnCEL_Vv9on0=.be185581-8096-40c8-9b3d-ff4c700455cf@github.com>
References: <NTIfhgemiSAQPzxwWkcPRSC1tfErg22tnCEL_Vv9on0=.be185581-8096-40c8-9b3d-ff4c700455cf@github.com>
Message-ID: <0XHWI-gvcbSXgdUg9S-nhHfJm-szENPG4y37vKINIpc=.20e3dc3c-43c4-40b6-93e5-380294b0e1e1@github.com>

On Tue, 26 Apr 2022 00:12:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial change to remove some unused/dead code. 
> 
> All tier1 tests pass.

This pull request has now been integrated.

Changeset: 80cf59ff
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/80cf59ff0bb4d16a4a7144a60a656825a659d203
Stats:     42 lines in 2 files changed: 0 ins; 42 del; 0 mod

8285610: TreeInfo.pathFor and its uses appear to be dead code

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8393

From jjg at openjdk.java.net  Fri Apr 29 00:38:15 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 29 Apr 2022 00:38:15 GMT
Subject: RFR: JDK-8285869: Selective cleanup in doclint Checker class
Message-ID: <nxNdyTvPonj_dJCS5DeoCQCqKRFuvT2MaEZLNGy-X04=.b6120aee-48c6-4701-bedc-83d5b82f4bad@github.com>

Please review some localized cleanup for the doclint Checker class, primarily focused on upgrading to the use of "enhanced `switch`"

The output of one test was changed because of some improvements in one switch statement to eliminate the use of fall-through semantics.

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

Commit messages:
 - JDK-8285869: Selective cleanup in doclint Checker class

Changes: https://git.openjdk.java.net/jdk/pull/8460/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8460&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285869
  Stats: 146 lines in 2 files changed: 12 ins; 39 del; 95 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8460.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8460/head:pull/8460

PR: https://git.openjdk.java.net/jdk/pull/8460

From darcy at openjdk.java.net  Fri Apr 29 01:09:35 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 01:09:35 GMT
Subject: Integrated: JDK-8285688: Add links to JEPs and JSRs to SourceVersion
In-Reply-To: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
References: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
Message-ID: <GFq2vtnJOBPtkcOm555OP96XnCA8wiiT8GZDLEauDco=.6c8af0ed-2ed6-4420-8ad5-5285da810529@github.com>

On Wed, 27 Apr 2022 01:28:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To provide more context to readers about the development of the language, add to the enum constants in SourceVersion @see links to the JEPs and JSRs that added features to a release.
> 
> (For now, have left out @see links to preview features.)

This pull request has now been integrated.

Changeset: e2e943ad
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e2e943adcbe9ddedcc1e4575d4b107c242073321
Stats:     35 lines in 1 file changed: 35 ins; 0 del; 0 mod

8285688: Add links to JEPs and JSRs to SourceVersion

Reviewed-by: vromero, jjg, iris

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

PR: https://git.openjdk.java.net/jdk/pull/8413

From darcy at openjdk.java.net  Fri Apr 29 01:09:34 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 01:09:34 GMT
Subject: RFR: JDK-8285688: Add links to JEPs and JSRs to SourceVersion [v2]
In-Reply-To: <MUdIA4clj7JTn5ksbw6M50N6D40Xf-JWY3HH9-A9k3w=.105cb30d-3322-440c-bb58-b828443b4642@github.com>
References: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
 <n0MvyDim80ZbKT3D4Sy06VFtDahEdth8sdBf25huYGM=.16fffd9a-c681-43f8-ac61-940acef889c1@github.com>
 <MUdIA4clj7JTn5ksbw6M50N6D40Xf-JWY3HH9-A9k3w=.105cb30d-3322-440c-bb58-b828443b4642@github.com>
Message-ID: <yeaQ9H2zB5S5dG23Ls8pNCqyCYhB4DeGGAJiRjJ4J54=.bdcdd136-2904-471a-b87e-9829102e078b@github.com>

On Thu, 28 Apr 2022 01:37:25 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix title of JSR 201.
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 196:
> 
>> 194:      * @see <a href="https://jcp.org/en/jsr/detail?id=376">
>> 195:      * JSR 376: Java&trade; Platform Module System</a>
>> 196:      * @see <a href="http://openjdk.java.net/jeps/213">
> 
> Recommend you use "https" instead of "http" protocol for all JEP references.

So changed. Note that the links on the main JEP page http://openjdk.java.net/jeps/0 are http rather than https. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8413

From darcy at openjdk.java.net  Fri Apr 29 01:09:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 01:09:33 GMT
Subject: RFR: JDK-8285688: Add links to JEPs and JSRs to SourceVersion [v3]
In-Reply-To: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
References: <0U8IW2qp4O7u93byZURWX6XU_Ab7c5lADO_qKMbpGsc=.1d9bf0a3-55c8-4309-a303-a242757218d3@github.com>
Message-ID: <zMJtXNZQqUrGCp6a92GalcVxPUtZ-Glb53DCw9hT9Mw=.96a52d4f-59dc-4f2e-b8e3-7158dc6299d5@github.com>

> To provide more context to readers about the development of the language, add to the enum constants in SourceVersion @see links to the JEPs and JSRs that added features to a release.
> 
> (For now, have left out @see links to preview features.)

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

 - Use https rather than http links for JEPs.
 - Merge branch 'master' into JDK-8285688
 - Fix title of JSR 201.
 - JDK-8285688: Add links to JEPs and JSRs to SourceVersion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8413/files
  - new: https://git.openjdk.java.net/jdk/pull/8413/files/39c1b70e..ff2f58fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8413&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8413&range=01-02

  Stats: 6625 lines in 156 files changed: 5437 ins; 493 del; 695 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8413.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8413/head:pull/8413

PR: https://git.openjdk.java.net/jdk/pull/8413

From sadayapalam at openjdk.java.net  Fri Apr 29 05:06:50 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 29 Apr 2022 05:06:50 GMT
Subject: RFR: 8155701: The compiler fails with an AssertionError: typeSig
 ERROR
In-Reply-To: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>
References: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>
Message-ID: <e93uOE6ei24j398qECA4jm2PB9LevAhD5y2ChzDXADQ=.41dc168d-83ac-4d58-a848-7442a659fc77@github.com>

On Wed, 27 Apr 2022 05:51:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Make sure javac issues suitable diagnostics for types not found in the class path

Thanks for the review, Vicente!

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

PR: https://git.openjdk.java.net/jdk/pull/8414

From sadayapalam at openjdk.java.net  Fri Apr 29 05:06:52 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 29 Apr 2022 05:06:52 GMT
Subject: Integrated: 8155701: The compiler fails with an AssertionError:
 typeSig ERROR
In-Reply-To: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>
References: <-87AEgqmNTbf2fXWFSDjvKd0BFczKX3QWolfWDzrm5E=.a85c08bb-e27b-4a17-8abf-0cfb46110896@github.com>
Message-ID: <z5GgKGe85keCEK2wVylAlz3p95WN6a74kg73Sec6GsY=.018afdc0-c944-4975-b154-fb21163d473c@github.com>

On Wed, 27 Apr 2022 05:51:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Make sure javac issues suitable diagnostics for types not found in the class path

This pull request has now been integrated.

Changeset: 1e28fcbc
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e28fcbc5f32103f460bc35235b3cad0cfaa69b5
Stats:     119 lines in 2 files changed: 116 ins; 0 del; 3 mod

8155701: The compiler fails with an AssertionError: typeSig ERROR

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/8414

From amaembo at gmail.com  Fri Apr 29 14:54:10 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 29 Apr 2022 16:54:10 +0200
Subject: Instance qualifier for static access warning and anonymous classes
Message-ID: <CAE+3fjYKD3e_r6rd4zcwzzZo82VWp-1Eq43GVwYBPbGUorejQA@mail.gmail.com>

Hello!

Consider the following code:

public class Demo {
    public static void main(String[] args) {
        var obj = new Object() {
            static void foo() {
                System.out.println("Static method of anonymous class");
            }
        };
        obj.foo(); // Cannot replace instance qualifier with class reference
    }
}

With -Xlint:static, javac reports the following warning:

Demo.java:8: warning: [static] static method should be qualified by
type name, <anonymous Demo$1>, instead of by an expression
        obj.foo(); // Cannot replace instance qualifier with class reference
           ^
1 warning

It's questionable whether this warning should be reported at all, as
it's impossible to call the static method of anonymous class with
class name qualifier. But in any case, suggesting to use `<anonymous
Demo$1>` as a qualifier is invalid.

With best regards,
Tagir Valeev.

From maurizio.cimadamore at oracle.com  Fri Apr 29 15:25:19 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 29 Apr 2022 16:25:19 +0100
Subject: Instance qualifier for static access warning and anonymous classes
In-Reply-To: <CAE+3fjYKD3e_r6rd4zcwzzZo82VWp-1Eq43GVwYBPbGUorejQA@mail.gmail.com>
References: <CAE+3fjYKD3e_r6rd4zcwzzZo82VWp-1Eq43GVwYBPbGUorejQA@mail.gmail.com>
Message-ID: <5cbdede3-c091-9a33-1ca6-14adf994db98@oracle.com>

Well spotted - this seems like a dark corner.

IMHO there are two possible interpretation, which depend on where we 
want to go with the warning:

1. static methods accessed through instance qualifiers are Bad, and we 
should try to wean developer off them over time (and align this with 
interface static methods). In this case the warning should stay (but of 
course the message needs to be fixed :-) ).
2. static methods accessed through instance qualifiers are a wart, but 
something we should be prepared to live with forever - best thing we can 
do in this space is to issue some "style" warnings, but nothing more 
will ever happen. In this case, for this example we should turn off the 
warning altogether.

Maurizio

On 29/04/2022 15:54, Tagir Valeev wrote:
> Hello!
>
> Consider the following code:
>
> public class Demo {
>      public static void main(String[] args) {
>          var obj = new Object() {
>              static void foo() {
>                  System.out.println("Static method of anonymous class");
>              }
>          };
>          obj.foo(); // Cannot replace instance qualifier with class reference
>      }
> }
>
> With -Xlint:static, javac reports the following warning:
>
> Demo.java:8: warning: [static] static method should be qualified by
> type name, <anonymous Demo$1>, instead of by an expression
>          obj.foo(); // Cannot replace instance qualifier with class reference
>             ^
> 1 warning
>
> It's questionable whether this warning should be reported at all, as
> it's impossible to call the static method of anonymous class with
> class name qualifier. But in any case, suggesting to use `<anonymous
> Demo$1>` as a qualifier is invalid.
>
> With best regards,
> Tagir Valeev.

From amaembo at gmail.com  Fri Apr 29 15:37:04 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 29 Apr 2022 17:37:04 +0200
Subject: Instance qualifier for static access warning and anonymous classes
In-Reply-To: <5cbdede3-c091-9a33-1ca6-14adf994db98@oracle.com>
References: <CAE+3fjYKD3e_r6rd4zcwzzZo82VWp-1Eq43GVwYBPbGUorejQA@mail.gmail.com>
 <5cbdede3-c091-9a33-1ca6-14adf994db98@oracle.com>
Message-ID: <CAE+3fjbzz0ABn5aL2AWvYR6jfjUEmZw+Wb4ekmLptD4sN4ga_w@mail.gmail.com>

We in JetBrains, decided to remove a warning in this case, as there's
no obvious fix and it's not a suspicious or buggy code, it's likely to
be intended in a way it is.

With best regards,
Tagir Valeev.

On Fri, Apr 29, 2022 at 5:25 PM Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> Well spotted - this seems like a dark corner.
>
> IMHO there are two possible interpretation, which depend on where we
> want to go with the warning:
>
> 1. static methods accessed through instance qualifiers are Bad, and we
> should try to wean developer off them over time (and align this with
> interface static methods). In this case the warning should stay (but of
> course the message needs to be fixed :-) ).
> 2. static methods accessed through instance qualifiers are a wart, but
> something we should be prepared to live with forever - best thing we can
> do in this space is to issue some "style" warnings, but nothing more
> will ever happen. In this case, for this example we should turn off the
> warning altogether.
>
> Maurizio
>
> On 29/04/2022 15:54, Tagir Valeev wrote:
> > Hello!
> >
> > Consider the following code:
> >
> > public class Demo {
> >      public static void main(String[] args) {
> >          var obj = new Object() {
> >              static void foo() {
> >                  System.out.println("Static method of anonymous class");
> >              }
> >          };
> >          obj.foo(); // Cannot replace instance qualifier with class reference
> >      }
> > }
> >
> > With -Xlint:static, javac reports the following warning:
> >
> > Demo.java:8: warning: [static] static method should be qualified by
> > type name, <anonymous Demo$1>, instead of by an expression
> >          obj.foo(); // Cannot replace instance qualifier with class reference
> >             ^
> > 1 warning
> >
> > It's questionable whether this warning should be reported at all, as
> > it's impossible to call the static method of anonymous class with
> > class name qualifier. But in any case, suggesting to use `<anonymous
> > Demo$1>` as a qualifier is invalid.
> >
> > With best regards,
> > Tagir Valeev.

From maurizio.cimadamore at oracle.com  Fri Apr 29 15:42:26 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 29 Apr 2022 16:42:26 +0100
Subject: Instance qualifier for static access warning and anonymous classes
In-Reply-To: <CAE+3fjbzz0ABn5aL2AWvYR6jfjUEmZw+Wb4ekmLptD4sN4ga_w@mail.gmail.com>
References: <CAE+3fjYKD3e_r6rd4zcwzzZo82VWp-1Eq43GVwYBPbGUorejQA@mail.gmail.com>
 <5cbdede3-c091-9a33-1ca6-14adf994db98@oracle.com>
 <CAE+3fjbzz0ABn5aL2AWvYR6jfjUEmZw+Wb4ekmLptD4sN4ga_w@mail.gmail.com>
Message-ID: <09f94ab8-be38-90ee-e528-12d473be79db@oracle.com>

Filed:
https://bugs.openjdk.java.net/browse/JDK-8285935

Thanks
Maurizio

On 29/04/2022 16:37, Tagir Valeev wrote:
> We in JetBrains, decided to remove a warning in this case, as there's
> no obvious fix and it's not a suspicious or buggy code, it's likely to
> be intended in a way it is.
>
> With best regards,
> Tagir Valeev.
>
> On Fri, Apr 29, 2022 at 5:25 PM Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> Well spotted - this seems like a dark corner.
>>
>> IMHO there are two possible interpretation, which depend on where we
>> want to go with the warning:
>>
>> 1. static methods accessed through instance qualifiers are Bad, and we
>> should try to wean developer off them over time (and align this with
>> interface static methods). In this case the warning should stay (but of
>> course the message needs to be fixed :-) ).
>> 2. static methods accessed through instance qualifiers are a wart, but
>> something we should be prepared to live with forever - best thing we can
>> do in this space is to issue some "style" warnings, but nothing more
>> will ever happen. In this case, for this example we should turn off the
>> warning altogether.
>>
>> Maurizio
>>
>> On 29/04/2022 15:54, Tagir Valeev wrote:
>>> Hello!
>>>
>>> Consider the following code:
>>>
>>> public class Demo {
>>>       public static void main(String[] args) {
>>>           var obj = new Object() {
>>>               static void foo() {
>>>                   System.out.println("Static method of anonymous class");
>>>               }
>>>           };
>>>           obj.foo(); // Cannot replace instance qualifier with class reference
>>>       }
>>> }
>>>
>>> With -Xlint:static, javac reports the following warning:
>>>
>>> Demo.java:8: warning: [static] static method should be qualified by
>>> type name, <anonymous Demo$1>, instead of by an expression
>>>           obj.foo(); // Cannot replace instance qualifier with class reference
>>>              ^
>>> 1 warning
>>>
>>> It's questionable whether this warning should be reported at all, as
>>> it's impossible to call the static method of anonymous class with
>>> class name qualifier. But in any case, suggesting to use `<anonymous
>>> Demo$1>` as a qualifier is invalid.
>>>
>>> With best regards,
>>> Tagir Valeev.

From dcubed at openjdk.java.net  Fri Apr 29 17:14:19 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 29 Apr 2022 17:14:19 GMT
Subject: Integrated: 8285938: ProblemList jdk/jshell/HighlightUITest.java on
 linux-x64
Message-ID: <9UzOs_Uq7mdTvj62tvfuHhuzX1--0fAikw-Qq_EaDVk=.55a5de2c-4df7-4855-925c-b94093a99ece@github.com>

A trivial fix to ProblemList jdk/jshell/HighlightUITest.java on linux-x64.

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

Commit messages:
 - 8285938: ProblemList jdk/jshell/HighlightUITest.java on linux-x64

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

PR: https://git.openjdk.java.net/jdk/pull/8470

From darcy at openjdk.java.net  Fri Apr 29 17:14:19 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 17:14:19 GMT
Subject: Integrated: 8285938: ProblemList jdk/jshell/HighlightUITest.java
 on linux-x64
In-Reply-To: <9UzOs_Uq7mdTvj62tvfuHhuzX1--0fAikw-Qq_EaDVk=.55a5de2c-4df7-4855-925c-b94093a99ece@github.com>
References: <9UzOs_Uq7mdTvj62tvfuHhuzX1--0fAikw-Qq_EaDVk=.55a5de2c-4df7-4855-925c-b94093a99ece@github.com>
Message-ID: <K9ocLX1dFGMZfzMuDQPKNTowLwVpjSKZUDsGb19lQRk=.3fdc2585-5fda-4d2b-ac67-98639e72d4a4@github.com>

On Fri, 29 Apr 2022 16:46:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jshell/HighlightUITest.java on linux-x64.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8470

From azvegint at openjdk.java.net  Fri Apr 29 17:14:20 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 29 Apr 2022 17:14:20 GMT
Subject: Integrated: 8285938: ProblemList jdk/jshell/HighlightUITest.java
 on linux-x64
In-Reply-To: <9UzOs_Uq7mdTvj62tvfuHhuzX1--0fAikw-Qq_EaDVk=.55a5de2c-4df7-4855-925c-b94093a99ece@github.com>
References: <9UzOs_Uq7mdTvj62tvfuHhuzX1--0fAikw-Qq_EaDVk=.55a5de2c-4df7-4855-925c-b94093a99ece@github.com>
Message-ID: <PSMaPk3TNhbe0NIAqDElNRzJhF5_U5nw836T406CLag=.c7c53c82-42f5-42ed-9ea6-0ca3810d5f74@github.com>

On Fri, 29 Apr 2022 16:46:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jshell/HighlightUITest.java on linux-x64.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8470

From dcubed at openjdk.java.net  Fri Apr 29 17:14:20 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 29 Apr 2022 17:14:20 GMT
Subject: Integrated: 8285938: ProblemList jdk/jshell/HighlightUITest.java
 on linux-x64
In-Reply-To: <K9ocLX1dFGMZfzMuDQPKNTowLwVpjSKZUDsGb19lQRk=.3fdc2585-5fda-4d2b-ac67-98639e72d4a4@github.com>
References: <9UzOs_Uq7mdTvj62tvfuHhuzX1--0fAikw-Qq_EaDVk=.55a5de2c-4df7-4855-925c-b94093a99ece@github.com>
 <K9ocLX1dFGMZfzMuDQPKNTowLwVpjSKZUDsGb19lQRk=.3fdc2585-5fda-4d2b-ac67-98639e72d4a4@github.com>
Message-ID: <vtYexWo7KJTXkoz7H1l9Pqd9MMTgEstIZ5NCpKinsxQ=.9858f88f-f673-463a-99fb-d8adde065d99@github.com>

On Fri, 29 Apr 2022 16:48:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jshell/HighlightUITest.java on linux-x64.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy and @azvegint - Thanks for the fast reviews!

Now I have to be patient and wait for the bots to catch up...

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

PR: https://git.openjdk.java.net/jdk/pull/8470

From dcubed at openjdk.java.net  Fri Apr 29 17:14:21 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 29 Apr 2022 17:14:21 GMT
Subject: Integrated: 8285938: ProblemList jdk/jshell/HighlightUITest.java on
 linux-x64
In-Reply-To: <9UzOs_Uq7mdTvj62tvfuHhuzX1--0fAikw-Qq_EaDVk=.55a5de2c-4df7-4855-925c-b94093a99ece@github.com>
References: <9UzOs_Uq7mdTvj62tvfuHhuzX1--0fAikw-Qq_EaDVk=.55a5de2c-4df7-4855-925c-b94093a99ece@github.com>
Message-ID: <xz1eJgS9glSYSZ_d8U1lntvDJ8B2_dC_z236EEHCxZs=.1fac60ac-cd20-4242-8efa-f17e0b3ad224@github.com>

On Fri, 29 Apr 2022 16:46:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jshell/HighlightUITest.java on linux-x64.

This pull request has now been integrated.

Changeset: cfe67af2
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cfe67af20985afdb55e7922b0814da9de0ebcc3a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8285938: ProblemList jdk/jshell/HighlightUITest.java on linux-x64

Reviewed-by: darcy, azvegint

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

PR: https://git.openjdk.java.net/jdk/pull/8470

From cushon at openjdk.java.net  Sat Apr 30 19:39:33 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Sat, 30 Apr 2022 19:39:33 GMT
Subject: RFR: 8282080: Lambda deserialization fails for Object method
 references on interfaces [v2]
In-Reply-To: <NANBTC8SHjxN4oFJ5rPMIQgBOYeU37FqMPuWEDJx3q8=.2b9936ad-bdf2-4bcc-bb3f-3f1321595594@github.com>
References: <L3VLjn2NSg6C4t1eDwUnQiGgDB6QUWFpGdV91S_Y-xk=.0fb228c8-ceae-4520-a1b6-7e0aa85624e3@github.com>
 <NANBTC8SHjxN4oFJ5rPMIQgBOYeU37FqMPuWEDJx3q8=.2b9936ad-bdf2-4bcc-bb3f-3f1321595594@github.com>
Message-ID: <zRvzXaRa4PhOokdDj5Vf8brpa7zvrxq3trkhSYmBQOQ=.d4199c2a-ed53-4a4a-9b7c-57a8501b2c4e@github.com>

On Thu, 28 Apr 2022 18:36:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Per JLS, every interface with no superinterfaces implicitly has all public methods `java.lang.Object` has (unless the interface declares them explicitly). So, having:
>> 
>> interface I {}
>> 
>> the interface has methods like `hashCode()`. But, before https://bugs.openjdk.java.net/browse/JDK-8272564, javac was referring to them as if they were a `java.lang.Object` methods, not the interface methods. E.g. saying `I i = null; i.hashCode()` lead to a reference to `java.lang.Object.hashCode()` not `I.hashCode()`. That was changed in JDK-8272564, and now the reference is to `I.hashCode()`.
>> 
>> There is one issue, though: when the reference is for a serializable (and serialized) method handle, the runtime method is still `java.lang.Object::hashCode`, but the deserialization code generated by javac expects `I::hashCode`, and hence the serialized method handle fails to deserialize.
>> 
>> The proposal here is to fix just this case, by changing the deserialization code to expect the method from `java.lang.Object`, which should revert the deserialization behavior back to JDK 17 behavior.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoiding a use of a new flag to determine Object methods copied to interfaces.

Re: the impact of JDK-8272564, for what it's worth, it ended up being a noticeable breaking change for us:

* Some static analysis that was looking for interfaces noticed the 'sharper' static type information on these calls. This is an improvement, but still a breaking one.
* A non-OpenJDK runtime's verifier didn't handle the new calls (which is their bug, but confirms this is a slightly surprising edge case), and we ended up doing some bytecode munging to rewrite back to invokevirtuals for code affected by that.

At this point we've absorbed the breaking change and I personally don't have any concerns with the new behaviour, I'm just sharing that in case you're still weighing the risk of whack-a-mole from keeping JDK-8272564.

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

PR: https://git.openjdk.java.net/jdk/pull/8054