From prr at openjdk.java.net  Mon Nov  2 04:29:10 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 2 Nov 2020 04:29:10 GMT
Subject: RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2
Message-ID: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>

This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library

https://bugs.openjdk.java.net/browse/JDK-8247872

This has passed building and headless and headful automated tests on all platforms.

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

Commit messages:
 - 8247872: Upgrade HarfBuzz to the latest 2.7.2

Changes: https://git.openjdk.java.net/jdk/pull/993/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=993&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247872
  Stats: 44663 lines in 207 files changed: 25198 ins; 12729 del; 6736 mod
  Patch: https://git.openjdk.java.net/jdk/pull/993.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/993/head:pull/993

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

From prr at openjdk.java.net  Mon Nov  2 04:29:10 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 2 Nov 2020 04:29:10 GMT
Subject: RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2
In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
Message-ID: <OPa33GFH_85XnA889rHqUsfBgJwoFk7uIEpmP-JIY3k=.fc3712b2-c6c9-4b7a-b0ce-924101cb79eb@github.com>

On Mon, 2 Nov 2020 04:19:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library
> 
> https://bugs.openjdk.java.net/browse/JDK-8247872
> 
> This has passed building and headless and headful automated tests on all platforms.

Aside from the code change there is a small build change is to remove some obsolete defines

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

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

From jlahoda at openjdk.java.net  Mon Nov  2 08:15:21 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 2 Nov 2020 08:15:21 GMT
Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from
 getTypeElement when cross-compiling with --release [v4]
In-Reply-To: <iWe2lgOsak5uDaFjLkz5quSVAL8i_cfVG8TCGh2U55A=.87f0e5cc-54e6-4234-a6bb-2ac9a9f876ab@github.com>
References: <iWe2lgOsak5uDaFjLkz5quSVAL8i_cfVG8TCGh2U55A=.87f0e5cc-54e6-4234-a6bb-2ac9a9f876ab@github.com>
Message-ID: <1dxDS8NcRcAH9S9p038xQo7zA3RVkKrfn6XHqzkXmzg=.76d60e31-96fb-4cee-b6d4-956d76de64e1@github.com>

> Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements across all modules in the module graph, and only return a value when they find exactly one element. This is troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that these unqualified methods would first look for elements visible from the root modules, and would search the internals of other modules only if nothing would be found in the first round.
> 
> The draft of the corresponding CSR is here: https://bugs.openjdk.java.net/browse/JDK-8253168.

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:

 - Merge branch 'master' into JDK-8236842
 - Linking to root and all modules definition.
 - Merge branch 'master' into JDK-8236842
 - Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched.
 - 8253168: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/200/files
  - new: https://git.openjdk.java.net/jdk/pull/200/files/33ca56ed..fa0e316a

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

  Stats: 462759 lines in 4438 files changed: 385829 ins; 55838 del; 21092 mod
  Patch: https://git.openjdk.java.net/jdk/pull/200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/200/head:pull/200

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

From jlahoda at openjdk.java.net  Mon Nov  2 10:22:02 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 2 Nov 2020 10:22:02 GMT
Subject: Integrated: 8236842: Surprising 'multiple elements' behaviour from
 getTypeElement when cross-compiling with --release
In-Reply-To: <iWe2lgOsak5uDaFjLkz5quSVAL8i_cfVG8TCGh2U55A=.87f0e5cc-54e6-4234-a6bb-2ac9a9f876ab@github.com>
References: <iWe2lgOsak5uDaFjLkz5quSVAL8i_cfVG8TCGh2U55A=.87f0e5cc-54e6-4234-a6bb-2ac9a9f876ab@github.com>
Message-ID: <on9ttvHk0x0erzBu9p1OV9cQdLi7yTBQLNoHJWyhEK0=.1bfeb816-c1e9-4835-a3a2-e4a93280bb02@github.com>

On Wed, 16 Sep 2020 07:57:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements across all modules in the module graph, and only return a value when they find exactly one element. This is troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that these unqualified methods would first look for elements visible from the root modules, and would search the internals of other modules only if nothing would be found in the first round.
> 
> The draft of the corresponding CSR is here: https://bugs.openjdk.java.net/browse/JDK-8253168.

This pull request has now been integrated.

Changeset: d05df7c1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d05df7c1
Stats:     551 lines in 4 files changed: 490 ins; 29 del; 32 mod

8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release

Reviewed-by: vromero

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

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

From ihse at openjdk.java.net  Mon Nov  2 12:35:56 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 2 Nov 2020 12:35:56 GMT
Subject: RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2
In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
Message-ID: <bQiz-WqX7VWlhn2jRNzAhn8qA7IAAhHGJviuJtfFa_8=.c1a75e8c-1b70-4984-af12-13d08488022f@github.com>

On Mon, 2 Nov 2020 04:19:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library
> 
> https://bugs.openjdk.java.net/browse/JDK-8247872
> 
> This has passed building and headless and headful automated tests on all platforms.

Build changes look good.

I'm just a bit curious about the added, empty, `src/java.desktop/share/native/libharfbuzz/abc.txt`...

If it really is in upstream source, I'm not saying you should remove it. It just looks very odd. It's not a merge artifact?

(I could not even add review comments to an empty file in github!  ??)

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

Marked as reviewed by ihse (Reviewer).

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

From jjg at openjdk.java.net  Mon Nov  2 17:52:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 17:52:56 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <DrJrH40To0Fq7TDeDV6ni9sik4WVsH-5pk6zcBUkR3A=.4f2bdac5-7269-40d5-9ad2-e997e281f21a@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
 <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>
 <DrJrH40To0Fq7TDeDV6ni9sik4WVsH-5pk6zcBUkR3A=.4f2bdac5-7269-40d5-9ad2-e997e281f21a@github.com>
Message-ID: <0nw1ywk_bFqAUlU9DuC_79QXVgx63FEsf3Jwt_Y187M=.1164173f-b6d5-4f20-bc66-f722ebb0be08@github.com>

On Thu, 29 Oct 2020 09:43:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I don't think there should be much interaction with -source <older-version>. We don't support preview features from previous version or preview class files from previous versions, so I think it should be enough to handle the currently present preview features.
>
> We don't support preview features from previous releases, AFAIK. So javadoc for JDK 16 should not accept e.g. record class when running with  -source 15.

Yeah, my recollection is that I was wondering whether preview-related code needs to be "guarded" to only work in the current release. But, I guess we may get the right effect (of forbidding preview features in older code) from the javac front end, so that in javadoc we can be assured that there are no instances of what may still be preview features in older code (i.e with older --source/--rlease options)

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

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

From jjg at openjdk.java.net  Mon Nov  2 17:52:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 17:52:56 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <R2KYb4nzD1FZrz1hP4dXxn6a16GAAHCjlglZ6V6U45I=.b421488e-2f19-4511-8a71-c52f18dfe740@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
 <R2KYb4nzD1FZrz1hP4dXxn6a16GAAHCjlglZ6V6U45I=.b421488e-2f19-4511-8a71-c52f18dfe740@github.com>
Message-ID: <bnNujCWoLYgdYrY_DE7HbPU31mxMVErp49NoXt-aRp8=.dd9add9c-ee0b-40a4-975b-65f8b39d1ba2@github.com>

On Thu, 29 Oct 2020 09:26:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java line 1288:
>> 
>>> 1286:                 case FIELD: case INSTANCE_INIT: case LOCAL_VARIABLE: case PARAMETER:
>>> 1287:                 case RESOURCE_VARIABLE: case STATIC_INIT: case TYPE_PARAMETER:
>>> 1288:                 case RECORD_COMPONENT:
>> 
>> I'm not saying this is wrong, but I'd like to understand why it is necessary.
>
> HtmlDocletWriter.getPreviewNotes analyzes classes and their members, to see if some are using aspects that are under preview. When looking at the members, it uses utils.isIncluded on the member, and that eventually gets here. And if the member is a RECORD_COMPONENT, it would fail here. But we can avoid asking for RECORD_COMPONENTS, if needed.

ok

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

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

From jlahoda at openjdk.java.net  Mon Nov  2 18:15:09 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 2 Nov 2020 18:15:09 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

 - Removing trailing whitespace.
 - Merging master into JDK-8250768.
 - Updating tests after records are a final feature.
 - Fixing tests.
 - Finalizing removal of record preview hooks.
 - Merging master into JDK-8250768
 - Reflecting review comments.
 - Merge branch 'master' into JDK-8250768
 - Removing unnecessary cast.
 - Using a more correct way to get URLs.
 - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=05
  Stats: 3012 lines in 142 files changed: 2521 ins; 260 del; 231 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From jjg at openjdk.java.net  Mon Nov  2 20:25:10 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 20:25:10 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
Message-ID: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>

On Mon, 2 Nov 2020 18:15:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Removing trailing whitespace.
>  - Merging master into JDK-8250768.
>  - Updating tests after records are a final feature.
>  - Fixing tests.
>  - Finalizing removal of record preview hooks.
>  - Merging master into JDK-8250768
>  - Reflecting review comments.
>  - Merge branch 'master' into JDK-8250768
>  - Removing unnecessary cast.
>  - Using a more correct way to get URLs.
>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900

I have read all the files. 

I have added a n umber of various minor non-blocking comments (no need for re-review( to fix these.  But I have a couple of comments/questions before finally giving approval.
There's a comment in `PreviewListWriter` about annotation members that needs too be addressed, and I wonder is RECORD and RECORD_COMPONENT need to be added into PreviewElementKind.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 75:

> 73:          * A key for testing.
> 74:          */
> 75:         TEST,

Slightly weird

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java line 257:

> 255:             //when patching modules (esp. java.base), it may be impossible to
> 256:             //clear the symbols read from the patch path:
> 257:             polluted |= get(JavaFileManager.class).hasLocation(StandardLocation.PATCH_MODULE_PATH);

OK, but looks unrelated to primary work

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

> 216:         return Errors.PreviewFeatureDisabledClassfile(classfile, majorVersionToSource.get(majorVersion).name);
> 217:     }
> 218: 

Up above in isPreview, lines 185-188, I'm supervised it's not a `switch` statement.  (Can't annotate those lines directly)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 89:

> 87:     @Override
> 88:     protected Content getDeprecatedOrPreviewLink(Element member) {
> 89:         Content content = new ContentBuilder();

Yeah the shorter name is good here and more in keeping with the code style

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 93:

> 91:         if (!utils.isConstructor(member)) {
> 92:             content.add(".");
> 93:             content.add(member.getSimpleName());

this is OK, but generally FYI, `Content` is now set up to allow chained method calls.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java line 436:

> 434:                 configuration, LinkInfoImpl.Kind.CLASS_USE_HEADER, typeElement)
> 435:                 .label(resources.getText("doclet.Class"))
> 436:                 .skipPreview(true));

@hns General comment, not directly related to this review: is it worth a cleanup to fold the sequence `getLink(new LinkInfoImpl(...))` into a hypothetical new `LinkBuilder` ?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 221:

> 219:         if (modifiers.endsWith(" ")) {
> 220:             pre.add(" ");
> 221:         }

Obligatory ugh that `modifiers` is a string and that it might end with a space. This is a possibility for future cleanup.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 283:

> 281:                 if (isFirst) {
> 282:                     pre.add(DocletConstants.NL);
> 283:                     pre.add("permits");

Note for javadoc-dev folk: we should have a better  more consistent way of handling keywords

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java line 254:

> 252:             contentTree.add(section);
> 253:         }
> 254: 

??

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java line 145:

> 143:     // which performs a somewhat similar role
> 144:     public enum ConditionalPage {
> 145:         CONSTANT_VALUES, DEPRECATED, PREVIEW, SERIALIZED_FORM, SYSTEM_PROPERTIES

??

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java line 120:

> 118:                                 title,
> 119:                                 classLinkInfo.target));
> 120:                         if (flags.contains(ElementFlag.PREVIEW)) {

I see a lot of `new HtmlTree(TagName.SUP).add(...)` ... enough to warrant a new factory method ``HtmlTree.SUP(Content)` or similar.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java line 39:

> 37: import jdk.javadoc.internal.doclets.formats.html.markup.HtmlStyle;
> 38: import jdk.javadoc.internal.doclets.formats.html.markup.HtmlTree;
> 39: import jdk.javadoc.internal.doclets.formats.html.markup.RawHtml;

Are these imports still required?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java line 40:

> 38: 
> 39: import com.sun.source.doctree.DocTree;
> 40: import javax.lang.model.element.ElementKind;

unordered imports

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java line 223:

> 221:                 case CONSTRUCTOR -> new ConstructorWriterImpl(this);
> 222:                 case ENUM_CONSTANT -> new EnumConstantWriterImpl(this);
> 223:                 case ANNOTATION_TYPE_MEMBER -> new AnnotationTypeOptionalMemberWriterImpl(this, null);

Hmmm. Not sure about this one. For better or worse, javadoc current handles optional and required members differently (i.e. with different classes). That's arguably something that should be cleaned up at some point, but in the meantime, I'm surprised to not see the distinction here.  I guess if we're not likely to see an interaction between preview-ness and annotation-members, this will not likely show up in practice.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java line 67:

> 65: public class PreviewListWriter extends SubWriterHolderWriter {
> 66: 
> 67:     private String getAnchorName(PreviewElementKind kind) {

1. I'm mildly surprised to not see anything record-related here. 
2. I'm mildly surprised you haven't used the new switch-expression syntax.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 67:

> 65:         ENUM_CONSTANT,
> 66:         ANNOTATION_TYPE_MEMBER // no ElementKind mapping
> 67:     };

Should there be RECORD and RECORD_COMPONENT in this list?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 932:

> 930:         switch (tagName) {
> 931:             case A: case BUTTON: case BR: case CODE: case EM: case I: case IMG:
> 932:             case LABEL: case SMALL: case SPAN: case STRONG: case SUB: case SUP:

See comment elsewhere about possibly adding a factory method for `SUP` trees.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 290:

> 288: doclet.Declared_Using_Preview.SEALED_PERMITS=Sealed Classes
> 289: doclet.PreviewPlatformLeadingNote={0} is a preview API of the Java platform.
> 290: doclet.ReflectivePreviewPlatformLeadingNote={0} is a reflective preview API of the Java platform.

Question: is the following "inconsistency" deliberate:
1. Java platform
2. Java language
3. Java SE (in javac diagnostics)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/FieldWriter.java line 75:

> 73: 
> 74:     /**
> 75:      * Add the preview output for the given member.

(minor) Should be "Adds"

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MethodWriter.java line 75:

> 73: 
> 74:     /**
> 75:      * Add the preview output for the given member.

(minor) should be "Adds"

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java line 156:

> 154:         buildSignature(annotationDocTree);
> 155:         buildDeprecationInfo(annotationDocTree);
> 156:         buildPreviewInfo(annotationDocTree);

(Just checking) I presume this behavior is inherited into `AnnotationTypeOptionalMemberBuilder` so no changes required there.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java line 166:

> 164:         writer.addPreview(currentElement, enumConstantsTree);
> 165:     }
> 166: 

Note to self: I regret that this duplication of adding this method everywhere seems to be necessary. This would be good to clean up at some point.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 213:

> 211: doclet.Preview=Preview.
> 212: doclet.Properties=Properties
> 213: doclet.constructors=constructors

Is the period after `Preview` intentional? It seems inconsistent.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Comparators.java line 131:

> 129:     /**
> 130:      * Returns a Comparator for deprecated items listed on deprecated list page, by comparing the
> 131:      * fully qualified names, and if those are equal the names of the enclosing modules.

Comment does not match method name

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 132:

> 130: import static com.sun.source.doctree.DocTree.Kind.*;
> 131: import javax.lang.model.AnnotatedConstruct;
> 132: import javax.lang.model.util.SimpleAnnotationValueVisitor14;

unordered imports

test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java line 75:

> 73:                                       </div>""";
> 74:             String expected = MessageFormat.format(expectedTemplate, zero, one, two, three);
> 75:             checkOutput("m/pkg/TestPreviewDeclaration.html", true, expected);

Interesting technique...

Future: it might be interesting to consider folding the bundle access on line 59 into a utility call in JavadocTester

test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java line 28:

> 26: import jdk.internal.javac.PreviewFeature.Feature;
> 27: 
> 28: @PreviewFeature(feature=Feature.TEST)

Yeah, I remember `Feature.TEST` from earlier.  I guess it's OK for now, as a workaround for a testing a feature which is inherently, by design, a moving target across releases. 

These days, javadoc tests are trending towards generating small sample test programs, instead of having small static side-files dominated  by a legal header. I wonder if there is a possibility of  having a "generator class" in the `javadoc.tester` package that can generate sample code using one or more of the current set of preview features, as a way of reducing the need for the TEST feature.

test/langtools/tools/javac/patterns/BindingsTest2.out line 54:

> 52: - compiler.note.preview.filename: BindingsTest2.java, DEFAULT
> 53: - compiler.note.preview.recompile
> 54: 51 errors

(issue unrelated to review)  it seems wrong that we encourage/allow the use of files that do not end in newline.

test/langtools/tools/javac/preview/PreviewAutoSuppress.java line 25:

> 23: 
> 24: /*
> 25:  * @test

no `@bug`?

test/langtools/tools/javac/preview/PreviewErrors.java line 38:

> 36:  * @build toolbox.ToolBox toolbox.JavacTask
> 37:  * @build combo.ComboTestHelper
> 38:  * @compile PreviewErrors.java

do you need `@compile` here: is `@build` not good enough?

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

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

From jjg at openjdk.java.net  Mon Nov  2 20:25:12 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 20:25:12 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <5xE8fziHH9n04bSHhODnOB9On3t_zGz-JY0gJhVhP74=.0c79430f-fac0-44f9-82be-40ef2f94a0d9@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <5xE8fziHH9n04bSHhODnOB9On3t_zGz-JY0gJhVhP74=.0c79430f-fac0-44f9-82be-40ef2f94a0d9@github.com>
Message-ID: <8FF_CARupWr7LcKZm5Th7wpIZ-QhNVOM_KytRUOPppE=.bf38fc0c-5c70-4bff-aa50-fe23c772fe2b@github.com>

On Fri, 16 Oct 2020 16:07:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java line 166:
> 
>> 164:             s = "compiler.misc.tree.tag." + StringUtils.toLowerCase(((Tag) arg).name());
>> 165:         } else if (arg instanceof Source && arg == Source.DEFAULT &&
>> 166:                 CODES_NEEDING_SOURCE_NORMALIZATION.contains(diag.getCode())) {
> 
> Nice trick to keep raw output constant across versions :-)

??

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

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

From jjg at openjdk.java.net  Mon Nov  2 20:25:12 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 20:25:12 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
 <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>
Message-ID: <qwHKfUsdnZ8nr_K3-KSb_JXg9odmcou78exxImP7bOE=.25ca0b72-cfb1-4e79-a8f2-c62151b5edbf@github.com>

On Tue, 27 Oct 2020 16:09:45 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 88:
>> 
>>> 86: 
>>> 87:     @Override
>>> 88:     protected Content getDeprecatedOrPreviewLink(Element member) {
>> 
>> This name is a side-effect of the `ElementFlag` question.  We should either use explicit field and method names, or we should use `ElementFlag` more consistently.   This method name works OK for now, but if if ever gets to have another `orFoo` component in the name, the signature should be parameterized with something like `ElementFlag` or its equivalent.
>
> Note this method returns the same link for deprecate or preview - it just was named "getDeprecatedLink", and when using it work preview, I renamed it "getDeprecatedOrPreviewLink". We may need to think of a better name.

This name is OK for now. Maybe we'll have m ore insight into a better name if/when we add a third variant ;-)

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

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

From vromero at openjdk.java.net  Mon Nov  2 21:00:58 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 2 Nov 2020 21:00:58 GMT
Subject: RFR: 8254105: allow static nested declarations [v4]
In-Reply-To: <Rf7Ek-6kxy6nq4T5scWatVRi44yV7hfBBuWRVe01fHk=.1e058f1d-97a9-4572-9fa9-cd0c3c173b41@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
 <AedXvKapJiCW0_ezWaAGUrGDBjBP2qHtwBhFlRqt9LE=.a0042d6f-ce7f-4089-a548-a1a8825a6336@github.com>
 <Rf7Ek-6kxy6nq4T5scWatVRi44yV7hfBBuWRVe01fHk=.1e058f1d-97a9-4572-9fa9-cd0c3c173b41@github.com>
Message-ID: <Bfm6vxGIIBvsm_mnUCk62UjEbkgygvN6ZAPClrrVTrQ=.0963d892-f33a-4c53-a9ec-2c5fe33c73b0@github.com>

On Wed, 28 Oct 2020 18:00:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removing duplicated test
>
> The changes look good, but I have one concern: this patch seem to apply the improvements unconditionally, regardless of the source version - is this what we want? While I understand that the risk is low (this patch makes space of compilable programs bigger), at the same times it feels wrong that when compiling with `--source 14` I can now nest static classes inside member classes (which is not compatible with what the SE 14 spec says).

> As @mcimadamore, I think this should only be allowed for -source 16+, right?

right but the new goodies are only available if records are allowed. The code is behind `allowRecords` which should only be true for source >= 16, shouldn't that be enough?

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

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

From vromero at openjdk.java.net  Tue Nov  3 17:20:58 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 3 Nov 2020 17:20:58 GMT
Subject: RFR: 8254105: allow static nested declarations [v4]
In-Reply-To: <Rf7Ek-6kxy6nq4T5scWatVRi44yV7hfBBuWRVe01fHk=.1e058f1d-97a9-4572-9fa9-cd0c3c173b41@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
 <AedXvKapJiCW0_ezWaAGUrGDBjBP2qHtwBhFlRqt9LE=.a0042d6f-ce7f-4089-a548-a1a8825a6336@github.com>
 <Rf7Ek-6kxy6nq4T5scWatVRi44yV7hfBBuWRVe01fHk=.1e058f1d-97a9-4572-9fa9-cd0c3c173b41@github.com>
Message-ID: <Anrn68oQfj9LMJv51fe-ib_RoDuDWtB860oBjY12Hyk=.11f9242b-0bbf-4e05-b0ac-46fb4c0eb4e7@github.com>

On Wed, 28 Oct 2020 18:00:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removing duplicated test
>
> The changes look good, but I have one concern: this patch seem to apply the improvements unconditionally, regardless of the source version - is this what we want? While I understand that the risk is low (this patch makes space of compilable programs bigger), at the same times it feels wrong that when compiling with `--source 14` I can now nest static classes inside member classes (which is not compatible with what the SE 14 spec says).

> As @mcimadamore, I think this should only be allowed for -source 16+, right?

I agree, I'm working on another iteration to fix the issue, thanks for the comments

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

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

From alex.buckley at oracle.com  Tue Nov  3 18:30:36 2020
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 3 Nov 2020 10:30:36 -0800
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
Message-ID: <78c1d663-f2e3-e805-a05e-f14537f0d2ac@oracle.com>

I saw Jon had a comment about terminology in jdk.javadoc -> 
resources/standard.properties, lines 280-290.

Those lines look good to me. For javadoc's purposes, there are (a) 
preview features of the Java platform which are either (b) preview 
features of the Java language or (c) [reflective] preview APIs [of the 
Java platform]. When we refer to one of the (b) features, it's enough to 
mention "the Java language" and assume that people know the language, 
like the APIs, is a part of the platform.

In theory, it would be right for javadoc output to be specific about 
which release of the Java language/platform defines the preview features 
in question. This is especially true when `javadoc` is run over user 
code (i.e., not JDK code) that happens to use preview language features. 
Referring to a specific release is easier with "Java SE" phrasing than 
"the Java platform" phrasing, which is why jdk.compiler -> 
resources/compiler.properties says "preview features of Java SE {1}". 
All that said, I think the jdk.javadoc -> resources/standard.properties 
file is fine as-is. Anyone running `javadoc` should know which JDK 
release they're getting it from, and anyone reading javadoc output must 
have some sense of the era that the output dates from.

Alex

On 11/2/2020 10:15 AM, Jan Lahoda wrote:
>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>>
>> The notable changes are:
>>
>>   * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>       * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>       * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>   * improving error/warning messages. Please see [1] for a list of cases/examples.
>>   * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>   * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>   * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>   * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>   
>>   Please also see the CSR [6] for more information.
>>   
>>   [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>   [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>   [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>   [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>   [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>   [6] https://bugs.openjdk.java.net/browse/JDK-8250769
> 
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>   - Removing trailing whitespace.
>   - Merging master into JDK-8250768.
>   - Updating tests after records are a final feature.
>   - Fixing tests.
>   - Finalizing removal of record preview hooks.
>   - Merging master into JDK-8250768
>   - Reflecting review comments.
>   - Merge branch 'master' into JDK-8250768
>   - Removing unnecessary cast.
>   - Using a more correct way to get URLs.
>   - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
> 
> -------------
> 
> Changes: https://git.openjdk.java.net/jdk/pull/703/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=05
>    Stats: 3012 lines in 142 files changed: 2521 ins; 260 del; 231 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/703.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703
> 
> PR: https://git.openjdk.java.net/jdk/pull/703
> 

From vromero at openjdk.java.net  Tue Nov  3 19:25:16 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 3 Nov 2020 19:25:16 GMT
Subject: RFR: 8254105: allow static nested declarations [v6]
In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
Message-ID: <Q2PJ720nm_k9B5hooXlLy_F8uOqx4JOPOB4h8MDdow8=.8886ccac-212a-4bfe-acf6-cbd84b2c19d5@github.com>

> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods.
> 
> TIA,
> Vicente
> 
> PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR.

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/571/files
  - new: https://git.openjdk.java.net/jdk/pull/571/files/1b478303..7dfca333

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

  Stats: 488 lines in 25 files changed: 134 ins; 340 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/571.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571

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

From vromero at openjdk.java.net  Tue Nov  3 19:25:17 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 3 Nov 2020 19:25:17 GMT
Subject: RFR: 8254105: allow static nested declarations [v4]
In-Reply-To: <Anrn68oQfj9LMJv51fe-ib_RoDuDWtB860oBjY12Hyk=.11f9242b-0bbf-4e05-b0ac-46fb4c0eb4e7@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
 <AedXvKapJiCW0_ezWaAGUrGDBjBP2qHtwBhFlRqt9LE=.a0042d6f-ce7f-4089-a548-a1a8825a6336@github.com>
 <Rf7Ek-6kxy6nq4T5scWatVRi44yV7hfBBuWRVe01fHk=.1e058f1d-97a9-4572-9fa9-cd0c3c173b41@github.com>
 <Anrn68oQfj9LMJv51fe-ib_RoDuDWtB860oBjY12Hyk=.11f9242b-0bbf-4e05-b0ac-46fb4c0eb4e7@github.com>
Message-ID: <NJqTi5YC0hNaEbH74KwklQki-paxRBMOuVOyDG77owE=.5f95ce43-070f-471a-ac26-950f530af60c@github.com>

On Tue, 3 Nov 2020 17:18:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> The changes look good, but I have one concern: this patch seem to apply the improvements unconditionally, regardless of the source version - is this what we want? While I understand that the risk is low (this patch makes space of compilable programs bigger), at the same times it feels wrong that when compiling with `--source 14` I can now nest static classes inside member classes (which is not compatible with what the SE 14 spec says).
>
>> As @mcimadamore, I think this should only be allowed for -source 16+, right?
> 
> I agree, I'm working on another iteration to fix the issue, thanks for the comments

I have pushed a commit addressing the review comments so far. I have re-added code in Attr but this time behind a guard checking if records are allowed in the current source and I have added back some tests I removed before. The tests are now executed with current source and with source 15. Thanks for the comments so far.

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

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

From jjg at openjdk.java.net  Wed Nov  4 00:50:55 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 4 Nov 2020 00:50:55 GMT
Subject: RFR: 8253385: annotation processors remove varargs information
 from record components
In-Reply-To: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
References: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
Message-ID: <Jctpv0K_zpOBL1QtRNh-G1hr5Knbj7x_cOLeyewXhKs=.9f39f9b3-b432-4b46-b4ea-ccd6d78f8a43@github.com>

On Fri, 16 Oct 2020 19:50:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix for a corner case bug. Essentially for code like:
> 
> import java.lang.annotation.*;
> 
> @Target({ElementType.TYPE_USE})
> @interface Simple {}
> 
> record R(@Simple int ...val) {
>     static void test() {
>         R rec = new R(10, 20);
>     }
> }
> 
> assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed.
> 
> TIA,
> Vicente

minor suggestions in comments

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

> 1786:         private final int pos;
> 1787: 
> 1788:         private boolean isVarargs;

field can be final?

test/langtools/tools/javac/records/RecordCompilationTests.java line 1694:

> 1692:                 @interface Simple {}
> 1693: 
> 1694:                 record R(@Simple int ...val) {

(minor) unusual typography for "int ...val". Suggest "int... val"

test/langtools/tools/javac/records/RecordCompilationTests.java line 1712:

> 1710:                 @interface Simple {}
> 1711: 
> 1712:                 record R(@Simple int ...val) {

(minor) unusual typography for "int ...val". Suggest "int... val"

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

Marked as reviewed by jjg (Reviewer).

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

From jlahoda at openjdk.java.net  Wed Nov  4 10:35:02 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 10:35:02 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <IijcUDOf-xzQhzimXQT8c7pe7AfuWn2Stirsv-KzC3Y=.c6050a44-bb8b-4ced-8f2d-1c1938c4a100@github.com>

On Mon, 2 Nov 2020 18:39:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java line 257:
> 
>> 255:             //when patching modules (esp. java.base), it may be impossible to
>> 256:             //clear the symbols read from the patch path:
>> 257:             polluted |= get(JavaFileManager.class).hasLocation(StandardLocation.PATCH_MODULE_PATH);
> 
> OK, but looks unrelated to primary work

The tests need to inject preview APIs into compilation, and without this tweak, the incorrect values are re-used for tests that use the javac pool. So it is related in the sense it is needed for the tests to pass.

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

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

From jlahoda at openjdk.java.net  Wed Nov  4 10:42:59 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 10:42:59 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <MkZSP-dnn9axp0s9fBfgTNKxR5Tpqo4IThFsFK4Pfqo=.f8962940-e5a9-40bf-a31a-608104ecae58@github.com>

On Mon, 2 Nov 2020 19:37:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java line 156:
> 
>> 154:         buildSignature(annotationDocTree);
>> 155:         buildDeprecationInfo(annotationDocTree);
>> 156:         buildPreviewInfo(annotationDocTree);
> 
> (Just checking) I presume this behavior is inherited into `AnnotationTypeOptionalMemberBuilder` so no changes required there.

Right, I think so.

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

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

From jlahoda at openjdk.java.net  Wed Nov  4 10:59:02 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 10:59:02 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <mzKNqA7xgHu-19kTap5m6RMUdXP85yPcERtjXSklSac=.11faf90c-5b79-4ce5-9ec7-673f3e335a9e@github.com>

On Mon, 2 Nov 2020 19:41:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 213:
> 
>> 211: doclet.Preview=Preview.
>> 212: doclet.Properties=Properties
>> 213: doclet.constructors=constructors
> 
> Is the period after `Preview` intentional? It seems inconsistent.

This is consistent with doclet.Deprecated key a few lines up. In the javadoc it then says something along these lines:
Preview.
A binding pattern tree

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

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

From jlahoda at openjdk.java.net  Wed Nov  4 11:04:04 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 11:04:04 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <BeSJxg7MFuEnGoXMsNJ6K6jpbPZZkQ-17xETBtCA42o=.21065724-decf-46a6-9463-2f61cccaf30c@github.com>

On Mon, 2 Nov 2020 19:59:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java line 28:
> 
>> 26: import jdk.internal.javac.PreviewFeature.Feature;
>> 27: 
>> 28: @PreviewFeature(feature=Feature.TEST)
> 
> Yeah, I remember `Feature.TEST` from earlier.  I guess it's OK for now, as a workaround for a testing a feature which is inherently, by design, a moving target across releases. 
> 
> These days, javadoc tests are trending towards generating small sample test programs, instead of having small static side-files dominated  by a legal header. I wonder if there is a possibility of  having a "generator class" in the `javadoc.tester` package that can generate sample code using one or more of the current set of preview features, as a way of reducing the need for the TEST feature.

I have intentionally added Feature.TEST to improve testability. Before, tests were using one of the constants (typically whatever was the first constant), but that seems somewhat problematic - what if (at some point, transiently) we have no preview features?

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

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

From jlahoda at openjdk.java.net  Wed Nov  4 13:29:10 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 13:29:10 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v6]
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <tHakK_zRnsUlnZscY1TJuS_ZrzuHs15ver2nRZD9tRY=.c137a9eb-d0e4-4586-8c69-88773a28e2a7@github.com>

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

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:

 - Merge branch 'master' into patterns-instanceof3
 - Merging master into patterns-instanceof3
 - Removing the preview deprecated methods from BindingPatternTree.
 - Merge branch 'master' into patterns-instanceof3
 - Fixing review comments.
 - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
 - Merge branch 'master' into patterns-instanceof3
 - Fixing more tests.
 - Correcting positions.
 - Improve the AST model.
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/7f4d873d...325f96ad

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

Changes: https://git.openjdk.java.net/jdk/pull/559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=05
  Stats: 651 lines in 90 files changed: 228 ins; 310 del; 113 mod
  Patch: https://git.openjdk.java.net/jdk/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559

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

From hannesw at openjdk.java.net  Wed Nov  4 15:53:59 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 4 Nov 2020 15:53:59 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec)
In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
Message-ID: <xdibT6UjI0iPmg9eadoabDffn-hqzx7-prHMFer4YC8=.b3cf6e32-349d-4879-bc06-0bd51b386243@github.com>

On Thu, 22 Oct 2020 02:40:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box.
> 
> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `<a href="url">label</a>` in the generated docs.
> 
> As a block tag, the format is simply
> 
>     @spec url label
> 
> which is handled in a manner analogous to
> 
>     @see <a href="url">label</a>
> 
> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here.
> 
> This change is only the _support_ for the new tag;  it does _not_ include any changes to API docs to _use_ the new tag.

It's very instructive to see a new tag introduced from scratch with all the accompanying infrastructure and tests. The changes looks good to me, but I need to stress than I'm not an expert on some of the affected areas such as the jdk.compiler parts.

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

Marked as reviewed by hannesw (Reviewer).

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

From mcimadamore at openjdk.java.net  Wed Nov  4 16:19:56 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 Nov 2020 16:19:56 GMT
Subject: RFR: 8254105: allow static nested declarations [v6]
In-Reply-To: <Q2PJ720nm_k9B5hooXlLy_F8uOqx4JOPOB4h8MDdow8=.8886ccac-212a-4bfe-acf6-cbd84b2c19d5@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
 <Q2PJ720nm_k9B5hooXlLy_F8uOqx4JOPOB4h8MDdow8=.8886ccac-212a-4bfe-acf6-cbd84b2c19d5@github.com>
Message-ID: <zSQm_fqwwNFv0bTr_zHqOLDCwDj9TGfhFUWyTY69TiU=.99a5e84d-97ed-4929-84b2-98c622b5bb1a@github.com>

On Tue, 3 Nov 2020 19:25:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods.
>> 
>> TIA,
>> Vicente
>> 
>> PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR.
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Changes look good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From vromero at openjdk.java.net  Wed Nov  4 16:33:04 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Nov 2020 16:33:04 GMT
Subject: RFR: 8254105: allow static nested declarations [v6]
In-Reply-To: <zSQm_fqwwNFv0bTr_zHqOLDCwDj9TGfhFUWyTY69TiU=.99a5e84d-97ed-4929-84b2-98c622b5bb1a@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
 <Q2PJ720nm_k9B5hooXlLy_F8uOqx4JOPOB4h8MDdow8=.8886ccac-212a-4bfe-acf6-cbd84b2c19d5@github.com>
 <zSQm_fqwwNFv0bTr_zHqOLDCwDj9TGfhFUWyTY69TiU=.99a5e84d-97ed-4929-84b2-98c622b5bb1a@github.com>
Message-ID: <HsqGRBWQRb5LyvrzclWXmMkIMkSi959G1fPOnw-gd1o=.0c82ede3-5614-4835-a49a-dc29d1e3b250@github.com>

On Wed, 4 Nov 2020 16:17:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Changes look good

thanks!

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

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

From vromero at openjdk.java.net  Wed Nov  4 17:13:07 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Nov 2020 17:13:07 GMT
Subject: RFR: 8253385: annotation processors remove varargs information
 from record components [v2]
In-Reply-To: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
References: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
Message-ID: <MO0ibVGdVFvQjht2E5b5oUQlyo4Y9jIvEzQLML8Dwgw=.97f61f2a-8ebd-4503-b377-6a5cde0c869a@github.com>

> Please review this fix for a corner case bug. Essentially for code like:
> 
> import java.lang.annotation.*;
> 
> @Target({ElementType.TYPE_USE})
> @interface Simple {}
> 
> record R(@Simple int ...val) {
>     static void test() {
>         R rec = new R(10, 20);
>     }
> }
> 
> assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed.
> 
> TIA,
> Vicente

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/709/files
  - new: https://git.openjdk.java.net/jdk/pull/709/files/379ee616..21e26551

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

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

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

From vromero at openjdk.java.net  Wed Nov  4 17:13:08 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Nov 2020 17:13:08 GMT
Subject: RFR: 8253385: annotation processors remove varargs information
 from record components [v2]
In-Reply-To: <Jctpv0K_zpOBL1QtRNh-G1hr5Knbj7x_cOLeyewXhKs=.9f39f9b3-b432-4b46-b4ea-ccd6d78f8a43@github.com>
References: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
 <Jctpv0K_zpOBL1QtRNh-G1hr5Knbj7x_cOLeyewXhKs=.9f39f9b3-b432-4b46-b4ea-ccd6d78f8a43@github.com>
Message-ID: <cJWmHVQkdgdAKxklPY5UUWrTfxgG0zprjGxCg4Ki39c=.c850616c-0b7a-4316-8a1a-f371d8ea7403@github.com>

On Wed, 4 Nov 2020 00:46:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1788:
> 
>> 1786:         private final int pos;
>> 1787: 
>> 1788:         private boolean isVarargs;
> 
> field can be final?

sure will do

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

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

From vromero at openjdk.java.net  Wed Nov  4 18:21:15 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Nov 2020 18:21:15 GMT
Subject: RFR: 8253385: annotation processors remove varargs information
 from record components [v3]
In-Reply-To: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
References: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
Message-ID: <KhF6tZd1-FUQPYZ7r8f4MtQZVOwZ3SRsTtZxpJlBWl0=.4e47b170-eb8e-42b2-a7e6-e50d6d188449@github.com>

> Please review this fix for a corner case bug. Essentially for code like:
> 
> import java.lang.annotation.*;
> 
> @Target({ElementType.TYPE_USE})
> @interface Simple {}
> 
> record R(@Simple int ...val) {
>     static void test() {
>         R rec = new R(10, 20);
>     }
> }
> 
> assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed.
> 
> TIA,
> Vicente

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

 - Merge branch 'master' into JDK-8253385
 - addressing review comments
 - 8253385: annotation processors remove varargs information from record components

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/709/files
  - new: https://git.openjdk.java.net/jdk/pull/709/files/21e26551..787196a2

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

  Stats: 91449 lines in 1574 files changed: 64459 ins; 19529 del; 7461 mod
  Patch: https://git.openjdk.java.net/jdk/pull/709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/709/head:pull/709

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

From jlahoda at openjdk.java.net  Wed Nov  4 19:36:11 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 19:36:11 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v7]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <wp_qEKajc8aWtWvHtSmytYLeBsrxKzcpHLXE72rP1Q0=.f320f566-3c9c-4a80-9be3-95bbd9d6a29f@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

 - Cleanup - removing unnecessary code.
 - Merging master into JDK-8250768-dev4
 - Reflecting review comments.
 - Removing trailing whitespace.
 - Merging master into JDK-8250768.
 - Updating tests after records are a final feature.
 - Fixing tests.
 - Finalizing removal of record preview hooks.
 - Merging master into JDK-8250768
 - Reflecting review comments.
 - ... and 39 more: https://git.openjdk.java.net/jdk/compare/7f4d873d...e4b02827

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=06
  Stats: 3719 lines in 148 files changed: 2701 ins; 730 del; 288 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From jlahoda at openjdk.java.net  Wed Nov  4 19:43:06 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 19:43:06 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>

On Mon, 2 Nov 2020 20:21:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> I have read all the files. 
> 
> I have added a n umber of various minor non-blocking comments (no need for re-review( to fix these.  But I have a couple of comments/questions before finally giving approval.
> There's a comment in `PreviewListWriter` about annotation members that needs too be addressed, and I wonder is RECORD and RECORD_COMPONENT need to be added into PreviewElementKind.

Thanks @jonathan-gibbons for your comments! I've tried to update the code based on them, mostly in https://github.com/lahodaj/jdk/commit/743f516c660b577035cdda4510a0bb97937fd9b2 and https://github.com/lahodaj/jdk/commit/e4b02827998fc2e8f19f983aabfb3d720b03d111

A big chunk of the update is generalization of the deprecated and preview list builders and writers into a "summary" list builder and writer. These should also now handle records. For record components, those are a little tricky, as (AFAIK) can't currently have deprecation/preview-ness for them (and hence there is no good way to test any support for record components in these). But the summary build and writer are looking for record components and will fail in case a record component is sent into them.

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

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

From jjg at openjdk.java.net  Wed Nov  4 20:57:06 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 4 Nov 2020 20:57:06 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v2]
In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
Message-ID: <nj16p9kuRLdEcRSAfX6hjkiETqLFM3XJgHzSep950jg=.3b870729-a855-4cae-b510-520d0166ffb3@github.com>

> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box.
> 
> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `<a href="url">label</a>` in the generated docs.
> 
> As a block tag, the format is simply
> 
>     @spec url label
> 
> which is handled in a manner analogous to
> 
>     @see <a href="url">label</a>
> 
> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here.
> 
> This change is only the _support_ for the new tag;  it does _not_ include any changes to API docs to _use_ the new tag.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Fix merge issues; review feedback
 - Merge with master
 - allow rich content in createAnchorAndSearchIndex
 - update Docs.gmk to stop disabling spec tag
 - fix TestSpecTag.testEncodedURI
 - fix tests
 - remove support to workaround legacy @spec tag
 - Merge remote-tracking branch 'upstream/master' into new-spec-tag
 - fix trailing whitespace in test
 - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51`
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9

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

Changes: https://git.openjdk.java.net/jdk/pull/790/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=790&range=01
  Stats: 1374 lines in 42 files changed: 1337 ins; 14 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/790.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/790/head:pull/790

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

From vromero at openjdk.java.net  Wed Nov  4 23:34:00 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Nov 2020 23:34:00 GMT
Subject: Integrated: 8253385: annotation processors remove varargs information
 from record components
In-Reply-To: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
References: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
Message-ID: <OywxJprvEGkTlouadzMKTb4FEHlpSXKPHYYM8mhGrIs=.d4ae49e4-2195-44af-98fc-d80c1e89d372@github.com>

On Fri, 16 Oct 2020 19:50:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix for a corner case bug. Essentially for code like:
> 
> import java.lang.annotation.*;
> 
> @Target({ElementType.TYPE_USE})
> @interface Simple {}
> 
> record R(@Simple int ...val) {
>     static void test() {
>         R rec = new R(10, 20);
>     }
> }
> 
> assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed.
> 
> TIA,
> Vicente

This pull request has now been integrated.

Changeset: 97a81cee
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/97a81cee
Stats:     44 lines in 2 files changed: 43 ins; 0 del; 1 mod

8253385: annotation processors remove varargs information from record components

Reviewed-by: jjg

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

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

From jlahoda at openjdk.java.net  Thu Nov  5 08:04:55 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 08:04:55 GMT
Subject: Integrated: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final)
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <nUkL9iXeuEGYEAKGy577xnEBf2E5G4nWx0RYA4j2m2s=.6a49113e-86ed-44d9-b115-fd47689abc71@github.com>

On Thu, 8 Oct 2020 11:49:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

This pull request has now been integrated.

Changeset: 18bc95ba
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18bc95ba
Stats:     651 lines in 90 files changed: 228 ins; 310 del; 113 mod

8250625: Compiler implementation of Pattern Matching for instanceof (Final)

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Thu Nov  5 09:31:20 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 09:31:20 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v8]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <y-trIOfLEVK-lQ45vC5TzEQAaZiBAHhcQ0oPzNox4kY=.47a73ac3-67a7-4024-a2fa-2bff9bbccb75@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

 - Merging master into JDK-8250768
 - Removing unnecessary property keys.
 - Cleanup - removing unnecessary code.
 - Merging master into JDK-8250768-dev4
 - Reflecting review comments.
 - Removing trailing whitespace.
 - Merging master into JDK-8250768.
 - Updating tests after records are a final feature.
 - Fixing tests.
 - Finalizing removal of record preview hooks.
 - ... and 41 more: https://git.openjdk.java.net/jdk/compare/700447f7...3d55f909

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=07
  Stats: 3665 lines in 136 files changed: 2701 ins; 692 del; 272 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From jlahoda at openjdk.java.net  Thu Nov  5 09:51:13 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 09:51:13 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v9]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <hLYgh37_nCbIVUDXUIl1LsiyNyD1Z9nmsLWguYFdtWA=.ff11a8ad-9271-4750-b47d-b1ae3fd3a379@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

  Removing obsolette @PreviewFeature.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/3d55f909..370031f0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=07-08

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

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

From jlahoda at openjdk.java.net  Thu Nov  5 11:08:18 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 11:08:18 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v10]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <0RHAqKvLjL4Y2yvmClOLoPrcEfdYyWid4BR-ntTWQ78=.e91baacb-444b-4cd1-89d1-8cb26f3de56f@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

  Fixing typo.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/370031f0..097ae3c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=08-09

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

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

From jlahoda at openjdk.java.net  Thu Nov  5 12:45:56 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 12:45:56 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
Message-ID: <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>

On Wed, 4 Nov 2020 19:40:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I have read all the files. 
>> 
>> I have added a n umber of various minor non-blocking comments (no need for re-review( to fix these.  But I have a couple of comments/questions before finally giving approval.
>> There's a comment in `PreviewListWriter` about annotation members that needs too be addressed, and I wonder is RECORD and RECORD_COMPONENT need to be added into PreviewElementKind.
>
> Thanks @jonathan-gibbons for your comments! I've tried to update the code based on them, mostly in https://github.com/lahodaj/jdk/commit/743f516c660b577035cdda4510a0bb97937fd9b2 and https://github.com/lahodaj/jdk/commit/e4b02827998fc2e8f19f983aabfb3d720b03d111
> 
> A big chunk of the update is generalization of the deprecated and preview list builders and writers into a "summary" list builder and writer. These should also now handle records. For record components, those are a little tricky, as (AFAIK) can't currently have deprecation/preview-ness for them (and hence there is no good way to test any support for record components in these). But the summary build and writer are looking for record components and will fail in case a record component is sent into them.

FWIW, a javadoc generated with the current version of the patch:
http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html

And a specdiff comparing it to the javadoc built from the corresponding master:
http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.specdiff.01/overview-summary.html

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

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

From prappo at openjdk.java.net  Thu Nov  5 13:15:59 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 5 Nov 2020 13:15:59 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v2]
In-Reply-To: <nj16p9kuRLdEcRSAfX6hjkiETqLFM3XJgHzSep950jg=.3b870729-a855-4cae-b510-520d0166ffb3@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
 <nj16p9kuRLdEcRSAfX6hjkiETqLFM3XJgHzSep950jg=.3b870729-a855-4cae-b510-520d0166ffb3@github.com>
Message-ID: <MqPZ88mOmrKhnxb7IcT6egjR6D2AYRtZwaU_CjEgcas=.d8fc4e4d-3aed-4887-bcf4-792a36fabc0f@github.com>

On Wed, 4 Nov 2020 20:57:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box.
>> 
>> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `<a href="url">label</a>` in the generated docs.
>> 
>> As a block tag, the format is simply
>> 
>>     @spec url label
>> 
>> which is handled in a manner analogous to
>> 
>>     @see <a href="url">label</a>
>> 
>> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here.
>> 
>> This change is only the _support_ for the new tag;  it does _not_ include any changes to API docs to _use_ the new tag.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fix merge issues; review feedback
>  - Merge with master
>  - allow rich content in createAnchorAndSearchIndex
>  - update Docs.gmk to stop disabling spec tag
>  - fix TestSpecTag.testEncodedURI
>  - fix tests
>  - remove support to workaround legacy @spec tag
>  - Merge remote-tracking branch 'upstream/master' into new-spec-tag
>  - fix trailing whitespace in test
>  - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51`
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9

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

> 307:      * Creates a new {@code SpecTree} object, to represent a {@code @spec} tag.
> 308:      *
> 309:      * @param inline whether this is instance is an inline tag

Should be: 
`* @param inline whether this instance is an inline tag`

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

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

From vromero at openjdk.java.net  Thu Nov  5 14:09:58 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 5 Nov 2020 14:09:58 GMT
Subject: RFR: 8253385: annotation processors remove varargs information
 from record components [v3]
In-Reply-To: <Jctpv0K_zpOBL1QtRNh-G1hr5Knbj7x_cOLeyewXhKs=.9f39f9b3-b432-4b46-b4ea-ccd6d78f8a43@github.com>
References: <qk9bgT9MV3udK3XoFhpIz_zdouzmZE39nHZlH1h5KbQ=.d8e56e5e-dcff-4a08-af9d-ed52648b11ce@github.com>
 <Jctpv0K_zpOBL1QtRNh-G1hr5Knbj7x_cOLeyewXhKs=.9f39f9b3-b432-4b46-b4ea-ccd6d78f8a43@github.com>
Message-ID: <R9Du5YpjYTi7pKYOlkDeOWSwQLdhOzU8beAE9Y4PdtU=.9d8457cc-c6db-4d18-8095-dcb41f226c04@github.com>

On Wed, 4 Nov 2020 00:48:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8253385
>>  - addressing review comments
>>  - 8253385: annotation processors remove varargs information from record components
>
> minor suggestions in comments

thanks for the review

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

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

From vicente.romero at oracle.com  Thu Nov  5 14:32:44 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 5 Nov 2020 09:32:44 -0500
Subject: RFR: JDK-8254784: javac should reject records with @SafeVarargs
 applied to varargs record component
Message-ID: <2da3a4bb-e4c9-28a8-831c-064738a9f808@oracle.com>

Hi,

Just a kind reminder, please review [1],

Thanks,
Vicente

[1] https://github.com/openjdk/jdk/pull/690

From prappo at openjdk.java.net  Thu Nov  5 16:19:59 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 5 Nov 2020 16:19:59 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v2]
In-Reply-To: <nj16p9kuRLdEcRSAfX6hjkiETqLFM3XJgHzSep950jg=.3b870729-a855-4cae-b510-520d0166ffb3@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
 <nj16p9kuRLdEcRSAfX6hjkiETqLFM3XJgHzSep950jg=.3b870729-a855-4cae-b510-520d0166ffb3@github.com>
Message-ID: <GEwkDW5Hm6vl7P3oQXO80jukkmydlyx4v4rXba7-f3E=.36cc3952-8017-46dc-bfd3-177bcbabe960@github.com>

On Wed, 4 Nov 2020 20:57:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box.
>> 
>> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `<a href="url">label</a>` in the generated docs.
>> 
>> As a block tag, the format is simply
>> 
>>     @spec url label
>> 
>> which is handled in a manner analogous to
>> 
>>     @see <a href="url">label</a>
>> 
>> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here.
>> 
>> This change is only the _support_ for the new tag;  it does _not_ include any changes to API docs to _use_ the new tag.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fix merge issues; review feedback
>  - Merge with master
>  - allow rich content in createAnchorAndSearchIndex
>  - update Docs.gmk to stop disabling spec tag
>  - fix TestSpecTag.testEncodedURI
>  - fix tests
>  - remove support to workaround legacy @spec tag
>  - Merge remote-tracking branch 'upstream/master' into new-spec-tag
>  - fix trailing whitespace in test
>  - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51`
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9

1. Thanks for incorporating my previous offline feedback.
2. Since Hannes and Erik seem to have looked at everything else, I looked mostly at changes in `src/jdk.compiler/share/classes/com/sun/source/**`, which are good!
3. There should be a corresponding but separate change to "Documentation Comment Specification for the Standard Doclet".
4. Can we use this new `@since` tag to refer to the spec at `com/sun/tools/javac/parser/DocCommentParser.java:1116`?
5. Should we specify in `com.sun.source.doctree.SpecTree` that both `url` and `label` parts are mandatory?
6. `DCSpec extends DCEndPosTree`, sigh... Although that is not a public API, this design suggests we could improve that abstraction sometime later.

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

> 1102: 
> 1103:         DCTree parse(int pos, Kind kind) throws ParseException {
> 1104:             if (kind != this.kind && this.kind != Kind.EITHER) {

This condition looks right, but shouldn't we add another one to guard against accidental passing of `kind == EITHER`?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 306:

> 304:      * The {@code ref} argument will be URL-encoded for use as the attribute value.
> 305:      *
> 306:      * @param ref the value for the {@code href} attribute}

Since you are here, could you please remove that trailing `}`?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 322:

> 320:      * {@link URI#toASCIIString() converted} to ASCII for use as the attribute value.
> 321:      *
> 322:      * @param ref the value for the {@code href} attribute}

One more, perhaps copy-pasted, trailing `}`.

test/langtools/tools/javac/diags/examples/NoLabel.java line 2:

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

Should be:
`Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 266:

> 264:     }
> 265: 
> 266:     String textOf(List<? extends DocTree> trees) {

I wonder if this method should work **recursively** rather than shallowly. Consider the following example:
@spec http://example.com Some code: {@code text}
I reckon we'll end up with only `Some code: `.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 81:

> 79:         return list.stream().allMatch(DCTree::isBlank);
> 80:     }
> 81: 

Adding these two methods **here** might be overkill.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java line 737:

> 735: 
> 736:         for (Taglet t : taglets) {
> 737:             String name = t.isBlockTag() ? "@" + t.getName() : "{@" + t.getName() + "}";

Out of curiosity, why did you flip that?

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

Changes requested by prappo (Reviewer).

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

From vromero at openjdk.java.net  Thu Nov  5 17:13:12 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 5 Nov 2020 17:13:12 GMT
Subject: RFR: 8254784: javac should reject records with @SafeVarargs
 applied to varargs record component [v2]
In-Reply-To: <qsYgkP7DYZbKKoKw2FCJrTtakM_m92eFFKb8a7DVozU=.bcc1c680-743c-438a-aa80-a93869c0e68e@github.com>
References: <qsYgkP7DYZbKKoKw2FCJrTtakM_m92eFFKb8a7DVozU=.bcc1c680-743c-438a-aa80-a93869c0e68e@github.com>
Message-ID: <g9iHAAuzadirk9gB3weLo97NRi0i2u2gsIGaywdWn1c=.b6155edc-c669-4934-a81a-8f7913163cbc@github.com>

> Please review this fix for issue [1]. This is the background, for a record defined like:
> 
> record R(@SafeVarargs String... s) {}
> 
> an the following accessor will be generated:
> 
>     `@SafeVararags public String[] s() { return s; }`
> 
> this code is incorrect as the accessor is not a varargs method. But still the compiler is not generating a compiler error. The reason for this is that the method defining the accessor is not generated until the compiler get to its backend phase (at Lower to be more specific) and the check for incorrect @SafeVarargs use in the compiler happen before that, in Attr.
> 
> We decided to do not generate record related code until late phases in order to avoid generating code in the compiler frontend and because if code is generated in early stages then APs could see ASTs not created from user defined code. 
> 
> The proposed fix is to issue an error as soon as the compiler finds out that the @SafeVarargs annotation is applied to a compiler generated accessor because in other case the compiler would be forced to generate incorrect code.
> 
> TIA for the reviews,
> Vicente
> 
> [1] [https://bugs.openjdk.java.net/browse/JDK-8254784](https://bugs.openjdk.java.net/browse/JDK-8254784)

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

 - manual merge with master
 - 8254784: javac should reject records with @SafeVarargs applied to varargs record component

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

Changes: https://git.openjdk.java.net/jdk/pull/690/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=690&range=01
  Stats: 62 lines in 4 files changed: 58 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/690.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/690/head:pull/690

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

From alex.buckley at oracle.com  Thu Nov  5 18:11:00 2020
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 5 Nov 2020 10:11:00 -0800
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
 <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
Message-ID: <a3e944fd-0344-a1a0-3597-34e80ccf045a@oracle.com>

On 11/5/2020 4:45 AM, Jan Lahoda wrote:
> FWIW, a javadoc generated with the current version of the patch:
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html

Allow me to draw people's attention to the PREVIEW link in the banner of 
the generated javadoc. It shows all the preview APIs in the release on 
one page. This is very helpful for understanding the surface area of a 
preview feature.

For example, with Sealed Classes being the only preview feature likely 
to target JDK 16, the PREVIEW page shows that the feature's API is 
solely about reflection. It's clear that Sealed Classes do not 
introduce, say, a java.lang.Sealed class analogous to the 
java.lang.Record class introduced by Records in JDK 14/15 (and which 
would have appeared on the PREVIEW page had it existed then).

Alex

From vromero at openjdk.java.net  Thu Nov  5 21:37:02 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 5 Nov 2020 21:37:02 GMT
Subject: RFR: 8255561: add tests to check binary compatibility rules for
 records
Message-ID: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>

Hi all,

Please review this change. It is providing compatibility tests for records in particular section: (13.4.27 Evolution of Record Classes)[http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27].

Thanks,
Vicente

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

Commit messages:
 - minor edit
 - Merge branch 'master' into JDK-8255561
 - 8255561: add tests to check binary compatibility rules for records

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

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

From jjg at openjdk.java.net  Thu Nov  5 22:14:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Nov 2020 22:14:02 GMT
Subject: RFR: 8255561: add tests to check binary compatibility rules for
 records
In-Reply-To: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
References: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
Message-ID: <HSn5c1MgogJ5_ABT0xL9bnknDaCfjNUGqoZG_3IK7OU=.f419f637-2745-4af7-9118-b3a9c5ace2ed@github.com>

On Thu, 5 Nov 2020 18:55:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi all,
> 
> Please review this change. It is providing compatibility tests for records. The tests are covering the assertions at section: [13.4.27 Evolution of Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27).
> 
> Thanks,
> Vicente

A coupe of suggestions, one more significant that the other

test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 277:

> 275: 
> 276:         // let's first check that it runs wo issues
> 277:         if (!output.contains("0")) {

This is a very weak test that may easily fail for the wrong reasons.  Can you make the reference value more distinctive, like 12345, or "Hello World" that could never appear accidentally

test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 251:

> 249:             String clientCode,
> 250:             boolean shouldFail,
> 251:             String expectedError) throws Exception {

Since the expected error always seems to be the name of a class, you could make the type of the parameter be `Class<?>` and then pass class literals as arguments. Inside the method, you get use `getName()` to get the name you expect to see.

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

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

From vromero at openjdk.java.net  Fri Nov  6 05:18:10 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 6 Nov 2020 05:18:10 GMT
Subject: RFR: 8255561: add tests to check binary compatibility rules for
 records [v2]
In-Reply-To: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
References: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
Message-ID: <r6ost0VLfxO758B4dpUc-Go1TXx9vBskxE4AuxugBGQ=.fb05a525-e622-4f01-a63b-b804c3579b54@github.com>

> Hi all,
> 
> Please review this change. It is providing compatibility tests for records. The tests are covering the assertions at section: [13.4.27 Evolution of Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27).
> 
> Thanks,
> Vicente

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1082/files
  - new: https://git.openjdk.java.net/jdk/pull/1082/files/d1e377c3..16a30015

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

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

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

From vromero at openjdk.java.net  Fri Nov  6 05:18:11 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 6 Nov 2020 05:18:11 GMT
Subject: RFR: 8255561: add tests to check binary compatibility rules for
 records [v2]
In-Reply-To: <HSn5c1MgogJ5_ABT0xL9bnknDaCfjNUGqoZG_3IK7OU=.f419f637-2745-4af7-9118-b3a9c5ace2ed@github.com>
References: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
 <HSn5c1MgogJ5_ABT0xL9bnknDaCfjNUGqoZG_3IK7OU=.f419f637-2745-4af7-9118-b3a9c5ace2ed@github.com>
Message-ID: <nl3DC4fSea3hpWkN12rLbLolwXZvBhznY5Mnen3cGYo=.b7c26b2f-554f-422b-a4a9-2a11a67c9478@github.com>

On Thu, 5 Nov 2020 22:08:22 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 251:
> 
>> 249:             String clientCode,
>> 250:             boolean shouldFail,
>> 251:             String expectedError) throws Exception {
> 
> Since the expected error always seems to be the name of a class, you could make the type of the parameter be `Class<?>` and then pass class literals as arguments. Inside the method, you get use `getName()` to get the name you expect to see.

I have uploaded a new iteration addressing your comments, thanks

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

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

From chris.hegarty at oracle.com  Fri Nov  6 15:12:45 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 6 Nov 2020 15:12:45 +0000
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <a3e944fd-0344-a1a0-3597-34e80ccf045a@oracle.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
 <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
 <a3e944fd-0344-a1a0-3597-34e80ccf045a@oracle.com>
Message-ID: <B9978080-4F14-47B9-AE8E-6D86C43DEBF8@oracle.com>


> On 5 Nov 2020, at 18:11, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 11/5/2020 4:45 AM, Jan Lahoda wrote:
>> FWIW, a javadoc generated with the current version of the patch:
>> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
> 
> Allow me to draw people's attention to the PREVIEW link in the banner of the generated javadoc. It shows all the preview APIs in the release on one page. This is very helpful for understanding the surface area of a preview feature.
> 
> For example, with Sealed Classes being the only preview feature likely to target JDK 16, the PREVIEW page shows that the feature's API is solely about reflection. It's clear that Sealed Classes do not introduce, say, a java.lang.Sealed class analogous to the java.lang.Record class introduced by Records in JDK 14/15 (and which would have appeared on the PREVIEW page had it existed then).

Very cool! ( I didn?t notice this until you pointed it out ;-) )

http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/preview-list.html <http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/preview-list.html>

There appears to be a very minor bug; when I click on the PREVIEW link in the banner, the page that lists the preview API points loads, but the banner does not ?highlight? that PREVIEW is ?selected?, but rather it ?highlights? DEPRECATED.

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201106/56d47fe2/attachment.htm>

From jjg at openjdk.java.net  Fri Nov  6 15:35:00 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 6 Nov 2020 15:35:00 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
 <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
Message-ID: <T9pPB5b2ARzPDwukZiP4FJKUwx-ZUnqULpH6FFPoTR8=.545a81ab-b04a-4044-bd07-9fe6dec44dbe@github.com>

On Thu, 5 Nov 2020 12:43:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Thanks @jonathan-gibbons for your comments! I've tried to update the code based on them, mostly in https://github.com/lahodaj/jdk/commit/743f516c660b577035cdda4510a0bb97937fd9b2 and https://github.com/lahodaj/jdk/commit/e4b02827998fc2e8f19f983aabfb3d720b03d111
>> 
>> A big chunk of the update is generalization of the deprecated and preview list builders and writers into a "summary" list builder and writer. These should also now handle records. For record components, those are a little tricky, as (AFAIK) can't currently have deprecation/preview-ness for them (and hence there is no good way to test any support for record components in these). But the summary build and writer are looking for record components and will fail in case a record component is sent into them.
>
> FWIW, a javadoc generated with the current version of the patch:
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
> 
> And a specdiff comparing it to the javadoc built from the corresponding master:
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.specdiff.01/overview-summary.html

The page and comments are generally good, but there is a bug that needs 
to be fixed.

After clicking on the PREVIEW link in the top bar to go to the Preview 
page, the word DEPRECATED is highlighted in the top navbar instead of 
PREVIEW.

-- Jon


On 11/5/20 10:13 AM, mlbridge[bot] wrote:
>
> /Mailing list message from Alex Buckley 
> <mailto:alex.buckley at oracle.com> on kulla-dev 
> <mailto:kulla-dev at openjdk.java.net>:/
>
> On 11/5/2020 4:45 AM, Jan Lahoda wrote:
>
>     FWIW, a javadoc generated with the current version of the patch:
>     http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
>
> Allow me to draw people's attention to the PREVIEW link in the banner of
> the generated javadoc. It shows all the preview APIs in the release on
> one page. This is very helpful for understanding the surface area of a
> preview feature.
>
> For example, with Sealed Classes being the only preview feature likely
> to target JDK 16, the PREVIEW page shows that the feature's API is
> solely about reflection. It's clear that Sealed Classes do not
> introduce, say, a java.lang.Sealed class analogous to the
> java.lang.Record class introduced by Records in JDK 14/15 (and which
> would have appeared on the PREVIEW page had it existed then).
>
> Alex
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/703*issuecomment-722549484__;Iw!!GqivPVa7Brio!ONrE9EESNKSCZJPGXBa8TTa4Ey9OqEVTynHLfgVOrBRIkb1Cr2iqLALb01M_DlGDeQEPpw$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRRTA7I6T2AUM3QT7QTSOLTLXANCNFSM4STPEYJQ__;!!GqivPVa7Brio!ONrE9EESNKSCZJPGXBa8TTa4Ey9OqEVTynHLfgVOrBRIkb1Cr2iqLALb01M_DlE4QxPnyw$>.
>

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

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

From jjg at openjdk.java.net  Fri Nov  6 16:21:55 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 6 Nov 2020 16:21:55 GMT
Subject: RFR: 8255561: add tests to check binary compatibility rules for
 records [v2]
In-Reply-To: <r6ost0VLfxO758B4dpUc-Go1TXx9vBskxE4AuxugBGQ=.fb05a525-e622-4f01-a63b-b804c3579b54@github.com>
References: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
 <r6ost0VLfxO758B4dpUc-Go1TXx9vBskxE4AuxugBGQ=.fb05a525-e622-4f01-a63b-b804c3579b54@github.com>
Message-ID: <wb7-Hv1mpms7i1yIIajZZqAr691LBpENDi1JOFX2tRw=.96290228-e4d6-40a7-a81d-e9a2dd5b4e12@github.com>

On Fri, 6 Nov 2020 05:18:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change. It is providing compatibility tests for records. The tests are covering the assertions at section: [13.4.27 Evolution of Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27).
>> 
>> Thanks,
>> Vicente
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Marked as reviewed by jjg (Reviewer).

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

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

From vromero at openjdk.java.net  Fri Nov  6 16:42:56 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 6 Nov 2020 16:42:56 GMT
Subject: RFR: 8255561: add tests to check binary compatibility rules for
 records [v2]
In-Reply-To: <wb7-Hv1mpms7i1yIIajZZqAr691LBpENDi1JOFX2tRw=.96290228-e4d6-40a7-a81d-e9a2dd5b4e12@github.com>
References: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
 <r6ost0VLfxO758B4dpUc-Go1TXx9vBskxE4AuxugBGQ=.fb05a525-e622-4f01-a63b-b804c3579b54@github.com>
 <wb7-Hv1mpms7i1yIIajZZqAr691LBpENDi1JOFX2tRw=.96290228-e4d6-40a7-a81d-e9a2dd5b4e12@github.com>
Message-ID: <S4zRiVkR1qRgGVAMNT0L2-Z3aoHjd59Xqdg7lRYbBjY=.7e3f455f-d92d-41f2-a057-b8a3bb9c403a@github.com>

On Fri, 6 Nov 2020 16:19:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> Marked as reviewed by jjg (Reviewer).

thanks for the approval

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

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

From vromero at openjdk.java.net  Fri Nov  6 16:42:58 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 6 Nov 2020 16:42:58 GMT
Subject: Integrated: 8255561: add tests to check binary compatibility rules
 for records
In-Reply-To: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
References: <mj-5GlKrjsxsIFj-bW4unm0Ze0lH2Lx1qMIO17fq7uI=.8cfbaa91-ed49-4f9c-9dc7-98e0adbd7f87@github.com>
Message-ID: <8sF3ZTfrD9h_PIPE5XmByNijZqbUa0yhupzyuBTHYJo=.2483cba0-267f-47a6-9600-b268a58e2134@github.com>

On Thu, 5 Nov 2020 18:55:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi all,
> 
> Please review this change. It is providing compatibility tests for records. The tests are covering the assertions at section: [13.4.27 Evolution of Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27).
> 
> Thanks,
> Vicente

This pull request has now been integrated.

Changeset: 688b10b9
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/688b10b9
Stats:     307 lines in 1 file changed: 307 ins; 0 del; 0 mod

8255561: add tests to check binary compatibility rules for records

Reviewed-by: jjg

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

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

From jlahoda at openjdk.java.net  Fri Nov  6 18:41:15 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 Nov 2020 18:41:15 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v11]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <fDWoj48-Ewh1-5pZKBQFI_UYuXFGPgjnXwmJuRlvKfY=.bb7279d8-008c-4254-8145-654579ef639f@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

  Fixing navigator for the PREVIEW page.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/097ae3c1..61264fe4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=09-10

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

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

From jlahoda at openjdk.java.net  Fri Nov  6 18:41:15 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 Nov 2020 18:41:15 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <T9pPB5b2ARzPDwukZiP4FJKUwx-ZUnqULpH6FFPoTR8=.545a81ab-b04a-4044-bd07-9fe6dec44dbe@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
 <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
 <T9pPB5b2ARzPDwukZiP4FJKUwx-ZUnqULpH6FFPoTR8=.545a81ab-b04a-4044-bd07-9fe6dec44dbe@github.com>
Message-ID: <bEQCaxy0VNHdMsS8Yhv_PqRo71oH0TMnHYSe4LIt5R4=.939875b7-57b7-4bfb-a0c7-e70d3b81e983@github.com>

On Fri, 6 Nov 2020 15:32:16 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> FWIW, a javadoc generated with the current version of the patch:
>> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
>> 
>> And a specdiff comparing it to the javadoc built from the corresponding master:
>> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.specdiff.01/overview-summary.html
>
> The page and comments are generally good, but there is a bug that needs 
> to be fixed.
> 
> After clicking on the PREVIEW link in the top bar to go to the Preview 
> page, the word DEPRECATED is highlighted in the top navbar instead of 
> PREVIEW.
> 
> -- Jon
> 
> 
> On 11/5/20 10:13 AM, mlbridge[bot] wrote:
>>
>> /Mailing list message from Alex Buckley 
>> <mailto:alex.buckley at oracle.com> on kulla-dev 
>> <mailto:kulla-dev at openjdk.java.net>:/
>>
>> On 11/5/2020 4:45 AM, Jan Lahoda wrote:
>>
>>     FWIW, a javadoc generated with the current version of the patch:
>>     http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
>>
>> Allow me to draw people's attention to the PREVIEW link in the banner of
>> the generated javadoc. It shows all the preview APIs in the release on
>> one page. This is very helpful for understanding the surface area of a
>> preview feature.
>>
>> For example, with Sealed Classes being the only preview feature likely
>> to target JDK 16, the PREVIEW page shows that the feature's API is
>> solely about reflection. It's clear that Sealed Classes do not
>> introduce, say, a java.lang.Sealed class analogous to the
>> java.lang.Record class introduced by Records in JDK 14/15 (and which
>> would have appeared on the PREVIEW page had it existed then).
>>
>> Alex
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/703*issuecomment-722549484__;Iw!!GqivPVa7Brio!ONrE9EESNKSCZJPGXBa8TTa4Ey9OqEVTynHLfgVOrBRIkb1Cr2iqLALb01M_DlGDeQEPpw$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRRTA7I6T2AUM3QT7QTSOLTLXANCNFSM4STPEYJQ__;!!GqivPVa7Brio!ONrE9EESNKSCZJPGXBa8TTa4Ey9OqEVTynHLfgVOrBRIkb1Cr2iqLALb01M_DlE4QxPnyw$>.
>>

Thanks for noticing Chris and @jonathan-gibbons. Fixed in 61264fe, updated javadoc:
http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.02/api/preview-list.html

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

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

From sirinath1978m at gmail.com  Sun Nov  8 06:16:40 2020
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Sun, 8 Nov 2020 11:46:40 +0530
Subject: Interface Related Improvements
Message-ID: <CAAfFNYGfZuUYONLPvvp61=NvpxaAhYdL70ALpOpz7PsWEUkTLg@mail.gmail.com>

Hello,

I am not sure where to post this, hope some one interested picks this up
for consideration.

With the introduction of default methods, private methods and static
methods in interfaces a few more changes are desirable to improve usability.

*Private fields*

Since interfaces currently can have private methods it would be much
desirable to have private fields also. These can static or instance fields,
but minimally at least private static fields initially.

If they are instance fields they will be only initialised once regardless
of how many places the interface is extended.

*Initializers*

Interfaces can add initialisers. These will only run one. Minimally at
least static initialisers initially.

*Reuse of Default Interface Methods*

Default methods can improve code reuse in anonymous inner classes and enums.

*Improvements to Annonymous Inner Classes to work with the new Java
Interfaces*

In order to reuse default methods, it will be convenient if something like
the following can be valid code. This is similar to what Scala and Groovy
does with traits.

    class X {}

    interface P<T> {
        default void f() {}
    }

    ...

    X x = new X() implements P<T>;

*Improving Enums to work with the new Java Interfaces*

In Enums there are times one does not need to share all
implementations like in:

    enum E {
        X {
            f() {}
        },
        Y {
            g() {}
        };
    }

In such cases some times the implementation of f and g can be shared if
following is allowed:

    interface P<X> {
        default void f() {}
    }

    interface Q<Y> {
        default void g() {}
    }

    enum E {
        X impliments P<X>,
        Y impliments Q<Y>;
    }

*Protected Methods*

Protected methods could be considered to control what can be accessed on
interfaces.

*Allow this*

Make the meaning of this pointer special in interfaces so features in the
implementing classes can be accessed:

    interface P {
        X this;

        default void f() {
            x();
        }
    }

    interface Q {
        X this;

        default void g() {
            x();
        }
    }

    class X implements P, Q {
        void x() {}
    }

Groovy and Scala has ways to implement something similar with traits.

Suminda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201108/e20b0b56/attachment.htm>

From jlahoda at openjdk.java.net  Mon Nov  9 12:54:06 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 9 Nov 2020 12:54:06 GMT
Subject: RFR: 8231599: NPE when loading a preview classfile from a future Java
 version
Message-ID: <b9pKEXG10M5ckEs5ZuMNKK9wfdAYKUwQvyU8IQqOhTs=.bf4c0ccf-701d-42b0-89ac-44e6733402a6@github.com>

The javac's ClassReader accepts class files with major version that is +1 higher than the current platform's major version. See https://bugs.openjdk.java.net/browse/JDK-6330997 for more information.

A problem is that when this too-new class file is a preview class file, the Preview class will attempt to produce a warning (or error) which includes the user-readable name of the Java platform, and it cannot find the name of the future platform name.

If the major version of the class file is >+1 higher than the current platform's, there is no such problem: ClassReader will reject to analyze the class file right away.

The proposed (middle ground) fix here is that ClassReader will reject all preview class files with major version > current platform's major version. It will keep accepting non-preview class files with major version +1 than the current.

With this patch, the standard error is produced:
brokenMajorVersionWithPreview/test/Test.java:1: error: cannot access C
class Test extends C {}
                   ^
  bad class file: brokenMajorVersionWithPreview/classes/C.class
    class file has wrong version 61.65535, should be 60.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.
1 error

Alternatives include:

 * reject all class files with major version > current
 * accept preview class files with major version +1 than the current, and attempt the generate a sensible (future) platform name

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

Commit messages:
 - 8231599: NPE when loading a preview classfile from a future Java version

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

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

From vromero at openjdk.java.net  Mon Nov  9 17:34:58 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 9 Nov 2020 17:34:58 GMT
Subject: RFR: 8231599: NPE when loading a preview classfile from a future
 Java version
In-Reply-To: <b9pKEXG10M5ckEs5ZuMNKK9wfdAYKUwQvyU8IQqOhTs=.bf4c0ccf-701d-42b0-89ac-44e6733402a6@github.com>
References: <b9pKEXG10M5ckEs5ZuMNKK9wfdAYKUwQvyU8IQqOhTs=.bf4c0ccf-701d-42b0-89ac-44e6733402a6@github.com>
Message-ID: <o-dA4inU7BjXPkh5_GBSoAAEeItQrnCUQ28q4dQWu98=.eac025d6-521d-40cd-b518-a0e9c3cb1c9e@github.com>

On Mon, 9 Nov 2020 12:47:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The javac's ClassReader accepts class files with major version that is +1 higher than the current platform's major version. See https://bugs.openjdk.java.net/browse/JDK-6330997 for more information.
> 
> A problem is that when this too-new class file is a preview class file, the Preview class will attempt to produce a warning (or error) which includes the user-readable name of the Java platform, and it cannot find the name of the future platform name.
> 
> If the major version of the class file is >+1 higher than the current platform's, there is no such problem: ClassReader will reject to analyze the class file right away.
> 
> The proposed (middle ground) fix here is that ClassReader will reject all preview class files with major version > current platform's major version. It will keep accepting non-preview class files with major version +1 than the current.
> 
> With this patch, the standard error is produced:
> brokenMajorVersionWithPreview/test/Test.java:1: error: cannot access C
> class Test extends C {}
>                    ^
>   bad class file: brokenMajorVersionWithPreview/classes/C.class
>     class file has wrong version 61.65535, should be 60.0
>     Please remove or make sure it appears in the correct subdirectory of the classpath.
> 1 error
> 
> Alternatives include:
> 
>  * reject all class files with major version > current
>  * accept preview class files with major version +1 than the current, and attempt the generate a sensible (future) platform name

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.java.net  Wed Nov 11 02:25:04 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 11 Nov 2020 02:25:04 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v11]
In-Reply-To: <fDWoj48-Ewh1-5pZKBQFI_UYuXFGPgjnXwmJuRlvKfY=.bb7279d8-008c-4254-8145-654579ef639f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <fDWoj48-Ewh1-5pZKBQFI_UYuXFGPgjnXwmJuRlvKfY=.bb7279d8-008c-4254-8145-654579ef639f@github.com>
Message-ID: <PvyAuDl9KUxhsTfT6gj82FHyDQsivb_OFBrsZ1Tsaqc=.eebe3873-97a9-4353-8df2-d49485193560@github.com>

On Fri, 6 Nov 2020 18:41:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing navigator for the PREVIEW page.

I have a mild queasiness about this new overloaded use of the word "Summary", since "summary tables" are normally the summary of the contents of a declaration, like fields and methods of a class.

That being said, the usage is primarily internal, and I have no overwhelmingly wonderful alternative, and (overloading aside) the term is accurate. 

So, OK for now. We can change it later if  we want to.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2949:

> 2947: 
> 2948:     /**
> 2949:      * Return the set of preview language features used to declare the given element.

"Returns"

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

Marked as reviewed by jjg (Reviewer).

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

From jlahoda at openjdk.java.net  Wed Nov 11 09:08:00 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 11 Nov 2020 09:08:00 GMT
Subject: RFR: 8256149: Weird AST structure for incomplete member select
Message-ID: <c09LcmEH_zjugw6V0nu2cWy_iSQrxL--uEL5Iq3zv6I=.cc1b09a7-2219-4abf-ad8c-718dcac7e43f@github.com>

Consider code like:
int i1 = "".
@Deprecated
void t1() {}

In current master, this will produce a somewhat twisted AST, and compile-time errors like:
E.java:2: error: <identifier> expected
int i = "".
           ^
E.java:3: error: illegal start of expression
@Deprecated void t() {}
^
E.java:3: error: ';' expected
@Deprecated void t() {}
           ^
3 errors

The reason is that `@Deprecated` is parsed as a type annotation following `"".<missing>`, which does not make much sense.

With this proposed patch, the AST is effectively the same as AST for:
int i1 = "".; //note the semicolon here
@Deprecated
void t1() {}

And the errors are much better as well:
E.java:2: error: <identifier> expected
int i = "".
           ^
1 error

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

Commit messages:
 - 8256149: Weird AST structure for incomplete member select

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

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

From jlahoda at openjdk.java.net  Wed Nov 11 09:13:59 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 11 Nov 2020 09:13:59 GMT
Subject: Integrated: 8231599: NPE when loading a preview classfile from a
 future Java version
In-Reply-To: <b9pKEXG10M5ckEs5ZuMNKK9wfdAYKUwQvyU8IQqOhTs=.bf4c0ccf-701d-42b0-89ac-44e6733402a6@github.com>
References: <b9pKEXG10M5ckEs5ZuMNKK9wfdAYKUwQvyU8IQqOhTs=.bf4c0ccf-701d-42b0-89ac-44e6733402a6@github.com>
Message-ID: <HyIb1xUoRNX31dCKKpP1hsmaeVZSoc2zx_bPxrC3HGU=.dfaedd8a-f1af-4609-9414-1de9880d29e2@github.com>

On Mon, 9 Nov 2020 12:47:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The javac's ClassReader accepts class files with major version that is +1 higher than the current platform's major version. See https://bugs.openjdk.java.net/browse/JDK-6330997 for more information.
> 
> A problem is that when this too-new class file is a preview class file, the Preview class will attempt to produce a warning (or error) which includes the user-readable name of the Java platform, and it cannot find the name of the future platform name.
> 
> If the major version of the class file is >+1 higher than the current platform's, there is no such problem: ClassReader will reject to analyze the class file right away.
> 
> The proposed (middle ground) fix here is that ClassReader will reject all preview class files with major version > current platform's major version. It will keep accepting non-preview class files with major version +1 than the current.
> 
> With this patch, the standard error is produced:
> brokenMajorVersionWithPreview/test/Test.java:1: error: cannot access C
> class Test extends C {}
>                    ^
>   bad class file: brokenMajorVersionWithPreview/classes/C.class
>     class file has wrong version 61.65535, should be 60.0
>     Please remove or make sure it appears in the correct subdirectory of the classpath.
> 1 error
> 
> Alternatives include:
> 
>  * reject all class files with major version > current
>  * accept preview class files with major version +1 than the current, and attempt the generate a sensible (future) platform name

This pull request has now been integrated.

Changeset: 129ff97f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/129ff97f
Stats:     137 lines in 2 files changed: 135 ins; 0 del; 2 mod

8231599: NPE when loading a preview classfile from a future Java version

Reviewed-by: vromero

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

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

From shade at openjdk.java.net  Thu Nov 12 17:49:10 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 12 Nov 2020 17:49:10 GMT
Subject: RFR: 8256290: javac/lambda/T8031967.java fails with
 StackOverflowError on x86_32
Message-ID: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com>

Observe:

$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=tools/javac/lambda/T8031967.java

STDOUT:
STDERR:

        GroupLayout l = new GroupLayout();
        ^
  symbol: class GroupLayout
  location: class Test

        GroupLayout l = new GroupLayout();
                            ^
  symbol: class GroupLayout
  location: class Test
java.lang.IllegalStateException: java.lang.StackOverflowError
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
at T8031967.runTestCase(T8031967.java:108)
at T8031967.run(T8031967.java:55)
at T8031967.main(T8031967.java:49)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.lang.StackOverflowError
at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2651)
at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:4020)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2407)

x86_32 defaults to 320K stack size, x86_64 (and pretty much every other platform) defaults to 1M stack size. Setting -Xss1M explicitly makes the test pass.

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

Commit messages:
 - 8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32

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

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

From mcimadamore at openjdk.java.net  Thu Nov 12 18:13:56 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 Nov 2020 18:13:56 GMT
Subject: RFR: 8256290: javac/lambda/T8031967.java fails with
 StackOverflowError on x86_32
In-Reply-To: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com>
References: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com>
Message-ID: <yNRHlqijgkgGKVHusc3FJwN5kHcrhDwfsPblQ0cIcGY=.140e5fc6-efaa-4224-b71e-97d4e913fb59@github.com>

On Thu, 12 Nov 2020 17:44:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Observe:
> 
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/javac/lambda/T8031967.java
> 
> STDOUT:
> STDERR:
> 
>         GroupLayout l = new GroupLayout();
>         ^
>   symbol: class GroupLayout
>   location: class Test
> 
>         GroupLayout l = new GroupLayout();
>                             ^
>   symbol: class GroupLayout
>   location: class Test
> java.lang.IllegalStateException: java.lang.StackOverflowError
> at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
> at T8031967.runTestCase(T8031967.java:108)
> at T8031967.run(T8031967.java:55)
> at T8031967.main(T8031967.java:49)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:831)
> Caused by: java.lang.StackOverflowError
> at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2651)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:4020)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2407)
> 
> x86_32 defaults to 320K stack size, x86_64 (and pretty much every other platform) defaults to 1M stack size. Setting -Xss1M explicitly makes the test pass.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From ihse at openjdk.java.net  Thu Nov 12 22:23:02 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 12 Nov 2020 22:23:02 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file
Message-ID: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>

Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.

Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.

So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.

Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 

I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)

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

Commit messages:
 - 8256308: Send arguments to javac server in a config file

Changes: https://git.openjdk.java.net/jdk/pull/1195/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256308
  Stats: 118 lines in 3 files changed: 48 ins; 33 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1195.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195

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

From ihse at openjdk.java.net  Thu Nov 12 22:54:13 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 12 Nov 2020 22:54:13 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v2]
In-Reply-To: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
Message-ID: <inP3RMWz29pY6yXUj5F4YYuT6zt1M6UylLyoznHLslk=.90ef3bca-1368-453d-92ea-83dcf6d16b1d@github.com>

> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
> 
> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
> 
> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
> 
> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
> 
> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)

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

  Fix race where multiple compilations overwrite the config file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1195/files
  - new: https://git.openjdk.java.net/jdk/pull/1195/files/26e5efdd..0a613f55

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

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

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

From ihse at openjdk.java.net  Fri Nov 13 00:12:12 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 Nov 2020 00:12:12 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v3]
In-Reply-To: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
Message-ID: <RVwE8tr7BlRdJLnh5h9t4zhQ_MdouyAHt7XJCuKAoNE=.5f2e6741-e68c-41a9-adb1-9225591f30a9@github.com>

> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
> 
> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
> 
> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
> 
> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
> 
> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)

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

  Paths on Windows must be converted before being written to the config file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1195/files
  - new: https://git.openjdk.java.net/jdk/pull/1195/files/0a613f55..c47f7c2a

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

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

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

From ihse at openjdk.java.net  Fri Nov 13 01:04:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 Nov 2020 01:04:15 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v4]
In-Reply-To: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
Message-ID: <UagaR1epX_1DEsUVB0bm8LeZYL9eywBqN6np0ao1lM4=.6ddba811-6352-48db-bf6c-1987c2459a01@github.com>

> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
> 
> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
> 
> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
> 
> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
> 
> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)

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

  Some rules had identical names which still caused races, so move config file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1195/files
  - new: https://git.openjdk.java.net/jdk/pull/1195/files/c47f7c2a..ba312950

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

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

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

From ihse at openjdk.java.net  Fri Nov 13 01:08:09 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 Nov 2020 01:08:09 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v5]
In-Reply-To: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
Message-ID: <Pw8vK7JzIediXUbiQk5MkDCFF3sNgyjJw-rUtM5Tyy8=.dfb68ad1-e82e-4628-a88e-cf40478d8d47@github.com>

> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
> 
> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
> 
> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
> 
> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
> 
> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)

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

  MODULE_SUBDIR must be defined before using

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1195/files
  - new: https://git.openjdk.java.net/jdk/pull/1195/files/ba312950..44507d25

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

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

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

From shade at openjdk.java.net  Fri Nov 13 07:43:00 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 13 Nov 2020 07:43:00 GMT
Subject: Integrated: 8256290: javac/lambda/T8031967.java fails with
 StackOverflowError on x86_32
In-Reply-To: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com>
References: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com>
Message-ID: <JewD4u_T054n1uRCUVVH44g5uvyDp5nb7TCAptPMb0U=.928d5b20-aa76-4679-be7b-40332d0ab062@github.com>

On Thu, 12 Nov 2020 17:44:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Observe:
> 
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/javac/lambda/T8031967.java
> 
> STDOUT:
> STDERR:
> 
>         GroupLayout l = new GroupLayout();
>         ^
>   symbol: class GroupLayout
>   location: class Test
> 
>         GroupLayout l = new GroupLayout();
>                             ^
>   symbol: class GroupLayout
>   location: class Test
> java.lang.IllegalStateException: java.lang.StackOverflowError
> at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
> at T8031967.runTestCase(T8031967.java:108)
> at T8031967.run(T8031967.java:55)
> at T8031967.main(T8031967.java:49)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:831)
> Caused by: java.lang.StackOverflowError
> at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2651)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:4020)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2407)
> 
> x86_32 defaults to 320K stack size, x86_64 (and pretty much every other platform) defaults to 1M stack size. Setting -Xss1M explicitly makes the test pass.

This pull request has now been integrated.

Changeset: 05b82456
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/05b82456
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32

Reviewed-by: mcimadamore

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

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

From shade at openjdk.java.net  Fri Nov 13 07:42:58 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 13 Nov 2020 07:42:58 GMT
Subject: RFR: 8256290: javac/lambda/T8031967.java fails with
 StackOverflowError on x86_32
In-Reply-To: <yNRHlqijgkgGKVHusc3FJwN5kHcrhDwfsPblQ0cIcGY=.140e5fc6-efaa-4224-b71e-97d4e913fb59@github.com>
References: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com>
 <yNRHlqijgkgGKVHusc3FJwN5kHcrhDwfsPblQ0cIcGY=.140e5fc6-efaa-4224-b71e-97d4e913fb59@github.com>
Message-ID: <Oi_fCwo3ljZqFgs3p1qIAm0YSwN0VPaS_q5MGyCL0ec=.4d5a831d-ea54-4947-a3a0-0fddc149d9a1@github.com>

On Thu, 12 Nov 2020 18:11:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Observe:
>> 
>> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/javac/lambda/T8031967.java
>> 
>> STDOUT:
>> STDERR:
>> 
>>         GroupLayout l = new GroupLayout();
>>         ^
>>   symbol: class GroupLayout
>>   location: class Test
>> 
>>         GroupLayout l = new GroupLayout();
>>                             ^
>>   symbol: class GroupLayout
>>   location: class Test
>> java.lang.IllegalStateException: java.lang.StackOverflowError
>> at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>> at T8031967.runTestCase(T8031967.java:108)
>> at T8031967.run(T8031967.java:55)
>> at T8031967.main(T8031967.java:49)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> at java.base/java.lang.Thread.run(Thread.java:831)
>> Caused by: java.lang.StackOverflowError
>> at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2651)
>> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:4020)
>> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2407)
>> 
>> x86_32 defaults to 320K stack size, x86_64 (and pretty much every other platform) defaults to 1M stack size. Setting -Xss1M explicitly makes the test pass.
>
> Looks good

Thanks!

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

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

From mcimadamore at openjdk.java.net  Fri Nov 13 12:47:06 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 Nov 2020 12:47:06 GMT
Subject: RFR: 8254784: javac should reject records with @SafeVarargs
 applied to varargs record component [v2]
In-Reply-To: <g9iHAAuzadirk9gB3weLo97NRi0i2u2gsIGaywdWn1c=.b6155edc-c669-4934-a81a-8f7913163cbc@github.com>
References: <qsYgkP7DYZbKKoKw2FCJrTtakM_m92eFFKb8a7DVozU=.bcc1c680-743c-438a-aa80-a93869c0e68e@github.com>
 <g9iHAAuzadirk9gB3weLo97NRi0i2u2gsIGaywdWn1c=.b6155edc-c669-4934-a81a-8f7913163cbc@github.com>
Message-ID: <iPkv4HzJx-zdI94MBm8tr_AcEAIz2XdWp6P_9BL-xWc=.fb2b0071-8284-4a25-a98f-b56402f19d22@github.com>

On Thu, 5 Nov 2020 17:13:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this fix for issue [1]. This is the background, for a record defined like:
>> 
>> record R(@SafeVarargs String... s) {}
>> 
>> an the following accessor will be generated:
>> 
>>     `@SafeVararags public String[] s() { return s; }`
>> 
>> this code is incorrect as the accessor is not a varargs method. But still the compiler is not generating a compiler error. The reason for this is that the method defining the accessor is not generated until the compiler get to its backend phase (at Lower to be more specific) and the check for incorrect @SafeVarargs use in the compiler happen before that, in Attr.
>> 
>> We decided to do not generate record related code until late phases in order to avoid generating code in the compiler frontend and because if code is generated in early stages then APs could see ASTs not created from user defined code. 
>> 
>> The proposed fix is to issue an error as soon as the compiler finds out that the @SafeVarargs annotation is applied to a compiler generated accessor because in other case the compiler would be forced to generate incorrect code.
>> 
>> TIA for the reviews,
>> Vicente
>> 
>> [1] [https://bugs.openjdk.java.net/browse/JDK-8254784](https://bugs.openjdk.java.net/browse/JDK-8254784)
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - manual merge with master
>  - 8254784: javac should reject records with @SafeVarargs applied to varargs record component

Seems sensible. A possible alternative would be to err immediately when we see (e.g. in TypeEnter?) that a record header contains a SafeVarargs annotation, in which case we know we can't support it.

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

Marked as reviewed by mcimadamore (Reviewer).

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

From erikj at openjdk.java.net  Fri Nov 13 14:32:03 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 13 Nov 2020 14:32:03 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v5]
In-Reply-To: <Pw8vK7JzIediXUbiQk5MkDCFF3sNgyjJw-rUtM5Tyy8=.dfb68ad1-e82e-4628-a88e-cf40478d8d47@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
 <Pw8vK7JzIediXUbiQk5MkDCFF3sNgyjJw-rUtM5Tyy8=.dfb68ad1-e82e-4628-a88e-cf40478d8d47@github.com>
Message-ID: <ihH9QEheKd11oLvWHSO4CH2KOMQaoi6RukeJbTFppE0=.9d164593-fcdd-4221-be52-acc0b9d3b9bc@github.com>

On Fri, 13 Nov 2020 01:08:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
>> 
>> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
>> 
>> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
>> 
>> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
>> 
>> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MODULE_SUBDIR must be defined before using

make/common/JavaCompilation.gmk line 237:

> 235:       $1_JAVAC_SERVER_CMD := $$(JAVA_DETACH) $$($1_JAVA_FLAGS) $$($1_JAVAC)
> 236: 
> 237:       $1_CONFIG_VARDEPS :=$$($1_JAVAC_PORT_FILE) $$($1_JAVAC_SERVER_CMD)

Space

make/common/JavaCompilation.gmk line 239:

> 237:       $1_CONFIG_VARDEPS :=$$($1_JAVAC_PORT_FILE) $$($1_JAVAC_SERVER_CMD)
> 238:       $1_CONFIG_VARDEPS_FILE := $$(call DependOnVariable, $1_CONFIG_VARDEPS, \
> 239:         $$($1_BIN)$$($1_MODULE_SUBDIR)/_the.$1.config_vardeps)

Indentation 4

make/common/JavaCompilation.gmk line 246:

> 244:         $1_ECHO_COMMAND := $(ECHO)
> 245:       endif
> 246:               $$($1_JAVAC_SERVER_CONFIG): $$($1_CONFIG_VARDEPS_FILE)

Indentation?

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

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

From erikj at openjdk.java.net  Fri Nov 13 14:31:59 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 13 Nov 2020 14:31:59 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file
In-Reply-To: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
Message-ID: <a9unEKAf8SWQ_H3x5LXdxmVyURRPmR9FpoqKryse068=.b84eca26-454f-493a-b527-69b5ce881d5a@github.com>

On Thu, 12 Nov 2020 22:13:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
> 
> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
> 
> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
> 
> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
> 
> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)

Looks good in general, just some whitespace issues.

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

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

From sormuras at gmail.com  Fri Nov 13 15:07:43 2020
From: sormuras at gmail.com (Christian Stein)
Date: Fri, 13 Nov 2020 16:07:43 +0100
Subject: jlink'ed javac misses --release support and numbers
Message-ID: <CAJi8+g6CvNbsMvwVwMnRMB8XufdvKUeMTRtiqg3Q58QetuNhfQ@mail.gmail.com>

Hi,

When creating a custom runtime image via jlink that includes
module jdk.compiler and its dependencies, the resulting javac tool of that
image doesn't support the --release option.

The error message reads, using 16-ea+24 as the basis and --release 16 on
the command:

  release version 16 not supported
    Usage: javac <options> <source files>
    use --help for a list of possible options

Running javac --help from within the custom image lacks all numbers:
[...]
  --release <release>
        Compile for the specified Java SE release. Supported releases:
  -s <directory>               Specify where to place generated source files
  --source <release>, -source <release>
        Provide source compatibility with the specified Java SE release.
Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
[...]

The help texts for options --source and --target do show all numbers.

Am I missing something? Perhaps an internal(?) module that contains the API
definitions used by javac?

Cheers,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201113/151efd4e/attachment.htm>

From jonathan.gibbons at oracle.com  Fri Nov 13 16:11:51 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 13 Nov 2020 08:11:51 -0800
Subject: jlink'ed javac misses --release support and numbers
In-Reply-To: <CAJi8+g6CvNbsMvwVwMnRMB8XufdvKUeMTRtiqg3Q58QetuNhfQ@mail.gmail.com>
References: <CAJi8+g6CvNbsMvwVwMnRMB8XufdvKUeMTRtiqg3Q58QetuNhfQ@mail.gmail.com>
Message-ID: <292a772b-f56a-cf7a-0925-6cfdcf1924ca@oracle.com>

Hi Christian,

This seems worthy of a bug to track this issue.

-- Jon

On 11/13/20 7:07 AM, Christian Stein wrote:
> Hi,
>
> When creating a custom runtime image via jlink that includes 
> module?jdk.compiler and its dependencies, the resulting javac tool of 
> that image doesn't support the --release option.
>
> The error message reads, using 16-ea+24 as the basis and --release 16 
> on the command:
>
> ? release version 16 not supported
> ? ? Usage: javac <options> <source files>
> ? ? use --help for a list of possible options
>
> Running javac --help from within the custom image lacks all numbers:
> [...]
> ? --release <release>
> ? ? ? ? Compile for the specified Java SE release. Supported releases:
> ? -s <directory> ? ? ? ? ? ? ? Specify where to place generated source 
> files
> ? --source <release>, -source <release>
> ? ? ? ? Provide source compatibility with the specified Java SE 
> release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
> [...]
>
> The help texts for options --source and --target do show all numbers.
>
> Am I missing something? Perhaps an internal(?) module that contains 
> the API definitions used by javac?
>
> Cheers,
> Christian

From jonathan.gibbons at oracle.com  Fri Nov 13 16:18:08 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 13 Nov 2020 08:18:08 -0800
Subject: jlink'ed javac misses --release support and numbers
In-Reply-To: <CAJi8+g6CvNbsMvwVwMnRMB8XufdvKUeMTRtiqg3Q58QetuNhfQ@mail.gmail.com>
References: <CAJi8+g6CvNbsMvwVwMnRMB8XufdvKUeMTRtiqg3Q58QetuNhfQ@mail.gmail.com>
Message-ID: <b968fe3d-5090-f95e-40de-4aaedeb6ad7e@oracle.com>

Filed as

https://bugs.openjdk.java.net/browse/JDK-8256343

-- Jon

On 11/13/20 7:07 AM, Christian Stein wrote:
> When creating a custom runtime image via jlink that includes 
> module?jdk.compiler and its dependencies, the resulting javac tool of 
> that image doesn't support the --release option.
>
> The error message reads, using 16-ea+24 as the basis and --release 16 
> on the command:
>
> ? release version 16 not supported
> ? ? Usage: javac <options> <source files>
> ? ? use --help for a list of possible options
>
> Running javac --help from within the custom image lacks all numbers:
> [...]
> ? --release <release>
> ? ? ? ? Compile for the specified Java SE release. Supported releases:
> ? -s <directory> ? ? ? ? ? ? ? Specify where to place generated source 
> files
> ? --source <release>, -source <release>
> ? ? ? ? Provide source compatibility with the specified Java SE 
> release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
> [...]
>
> The help texts for options --source and --target do show all numbers.

From jlahoda at openjdk.java.net  Fri Nov 13 16:52:07 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 13 Nov 2020 16:52:07 GMT
Subject: RFR: 8256266: Declaration annotations don't work properly for binding
 variables
Message-ID: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>

Basically, javac does not handle code like this properly:

import java.lang.annotation.*;

public class B {
     public void test(Object o) {
         if (o instanceof @A String s) {}
     }
}

@Target(ElementType.LOCAL_VARIABLE)
@interface A {}

The parser needs to allow declaration annotations on binding variables, see:
http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1

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

Commit messages:
 - Removing an extra whitespace.
 - 8256266: Declaration annotations don't work properly for binding variables

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

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

From neshkeev at yandex.ru  Sat Nov 14 21:44:11 2020
From: neshkeev at yandex.ru (Nikita Eshkeev)
Date: Sun, 15 Nov 2020 00:44:11 +0300
Subject: Extend Sealed Types to support GADT
Message-ID: <2701151605389322@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201115/d8bacbd8/attachment.htm>

From neshkeev at yandex.ru  Sat Nov 14 21:58:53 2020
From: neshkeev at yandex.ru (Nikita Eshkeev)
Date: Sun, 15 Nov 2020 00:58:53 +0300
Subject: Adding Do notaion/For comprehension 
Message-ID: <876231605390259@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201115/bb5fef0b/attachment.htm>

From forax at univ-mlv.fr  Sun Nov 15 17:02:58 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 15 Nov 2020 18:02:58 +0100 (CET)
Subject: Records, Intersection type and lambda
Message-ID: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>

I've found this bug trying to refactor existing classes to records but it's not directly related to record, i believe.

It's an issue with intersection type and lambdas,
Weirdly, i seen to recall alreadu seeing this bug ??

For me it's a compiler error, the compiler choose the first type of the intersection type (Record & Foo) instead of choosing the second, the one allowing m(Foo) to be called.

regards,
R?mi

----

import java.util.List;

public class RecordIntersectionTypeAndLambda {
  interface Foo { }
  record Bar1() implements Foo { }
  record Bar2() implements Foo { }

  static class Hello {
    void m(Foo foo) { }
  }

  public static void main(String[] args) {
    var list = List.of(new Bar1(), new Bar2());
    list.forEach(new Hello()::m);
  }
}

[forax at localhost java-fun]$ ~/jdk/jdk-16/bin/java --version
openjdk 16-ea 2021-03-16
OpenJDK Runtime Environment (build 16-ea+24-1553)
OpenJDK 64-Bit Server VM (build 16-ea+24-1553, mixed mode, sharing)

[forax at localhost java-fun]$ cd src/
[forax at localhost src]$ ~/jdk/jdk-16/bin/javac RecordIntersectionTypeAndLambda.java 
[forax at localhost src]$ ~/jdk/jdk-16/bin/java RecordIntersectionTypeAndLambda
Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method initialization exception
        at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194)
        at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:315)
        at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
        at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
        at RecordIntersectionTypeAndLambda.main(RecordIntersectionTypeAndLambda.java:14)
Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for lambda argument 1: class java.lang.Record is not convertible to interface RecordIntersectionTypeAndLambda$Foo
        at java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:293)
        at java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:327)
        at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127)
        ... 4 more

From jan.lahoda at oracle.com  Mon Nov 16 10:33:35 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 16 Nov 2020 11:33:35 +0100
Subject: Experimental fix for capturing anonymous classes inside lambda
 (JDK-8229862)
In-Reply-To: <CAEgw74C_LQ4VMsAa1js6TMdHpG8FNrjByiKLyaqk_+-tPo_FmQ@mail.gmail.com>
References: <CAEgw74C_LQ4VMsAa1js6TMdHpG8FNrjByiKLyaqk_+-tPo_FmQ@mail.gmail.com>
Message-ID: <c488ead3-6dc3-3d30-25ca-f67d65bc06fe@oracle.com>

Hi Bernard,

Sorry for belated answer.

I've filled:
https://github.com/openjdk/jdk/pull/1221

based on your patch. Hope that is fine. Any feedback is welcome!

Thanks,
     Jan

On 20. 10. 20 20:46, B. Blaser wrote:
> Hi,
> 
> JDK-8229862 reveals that capturing anonymous classes inside lambda
> seem not to be properly implemented yet, although the opposite
> currently works fine in JDK-16 (see [1] or [2], for example).
> 
> The following experimental fix (on jdk14u) searches for local
> variables captured by anonymous classes inside lambda (in
> LambdaToMethod) and translates them according to corresponding proxies
> (in Lower).
> 
> What do you think (langtools:tier1 is OK)?
> 
> Thanks,
> Bernard
> 
> [1] test/langtools/tools/javac/lambda/T8209407/VerifierErrorInnerPlusLambda.java
> [2] test/langtools/tools/javac/lambda/methodReference/ProtectedInaccessibleMethodRefTest.java
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> @@ -1380,9 +1380,18 @@
>               super.visitIdent(tree);
>           }
> 
> +        boolean inLambda = false;
> +
>           @Override
>           public void visitLambda(JCLambda tree) {
> -            analyzeLambda(tree, "lambda.stat");
> +            boolean prevInLambda = inLambda;
> +            try {
> +                inLambda = true;
> +                analyzeLambda(tree, "lambda.stat");
> +            }
> +            finally {
> +                inLambda = prevInLambda;
> +            }
>           }
> 
>           private void analyzeLambda(JCLambda tree, JCExpression
> methodReferenceReceiver) {
> @@ -1430,6 +1439,16 @@
> 
>           @Override
>           public void visitNewClass(JCNewClass tree) {
> +            if (tree.def != null && inLambda) {
> +                try {
> +                    inLambda = false;
> +                    visitClassDef(tree.def);
> +                }
> +                finally {
> +                    inLambda = true;
> +                }
> +            }
> +
>               TypeSymbol def = tree.type.tsym;
>               boolean inReferencedClass = currentlyInClass(def);
>               boolean isLocal = def.isLocal();
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> @@ -2812,7 +2812,14 @@
>           // If we have an anonymous class, create its flat version, rather
>           // than the class or interface following new.
>           if (tree.def != null) {
> -            translate(tree.def);
> +            Map<Symbol, Symbol> prevLambdaTranslationMap =
> lambdaTranslationMap;
> +            try {
> +                lambdaTranslationMap = null;
> +                translate(tree.def);
> +            } finally {
> +                lambdaTranslationMap = prevLambdaTranslationMap;
> +            }
> +
>               tree.clazz = access(make_at(tree.clazz.pos()).Ident(tree.def.sym));
>               tree.def = null;
>           } else {
> 

From jlahoda at openjdk.java.net  Mon Nov 16 10:38:03 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 Nov 2020 10:38:03 GMT
Subject: RFR: 8229862: NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570)
Message-ID: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>

Based on Bernard's code from:
http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015225.html

Capturing anonymous classes inside lambdas may fail to compile, because:
-the captured variables are not detected correctly, because `LambdaToMethod...captureLocalClassDefs` needs to find the AST node for the given `ClassSymbol`, but it has not yet been added into the `localClassDefs`. The proposed solution is to re-order the tasks done for JCNewClass, and call the super implementation sooner. This will enter the `ClassSymbol` and corresponding AST node into `localClassDefs` before the capture variables detection.
-inside the anonymous class definition, some references to the captured variables are replaced using a map that maps captured variables for lambdas (`lambdaTranslationMap`) - but inside the anonymous class, there the captured variables should be mapped using the anonymous class' map/proxies (to fields). The proposed solution is to clear `lambdaTranslationMap` before processing the anonymous class body.

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

Commit messages:
 - 8229862: NPE in jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570)

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

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

From magnus.ihse.bursie at oracle.com  Mon Nov 16 12:43:53 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Nov 2020 13:43:53 +0100
Subject: RFR: 8256308: Send arguments to javac server in a config file
In-Reply-To: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
Message-ID: <b76cd2f1-a01b-4102-40e8-da0f153d6eb0@oracle.com>

I would appreciate if someone from langtools could have a look at this 
as well. Thanks!

/Magnus

On 2020-11-12 23:23, Magnus Ihse Bursie wrote:
> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
>
> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
>
> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
>
> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed.
>
> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)
>
> -------------
>
> Commit messages:
>   - 8256308: Send arguments to javac server in a config file
>
> Changes: https://git.openjdk.java.net/jdk/pull/1195/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8256308
>    Stats: 118 lines in 3 files changed: 48 ins; 33 del; 37 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/1195.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195
>
> PR: https://git.openjdk.java.net/jdk/pull/1195


From ihse at openjdk.java.net  Mon Nov 16 12:44:08 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 16 Nov 2020 12:44:08 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v6]
In-Reply-To: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
Message-ID: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>

> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
> 
> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
> 
> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
> 
> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
> 
> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)

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

  Fix whitespace issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1195/files
  - new: https://git.openjdk.java.net/jdk/pull/1195/files/44507d25..3015d5e4

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

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

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

From vromero at openjdk.java.net  Mon Nov 16 13:36:13 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 16 Nov 2020 13:36:13 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
Message-ID: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>

Please review the code for the second iteration of sealed classes. In this iteration we are:

- Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies.
- Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface

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

Commit messages:
 - 8246778: Compiler implementation for Sealed Classes (Second Preview)

Changes: https://git.openjdk.java.net/jdk/pull/1227/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
  Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1227/head:pull/1227

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

From erikj at openjdk.java.net  Mon Nov 16 13:43:07 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 16 Nov 2020 13:43:07 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v6]
In-Reply-To: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
 <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>
Message-ID: <YuTI7zxsBC8EhTwxfXHcF_pTMuw8L8-prvnRMoEE9rI=.e620529c-85f7-4f59-964b-e30ef7c3250e@github.com>

On Mon, 16 Nov 2020 12:44:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
>> 
>> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
>> 
>> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
>> 
>> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
>> 
>> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace issues

Marked as reviewed by erikj (Reviewer).

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

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

From alanb at openjdk.java.net  Mon Nov 16 13:52:06 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 16 Nov 2020 13:52:06 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>

On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> - adding code to make sure that annotations can't be sealed
> - improving some tests
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

src/java.base/share/classes/java/lang/Package.java line 227:

> 225:      * This method reports on a distinct concept of sealing from
> 226:      * {@link Class#isSealed() Class::isSealed}.
> 227:      *

This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing.

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

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

From mcimadamore at openjdk.java.net  Mon Nov 16 14:01:04 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 Nov 2020 14:01:04 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <zAzRRkn9tXvuua8s5NnBE9zs409-pHY6WCW9y9uwiEo=.9a24bee1-a3a7-4da4-81bb-a332848a5ba3@github.com>

On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> - adding code to make sure that annotations can't be sealed
> - improving some tests
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

I left some comments re. the changes in cast conversion routine

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1659:

> 1657:             result = isCastable.visit(t,s);
> 1658:         }
> 1659:         if ((t.tsym.isSealed() || s.tsym.isSealed())) {

It would probably be better to only run this extra check if `result == true`, to minimize compatibility impact.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1672:

> 1670:             }
> 1671:             // if both are classes or both are interfaces, shortcut
> 1672:             if (ts.isInterface() == ss.isInterface()) {

What happens with code like this?

interface A permits B { }
non-sealed interface B extends A { }
interface C { }

class D implements C, B { } // this is a valid witness for both A and C, but A and C are unrelated with subtyping

class Test {
  void m(A a, C c) {
     a = (A)c;
  }
}```
Note that, w/o sealed types, the above snippet compiles ok - e.g. casting C to A is not going to give problems (as there could be a common subtype D <: A, C).

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

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

From bsrbnd at gmail.com  Mon Nov 16 17:06:12 2020
From: bsrbnd at gmail.com (B. Blaser)
Date: Mon, 16 Nov 2020 18:06:12 +0100
Subject: Experimental fix for capturing anonymous classes inside lambda
 (JDK-8229862)
In-Reply-To: <c488ead3-6dc3-3d30-25ca-f67d65bc06fe@oracle.com>
References: <CAEgw74C_LQ4VMsAa1js6TMdHpG8FNrjByiKLyaqk_+-tPo_FmQ@mail.gmail.com>
 <c488ead3-6dc3-3d30-25ca-f67d65bc06fe@oracle.com>
Message-ID: <CAEgw74CSwoYbbjUSGhmCWfUFsfq4O4P+VtvJBGppPMkoNzttiQ@mail.gmail.com>

Thanks Jan, your improvement in LambdaToMethod seems reasonable to me.

Cheers,
Bernard

On Mon, 16 Nov 2020 at 11:33, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
> Hi Bernard,
>
> Sorry for belated answer.
>
> I've filled:
> https://github.com/openjdk/jdk/pull/1221
>
> based on your patch. Hope that is fine. Any feedback is welcome!
>
> Thanks,
>      Jan

From bsrbnd at gmail.com  Mon Nov 16 17:13:55 2020
From: bsrbnd at gmail.com (B. Blaser)
Date: Mon, 16 Nov 2020 18:13:55 +0100
Subject: Records, Intersection type and lambda
In-Reply-To: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>
References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAEgw74At3W0manZ4yQsUewZz8iYJ5D136MXLw_nfR6OzjjYUcA@mail.gmail.com>

Probably related to:
http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015185.html

Regards,
Bernard

On Sun, 15 Nov 2020 at 18:03, Remi Forax <forax at univ-mlv.fr> wrote:
>
> I've found this bug trying to refactor existing classes to records but it's not directly related to record, i believe.
>
> It's an issue with intersection type and lambdas,
> Weirdly, i seen to recall alreadu seeing this bug ??
>
> For me it's a compiler error, the compiler choose the first type of the intersection type (Record & Foo) instead of choosing the second, the one allowing m(Foo) to be called.
>
> regards,
> R?mi
>
> ----
>
> import java.util.List;
>
> public class RecordIntersectionTypeAndLambda {
>   interface Foo { }
>   record Bar1() implements Foo { }
>   record Bar2() implements Foo { }
>
>   static class Hello {
>     void m(Foo foo) { }
>   }
>
>   public static void main(String[] args) {
>     var list = List.of(new Bar1(), new Bar2());
>     list.forEach(new Hello()::m);
>   }
> }
>
> [forax at localhost java-fun]$ ~/jdk/jdk-16/bin/java --version
> openjdk 16-ea 2021-03-16
> OpenJDK Runtime Environment (build 16-ea+24-1553)
> OpenJDK 64-Bit Server VM (build 16-ea+24-1553, mixed mode, sharing)
>
> [forax at localhost java-fun]$ cd src/
> [forax at localhost src]$ ~/jdk/jdk-16/bin/javac RecordIntersectionTypeAndLambda.java
> [forax at localhost src]$ ~/jdk/jdk-16/bin/java RecordIntersectionTypeAndLambda
> Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method initialization exception
>         at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194)
>         at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:315)
>         at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
>         at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
>         at RecordIntersectionTypeAndLambda.main(RecordIntersectionTypeAndLambda.java:14)
> Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for lambda argument 1: class java.lang.Record is not convertible to interface RecordIntersectionTypeAndLambda$Foo
>         at java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:293)
>         at java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:327)
>         at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127)
>         ... 4 more

From jlahoda at openjdk.java.net  Mon Nov 16 18:17:09 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 Nov 2020 18:17:09 GMT
Subject: RFR: 8256411: Based anonymous classes have a weird end position
Message-ID: <7aKd4Z5-b2wrbXxf5Kz2ZRjPKyl4Zw0JRVTt6e9hA2M=.71073831-380f-4a99-ad8d-1112a05af229@github.com>

Consider code like this:

package t;
class Test {
    class I {}
    static Object S = new Test().new I() {};
}

There is a synthetically generated `Test.I` in the extends clause of the anonymous class. The current end position for it is the end of the whole anonymous class (i.e. at '}'), which does not make much sense. The proposal is that the end position should be the end position of the "I" identifier, which is the same as if the anonymous class would not be based on an enclosing instance.

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

Commit messages:
 - 8256411: Based anonymous classes have a weird end position

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

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

From mchung at openjdk.java.net  Tue Nov 17 00:29:03 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 17 Nov 2020 00:29:03 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
Message-ID: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>

On Mon, 16 Nov 2020 13:49:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> - adding code to make sure that annotations can't be sealed
>> - improving some tests
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>
> src/java.base/share/classes/java/lang/Package.java line 227:
> 
>> 225:      * This method reports on a distinct concept of sealing from
>> 226:      * {@link Class#isSealed() Class::isSealed}.
>> 227:      *
> 
> This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing.

I agree.  This @apiNote needs more clarification to help the readers to understand the context here.    One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes".

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

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

From mchung at openjdk.java.net  Tue Nov 17 02:07:06 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 17 Nov 2020 02:07:06 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <Cb_cEhs4LxIUbtSKvPn5n3V5cImRB_bioYSQHHvTxHE=.8f18e946-ec20-4465-a709-f644a974ab71@github.com>

On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> - adding code to make sure that annotations can't be sealed
> - improving some tests
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

src/java.base/share/classes/java/lang/Class.java line 4381:

> 4379:      */
> 4380:     @jdk.internal.PreviewFeature(feature=jdk.internal.PreviewFeature.Feature.SEALED_CLASSES, essentialAPI=false)
> 4381:     public Class<?>[] getPermittedSubclasses() {

What happens if a permitted subclass is not found?   I see that `getPermittedSubclasses0` ignores the entry if the class is not found.    Should that be specified?

Have you considered whether security package access is needed (now that this method returns `Class` objects the caller may not have access to)? This needs to be discussed with the security team.    If someone gets a hold of a sealed class (e.g. `obj.getClass()`), this method could leak other `Class` objects.

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

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

From forax at univ-mlv.fr  Tue Nov 17 07:46:20 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 17 Nov 2020 08:46:20 +0100 (CET)
Subject: Records, Intersection type and lambda
In-Reply-To: <CAEgw74At3W0manZ4yQsUewZz8iYJ5D136MXLw_nfR6OzjjYUcA@mail.gmail.com>
References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>
 <CAEgw74At3W0manZ4yQsUewZz8iYJ5D136MXLw_nfR6OzjjYUcA@mail.gmail.com>
Message-ID: <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "B. Blaser" <bsrbnd at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, "Vicente Romero" <vicente.romero at oracle.com>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>, "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoy?: Lundi 16 Novembre 2020 18:13:55
> Objet: Re: Records, Intersection type and lambda

> Probably related to:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015185.html

yes, thanks !
still not fixed :(

> 
> Regards,
> Bernard

regards,
R?mi

> 
> On Sun, 15 Nov 2020 at 18:03, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> I've found this bug trying to refactor existing classes to records but it's not
>> directly related to record, i believe.
>>
>> It's an issue with intersection type and lambdas,
>> Weirdly, i seen to recall alreadu seeing this bug ??
>>
>> For me it's a compiler error, the compiler choose the first type of the
>> intersection type (Record & Foo) instead of choosing the second, the one
>> allowing m(Foo) to be called.
>>
>> regards,
>> R?mi
>>
>> ----
>>
>> import java.util.List;
>>
>> public class RecordIntersectionTypeAndLambda {
>>   interface Foo { }
>>   record Bar1() implements Foo { }
>>   record Bar2() implements Foo { }
>>
>>   static class Hello {
>>     void m(Foo foo) { }
>>   }
>>
>>   public static void main(String[] args) {
>>     var list = List.of(new Bar1(), new Bar2());
>>     list.forEach(new Hello()::m);
>>   }
>> }
>>
>> [forax at localhost java-fun]$ ~/jdk/jdk-16/bin/java --version
>> openjdk 16-ea 2021-03-16
>> OpenJDK Runtime Environment (build 16-ea+24-1553)
>> OpenJDK 64-Bit Server VM (build 16-ea+24-1553, mixed mode, sharing)
>>
>> [forax at localhost java-fun]$ cd src/
>> [forax at localhost src]$ ~/jdk/jdk-16/bin/javac
>> RecordIntersectionTypeAndLambda.java
>> [forax at localhost src]$ ~/jdk/jdk-16/bin/java RecordIntersectionTypeAndLambda
>> Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method
>> initialization exception
>>         at
>>         java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194)
>>         at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:315)
>>         at
>>         java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
>>         at
>>         java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
>>         at RecordIntersectionTypeAndLambda.main(RecordIntersectionTypeAndLambda.java:14)
>> Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for lambda
>> argument 1: class java.lang.Record is not convertible to interface
>> RecordIntersectionTypeAndLambda$Foo
>>         at
>>         java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:293)
>>         at
>>         java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:327)
>>         at
>>         java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127)
> >         ... 4 more

From fw at deneb.enyo.de  Tue Nov 17 17:01:17 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 17 Nov 2020 18:01:17 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest
 2.7.2
In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
 (Phil Race's message of "Mon, 2 Nov 2020 04:29:10 GMT")
References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
Message-ID: <87o8jv6hpe.fsf@mid.deneb.enyo.de>

* Phil Race:

> This upgrades JDK to import the current 2.7.2 version of harfbuzz -
> an OpenType text shaping library
>
> https://bugs.openjdk.java.net/browse/JDK-8247872
>
> This has passed building and headless and headful automated tests on
> all platforms.

Is it just me, or does the new Harfbuzz build *significantly* slower?

It adds about 20 seconds to the build, compared to using the system
Harfbuzz, whereas before it was around 5 seconds.

From philip.race at oracle.com  Tue Nov 17 17:56:47 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 17 Nov 2020 09:56:47 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest
 2.7.2
In-Reply-To: <87o8jv6hpe.fsf@mid.deneb.enyo.de>
References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
 <87o8jv6hpe.fsf@mid.deneb.enyo.de>
Message-ID: <5FB40EDF.4090300@oracle.com>

There is more code in the newer version but not 4 times as much !
Harfbuzz now requires c++11 features (-std=c++11)
Possibly the C++ compiler you are using (you don't mention platform) is 
slower in this mode.

-phil.

On 11/17/20, 9:01 AM, Florian Weimer wrote:
> * Phil Race:
>
>> This upgrades JDK to import the current 2.7.2 version of harfbuzz -
>> an OpenType text shaping library
>>
>> https://bugs.openjdk.java.net/browse/JDK-8247872
>>
>> This has passed building and headless and headful automated tests on
>> all platforms.
> Is it just me, or does the new Harfbuzz build *significantly* slower?
>
> It adds about 20 seconds to the build, compared to using the system
> Harfbuzz, whereas before it was around 5 seconds.

From fw at deneb.enyo.de  Tue Nov 17 18:00:02 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 17 Nov 2020 19:00:02 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest
 2.7.2
In-Reply-To: <5FB40EDF.4090300@oracle.com> (Philip Race's message of "Tue, 17
 Nov 2020 09:56:47 -0800")
References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
 <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com>
Message-ID: <87y2iz50f1.fsf@mid.deneb.enyo.de>

* Philip Race:

> There is more code in the newer version but not 4 times as much !
> Harfbuzz now requires c++11 features (-std=c++11)
> Possibly the C++ compiler you are using (you don't mention platform) is 
> slower in this mode.

It's GCC 8 on Debian buster, which defaults to C++14.  And it's
possible to write slow-to-compile C++ in all language modes.

Is the Harfbuzz build parallelized?

From philip.race at oracle.com  Tue Nov 17 18:08:08 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 17 Nov 2020 10:08:08 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest
 2.7.2
In-Reply-To: <87y2iz50f1.fsf@mid.deneb.enyo.de>
References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
 <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com>
 <87y2iz50f1.fsf@mid.deneb.enyo.de>
Message-ID: <5FB41188.30704@oracle.com>

So maybe the actual *usage* of C++11 features slows it down.

I found this :-
https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98

I really did not even think to measure the build time and I don't
think there's any JDK build parallelism in building a specific native 
library.
The build is parallel at a higher level but not at that lower level.

-phil

On 11/17/20, 10:00 AM, Florian Weimer wrote:
> * Philip Race:
>
>> There is more code in the newer version but not 4 times as much !
>> Harfbuzz now requires c++11 features (-std=c++11)
>> Possibly the C++ compiler you are using (you don't mention platform) is
>> slower in this mode.
> It's GCC 8 on Debian buster, which defaults to C++14.  And it's
> possible to write slow-to-compile C++ in all language modes.
>
> Is the Harfbuzz build parallelized?

From magnus.ihse.bursie at oracle.com  Tue Nov 17 21:40:33 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 17 Nov 2020 22:40:33 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest
 2.7.2
In-Reply-To: <5FB41188.30704@oracle.com>
References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com>
 <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com>
 <87y2iz50f1.fsf@mid.deneb.enyo.de> <5FB41188.30704@oracle.com>
Message-ID: <608e514f-8299-46bd-6821-be17ff7aedf5@oracle.com>



On 2020-11-17 19:08, Philip Race wrote:
> So maybe the actual *usage* of C++11 features slows it down.
>
> I found this :-
> https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98 
>
>
> I really did not even think to measure the build time and I don't
> think there's any JDK build parallelism in building a specific native 
> library.
> The build is parallel at a higher level but not at that lower level.
There is build parallelism on multiple levels. When building an 
individual library, make is free to parallelize the compile task; only 
the link task is done singlethreaded. When determining which libraries 
to build, make is free to chose those available depending on tasks 
already finished. For instance, to build java.desktop-libs, we need to 
have finished java.desktop-java (since javac generates the header files 
needed by JNI integration). But after that, it can be compiled whenever 
make think it's suitable.

This freedom for make to reorganize the order also means that it is hard 
to determine the additional cost for building a specific part. You could 
try to build java.desktop-java, and then run "make LOG=info 
java.desktop-libs" JOBS=1 to get a somewhat proper assessment of the 
time spent building all native libs for java.desktop. If this changes 
with the HarfBuzz upgrade, the HB upgrade is likely to blame.

/Magnus
>
> -phil
>
> On 11/17/20, 10:00 AM, Florian Weimer wrote:
>> * Philip Race:
>>
>>> There is more code in the newer version but not 4 times as much !
>>> Harfbuzz now requires c++11 features (-std=c++11)
>>> Possibly the C++ compiler you are using (you don't mention platform) is
>>> slower in this mode.
>> It's GCC 8 on Debian buster, which defaults to C++14.? And it's
>> possible to write slow-to-compile C++ in all language modes.
>>
>> Is the Harfbuzz build parallelized?


From jjg at openjdk.java.net  Tue Nov 17 23:03:08 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 17 Nov 2020 23:03:08 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v6]
In-Reply-To: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
 <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>
Message-ID: <2dyPy7yPtxW7Xo0R1yFx958RE2viLNNd5eWMS-SICMk=.cb7adb60-9e0c-43d0-a945-88d3ede6953c@github.com>

On Mon, 16 Nov 2020 12:44:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
>> 
>> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
>> 
>> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
>> 
>> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
>> 
>> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace issues

There seems to be much more here than there needs to be.

If the issue is just long command lines, then the obvious/conventional solution would be to use @files, which would be a tiny change to the sjavac source code, to insert a single call to `CommandLine.parse` to expand any @file arguments on the command line.

So, before reading all the various details in this proposed change, is there any reason why the simple @file solution cannot be used?

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

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

From ihse at openjdk.java.net  Wed Nov 18 00:07:11 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 18 Nov 2020 00:07:11 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v6]
In-Reply-To: <2dyPy7yPtxW7Xo0R1yFx958RE2viLNNd5eWMS-SICMk=.cb7adb60-9e0c-43d0-a945-88d3ede6953c@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
 <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>
 <2dyPy7yPtxW7Xo0R1yFx958RE2viLNNd5eWMS-SICMk=.cb7adb60-9e0c-43d0-a945-88d3ede6953c@github.com>
Message-ID: <wSrs1Bkpkd3dT7b1b37hfGcegb5e4GNyKYN9G9MICT0=.4bf40aab-4231-417f-8802-4ac2c634f698@github.com>

On Tue, 17 Nov 2020 23:00:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace issues
>
> There seems to be much more here than there needs to be.
> 
> If the issue is just long command lines, then the obvious/conventional solution would be to use @files, which would be a tiny change to the sjavac source code, to insert a single call to `CommandLine.parse` to expand any @file arguments on the command line.
> 
> So, before reading all the various details in this proposed change, is there any reason why the simple @file solution cannot be used?

The main issue is not the long command lines. Getting shorter command lines is nice, but more a side-effect.

The real driver here is the awkward encoding of the command line, with spaces replaced by %20. This makes it impossible to parse the --server option to Java and properly replace unix paths with Windows paths, in the way that is needed by the upcoming changes to how we build on Windows.

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

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

From david.holmes at oracle.com  Wed Nov 18 05:31:11 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Nov 2020 15:31:11 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>

Hi Vincente,

On 16/11/2020 11:36 pm, Vicente Romero wrote:
> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies.
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface

The major change here seems to be that getPermittedSubclasses() now 
returns actual Class objects instead of ClassDesc. My recollection from 
earlier discussions here was that the use of ClassDesc was very 
deliberate as the permitted subclasses may not actually exist and there 
may be security concerns with returning them!

Cheers,
David
-----

> -------------
> 
> Commit messages:
>   - 8246778: Compiler implementation for Sealed Classes (Second Preview)
> 
> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>    Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/1227/head:pull/1227
> 
> PR: https://git.openjdk.java.net/jdk/pull/1227
> 

From bsrbnd at gmail.com  Wed Nov 18 15:21:44 2020
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 18 Nov 2020 16:21:44 +0100
Subject: Records, Intersection type and lambda
In-Reply-To: <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr>
References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>
 <CAEgw74At3W0manZ4yQsUewZz8iYJ5D136MXLw_nfR6OzjjYUcA@mail.gmail.com>
 <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAEgw74DK6=Hvehk+GxVL8TcKeMFxUsHevSU0ATzTJQzGB-AoaA@mail.gmail.com>

On Tue, 17 Nov 2020 at 08:46, <forax at univ-mlv.fr> wrote:
>
> yes, thanks !
> still not fixed :(

Probably not a frequent issue with usual classes but I believe this
might be a rather common use case with records, so I verified that my
initial fix is still working fine with your latest example.
However, Vicente seems to be investigating something else in the same
area but I'd suggest to eventually file a separate issue for that in
order to go ahead with my proposal, what do you think?

Thanks,
Bernard

From jjg at openjdk.java.net  Wed Nov 18 20:09:15 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 Nov 2020 20:09:15 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v3]
In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
Message-ID: <rB_89Zu_8v6IdlLkQPlELTkpiVAmtkE6qUkg_Bp3370=.f7b104d6-fa5c-4a00-91ee-f71bf7ac5e6c@github.com>

> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box.
> 
> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `<a href="url">label</a>` in the generated docs.
> 
> As a block tag, the format is simply
> 
>     @spec url label
> 
> which is handled in a manner analogous to
> 
>     @see <a href="url">label</a>
> 
> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here.
> 
> This change is only the _support_ for the new tag;  it does _not_ include any changes to API docs to _use_ the new tag.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge master
 - Fix merge issues; review feedback
 - Merge with master
 - allow rich content in createAnchorAndSearchIndex
 - update Docs.gmk to stop disabling spec tag
 - fix TestSpecTag.testEncodedURI
 - fix tests
 - remove support to workaround legacy @spec tag
 - Merge remote-tracking branch 'upstream/master' into new-spec-tag
 - fix trailing whitespace in test
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/300cbaa6...69595e04

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

Changes: https://git.openjdk.java.net/jdk/pull/790/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=790&range=02
  Stats: 1374 lines in 42 files changed: 1337 ins; 14 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/790.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/790/head:pull/790

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

From jlahoda at openjdk.java.net  Thu Nov 19 18:30:21 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 19 Nov 2020 18:30:21 GMT
Subject: RFR: 7194212: NPE in Flow.visitIdent
Message-ID: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>

A somewhat corner-case issue, but consider a case where classfiles for:

public class Outer {
    public class Inner { }
}

Are on a classpath while compiling:

public class Outer$Inner extends Outer { }

This leads to a crash in javac (in Flow), because when Outer is completed, its InnerClasses attribute is read, and, based on it, the flags_field of Outer$Inner is (re)set (and it is put as an nested class to Outer, although that is not correct). But the flags_field used to contain UNATTRIBUTED flag. As this flag is cleared, the method bodies for Outer$Inner are never attributed (its default constructor in this case), which ultimately leads to the crash in Flow.

The proposed patch is to ensure the InnerClasses entry is ignored if we are compiling a same-named class from source. The cost is yet another Flag bit.

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

Commit messages:
 - Fixing FlagsTest.
 - 7194212: NPE in Flow.visitIdent

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

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

From jjg at openjdk.java.net  Fri Nov 20 17:56:15 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 20 Nov 2020 17:56:15 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
Message-ID: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>

This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.

The goal is to be able to simplify the following common pattern:

    /**
     * Returns the result. Optional additional text.
     * @return the result
     */
    int method() { 

by 

    /**
     * {@return the result} Optional additional text.
     */
    int method() { 

Note:

* The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
* The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
* If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
* The inline tag can be inherited into overriding methods as if it was provided as a block tag.

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

Commit messages:
 - Fix trailing whitespace in test
 - Merge master
 - JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations.

Changes: https://git.openjdk.java.net/jdk/pull/1355/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8075778
  Stats: 526 lines in 15 files changed: 441 ins; 20 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355

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

From jjg at openjdk.java.net  Fri Nov 20 18:51:17 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 20 Nov 2020 18:51:17 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v2]
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <UgtulkxfUx8wLP1VwxW-wWTz92FU7u7dUnLox3e5v-A=.b6014e31-f2d2-48ae-a95b-687ff8d02d16@github.com>

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:

 - Add default impl for new method
 - Fix test failure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1355/files
  - new: https://git.openjdk.java.net/jdk/pull/1355/files/483ede11..89846ff1

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

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

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

From vromero at openjdk.java.net  Fri Nov 20 19:03:25 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 20 Nov 2020 19:03:25 GMT
Subject: RFR: 8254105: allow static nested declarations [v7]
In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
Message-ID: <o5zEQgroDFAJywAXydC3kcA6gDdZ7bPFwSsqIL8Y5SE=.8df23dbe-cc34-40a5-98a3-78063c1dc457@github.com>

> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods.
> 
> TIA,
> Vicente
> 
> PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR.

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into JDK-8254105
 - addressing review comments
 - manual merge with master branch
 - removing duplicated test
 - test cleanup
 - Merge branch 'master' into JDK-8254105
 - 8254105: allow static members in inner classes, add binary compatibility tests

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

Changes: https://git.openjdk.java.net/jdk/pull/571/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=06
  Stats: 758 lines in 26 files changed: 313 ins; 191 del; 254 mod
  Patch: https://git.openjdk.java.net/jdk/pull/571.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571

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

From ebaron at openjdk.java.net  Fri Nov 20 22:27:15 2020
From: ebaron at openjdk.java.net (Elliott Baron)
Date: Fri, 20 Nov 2020 22:27:15 GMT
Subject: RFR: 8256809: Annotation processing causes NPE during flow analysis
Message-ID: <TsYokvRYpKkdBNjc4_rovoVSO4-f-Npvf0qCios4etE=.a2a85c34-ded3-4efc-bf1e-17f4efbf8b23@github.com>

If an error is found in JavacProcessingEnvironment.newRound, the erroneous ClassSymbols are meant to have their types replaced with new ClassTypes. There is a bug here where the check for whether a ClassSymbol is erroneous happens after the ClassSymbol is reset, replacing its kind with `TYP`. This means the check always fails, and the `kind == ERR` branch is never taken.

This can lead to a NullPointerException later on during flow analysis, which I've captured with the included test.

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

Commit messages:
 - Remove debug output from test
 - 8256809: Annotation processing causes NPE during flow analysis

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

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

From jjg at openjdk.java.net  Sat Nov 21 00:34:22 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 21 Nov 2020 00:34:22 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v3]
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <_9Wkj9PHga5Y5GTI2RpJqyCtdYJs3PXI2R8falBJYlA=.26b53df7-c507-4242-8973-f7af82a25213@github.com>

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

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

  Update DocCommentParser to permit nested inline tags in specified cases: @return

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1355/files
  - new: https://git.openjdk.java.net/jdk/pull/1355/files/89846ff1..87edfb0c

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

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

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

From ebaron at openjdk.java.net  Sat Nov 21 02:06:20 2020
From: ebaron at openjdk.java.net (Elliott Baron)
Date: Sat, 21 Nov 2020 02:06:20 GMT
Subject: RFR: 8256809: Annotation processing causes NPE during flow
 analysis [v2]
In-Reply-To: <TsYokvRYpKkdBNjc4_rovoVSO4-f-Npvf0qCios4etE=.a2a85c34-ded3-4efc-bf1e-17f4efbf8b23@github.com>
References: <TsYokvRYpKkdBNjc4_rovoVSO4-f-Npvf0qCios4etE=.a2a85c34-ded3-4efc-bf1e-17f4efbf8b23@github.com>
Message-ID: <GJK-ltKGFm3aWmyfTejdBqagnP9qVJ67c4sQxM_g5_M=.8034aff7-7316-4ca7-af1f-961fb6d94f7a@github.com>

> If an error is found in JavacProcessingEnvironment.newRound, the erroneous ClassSymbols are meant to have their types replaced with new ClassTypes. There is a bug here where the check for whether a ClassSymbol is erroneous happens after the ClassSymbol is reset, replacing its kind with `TYP`. This means the check always fails, and the `kind == ERR` branch is never taken.
> 
> This can lead to a NullPointerException later on during flow analysis, which I've captured with the included test.

Elliott Baron has updated the pull request incrementally with one additional commit since the last revision:

  Fix processor-path in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1359/files
  - new: https://git.openjdk.java.net/jdk/pull/1359/files/69372295..2ca76c32

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

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

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

From vromero at openjdk.java.net  Sat Nov 21 03:22:11 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 21 Nov 2020 03:22:11 GMT
Subject: Integrated: 8254105: allow static nested declarations
In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
Message-ID: <rOQSTSnGDqwNXW5oGfkJtGhV50LkjncHlr0L1zkBc7o=.eac505dd-efa3-4848-87c7-a5bd5d750162@github.com>

On Fri, 9 Oct 2020 00:01:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods.
> 
> TIA,
> Vicente
> 
> PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR.

This pull request has now been integrated.

Changeset: 9a19eb69
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a19eb69
Stats:     758 lines in 26 files changed: 313 ins; 191 del; 254 mod

8254105: allow static nested declarations

Reviewed-by: mcimadamore

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

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

From kbarrett at openjdk.java.net  Sat Nov 21 16:06:10 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 21 Nov 2020 16:06:10 GMT
Subject: RFR: 8256824:
 test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java has a
 bad copyright
Message-ID: <oY2b1051enPBbH4qj_X7yi5mTAjVeyocrbtH7TaoDmQ=.d2e9c5b6-ff46-4033-ae49-acd017add156@github.com>

Add missing comma in copyright text for test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java

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

Commit messages:
 - fix copyright

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

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

From dcubed at openjdk.java.net  Sat Nov 21 16:06:10 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 21 Nov 2020 16:06:10 GMT
Subject: RFR: 8256824:
 test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java has a
 bad copyright
In-Reply-To: <oY2b1051enPBbH4qj_X7yi5mTAjVeyocrbtH7TaoDmQ=.d2e9c5b6-ff46-4033-ae49-acd017add156@github.com>
References: <oY2b1051enPBbH4qj_X7yi5mTAjVeyocrbtH7TaoDmQ=.d2e9c5b6-ff46-4033-ae49-acd017add156@github.com>
Message-ID: <-1h-ua5JLs0hvhPKDAXbuYddI7kKnwEavaOVsoL9Faw=.ea5b272c-e64c-49c4-9b66-6e4e6272fb32@github.com>

On Sat, 21 Nov 2020 15:57:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Add missing comma in copyright text for test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java

Thumbs up!

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

Marked as reviewed by dcubed (Reviewer).

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

From kbarrett at openjdk.java.net  Sat Nov 21 16:12:59 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 21 Nov 2020 16:12:59 GMT
Subject: Integrated: 8256824:
 test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java has a
 bad copyright
In-Reply-To: <oY2b1051enPBbH4qj_X7yi5mTAjVeyocrbtH7TaoDmQ=.d2e9c5b6-ff46-4033-ae49-acd017add156@github.com>
References: <oY2b1051enPBbH4qj_X7yi5mTAjVeyocrbtH7TaoDmQ=.d2e9c5b6-ff46-4033-ae49-acd017add156@github.com>
Message-ID: <XdmzaMZ9pxaAxn8GsbZmvNcnXkZSBxoKZlCL3BJucc8=.81765db4-230e-4d8d-9bf2-0bfcce8dcb1b@github.com>

On Sat, 21 Nov 2020 15:57:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Add missing comma in copyright text for test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java

This pull request has now been integrated.

Changeset: edf72f06
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/edf72f06
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8256824: test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java has a bad copyright

Reviewed-by: dcubed

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

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

From jlahoda at openjdk.java.net  Mon Nov 23 08:23:59 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 23 Nov 2020 08:23:59 GMT
Subject: RFR: 8256809: Annotation processing causes NPE during flow
 analysis [v2]
In-Reply-To: <GJK-ltKGFm3aWmyfTejdBqagnP9qVJ67c4sQxM_g5_M=.8034aff7-7316-4ca7-af1f-961fb6d94f7a@github.com>
References: <TsYokvRYpKkdBNjc4_rovoVSO4-f-Npvf0qCios4etE=.a2a85c34-ded3-4efc-bf1e-17f4efbf8b23@github.com>
 <GJK-ltKGFm3aWmyfTejdBqagnP9qVJ67c4sQxM_g5_M=.8034aff7-7316-4ca7-af1f-961fb6d94f7a@github.com>
Message-ID: <HUPi0XQPaAGWgeKJ2UjsYUd7KQfuQKNUx71KpvshQEk=.6a224d25-fd94-4f63-8f50-169f69d4b7c0@github.com>

On Sat, 21 Nov 2020 02:06:20 GMT, Elliott Baron <ebaron at openjdk.org> wrote:

>> If an error is found in JavacProcessingEnvironment.newRound, the erroneous ClassSymbols are meant to have their types replaced with new ClassTypes. There is a bug here where the check for whether a ClassSymbol is erroneous happens after the ClassSymbol is reset, replacing its kind with `TYP`. This means the check always fails, and the `kind == ERR` branch is never taken.
>> 
>> This can lead to a NullPointerException later on during flow analysis, which I've captured with the included test.
>
> Elliott Baron has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix processor-path in test

Looks good!

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

Marked as reviewed by jlahoda (Reviewer).

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

From magnus.ihse.bursie at oracle.com  Mon Nov 23 12:57:56 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 23 Nov 2020 13:57:56 +0100
Subject: RFR: 8256308: Send arguments to javac server in a config file
In-Reply-To: <b76cd2f1-a01b-4102-40e8-da0f153d6eb0@oracle.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
 <b76cd2f1-a01b-4102-40e8-da0f153d6eb0@oracle.com>
Message-ID: <f04e92d8-2856-fb1f-c5a8-79c6ae336dbd@oracle.com>

I hope I could adequately answer why @files is not a solution to the 
problem I need to solve.

Since this is a blocker for the winenv rewrite, I'd very much like to 
have this integrated. And I'd very much like to have a review from 
anyone in the lang tools team, and not just Erik's.

Anyone, please?

/Magnus

On 2020-11-16 13:43, Magnus Ihse Bursie wrote:
> I would appreciate if someone from langtools could have a look at this 
> as well. Thanks!
>
> /Magnus
>
> On 2020-11-12 23:23, Magnus Ihse Bursie wrote:
>> Currently, to use the javac server, a horrendously long command line 
>> option is created, looking like this: `--server:portfile=<path to 
>> portfile>:sjavac=<command to launch server>`, where the sjavac 
>> command has had all spaces replaced by %20. Since Project Jigsaw, the 
>> set of module arguments needed is huge to begin with, making this 
>> command line incomprehensible after mangling.
>>
>> Apart from making java command lines hard to read (and copy/paste!) 
>> by developers, it also makes it hard for scripts to parse. The 
>> upcoming winenv rewrite is dependent on being able to differentiate 
>> between path names and other arguments, which is not possible in this 
>> mess.
>>
>> So, instead, let's write it to a file, without any escaping, and just 
>> pass the configuration file name to the server.
>>
>> Note that this will change the behavior of the javac server, but as 
>> the source code states this is not a documented or externally 
>> supported API no CSR is needed.
>>
>> I also cleaned up some code in SjavacClient, in particular code 
>> relating to the passing of arguments. (We never change poolsize or 
>> keepalive when we call it.)
>>
>> -------------
>>
>> Commit messages:
>> ? - 8256308: Send arguments to javac server in a config file
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/1195/files
>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=00
>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8256308
>> ?? Stats: 118 lines in 3 files changed: 48 ins; 33 del; 37 mod
>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1195.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>> pull/1195/head:pull/1195
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1195
>


From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Nov 23 15:28:20 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 23 Nov 2020 15:28:20 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible constructor
Message-ID: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>

Hi all,

When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
This patch solves this bug, regardless of the construction order, compiler can always output expected message.
Thank you for taking the time to review.

Best Regards.

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

Commit messages:
 - 8255968: Confusing error message for inaccessible constructor

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

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

From mcimadamore at openjdk.java.net  Mon Nov 23 15:45:57 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 Nov 2020 15:45:57 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible constructor
In-Reply-To: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
Message-ID: <J-7HHUn8Ne6qodq6B14lwx1Iw7eGmSiBuyueVL9Uij8=.609b4259-718f-4bf9-a490-a771f03f006e@github.com>

On Mon, 23 Nov 2020 15:22:26 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
> Thank you for taking the time to review.
> 
> Best Regards.

While I somewhat sympathize with the problem you are trying to solve, note that, by doing this, the output of the compiler will regress in case where not _all_ the overload candidates are not accessible. E.g.

m(1): //client

m();
private m(int);

In this case I guess it's less clear as what "should" happen: does the user want to call the first, or second version of `m` ? Both cases are possible - e.g. the user might accidentally call the private version of some method (in which the compiler is right in pointing out that the callsite is wrong), or the user indeed might want to access the private method (in which case your patch to shift the focus onto the access error might seem more appropriate).

I'm a bit skeptical that there exist a silver bullet for these kind of mixed cases. Technically speaking, from a JLS perspective, non-accessible methods should not even take place in overload resolution - so the current compiler behavior is cases where both accessible and inaccessible methods are present seems more appropriate.

In other words, if we really want to improve the status quo, we should detect cases where _all_ candidates are not accessible. Or, we should question whether javac's behavior of tagging inaccessible methods with the kind `WRONG_MTH`/`WRONG_MTHS` is correct in the first place.

It would be nice, I guess, if we could make the inaccessible error more powerful, so that we could keep adding inaccessble symbols as we go along, so that javac could display something like "cannot resolve symbol `m` - but some inaccessible symbols have been found <list>".

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

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

From ebaron at openjdk.java.net  Mon Nov 23 16:06:00 2020
From: ebaron at openjdk.java.net (Elliott Baron)
Date: Mon, 23 Nov 2020 16:06:00 GMT
Subject: Integrated: 8256809: Annotation processing causes NPE during flow
 analysis
In-Reply-To: <TsYokvRYpKkdBNjc4_rovoVSO4-f-Npvf0qCios4etE=.a2a85c34-ded3-4efc-bf1e-17f4efbf8b23@github.com>
References: <TsYokvRYpKkdBNjc4_rovoVSO4-f-Npvf0qCios4etE=.a2a85c34-ded3-4efc-bf1e-17f4efbf8b23@github.com>
Message-ID: <2GQZsNUAQY2F1qTd0xGWptSEwh77paq4x-GDL-k3-6A=.927c2c68-205d-45e2-bc7e-884e2f38904c@github.com>

On Fri, 20 Nov 2020 22:22:17 GMT, Elliott Baron <ebaron at openjdk.org> wrote:

> If an error is found in JavacProcessingEnvironment.newRound, the erroneous ClassSymbols are meant to have their types replaced with new ClassTypes. There is a bug here where the check for whether a ClassSymbol is erroneous happens after the ClassSymbol is reset, replacing its kind with `TYP`. This means the check always fails, and the `kind == ERR` branch is never taken.
> 
> This can lead to a NullPointerException later on during flow analysis, which I've captured with the included test.

This pull request has now been integrated.

Changeset: 8ddf5e17
Author:    Elliott Baron <ebaron at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8ddf5e17
Stats:     160 lines in 2 files changed: 159 ins; 0 del; 1 mod

8256809: Annotation processing causes NPE during flow analysis

Reviewed-by: jlahoda

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

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

From david.holmes at oracle.com  Tue Nov 24 01:04:55 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2020 11:04:55 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
Message-ID: <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>

Hi Harold,

On 24/11/2020 6:27 am, Harold Seigel wrote:
> Hi David,
> 
> Thanks for looking at this.
> 
> The intent was for method Class.permittedSubclasses() to be implemented 
> similarly to Class.getNestMembers().? Are you suggesting that a security 
> manager check be added to permittedSubclasses() similar to the security 
> manager check in getNestMembers()?

No I'm suggesting the change to the API is plain wrong. :) Please see 
discussion in the CSR.

Cheers,
David

> Thanks, Harold
> 
> On 11/18/2020 12:31 AM, David Holmes wrote:
>> Hi Vincente,
>>
>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>> Please review the code for the second iteration of sealed classes. In 
>>> this iteration we are:
>>>
>>> - Enhancing narrowing reference conversion to allow for stricter 
>>> checking of cast conversions with respect to sealed type hierarchies.
>>> - Also local classes are not considered when determining implicitly 
>>> declared permitted direct subclasses of a sealed class or sealed 
>>> interface
>>
>> The major change here seems to be that getPermittedSubclasses() now 
>> returns actual Class objects instead of ClassDesc. My recollection 
>> from earlier discussions here was that the use of ClassDesc was very 
>> deliberate as the permitted subclasses may not actually exist and 
>> there may be security concerns with returning them!
>>
>> Cheers,
>> David
>> -----
>>
>>> -------------
>>>
>>> Commit messages:
>>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>
>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>>> pull/1227/head:pull/1227
>>>
>>> PR: https://git.openjdk.java.net/jdk/pull/1227
>>>

From forax at univ-mlv.fr  Tue Nov 24 09:45:14 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 24 Nov 2020 10:45:14 +0100 (CET)
Subject: RFR: 8246778: Compiler implementation for Sealed Classes
 (Second Preview)
In-Reply-To: <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
 <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
Message-ID: <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> ?: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>
> Envoy?: Mardi 24 Novembre 2020 02:04:55
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

> Hi Harold,
> 
> On 24/11/2020 6:27 am, Harold Seigel wrote:
>> Hi David,
>> 
>> Thanks for looking at this.
>> 
>> The intent was for method Class.permittedSubclasses() to be implemented
>> similarly to Class.getNestMembers().? Are you suggesting that a security
>> manager check be added to permittedSubclasses() similar to the security
>> manager check in getNestMembers()?
> 
> No I'm suggesting the change to the API is plain wrong. :) Please see
> discussion in the CSR.

Given that the CSR is closed, i will answer here.
There are two issues with the previous implementation of permittedSubclasses, first it's the only method that using method desc which means that people has to be aware on another non trivial concept (object that describes constant pool constant) to understand how to use the method then i've tested this API with my students, all but one what able to correctly derives the Class from a ClassDesc, so instead of asking every users of permittedSubclasses to go through the oops of getting Class from a ClassDesc, i think we can agree that it's better to move the burden from the user to the JDK implementors.

> 
> Cheers,
> David

regards,
R?mi

> 
>> Thanks, Harold
>> 
>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>> Hi Vincente,
>>>
>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>> Please review the code for the second iteration of sealed classes. In
>>>> this iteration we are:
>>>>
>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>> - Also local classes are not considered when determining implicitly
>>>> declared permitted direct subclasses of a sealed class or sealed
>>>> interface
>>>
>>> The major change here seems to be that getPermittedSubclasses() now
>>> returns actual Class objects instead of ClassDesc. My recollection
>>> from earlier discussions here was that the use of ClassDesc was very
>>> deliberate as the permitted subclasses may not actually exist and
>>> there may be security concerns with returning them!
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>> -------------
>>>>
>>>> Commit messages:
>>>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>
>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>>> pull/1227/head:pull/1227
>>>>
>>>> PR: https://git.openjdk.java.net/jdk/pull/1227

From jfranck at openjdk.java.net  Tue Nov 24 09:57:58 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Tue, 24 Nov 2020 09:57:58 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v6]
In-Reply-To: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
 <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>
Message-ID: <CYQLQ66AL1XZ-ouQlv4baG5TV_-gEftfeCpl2oSyDh4=.14f09436-4582-4608-8983-b9da0b7458ab@github.com>

On Mon, 16 Nov 2020 12:44:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
>> 
>> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
>> 
>> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
>> 
>> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
>> 
>> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace issues

Marked as reviewed by jfranck (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java line 96:

> 94: 
> 95:     public static String extractStringOptionLine(String opName, String s, String deflt) {
> 96:         return extractStringOptionWithDelimiter(opName, s, deflt, '\n').strip();

Is '\n' going to be problematic due to differences in line endings on various platforms?

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

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

From chegar at openjdk.java.net  Tue Nov 24 10:06:09 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 24 Nov 2020 10:06:09 GMT
Subject: RFR: 8256755: Update build.tools.depend.Depend to handle record
 components in API signatures
Message-ID: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com>

The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records.

The components of a public record class, that is a member of an exported package, are logically part of the module's API. The name, type, and order are significant. This issue updates the build tool to include the aforementioned component characteristics.

This issue is a blocker to adding any public record types to the JDK - since the build will fail.

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

Commit messages:
 - Update the Depend(ency) build tool to handle the record attribute

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

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

From jlahoda at openjdk.java.net  Tue Nov 24 10:13:56 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 24 Nov 2020 10:13:56 GMT
Subject: RFR: 8256755: Update build.tools.depend.Depend to handle record
 components in API signatures
In-Reply-To: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com>
References: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com>
Message-ID: <3Qt6HXmLkLPC3EEKz1NZa00iwS8z2c3bzHTbszLg3n0=.b8798de1-2b51-44b4-8e73-403de15ee98b@github.com>

On Tue, 24 Nov 2020 09:59:44 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records.
> 
> The components of a public record class, that is a member of an exported package, are logically part of the module's API. The name, type, and order are significant. This issue updates the build tool to include the aforementioned component characteristics.
> 
> This issue is a blocker to adding any public record types to the JDK - since the build will fail.

Looks great, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

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

From ihse at openjdk.java.net  Tue Nov 24 11:17:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 24 Nov 2020 11:17:06 GMT
Subject: Integrated: 8256308: Send arguments to javac server in a config file
In-Reply-To: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
Message-ID: <YfmvBC1RKUbx4esjL823eaDwwWZJf37flvfzRPp4wgs=.29dbfd91-cddd-4fce-b2c7-96bb60d5a658@github.com>

On Thu, 12 Nov 2020 22:13:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=<path to portfile>:sjavac=<command to launch server>`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling.
> 
> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
> 
> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
> 
> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. 
> 
> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)

This pull request has now been integrated.

Changeset: 9e4944f7
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9e4944f7
Stats:     136 lines in 3 files changed: 59 ins; 40 del; 37 mod

8256308: Send arguments to javac server in a config file

Reviewed-by: erikj, jfranck

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

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

From ihse at openjdk.java.net  Tue Nov 24 11:17:05 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 24 Nov 2020 11:17:05 GMT
Subject: RFR: 8256308: Send arguments to javac server in a config file [v6]
In-Reply-To: <CYQLQ66AL1XZ-ouQlv4baG5TV_-gEftfeCpl2oSyDh4=.14f09436-4582-4608-8983-b9da0b7458ab@github.com>
References: <eqHGgeRi3mOTAavirLBwPueWlYJZ7lpLMcX3dPUlaFU=.1359eb0b-6aa9-4a2c-b323-41e5df060b87@github.com>
 <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com>
 <CYQLQ66AL1XZ-ouQlv4baG5TV_-gEftfeCpl2oSyDh4=.14f09436-4582-4608-8983-b9da0b7458ab@github.com>
Message-ID: <WDYO7VYcZYTtxkduojQq2jYjgY8ara7r0Vfzjn_5nhk=.9fe6df74-b206-45f1-b420-aa36e3957392@github.com>

On Tue, 24 Nov 2020 09:52:34 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace issues
>
> src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java line 96:
> 
>> 94: 
>> 95:     public static String extractStringOptionLine(String opName, String s, String deflt) {
>> 96:         return extractStringOptionWithDelimiter(opName, s, deflt, '\n').strip();
> 
> Is '\n' going to be problematic due to differences in line endings on various platforms?

The JDK project is limited to unix-style line endings only. No other styles are supported, and any attempt to use such will break the build (often early on).

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Nov 24 11:46:57 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 24 Nov 2020 11:46:57 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible constructor
In-Reply-To: <J-7HHUn8Ne6qodq6B14lwx1Iw7eGmSiBuyueVL9Uij8=.609b4259-718f-4bf9-a490-a771f03f006e@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <J-7HHUn8Ne6qodq6B14lwx1Iw7eGmSiBuyueVL9Uij8=.609b4259-718f-4bf9-a490-a771f03f006e@github.com>
Message-ID: <otUxRw29LNMWg7fza_Oeym1cQMc6BZBejALOcvdL5sY=.1ed720b5-25fd-42f7-afac-faf5f9c27a64@github.com>

On Mon, 23 Nov 2020 15:42:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi all,
>> 
>> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
>> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> While I somewhat sympathize with the problem you are trying to solve, note that, by doing this, the output of the compiler will regress in case where not _all_ the overload candidates are not accessible. E.g.
> 
> m(1): //client
> 
> m();
> private m(int);
> 
> In this case I guess it's less clear as what "should" happen: does the user want to call the first, or second version of `m` ? Both cases are possible - e.g. the user might accidentally call the private version of some method (in which the compiler is right in pointing out that the callsite is wrong), or the user indeed might want to access the private method (in which case your patch to shift the focus onto the access error might seem more appropriate).
> 
> I'm a bit skeptical that there exist a silver bullet for these kind of mixed cases. Technically speaking, from a JLS perspective, non-accessible methods should not even take place in overload resolution - so the current compiler behavior is cases where both accessible and inaccessible methods are present seems more appropriate.
> 
> In other words, if we really want to improve the status quo, we should detect cases where _all_ candidates are not accessible. Or, we should question whether javac's behavior of tagging inaccessible methods with the kind `WRONG_MTH`/`WRONG_MTHS` is correct in the first place.
> 
> It would be nice, I guess, if we could make the inaccessible error more powerful, so that we could keep adding inaccessble symbols as we go along, so that javac could display something like "cannot resolve symbol `m` - but some inaccessible symbols have been found <list>".

Currently, the compiler output the error message depending on the order of the methods. Please see the below test cases.

- the `private Test(int x) {}` is at the end of other(one or more) method(s).
class T8255968 {
    Test c = new Test(0);
}
class Test {
    private Test(String[] x) {}
    Test(String x) {}
    private Test(int x) {}  // at the end
}

current output:
error: Test(int) has private access in Test
    Test c = new Test(0);
             ^
1 error
- the `private Test(int x) {}` is not at the end of other(only one) method.
class T8255968 {
    Test c = new Test(0);
}
class Test {
    private Test(int x) {}  // not at the end
    Test(String x) {} // can be private, output same error message
}

current output:
error: incompatible types: int cannot be converted to String
    Test c = new Test(0);
                      ^
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error

- the `private Test(int x) {}` is not at the end of other(more than one) methods.
class T8255968 {
    Test c = new Test(0);
}
class Test {
    private Test(String x) {}
    private Test(int x) {}  // not at the end
    Test(String[] x) {}
}

current output:
error: no suitable constructor found for Test(int)
    Test c = new Test(0);
             ^
    constructor Test.Test(String) is not applicable
      (argument mismatch; int cannot be converted to String)
    constructor Test.Test(String[]) is not applicable
      (argument mismatch; int cannot be converted to String[])
1 error
These output messages which depending on the order of the methods would confuse users. Because the order of the methods  should not have any influence.

@mcimadamore According to your comment, I want to unify the output messages as below.

- the `private Test(int x) {}` is at the end of other(one or more) method(s).
class T8255968 {
    Test c = new Test(0);
}
class Test {
    private Test(String[] x) {}
    Test(String x) {}
    private Test(int x) {}  // at the end
}

expected output:
error: no suitable constructor found for Test(int)
    Test c = new Test(0);
             ^
    constructor Test.Test(String[]) is not applicable
      (argument mismatch; int cannot be converted to String[])
    constructor Test.Test(int) is not applicable
      (Test(int) has private access in Test)
    constructor Test.Test(String) is not applicable
      (argument mismatch; int cannot be converted to String)
1 error
- the `private Test(int x) {}` is not at the end of other(only one) method.
class T8255968 {
    Test c = new Test(0);
}
class Test {
    private Test(int x) {}  // not at the end
    Test(String x) {} // can be private, output same error message
}

expected output:
error: no suitable constructor found for Test(int)
    Test c = new Test(0);
             ^
    constructor Test.Test(int) is not applicable
      (Test(int) has private access in Test)
    constructor Test.Test(String) is not applicable
      (argument mismatch; int cannot be converted to String)
1 error

- the `private Test(int x) {}` is not at the end of other(more than one) methods.
class T8255968 {
    Test c = new Test(0);
}
class Test {
    private Test(String x) {}
    private Test(int x) {}  // not at the end
    Test(String[] x) {}
}

expected output:
error: no suitable constructor found for Test(int)
    Test c = new Test(0);
             ^
    constructor Test.Test(String) is not applicable
      (argument mismatch; int cannot be converted to String)
    constructor Test.Test(int) is not applicable
      (Test(int) has private access in Test)
    constructor Test.Test(String[]) is not applicable
      (argument mismatch; int cannot be converted to String[])
1 error

And the following two situations are not modified.
class T8255968 {
    Test c = new Test(0);
}
class Test {
    private Test(int x) {}
}

current and expected output:
error: Test(int) has private access in Test
    Test c = new Test(0);
             ^
1 error
class T8255968 {
    Test c = new Test(0);
}
class Test {
    Test(String x) {}
}

current and expected output:
error: incompatible types: int cannot be converted to String
    Test c = new Test(0);
                      ^
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error

I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing.

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

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

From mcimadamore at openjdk.java.net  Tue Nov 24 12:03:56 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 12:03:56 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible constructor
In-Reply-To: <otUxRw29LNMWg7fza_Oeym1cQMc6BZBejALOcvdL5sY=.1ed720b5-25fd-42f7-afac-faf5f9c27a64@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <J-7HHUn8Ne6qodq6B14lwx1Iw7eGmSiBuyueVL9Uij8=.609b4259-718f-4bf9-a490-a771f03f006e@github.com>
 <otUxRw29LNMWg7fza_Oeym1cQMc6BZBejALOcvdL5sY=.1ed720b5-25fd-42f7-afac-faf5f9c27a64@github.com>
Message-ID: <_H4ahKkEA4ya6WeJoA82pW2OM_dcLx3SxTz12B6iT50=.29fecbd1-c61c-4f1f-a190-2a5bd7db5a5e@github.com>

On Tue, 24 Nov 2020 11:44:06 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> 
> I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing.

This seems a good direction - but there are few dragons in there. As I said in my previous message, inaccessible members are just not overload resolution candidates and are "skipped" over by the overload selection logic. This is visible in examples like these:

class Sup {
   private void m(String s);
}

class Outer {
     void m() { ... }
     void m(Integer s) { ... }

     class Inner extends Sup {
          void test() {
               m();
           }
      }
}
In this example, overload selection should look for `m` candidates inside the `Outer` class. If, with a patch, you make access errors more similar to `WRONG_MTH`, or `WRONG_MTHS` kinds (by unifying them) chances are that overload selection will start thinking that it found a candidate in `Sup` and stop there - which would be against the JLS. I'm not saying it cannot be done, but more that it has to be done in a careful way - that is, you can only unify the error messages in situation where you know there's a mix of inaccessible and inapplicable methods, so you know already that overload selection will stop at that class.

Another aspect to look out for/test is method references - whatever we say here for plain method calls, has to hold for method reference selection - so you'll want to create specific tests which aims at showing that whatever change is applied, it also improves the situation with method references (or at least does not cause unwanted regressions there).

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

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

From david.holmes at oracle.com  Tue Nov 24 12:16:39 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2020 22:16:39 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
 <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
 <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>
Message-ID: <d428aa49-7a8c-bf14-8294-62239965d998@oracle.com>

Hi Remi,

On 24/11/2020 7:45 pm, Remi Forax wrote:
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> ?: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
>> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
>> <hotspot-dev at openjdk.java.net>
>> Envoy?: Mardi 24 Novembre 2020 02:04:55
>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)
> 
>> Hi Harold,
>>
>> On 24/11/2020 6:27 am, Harold Seigel wrote:
>>> Hi David,
>>>
>>> Thanks for looking at this.
>>>
>>> The intent was for method Class.permittedSubclasses() to be implemented
>>> similarly to Class.getNestMembers().? Are you suggesting that a security
>>> manager check be added to permittedSubclasses() similar to the security
>>> manager check in getNestMembers()?
>>
>> No I'm suggesting the change to the API is plain wrong. :) Please see
>> discussion in the CSR.
> 
> Given that the CSR is closed, i will answer here.
> There are two issues with the previous implementation of permittedSubclasses, first it's the only method that using method desc which means that people has to be aware on another non trivial concept (object that describes constant pool constant) to understand how to use the method then i've tested this API with my students, all but one what able to correctly derives the Class from a ClassDesc, so instead of asking every users of permittedSubclasses to go through the oops of getting Class from a ClassDesc, i think we can agree that it's better to move the burden from the user to the JDK implementors.

Why is the objective to get the Class objects? What purpose does that 
serve? The original API provided a descriptor for the contents of the 
permittedSubclasses attribute. I find it totally bizarre to have an API 
whose role is now to attempt to load all the subclasses of a sealed class.

YMMV.

David

>>
>> Cheers,
>> David
> 
> regards,
> R?mi
> 
>>
>>> Thanks, Harold
>>>
>>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>>> Hi Vincente,
>>>>
>>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>>> Please review the code for the second iteration of sealed classes. In
>>>>> this iteration we are:
>>>>>
>>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>>> - Also local classes are not considered when determining implicitly
>>>>> declared permitted direct subclasses of a sealed class or sealed
>>>>> interface
>>>>
>>>> The major change here seems to be that getPermittedSubclasses() now
>>>> returns actual Class objects instead of ClassDesc. My recollection
>>>> from earlier discussions here was that the use of ClassDesc was very
>>>> deliberate as the permitted subclasses may not actually exist and
>>>> there may be security concerns with returning them!
>>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>> -------------
>>>>>
>>>>> Commit messages:
>>>>>  ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>>
>>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>>>  ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>>>  ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>>>  ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>>>  ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>>>  ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>>>> pull/1227/head:pull/1227
>>>>>
>>>>> PR: https://git.openjdk.java.net/jdk/pull/1227

From forax at univ-mlv.fr  Tue Nov 24 13:56:22 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 24 Nov 2020 14:56:22 +0100 (CET)
Subject: RFR: 8246778: Compiler implementation for Sealed Classes
 (Second Preview)
In-Reply-To: <d428aa49-7a8c-bf14-8294-62239965d998@oracle.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
 <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
 <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>
 <d428aa49-7a8c-bf14-8294-62239965d998@oracle.com>
Message-ID: <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>
> Envoy?: Mardi 24 Novembre 2020 13:16:39
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

> Hi Remi,
> 
> On 24/11/2020 7:45 pm, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "David Holmes" <david.holmes at oracle.com>
>>> ?: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero"
>>> <vromero at openjdk.java.net>, "compiler-dev"
>>> <compiler-dev at openjdk.java.net>, "core-libs-dev"
>>> <core-libs-dev at openjdk.java.net>, "hotspot-dev"
>>> <hotspot-dev at openjdk.java.net>
>>> Envoy?: Mardi 24 Novembre 2020 02:04:55
>>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second
>>> Preview)
>> 
>>> Hi Harold,
>>>
>>> On 24/11/2020 6:27 am, Harold Seigel wrote:
>>>> Hi David,
>>>>
>>>> Thanks for looking at this.
>>>>
>>>> The intent was for method Class.permittedSubclasses() to be implemented
>>>> similarly to Class.getNestMembers().? Are you suggesting that a security
>>>> manager check be added to permittedSubclasses() similar to the security
>>>> manager check in getNestMembers()?
>>>
>>> No I'm suggesting the change to the API is plain wrong. :) Please see
>>> discussion in the CSR.
>> 
>> Given that the CSR is closed, i will answer here.
>> There are two issues with the previous implementation of permittedSubclasses,
>> first it's the only method that using method desc which means that people has
>> to be aware on another non trivial concept (object that describes constant pool
>> constant) to understand how to use the method then i've tested this API with my
>> students, all but one what able to correctly derives the Class from a
>> ClassDesc, so instead of asking every users of permittedSubclasses to go
>> through the oops of getting Class from a ClassDesc, i think we can agree that
>> it's better to move the burden from the user to the JDK implementors.
> 
> Why is the objective to get the Class objects? What purpose does that
> serve?

The whole idea of the reflection is to provide the runtime view of Java the language.
Even if such thing does not exist.

> The original API provided a descriptor for the contents of the
> permittedSubclasses attribute. I find it totally bizarre to have an API
> whose role is now to attempt to load all the subclasses of a sealed class.

It's as bizarre as Class.getClasses() loading all the member classes.

You are discovering that the reflection API is bizarre, and it is :)
It's not the view of the JVM, it's the view of Java at runtime, whatever it means.

> 
> YMMV.
> 
> David

R?mi

[1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Class.html#getClasses()

> 
>>>
>>> Cheers,
>>> David
>> 
>> regards,
>> R?mi
>> 
>>>
>>>> Thanks, Harold
>>>>
>>>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>>>> Hi Vincente,
>>>>>
>>>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>>>> Please review the code for the second iteration of sealed classes. In
>>>>>> this iteration we are:
>>>>>>
>>>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>>>> - Also local classes are not considered when determining implicitly
>>>>>> declared permitted direct subclasses of a sealed class or sealed
>>>>>> interface
>>>>>
>>>>> The major change here seems to be that getPermittedSubclasses() now
>>>>> returns actual Class objects instead of ClassDesc. My recollection
>>>>> from earlier discussions here was that the use of ClassDesc was very
>>>>> deliberate as the permitted subclasses may not actually exist and
>>>>> there may be security concerns with returning them!
>>>>>
>>>>> Cheers,
>>>>> David
>>>>> -----
>>>>>
>>>>>> -------------
>>>>>>
>>>>>> Commit messages:
>>>>>>  ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>>>
>>>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>>>>  ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>>>>  ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>>>>  ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>>>>  ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>>>>  ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>>>>> pull/1227/head:pull/1227
>>>>>>
> >>>>> PR: https://git.openjdk.java.net/jdk/pull/1227

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Nov 24 15:32:31 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 24 Nov 2020 15:32:31 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v2]
In-Reply-To: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
Message-ID: <0F2zSzccgh53MnY3qH8jVfFQR6U3B5Q7RNWqmLOWPGY=.d507497f-c6bc-459c-953a-5e911ebfad47@github.com>

> Hi all,
> 
> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Unify error messages for inaccessible constructor

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1389/files
  - new: https://git.openjdk.java.net/jdk/pull/1389/files/020311a1..a9a68149

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

  Stats: 87 lines in 16 files changed: 75 ins; 5 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1389/head:pull/1389

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Nov 24 15:37:58 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 24 Nov 2020 15:37:58 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v2]
In-Reply-To: <_H4ahKkEA4ya6WeJoA82pW2OM_dcLx3SxTz12B6iT50=.29fecbd1-c61c-4f1f-a190-2a5bd7db5a5e@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <J-7HHUn8Ne6qodq6B14lwx1Iw7eGmSiBuyueVL9Uij8=.609b4259-718f-4bf9-a490-a771f03f006e@github.com>
 <otUxRw29LNMWg7fza_Oeym1cQMc6BZBejALOcvdL5sY=.1ed720b5-25fd-42f7-afac-faf5f9c27a64@github.com>
 <_H4ahKkEA4ya6WeJoA82pW2OM_dcLx3SxTz12B6iT50=.29fecbd1-c61c-4f1f-a190-2a5bd7db5a5e@github.com>
Message-ID: <XcfDrTlhe-Pv1c9hMD7cm3-0WP4uksQV9yQJsFzCKDE=.a5d2ab43-9c7b-4369-bf98-8e008d211282@github.com>

On Tue, 24 Nov 2020 12:00:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Currently, the compiler output the error message depending on the order of the methods. Please see the below test cases.
>> 
>> - the `private Test(int x) {}` is at the end of other(one or more) method(s).
>> class T8255968 {
>>     Test c = new Test(0);
>> }
>> class Test {
>>     private Test(String[] x) {}
>>     Test(String x) {}
>>     private Test(int x) {}  // at the end
>> }
>> 
>> current output:
>> error: Test(int) has private access in Test
>>     Test c = new Test(0);
>>              ^
>> 1 error
>> - the `private Test(int x) {}` is not at the end of other(only one) method.
>> class T8255968 {
>>     Test c = new Test(0);
>> }
>> class Test {
>>     private Test(int x) {}  // not at the end
>>     Test(String x) {} // can be private, output same error message
>> }
>> 
>> current output:
>> error: incompatible types: int cannot be converted to String
>>     Test c = new Test(0);
>>                       ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> - the `private Test(int x) {}` is not at the end of other(more than one) methods.
>> class T8255968 {
>>     Test c = new Test(0);
>> }
>> class Test {
>>     private Test(String x) {}
>>     private Test(int x) {}  // not at the end
>>     Test(String[] x) {}
>> }
>> 
>> current output:
>> error: no suitable constructor found for Test(int)
>>     Test c = new Test(0);
>>              ^
>>     constructor Test.Test(String) is not applicable
>>       (argument mismatch; int cannot be converted to String)
>>     constructor Test.Test(String[]) is not applicable
>>       (argument mismatch; int cannot be converted to String[])
>> 1 error
>> These output messages which depending on the order of the methods would confuse users. Because the order of the methods  should not have any influence.
>> 
>> @mcimadamore According to your comment, I want to unify the output messages as below.
>> 
>> - the `private Test(int x) {}` is at the end of other(one or more) method(s).
>> class T8255968 {
>>     Test c = new Test(0);
>> }
>> class Test {
>>     private Test(String[] x) {}
>>     Test(String x) {}
>>     private Test(int x) {}  // at the end
>> }
>> 
>> expected output:
>> error: no suitable constructor found for Test(int)
>>     Test c = new Test(0);
>>              ^
>>     constructor Test.Test(String[]) is not applicable
>>       (argument mismatch; int cannot be converted to String[])
>>     constructor Test.Test(int) is not applicable
>>       (Test(int) has private access in Test)
>>     constructor Test.Test(String) is not applicable
>>       (argument mismatch; int cannot be converted to String)
>> 1 error
>> - the `private Test(int x) {}` is not at the end of other(only one) method.
>> class T8255968 {
>>     Test c = new Test(0);
>> }
>> class Test {
>>     private Test(int x) {}  // not at the end
>>     Test(String x) {} // can be private, output same error message
>> }
>> 
>> expected output:
>> error: no suitable constructor found for Test(int)
>>     Test c = new Test(0);
>>              ^
>>     constructor Test.Test(int) is not applicable
>>       (Test(int) has private access in Test)
>>     constructor Test.Test(String) is not applicable
>>       (argument mismatch; int cannot be converted to String)
>> 1 error
>> 
>> - the `private Test(int x) {}` is not at the end of other(more than one) methods.
>> class T8255968 {
>>     Test c = new Test(0);
>> }
>> class Test {
>>     private Test(String x) {}
>>     private Test(int x) {}  // not at the end
>>     Test(String[] x) {}
>> }
>> 
>> expected output:
>> error: no suitable constructor found for Test(int)
>>     Test c = new Test(0);
>>              ^
>>     constructor Test.Test(String) is not applicable
>>       (argument mismatch; int cannot be converted to String)
>>     constructor Test.Test(int) is not applicable
>>       (Test(int) has private access in Test)
>>     constructor Test.Test(String[]) is not applicable
>>       (argument mismatch; int cannot be converted to String[])
>> 1 error
>> 
>> And the following two situations are not modified.
>> class T8255968 {
>>     Test c = new Test(0);
>> }
>> class Test {
>>     private Test(int x) {}
>> }
>> 
>> current and expected output:
>> error: Test(int) has private access in Test
>>     Test c = new Test(0);
>>              ^
>> 1 error
>> class T8255968 {
>>     Test c = new Test(0);
>> }
>> class Test {
>>     Test(String x) {}
>> }
>> 
>> current and expected output:
>> error: incompatible types: int cannot be converted to String
>>     Test c = new Test(0);
>>                       ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing.
>
>> 
>> I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing.
> 
> This seems a good direction - but there are few dragons in there. As I said in my previous message, inaccessible members are just not overload resolution candidates and are "skipped" over by the overload selection logic. This is visible in examples like these:
> 
> class Sup {
>    private void m(String s);
> }
> 
> class Outer {
>      void m() { ... }
>      void m(Integer s) { ... }
> 
>      class Inner extends Sup {
>           void test() {
>                m();
>            }
>       }
> }
> In this example, overload selection should look for `m` candidates inside the `Outer` class. If, with a patch, you make access errors more similar to `WRONG_MTH`, or `WRONG_MTHS` kinds (by unifying them) chances are that overload selection will start thinking that it found a candidate in `Sup` and stop there - which would be against the JLS. I'm not saying it cannot be done, but more that it has to be done in a careful way - that is, you can only unify the error messages in situation where you know there's a mix of inaccessible and inapplicable methods, so you know already that overload selection will stop at that class.
> 
> Another aspect to look out for/test is method references - whatever we say here for plain method calls, has to hold for method reference selection - so you'll want to create specific tests which aims at showing that whatever change is applied, it also improves the situation with method references (or at least does not cause unwanted regressions there).

I update the code which unifies the error messages. I use the following command to run test locally and all the test passed.
make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release JOBS=8

output:
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/langtools/tools/javac                   3503  3503     0     0   
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'linux-x86_64-server-release'

Thank you for taking the time to review.

Best Regards.

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

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

From mcimadamore at openjdk.java.net  Tue Nov 24 18:45:00 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 18:45:00 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v2]
In-Reply-To: <0F2zSzccgh53MnY3qH8jVfFQR6U3B5Q7RNWqmLOWPGY=.d507497f-c6bc-459c-953a-5e911ebfad47@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <0F2zSzccgh53MnY3qH8jVfFQR6U3B5Q7RNWqmLOWPGY=.d507497f-c6bc-459c-953a-5e911ebfad47@github.com>
Message-ID: <rcoMfAOs1N7XxfjK7rng9A5eyg2ghgL4eqvVdWzoUlc=.f727d0c2-8a76-496a-85d2-c4be28445f12@github.com>

On Tue, 24 Nov 2020 15:32:31 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
>> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify error messages for inaccessible constructor

Looks a nice generalization. However I still have some concerns:

* the logic, as I feared, is turning `ABSENT` into `WRONG_MTHS` - note that AccessError and InapplicableSymbol/s have different properties when it comes to method lookup - more specifically look at ResolveError::exists which return `false` in one case and `true` in the other. This is used, among other things, to shortcircuit method lookups (see `Resolve::findFun`) - so flipping from `AccessError` to `InapplicableSymbols` is almost guaranteed to cause a change in behavior in the compiler. That said, given the nature of the code involved, is not super trivial to come up with an example which demonstrates the difference - but I'll keep thinking.

* While the tests you add are good, I don't see the corresponding tests for the method reference case.

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

> 1588:                     return new InapplicableSymbolError(currentResolutionContext);
> 1589:                 case HIDDEN:
> 1590:                     if (bestSoFar instanceof AccessError) {

These changes are a bit convoluted - but that's the nature of the code in here. I also see that you special case AccessError (since now we have, from modules, different kind of HIDDEN error class, which is probably worth another cleanup). If an access error shows up and we already have an access error, you add that to the list of "candidates", and return a WRONG_MTHS kind. Sounds logical.

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

> 1607:             AccessError curAccessError = new AccessError(env, site, sym);
> 1608:             JCDiagnostic curDiagnostic = curAccessError.getDiagnostic(JCDiagnostic.DiagnosticType.FRAGMENT, null, null, site, null, argtypes, typeargtypes);
> 1609:             if (bestSoFar.kind == ABSENT_MTH) {

This seems like a good generalization of existing code. Give a new access error, we have following cases:

* best was `ABSENT` - in which case we return the access error
* best was `WRONG_MTH/WRONG_MTHS/HIDDEN` in which case we return `WRONG_MTHS` with access error added to the list

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

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

From david.holmes at oracle.com  Tue Nov 24 22:49:25 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Nov 2020 08:49:25 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
 <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
 <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>
 <d428aa49-7a8c-bf14-8294-62239965d998@oracle.com>
 <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr>
Message-ID: <d6e01885-9db7-0958-b8b7-45595e8f9cdc@oracle.com>

On 24/11/2020 11:56 pm, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
>> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
>> <hotspot-dev at openjdk.java.net>
>> Envoy?: Mardi 24 Novembre 2020 13:16:39
>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)
> 
>> Hi Remi,
>>
>> On 24/11/2020 7:45 pm, Remi Forax wrote:
>>> ----- Mail original -----
>>>> De: "David Holmes" <david.holmes at oracle.com>
>>>> ?: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero"
>>>> <vromero at openjdk.java.net>, "compiler-dev"
>>>> <compiler-dev at openjdk.java.net>, "core-libs-dev"
>>>> <core-libs-dev at openjdk.java.net>, "hotspot-dev"
>>>> <hotspot-dev at openjdk.java.net>
>>>> Envoy?: Mardi 24 Novembre 2020 02:04:55
>>>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second
>>>> Preview)
>>>
>>>> Hi Harold,
>>>>
>>>> On 24/11/2020 6:27 am, Harold Seigel wrote:
>>>>> Hi David,
>>>>>
>>>>> Thanks for looking at this.
>>>>>
>>>>> The intent was for method Class.permittedSubclasses() to be implemented
>>>>> similarly to Class.getNestMembers().? Are you suggesting that a security
>>>>> manager check be added to permittedSubclasses() similar to the security
>>>>> manager check in getNestMembers()?
>>>>
>>>> No I'm suggesting the change to the API is plain wrong. :) Please see
>>>> discussion in the CSR.
>>>
>>> Given that the CSR is closed, i will answer here.
>>> There are two issues with the previous implementation of permittedSubclasses,
>>> first it's the only method that using method desc which means that people has
>>> to be aware on another non trivial concept (object that describes constant pool
>>> constant) to understand how to use the method then i've tested this API with my
>>> students, all but one what able to correctly derives the Class from a
>>> ClassDesc, so instead of asking every users of permittedSubclasses to go
>>> through the oops of getting Class from a ClassDesc, i think we can agree that
>>> it's better to move the burden from the user to the JDK implementors.
>>
>> Why is the objective to get the Class objects? What purpose does that
>> serve?
> 
> The whole idea of the reflection is to provide the runtime view of Java the language.
> Even if such thing does not exist.

And providing some kind of descriptor for an attribute fulfills that 
role. Nothing says it has to produce Class objects.

>> The original API provided a descriptor for the contents of the
>> permittedSubclasses attribute. I find it totally bizarre to have an API
>> whose role is now to attempt to load all the subclasses of a sealed class.
> 
> It's as bizarre as Class.getClasses() loading all the member classes.

Not at all. Nested types are considered to be part of the same 
implementation as the outer type. They are intimately related and all 
part of the same accessibility domain.

Loading subtypes that likely exist outside of the current package (else 
why would you need to be using sealed types) is a completely different 
matter.

> You are discovering that the reflection API is bizarre, and it is :)

I don't find it that bizarre.

> It's not the view of the JVM, it's the view of Java at runtime, whatever it means.

It means whatever we implement it to mean. So if we implement it in 
bizarre ways then it will be perceived as bizarre.

David
-----

>>
>> YMMV.
>>
>> David
> 
> R?mi
> 
> [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Class.html#getClasses()
> 
>>
>>>>
>>>> Cheers,
>>>> David
>>>
>>> regards,
>>> R?mi
>>>
>>>>
>>>>> Thanks, Harold
>>>>>
>>>>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>>>>> Hi Vincente,
>>>>>>
>>>>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>>>>> Please review the code for the second iteration of sealed classes. In
>>>>>>> this iteration we are:
>>>>>>>
>>>>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>>>>> - Also local classes are not considered when determining implicitly
>>>>>>> declared permitted direct subclasses of a sealed class or sealed
>>>>>>> interface
>>>>>>
>>>>>> The major change here seems to be that getPermittedSubclasses() now
>>>>>> returns actual Class objects instead of ClassDesc. My recollection
>>>>>> from earlier discussions here was that the use of ClassDesc was very
>>>>>> deliberate as the permitted subclasses may not actually exist and
>>>>>> there may be security concerns with returning them!
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> -------------
>>>>>>>
>>>>>>> Commit messages:
>>>>>>>   ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>>>>
>>>>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>>>>>   ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>>>>>   ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>>>>>   ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>>>>>   ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>>>>>   ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>>>>>> pull/1227/head:pull/1227
>>>>>>>
>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/1227

From mchung at openjdk.java.net  Tue Nov 24 23:02:53 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 24 Nov 2020 23:02:53 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
 <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
Message-ID: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>

On Tue, 17 Nov 2020 00:25:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Package.java line 227:
>> 
>>> 225:      * This method reports on a distinct concept of sealing from
>>> 226:      * {@link Class#isSealed() Class::isSealed}.
>>> 227:      *
>> 
>> This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing.
>
> I agree.  This @apiNote needs more clarification to help the readers to understand the context here.    One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes".

I added an API note in `Package::isSealed` [1] to clarify sealed package vs sealed class or interface.

The API note you added in `Class::isSealed` can be clarified in a similar fashion like: "Sealed class or interface has no relationship with {@linkplain Package#isSealed package sealing}".

[1] https://github.com/openjdk/jdk/commit/3c230b8a

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

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

From forax at univ-mlv.fr  Tue Nov 24 23:18:55 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 25 Nov 2020 00:18:55 +0100 (CET)
Subject: RFR: 8246778: Compiler implementation for Sealed Classes
 (Second Preview)
In-Reply-To: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
 <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
 <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
Message-ID: <1050079243.1769685.1606259935502.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Mandy Chung" <mchung at openjdk.java.net>
> ?: "compiler-dev" <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>
> Envoy?: Mercredi 25 Novembre 2020 00:02:53
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

> On Tue, 17 Nov 2020 00:25:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:
> 
>>> src/java.base/share/classes/java/lang/Package.java line 227:
>>> 
>>>> 225:      * This method reports on a distinct concept of sealing from
>>>> 226:      * {@link Class#isSealed() Class::isSealed}.
>>>> 227:      *
>>> 
>>> This API note will be very confusing to readers. I think the javadoc will need
>>> to be fleshed out and probably will need to link to a section the Package class
>>> description that defines the legacy concept of sealing.
>>
>> I agree.  This @apiNote needs more clarification to help the readers to
>> understand the context here.    One thing we could do in the Package class
>> description to add a "Package Sealing" section that can also explain that it
>> has no relationship to "sealed classes".
> 
> I added an API note in `Package::isSealed` [1] to clarify sealed package vs
> sealed class or interface.
> 
> The API note you added in `Class::isSealed` can be clarified in a similar
> fashion like: "Sealed class or interface has no relationship with {@linkplain
> Package#isSealed package sealing}".

Hi Mandy,
given that almost nobody knows about sealed packages, i'm not sure that adding a reference to Package::isSealed in Class::isSealed actually helps, it might be confusing.

> 
> [1] https://github.com/openjdk/jdk/commit/3c230b8a
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1227

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Nov 25 07:03:14 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 25 Nov 2020 07:03:14 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
Message-ID: <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>

> Hi all,
> 
> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision:

 - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability.
 - Add corresponding tests for the method reference cases.
 - Add comments to state the situations

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1389/files
  - new: https://git.openjdk.java.net/jdk/pull/1389/files/a9a68149..98ee2f2a

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

  Stats: 268 lines in 23 files changed: 250 ins; 4 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1389/head:pull/1389

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Nov 25 07:22:56 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 25 Nov 2020 07:22:56 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v2]
In-Reply-To: <rcoMfAOs1N7XxfjK7rng9A5eyg2ghgL4eqvVdWzoUlc=.f727d0c2-8a76-496a-85d2-c4be28445f12@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <0F2zSzccgh53MnY3qH8jVfFQR6U3B5Q7RNWqmLOWPGY=.d507497f-c6bc-459c-953a-5e911ebfad47@github.com>
 <rcoMfAOs1N7XxfjK7rng9A5eyg2ghgL4eqvVdWzoUlc=.f727d0c2-8a76-496a-85d2-c4be28445f12@github.com>
Message-ID: <WT7vtE2N2ftF9fpY7qFxq-238cpTM0gpbW83ys2PUBg=.8bf36bcd-ae2a-4bf0-b698-6a50305f1005@github.com>

On Tue, 24 Nov 2020 18:42:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>  That said, given the nature of the code involved, is not super trivial to come up with an example which demonstrates the difference

I can't find a example to demonstrate the differences too.

> While the tests you add are good, I don't see the corresponding tests for the method reference case.

I add corresponding tests about the method reference cases.

> If an access error shows up and we already have an access error, you add that to the list of "candidates", and return a WRONG_MTHS kind.

It should be:  If an **InapplicableMethodException** occurs and we already have an access error

I add some comments to state the situations and improve readability.

Thank you for taking the time to review.

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

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

From chegar at openjdk.java.net  Wed Nov 25 11:08:19 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 25 Nov 2020 11:08:19 GMT
Subject: RFR: 8256755: Update build.tools.depend.Depend to handle record
 components in API signatures [v2]
In-Reply-To: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com>
References: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com>
Message-ID: <r_PSsVstBOaTCbHaAB79RX5R7etKFiXkVEO5fn_BPGU=.ea8b2231-7ac5-4add-9b6b-54edb1f0b681@github.com>

> The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records.
> 
> The components of a public record class, that is a member of an exported package, are logically part of the module's API. The name, type, and order are significant. This issue updates the build tool to include the aforementioned component characteristics.
> 
> This issue is a blocker to adding any public record types to the JDK - since the build will fail.

Chris Hegarty 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:

 - Additional tests for explicit constructors
 - Merge branch 'master' into depends
 - Update the Depend(ency) build tool to handle the record attribute

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1405/files
  - new: https://git.openjdk.java.net/jdk/pull/1405/files/ce0089d4..9ff3b10c

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

  Stats: 295440 lines in 2312 files changed: 182698 ins; 87418 del; 25324 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1405.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1405/head:pull/1405

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

From chegar at openjdk.java.net  Wed Nov 25 11:39:55 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 25 Nov 2020 11:39:55 GMT
Subject: Integrated: 8256755: Update build.tools.depend.Depend to handle
 record components in API signatures
In-Reply-To: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com>
References: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com>
Message-ID: <66B56fY1kM9aCoTSxCYVs0g_KJsV7lirZv63ujJ32V8=.502db1ba-003a-45eb-9d63-93becab0afe9@github.com>

On Tue, 24 Nov 2020 09:59:44 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records.
> 
> The components of a public record class, that is a member of an exported package, are logically part of the module's API. The name, type, and order are significant. This issue updates the build tool to include the aforementioned component characteristics.
> 
> This issue is a blocker to adding any public record types to the JDK - since the build will fail.

This pull request has now been integrated.

Changeset: b0bd0c24
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b0bd0c24
Stats:     41 lines in 2 files changed: 39 ins; 0 del; 2 mod

8256755: Update build.tools.depend.Depend to handle record components in API signatures

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.java.net  Wed Nov 25 12:43:59 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 25 Nov 2020 12:43:59 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
 <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
 <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
Message-ID: <o8euUFO4RVWh0WHVzhNfzLMWX79bYp4ZFnQYOtGhv1g=.57bdc5a7-a31c-4597-87ae-0369f5bbe036@github.com>

On Tue, 24 Nov 2020 23:00:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I agree.  This @apiNote needs more clarification to help the readers to understand the context here.    One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes".
>
> I added an API note in `Package::isSealed` [1] to clarify sealed package vs sealed class or interface.
> 
> The API note you added in `Class::isSealed` can be clarified in a similar fashion like: "Sealed class or interface has no relationship with {@linkplain Package#isSealed package sealing}".
> 
> [1] https://github.com/openjdk/jdk/commit/3c230b8a

Thanks for that update, Mandy! I've tweaked the API note as per your recommendation. I'll publish a fixed PR later, reflecting the other review comments as well.

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

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

From mcimadamore at openjdk.java.net  Wed Nov 25 13:47:00 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 25 Nov 2020 13:47:00 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
Message-ID: <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>

On Wed, 25 Nov 2020 07:03:14 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
>> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability.
>  - Add corresponding tests for the method reference cases.
>  - Add comments to state the situations

I left some additional comments on tests. I plan to do some experiments to validate that we are not going to introduce bad regressions.

test/langtools/tools/javac/T8255968/T8255968_10.java line 24:

> 22:  */
> 23: 
> 24: class T8255968 {

Can you please disambiguate all these class names? Having the same class name in multiple tests can create havocs, especially when running in concurrent mode. Please make sure that classes have different names, and that the auxiliary classes defined in these test are, instead, defined as nested classes (so that, again, everything will be encapsulated on a test-by-test basis, w/o any risk of a test picking up a class from another test).

test/langtools/tools/javac/T8255968/T8255968.java line 27:

> 25:  * @test
> 26:  * @bug 8255968
> 27:  * @summary Confusing error message for inaccessible constructor

Any reason as to why you went for this single file which lists all tests rather than adding jtreg tags in all the various test cases? AFAIK, in the javac code base the latter style is often preferred.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Nov 25 16:43:58 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 25 Nov 2020 16:43:58 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
 <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
Message-ID: <eD34wWmC9ahraRWL-TzklHnun2EcGXxxPxRNUpg37lA=.1b83f915-4aca-48f0-aea7-fe4600e9fafc@github.com>

On Wed, 25 Nov 2020 13:42:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability.
>>  - Add corresponding tests for the method reference cases.
>>  - Add comments to state the situations
>
> test/langtools/tools/javac/T8255968/T8255968_10.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: class T8255968 {
> 
> Can you please disambiguate all these class names? Having the same class name in multiple tests can create havocs, especially when running in concurrent mode. Please make sure that classes have different names, and that the auxiliary classes defined in these test are, instead, defined as nested classes (so that, again, everything will be encapsulated on a test-by-test basis, w/o any risk of a test picking up a class from another test).

It sounds a great way to avoid some problem. I would revise my code to meet this style. Thanks for the suggestion.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Nov 25 17:00:59 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 25 Nov 2020 17:00:59 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
 <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
Message-ID: <jSh1_ft0xbNBOsNvBe67UACwfplSr4jBdQ460GoV6Jo=.35785335-c26b-48b3-a0e9-a72d5d0c360a@github.com>

On Wed, 25 Nov 2020 13:42:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability.
>>  - Add corresponding tests for the method reference cases.
>>  - Add comments to state the situations
>
> test/langtools/tools/javac/T8255968/T8255968.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8255968
>> 27:  * @summary Confusing error message for inaccessible constructor
> 
> Any reason as to why you went for this single file which lists all tests rather than adding jtreg tags in all the various test cases? AFAIK, in the javac code base the latter style is often preferred.

I have seem these two styles in the test code base. I don't prefer any style because these two styles both work well. It is better to have a standard style to guide developers. But now it has no such standard.

> AFAIK, in the javac code base the latter style is often preferred.

According to your comment, I would revise the tests to meets the latter style.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Nov 25 17:34:57 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 25 Nov 2020 17:34:57 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
 <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
Message-ID: <mvyRuBGSkEHdMZBwYtjZyQndqROvBMr8OIwzvWv38S8=.1d58f8b5-d8c4-4fda-9943-082278cea832@github.com>

On Wed, 25 Nov 2020 13:44:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability.
>>  - Add corresponding tests for the method reference cases.
>>  - Add comments to state the situations
>
> I left some additional comments on tests. I plan to do some experiments to validate that we are not going to introduce bad regressions.

The old style which is shown below is not good.
class T8255968 {
    Test c = new Test(0);
}

class Test {
    private Test(int x) {}
}

> and that the auxiliary classes defined in these test are, instead, defined as nested classes

I change it to the following style according to the comment. But the compiler compiles it successfully because the outer class can visit private method of its inner class.
class T8255968_1 {
    Test c = new Test(0);

    class Test {
        private Test(int x) {}
    }
}


So I would like to use the following style(don't use nested classes).
class T8255968_1 {
    T8255968Test1 c = new T8255968Test1(0);
}

class T8255968Test1 {
    private T8255968Test1(int x) {}
}

@mcimadamore Do you agree with this style?

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

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

From mcimadamore at openjdk.java.net  Wed Nov 25 18:53:53 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 25 Nov 2020 18:53:53 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
 <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
Message-ID: <U2-3quCDFU_JElvF70uIEQX8TDx_jSVAT5g3ejou_2E=.9a42898d-a8f8-4728-b3bd-c15ae2211614@github.com>

On Wed, 25 Nov 2020 13:44:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability.
>>  - Add corresponding tests for the method reference cases.
>>  - Add comments to state the situations
>
> I left some additional comments on tests. I plan to do some experiments to validate that we are not going to introduce bad regressions.

> @mcimadamore Do you agree with this style?

Yeah - of course nesting things is gonna mess up with access checks - sorry for sending you down the wrong direction!

You could prefix every class in the test with `T8255968_1` e.g.

class T8255968_1 {
    T8255968Test1 c = new T8255968_1_Test(0);
}

class T8255968_1_Test {
    private T8255968_1_Test(int x) {}
}

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

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

From joe.darcy at oracle.com  Wed Nov 25 23:49:39 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 25 Nov 2020 15:49:39 -0800
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v3]
In-Reply-To: <_9Wkj9PHga5Y5GTI2RpJqyCtdYJs3PXI2R8falBJYlA=.26b53df7-c507-4242-8973-f7af82a25213@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <_9Wkj9PHga5Y5GTI2RpJqyCtdYJs3PXI2R8falBJYlA=.26b53df7-c507-4242-8973-f7af82a25213@github.com>
Message-ID: <b36ae6db-5adb-c0a2-8557-8440a22c5452@oracle.com>

FYI, I had a good experience taking a trial run of this patch to update 
the java.compiler APIs to use the new feature. I didn't find any issues; 
a specdiff comparing with and without use of the new tag didn't have any 
unexpected diffs. (There were cases where small wording differences 
existed and were regularized in the patch.)

After this goes back, looking forward to pushing a fix for JDK-8256917: 
Use combo @returns tag in java.compiler javadoc.

Cheers,

-Joe

On 11/20/2020 4:34 PM, Jonathan Gibbons wrote:
>> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
>>
>> The goal is to be able to simplify the following common pattern:
>>
>>      /**
>>       * Returns the result. Optional additional text.
>>       * @return the result
>>       */
>>      int method() {
>>
>> by
>>
>>      /**
>>       * {@return the result} Optional additional text.
>>       */
>>      int method() {
>>
>> Note:
>>
>> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
>> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag.
>> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
>> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>
>    Update DocCommentParser to permit nested inline tags in specified cases: @return
>
> -------------
>
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/1355/files
>    - new: https://git.openjdk.java.net/jdk/pull/1355/files/89846ff1..87edfb0c
>
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=02
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=01-02
>
>    Stats: 88 lines in 3 files changed: 82 ins; 3 del; 3 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/1355.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355
>
> PR: https://git.openjdk.java.net/jdk/pull/1355

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Nov 26 03:36:53 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 26 Nov 2020 03:36:53 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v4]
In-Reply-To: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
Message-ID: <6-LVKf_d0EqzNytbRg1FQ-JZYSYX55HpGpzCJMBacXY=.79ed53cd-27d4-4802-b816-b27a7e562228@github.com>

> Hi all,
> 
> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Revise test cases. Rename classes and divide the jtreg tags by unit.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1389/files
  - new: https://git.openjdk.java.net/jdk/pull/1389/files/98ee2f2a..dc029923

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

  Stats: 269 lines in 31 files changed: 113 ins; 44 del; 112 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1389/head:pull/1389

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Nov 26 15:21:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 26 Nov 2020 15:21:55 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <U2-3quCDFU_JElvF70uIEQX8TDx_jSVAT5g3ejou_2E=.9a42898d-a8f8-4728-b3bd-c15ae2211614@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
 <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
 <U2-3quCDFU_JElvF70uIEQX8TDx_jSVAT5g3ejou_2E=.9a42898d-a8f8-4728-b3bd-c15ae2211614@github.com>
Message-ID: <NveL4QvyJAGN15-Q9WpuE5-CsyCq2DfW3aOBU2qBGls=.2556e891-c2c8-48ae-9328-70fb52ec21d2@github.com>

On Wed, 25 Nov 2020 18:51:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I left some additional comments on tests. I plan to do some experiments to validate that we are not going to introduce bad regressions.
>
>> @mcimadamore Do you agree with this style?
> 
> Yeah - of course nesting things is gonna mess up with access checks - sorry for sending you down the wrong direction!
> 
> You could prefix every class in the test with `T8255968_1` e.g.
> 
> class T8255968_1 {
>     T8255968Test1 c = new T8255968_1_Test(0);
> }
> 
> class T8255968_1_Test {
>     private T8255968_1_Test(int x) {}
> }

I update the code about test cases. Thank you for taking the time to review.

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

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

From hannesw at openjdk.java.net  Thu Nov 26 16:54:06 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 26 Nov 2020 16:54:06 GMT
Subject: RFR: 8242652: Throw SkippedException if no JS engine availabe in
 TestSearchScript [v2]
In-Reply-To: <VcraDYMQ9MnrhQh_F5vz6QLCrqcG2erOCSAbdoe9758=.67b995d2-12e3-4ccb-b8d7-00d5e3236583@github.com>
References: <VcraDYMQ9MnrhQh_F5vz6QLCrqcG2erOCSAbdoe9758=.67b995d2-12e3-4ccb-b8d7-00d5e3236583@github.com>
Message-ID: <kk9g31BsZRc6Tcll48WGY4JGzR59eHQkn5DZrIVdX54=.563c8705-73ad-41ea-a0a6-ede32502f234@github.com>

> This is a simple change to throw jtreg.SkippedException if no JavaScript engine is available to run the TestSearchScript test. In my previous attempt I tried to use the SkippedException class already present elsewhere in the test tree, not realizing I couuld just copy/create the exception in the javadoc test library.
> 
> Note that while the test is skipped correctly if no JS engine is available, the test will currently fail in the presence of a JS engine such as GraalJS. This is fixed by JDK-8244535.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Use existing SkippedException class in TestSearchScript.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1412/files
  - new: https://git.openjdk.java.net/jdk/pull/1412/files/d6bc3b79..02ab014b

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

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

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

From prappo at openjdk.java.net  Thu Nov 26 16:59:00 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 26 Nov 2020 16:59:00 GMT
Subject: RFR: 8242652: Throw SkippedException if no JS engine availabe in
 TestSearchScript [v2]
In-Reply-To: <kk9g31BsZRc6Tcll48WGY4JGzR59eHQkn5DZrIVdX54=.563c8705-73ad-41ea-a0a6-ede32502f234@github.com>
References: <VcraDYMQ9MnrhQh_F5vz6QLCrqcG2erOCSAbdoe9758=.67b995d2-12e3-4ccb-b8d7-00d5e3236583@github.com>
 <kk9g31BsZRc6Tcll48WGY4JGzR59eHQkn5DZrIVdX54=.563c8705-73ad-41ea-a0a6-ede32502f234@github.com>
Message-ID: <LjUOS4RUfm-03wC_wdRKkHk9dCH-FXlSDghDZZuB0Uw=.6ec6b99e-f9e2-44aa-8356-581647499692@github.com>

On Thu, 26 Nov 2020 16:54:06 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This is a simple change to throw jtreg.SkippedException if no JavaScript engine is available to run the TestSearchScript test. In my previous attempt I tried to use the SkippedException class already present elsewhere in the test tree, not realizing I couuld just copy/create the exception in the javadoc test library.
>> 
>> Note that while the test is skipped correctly if no JS engine is available, the test will currently fail in the presence of a JS engine such as GraalJS. This is fixed by JDK-8244535.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use existing SkippedException class in TestSearchScript.java

This change looks good to me. Since you've changed `test/langtools/TEST.ROOT`, please make sure all the langtools tests pass (not just `TestSearchScript.java`) before integrating this change.

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

Marked as reviewed by prappo (Reviewer).

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

From hannesw at openjdk.java.net  Fri Nov 27 09:46:58 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 27 Nov 2020 09:46:58 GMT
Subject: Integrated: 8242652: Throw SkippedException if no JS engine availabe
 in TestSearchScript
In-Reply-To: <VcraDYMQ9MnrhQh_F5vz6QLCrqcG2erOCSAbdoe9758=.67b995d2-12e3-4ccb-b8d7-00d5e3236583@github.com>
References: <VcraDYMQ9MnrhQh_F5vz6QLCrqcG2erOCSAbdoe9758=.67b995d2-12e3-4ccb-b8d7-00d5e3236583@github.com>
Message-ID: <Ics8qy1xxj1CLavuL089rbMA2nAPq3VjLqPP6t-dMgg=.780ff42a-3f54-4777-a4db-7d1ea965f4a7@github.com>

On Tue, 24 Nov 2020 15:08:27 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This is a simple change to throw jtreg.SkippedException if no JavaScript engine is available to run the TestSearchScript test. In my previous attempt I tried to use the SkippedException class already present elsewhere in the test tree, not realizing I couuld just copy/create the exception in the javadoc test library.
> 
> Note that while the test is skipped correctly if no JS engine is available, the test will currently fail in the presence of a JS engine such as GraalJS. This is fixed by JDK-8244535.

This pull request has now been integrated.

Changeset: f2f3ba92
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f2f3ba92
Stats:     20 lines in 2 files changed: 8 ins; 10 del; 2 mod

8242652: Throw SkippedException if no JS engine availabe in TestSearchScript

Reviewed-by: prappo

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

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

From github.com+3896345+hltj at openjdk.java.net  Fri Nov 27 13:19:56 2020
From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei)
Date: Fri, 27 Nov 2020 13:19:56 GMT
Subject: RFR: 8229862: NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570)
In-Reply-To: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>
References: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>
Message-ID: <S5lEOSsbhBqYgRK2B78Z5wpzS-f0SWbKFKmn9uxmsMk=.1fe25ad2-c230-4355-90bf-143f1d5aff50@github.com>

On Mon, 16 Nov 2020 10:32:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Based on Bernard's code from:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015225.html
> 
> Capturing anonymous classes inside lambdas may fail to compile, because:
> -the captured variables are not detected correctly, because `LambdaToMethod...captureLocalClassDefs` needs to find the AST node for the given `ClassSymbol`, but it has not yet been added into the `localClassDefs`. The proposed solution is to re-order the tasks done for JCNewClass, and call the super implementation sooner. This will enter the `ClassSymbol` and corresponding AST node into `localClassDefs` before the capture variables detection.
> -inside the anonymous class definition, some references to the captured variables are replaced using a map that maps captured variables for lambdas (`lambdaTranslationMap`) - but inside the anonymous class, there the captured variables should be mapped using the anonymous class' map/proxies (to fields). The proposed solution is to clear `lambdaTranslationMap` before processing the anonymous class body.

Great! It fix the issue I have met when I trying to fix another issue (#1479).

My minimal reproducing code is:

 java
class Main {
    static Runnable runnable = () -> {
        String s0 = "hello";

        class Local {
            int i = s0.length();
        }

        Runnable dummy = () -> new Local() {
        };
    };
}

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

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

From jlahoda at openjdk.java.net  Fri Nov 27 15:45:12 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 27 Nov 2020 15:45:12 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol generator
 CreateSymbols
Message-ID: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>

Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
-updating and moving tests into test/langtools, so that it is easier to run them.
-fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
-fixing the -Xprint annotation processor to print record component annotations.

Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

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

Commit messages:
 - Update CreateSymbolsTest.java
 - Cleaning TODO.
 - Cleaning TODO.
 - Adding test verifying javac can read Record attribute properly.
 - Cleanup.
 - JDK-8256950: Add record attribute support to symbol generator CreateSymbols

Changes: https://git.openjdk.java.net/jdk/pull/1480/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256950
  Stats: 1910 lines in 12 files changed: 1147 ins; 745 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

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

From rriggs at openjdk.java.net  Fri Nov 27 16:35:55 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 16:35:55 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>

On Fri, 20 Nov 2020 17:15:22 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

/**
  * {@return the result} Optional additional text.
  */
 ```
The java source looks a bit odd/unusual because the "first sentence" does not appear to end with a period.
Though it seems like a convenience to include the '.' in the expansion, the source might be clearer if it did not, as in:
/**
  * {@return the result}. Optional additional text.
  */ 
Similarly, prepending the "Returns", forces the verb, which is conventional but always the most appropriate word.
Changing the expansion to be only the contents of @ return would allow more flexible use.
It would put more responsibility on the developer to form the first sentence. (With "Returns"... and the "." outside the tag.

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

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

From jlahoda at openjdk.java.net  Fri Nov 27 17:06:03 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 27 Nov 2020 17:06:03 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
Message-ID: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>

This pull request replaces https://github.com/openjdk/jdk/pull/1227.

>From the original PR:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> 
>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> 
>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> 
>     * adding code to make sure that annotations can't be sealed
> 
>     * improving some tests
> 
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

This PR strives to reflect the review comments from 1227:
 * adjustments to javadoc of j.l.Class methods
 * package access checks in Class.getPermittedSubclasses()
 * fixed to the narrowing conversion/castability as pointed out by Maurizio

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

Commit messages:
 - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
 - Improving getPermittedSubclasses() javadoc.
 - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
 - Removing unnecessary file.
 - Tweaking javadoc.
 - Reflecting review comments w.r.t. narrowing conversion.
 - Improving checks in getPermittedSubclasses()
 - Merging master into JDK-8246778
 - Adding checkPackageAccess to Class.getPermittedSubclasses().
 - 8246778: Compiler implementation for Sealed Classes (Second Preview)

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

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

From jjg at openjdk.java.net  Fri Nov 27 17:29:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 27 Nov 2020 17:29:56 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
In-Reply-To: <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
Message-ID: <XWfUZPhzhQTcjco_07M_kO0eNNo44unj4pCXpe4MGZs=.4fffd031-d076-437e-ae89-d9b66e1f8786@github.com>

On Fri, 27 Nov 2020 16:33:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
>> 
>> The goal is to be able to simplify the following common pattern:
>> 
>>     /**
>>      * Returns the result. Optional additional text.
>>      * @return the result
>>      */
>>     int method() { 
>> 
>> by 
>> 
>>     /**
>>      * {@return the result} Optional additional text.
>>      */
>>     int method() { 
>> 
>> Note:
>> 
>> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
>> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
>> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
>> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.
>
> /**
>   * {@return the result} Optional additional text.
>   */
>  ```
> The java source looks a bit odd/unusual because the "first sentence" does not appear to end with a period.
> Though it seems like a convenience to include the '.' in the expansion, the source might be clearer if it did not, as in:
> /**
>   * {@return the result}. Optional additional text.
>   */ 
> Similarly, prepending the "Returns", forces the verb, which is conventional but always the most appropriate word.
> Changing the expansion to be only the contents of @ return would allow more flexible use.
> It would put more responsibility on the developer to form the first sentence. (With "Returns"... and the "." outside the tag.

@RogerRiggs I think that having to write `Returns {@return the result}.` would look more weird than the current proposal to omit the `.`.  Note also that the proposed form matches the existing `{@summary ...}` tag which can be used to explicit define the "first sentence" that appears in summary tables.

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

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

From mcimadamore at openjdk.java.net  Fri Nov 27 18:35:55 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 27 Nov 2020 18:35:55 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <NveL4QvyJAGN15-Q9WpuE5-CsyCq2DfW3aOBU2qBGls=.2556e891-c2c8-48ae-9328-70fb52ec21d2@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
 <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
 <U2-3quCDFU_JElvF70uIEQX8TDx_jSVAT5g3ejou_2E=.9a42898d-a8f8-4728-b3bd-c15ae2211614@github.com>
 <NveL4QvyJAGN15-Q9WpuE5-CsyCq2DfW3aOBU2qBGls=.2556e891-c2c8-48ae-9328-70fb52ec21d2@github.com>
Message-ID: <Qy4yzP3eBRDTUfIhEll18AMEgC_fHJjj7E3Qm3WPgPA=.bff76179-0e68-4dbc-b620-b446921b3619@github.com>

On Thu, 26 Nov 2020 15:18:48 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>>> @mcimadamore Do you agree with this style?
>> 
>> Yeah - of course nesting things is gonna mess up with access checks - sorry for sending you down the wrong direction!
>> 
>> You could prefix every class in the test with `T8255968_1` e.g.
>> 
>> class T8255968_1 {
>>     T8255968Test1 c = new T8255968_1_Test(0);
>> }
>> 
>> class T8255968_1_Test {
>>     private T8255968_1_Test(int x) {}
>> }
>
> I update the code about test cases. Thank you for taking the time to review.

I haven't forgotten about this - we're running some extensive corpus analysis to make sure that the patch won't introduce any unwanted regressions. Please bear with us :-)

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Nov 28 09:51:08 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 28 Nov 2020 09:51:08 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated constructor
 with diamond
Message-ID: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>

Hi all,

When calling deprecated constructor with diamond, the compiler doesn't output warning.
The test case is shown below.

GenericClass<Object> o2 = new GenericClass<>();

public class GenericClass<T> {
    @Deprecated
    public GenericClass() {}
}

This patch solves the bug and adds corresponding test case.
Thank you for taking the time to review.

Best Regards.

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

Commit messages:
 - 8257037: No javac warning when calling deprecated constructor with diamond

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Nov 28 10:54:56 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 28 Nov 2020 10:54:56 GMT
Subject: Withdrawn: 8257037: No javac warning when calling deprecated
 constructor with diamond
In-Reply-To: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
Message-ID: <QpwHtauDaFeh8FL8RVe62wbbx_mjH6TnN3lvTwa1Nds=.9082f868-c2cc-4b3c-aa53-25fb26693123@github.com>

On Sat, 28 Nov 2020 09:46:06 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> When calling deprecated constructor with diamond, the compiler doesn't output warning.
> The test case is shown below.
> 
> GenericClass<Object> o2 = new GenericClass<>();
> 
> public class GenericClass<T> {
>     @Deprecated
>     public GenericClass() {}
> }
> 
> This patch solves the bug and adds corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Nov 28 11:46:08 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 28 Nov 2020 11:46:08 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
Message-ID: <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>

> Hi all,
> 
> When calling deprecated constructor with diamond, the compiler doesn't output warning.
> The test case is shown below.
> 
> GenericClass<Object> o2 = new GenericClass<>();
> 
> public class GenericClass<T> {
>     @Deprecated
>     public GenericClass() {}
> }
> 
> This patch solves the bug and adds corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Polish

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1490/files
  - new: https://git.openjdk.java.net/jdk/pull/1490/files/1ceb9993..1d2a73c5

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Nov 28 11:46:08 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 28 Nov 2020 11:46:08 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond
In-Reply-To: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
Message-ID: <zYOHKSyh01q-x-aJcyyfKIRedlnaKjrqTg3xuVH-kJQ=.07dc5699-0649-4242-bb9c-dbc94150df84@github.com>

On Sat, 28 Nov 2020 09:46:06 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> When calling deprecated constructor with diamond, the compiler doesn't output warning.
> The test case is shown below.
> 
> GenericClass<Object> o2 = new GenericClass<>();
> 
> public class GenericClass<T> {
>     @Deprecated
>     public GenericClass() {}
> }
> 
> This patch solves the bug and adds corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards.

Sorry for closing the PR accidentally.

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

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

From alanb at openjdk.java.net  Mon Nov 30 09:58:58 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 Nov 2020 09:58:58 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <Z3AFytvDqAjrVEm6tnmJ5MzgynTJU9e6Kc8-u2K1R0c=.44f7ccbb-eae1-4920-8feb-2a26a27a769d@github.com>

On Fri, 27 Nov 2020 16:57:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

src/java.base/share/classes/java/lang/Class.java line 4420:

> 4418:      * {@linkplain #getClassLoader() the defining class loader} of the current
> 4419:      * {@code Class} object. If a name cannot be converted to the {@code Class}
> 4420:      * instance, it is silently excluded from the result.

I think this paragraph will need a little bit of wordsmithing. The 3rd paragraph of getNestMembers might be useful to examine as it more clearly describes how the method attempts to "obtain" the Class object for each of the class names in the NestMembers attribute and maybe some of that wording could be used instead of using the term "convert".

Minor nit but the prevailing style for the @throws SecurityException is to align the description with the exception, probably best to keep it consistent if you can.

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

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

From mcimadamore at openjdk.java.net  Mon Nov 30 11:46:58 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 30 Nov 2020 11:46:58 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v4]
In-Reply-To: <6-LVKf_d0EqzNytbRg1FQ-JZYSYX55HpGpzCJMBacXY=.79ed53cd-27d4-4802-b816-b27a7e562228@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <6-LVKf_d0EqzNytbRg1FQ-JZYSYX55HpGpzCJMBacXY=.79ed53cd-27d4-4802-b816-b27a7e562228@github.com>
Message-ID: <XpFx5talhawDeusTxOsSuBFv2cI0cDuOmqNxGRyxQVk=.ee26091a-5210-4e6c-bd68-14f9c9681623@github.com>

On Thu, 26 Nov 2020 03:36:53 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
>> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise test cases. Rename classes and divide the jtreg tags by unit.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon Nov 30 11:46:58 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 30 Nov 2020 11:46:58 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v3]
In-Reply-To: <Qy4yzP3eBRDTUfIhEll18AMEgC_fHJjj7E3Qm3WPgPA=.bff76179-0e68-4dbc-b620-b446921b3619@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <XvWOq_cDLq7yo80xoDb-GeUyspfCrE4yMvCbCJumHXo=.825b6ae3-f466-4f65-ae97-0a895a327a1f@github.com>
 <MIuXwobSTXZOYkS5x9B_kkgBafy5oJYFhL1J_CNwt3M=.870f7f03-6a1b-4487-b882-69541d78a28b@github.com>
 <U2-3quCDFU_JElvF70uIEQX8TDx_jSVAT5g3ejou_2E=.9a42898d-a8f8-4728-b3bd-c15ae2211614@github.com>
 <NveL4QvyJAGN15-Q9WpuE5-CsyCq2DfW3aOBU2qBGls=.2556e891-c2c8-48ae-9328-70fb52ec21d2@github.com>
 <Qy4yzP3eBRDTUfIhEll18AMEgC_fHJjj7E3Qm3WPgPA=.bff76179-0e68-4dbc-b620-b446921b3619@github.com>
Message-ID: <LGHbZriYYLAplZPT2zZSVQhfM-kJDvVxd7_VpV5Vu4c=.5c7492bc-016c-4f95-89db-d4a7f571e66d@github.com>

On Fri, 27 Nov 2020 18:32:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I update the code about test cases. Thank you for taking the time to review.
>
> I haven't forgotten about this - we're running some extensive corpus analysis to make sure that the patch won't introduce any unwanted regressions. Please bear with us :-)

All the internal testing went ok. At this point I see no reason to delay this further. Thanks.

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

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

From chegar at openjdk.java.net  Mon Nov 30 12:20:59 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 30 Nov 2020 12:20:59 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <Nb3T1W85nkapp8K5WaNo83AqYqokU2YfSsK-cmOq3Tw=.4ff787ce-f34d-48ad-829c-4f16da07041c@github.com>

On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 965:

> 963:                            new NestMembers_attribute(attributeString, nestMembers));
> 964:         }
> 965:         if (header.recordComponents != null && !header.recordComponents.isEmpty()) {

I am not sure of the exact logic here, but it is perfectly fine for a record attribute to contain zero components, and for the class to still be considered a "record class". But maybe that is not all that significant here? I just want to call it out so that it is considered.

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

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

From mcimadamore at openjdk.java.net  Mon Nov 30 12:35:56 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 30 Nov 2020 12:35:56 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
Message-ID: <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>

On Sat, 28 Nov 2020 11:46:08 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> When calling deprecated constructor with diamond, the compiler doesn't output warning.
>> The test case is shown below.
>> 
>> GenericClass<Object> o2 = new GenericClass<>();
>> 
>> public class GenericClass<T> {
>>     @Deprecated
>>     public GenericClass() {}
>> }
>> 
>> This patch solves the bug and adds corresponding test case.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Polish

I think the fix seems in spirit with respect to what happens for ordinary constructor resolution. I guess there is a question as to whether we should check for these warnings during resolution or after (probably checking for warning after resolution might be a better idea) - as there is some duplication between the code in `findConstructor` and the new `findDiamond` and what goes on in `Attr::checkId` which also check for these warnings (and some more) but doesn't apply checks on constructors.

Just for fun, I tried this patch:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index df21524229c..05d56136000 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -4459,15 +4459,11 @@ public class Attr extends JCTree.Visitor {
             }
 
             // Emit a `deprecation' warning if symbol is deprecated.
-            // (for constructors (but not for constructor references), the error
-            // was given when the constructor was resolved)
 
-            if (sym.name != names.init || tree.hasTag(REFERENCE)) {
-                chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
-                chk.checkSunAPI(tree.pos(), sym);
-                chk.checkProfile(tree.pos(), sym);
-                chk.checkPreview(tree.pos(), sym);
-            }
+            chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
+            chk.checkSunAPI(tree.pos(), sym);
+            chk.checkProfile(tree.pos(), sym);
+            chk.checkPreview(tree.pos(), sym);
 
             // If symbol is a variable, check that its type and
             // kind are compatible with the prototype and protokind.
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
index 727d2989adf..9bb37fc23b8 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
@@ -2859,8 +2859,6 @@ public class Resolve {
                                     names.init, argtypes,
                                     typeargtypes, allowBoxing,
                                     useVarargs);
-        chk.checkDeprecated(pos, env.info.scope.owner, sym);
-        chk.checkPreview(pos, sym);
         return sym;
     }
 
@@ -2937,6 +2935,7 @@ public class Resolve {
                             return sym;
                         }
                     };
+                    newConstr.setAttributes(sym);
                     bestSoFar = selectBest(env, site, argtypes, typeargtypes,
                             newConstr,
                             bestSoFar,
This fixes your issues, and removes the warning code duplication between `Attr` and `Resolve`, as well as adding checks for all the remaining kinds of warnings (sunAPI, deprecation, preview and profile) - although I believe most of those are not as important.

I guess I'll leave you to decide how you want to tackle this. As I said, the patch you wrote remains within the spirit of the original code - my only minor quibble is that this "spirit" is questionable, as it involves issuing same warnings in different places, this enforcing developers to replicate code (and forgetting to do so, as it already happened) in multiple places.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Nov 30 12:50:56 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 30 Nov 2020 12:50:56 GMT
Subject: RFR: 8255968: Confusing error message for inaccessible
 constructor [v4]
In-Reply-To: <XpFx5talhawDeusTxOsSuBFv2cI0cDuOmqNxGRyxQVk=.ee26091a-5210-4e6c-bd68-14f9c9681623@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
 <6-LVKf_d0EqzNytbRg1FQ-JZYSYX55HpGpzCJMBacXY=.79ed53cd-27d4-4802-b816-b27a7e562228@github.com>
 <XpFx5talhawDeusTxOsSuBFv2cI0cDuOmqNxGRyxQVk=.ee26091a-5210-4e6c-bd68-14f9c9681623@github.com>
Message-ID: <rA-bYuYc02j2AMuQetnr2sfcy4QYyS679dvb0n4TcNk=.b2a672d7-ecc5-48b0-878e-0f1066f6f235@github.com>

On Mon, 30 Nov 2020 11:43:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test cases. Rename classes and divide the jtreg tags by unit.
>
> Looks good

Thank you for the review.

@mcimadamore 
Could you please sponsor this patch?
Thanks again.

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

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

From jlahoda at openjdk.java.net  Mon Nov 30 14:21:16 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 14:21:16 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v2]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <0IU-_p6RHP0YTRd5q17XiSKjstg63aZBK4GcvliVvTM=.0caf6919-4eb3-4c13-8447-a953e1185153@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

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

 - Merge branch 'JDK-8256950' of https://github.com/lahodaj/jdk into JDK-8256950
 - CreateSymbols should support records with no components.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/c3696e72..7ce38709

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

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

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

From jlahoda at openjdk.java.net  Mon Nov 30 14:27:13 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 14:27:13 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <Nb3T1W85nkapp8K5WaNo83AqYqokU2YfSsK-cmOq3Tw=.4ff787ce-f34d-48ad-829c-4f16da07041c@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <Nb3T1W85nkapp8K5WaNo83AqYqokU2YfSsK-cmOq3Tw=.4ff787ce-f34d-48ad-829c-4f16da07041c@github.com>
Message-ID: <bGe6Plxy_wMV2aISRvW1XiJoaWu9Wxr2JF_41pn-No8=.2e18b5f7-6f0b-4df0-98fd-bcb074be762e@github.com>

On Mon, 30 Nov 2020 12:17:46 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests on Windows - normalizing line endings.
>
> make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 965:
> 
>> 963:                            new NestMembers_attribute(attributeString, nestMembers));
>> 964:         }
>> 965:         if (header.recordComponents != null && !header.recordComponents.isEmpty()) {
> 
> I am not sure of the exact logic here, but it is perfectly fine for a record attribute to contain zero components, and for the class to still be considered a "record class". But maybe that is not all that significant here? I just want to call it out so that it is considered.

Ah, right - fixed in:
https://github.com/openjdk/jdk/pull/1480/commits/e1ec2b7ff49e1307a348ad58b12e5ed39ebe7224

Thanks for the comment!

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

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

From jlahoda at openjdk.java.net  Mon Nov 30 14:27:11 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 14:27:11 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

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

  Fixing tests on Windows - normalizing line endings.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/7ce38709..a3f79aba

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

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

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

From jlahoda at openjdk.java.net  Mon Nov 30 15:59:07 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 15:59:07 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

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

 - Improving getPermittedSubclasses javadoc.
 - Merge branch 'master' into JDK-8246778
 - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
 - Improving getPermittedSubclasses() javadoc.
 - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
 - Removing unnecessary file.
 - Tweaking javadoc.
 - Reflecting review comments w.r.t. narrowing conversion.
 - Improving checks in getPermittedSubclasses()
 - Merging master into JDK-8246778
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

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

Changes: https://git.openjdk.java.net/jdk/pull/1483/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=01
  Stats: 918 lines in 12 files changed: 837 ins; 9 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1483.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483

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

From jlahoda at openjdk.java.net  Mon Nov 30 15:59:09 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 15:59:09 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <Z3AFytvDqAjrVEm6tnmJ5MzgynTJU9e6Kc8-u2K1R0c=.44f7ccbb-eae1-4920-8feb-2a26a27a769d@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <Z3AFytvDqAjrVEm6tnmJ5MzgynTJU9e6Kc8-u2K1R0c=.44f7ccbb-eae1-4920-8feb-2a26a27a769d@github.com>
Message-ID: <cxEgg9WpUs9_npjqYljnwDYGRlMcZrY5UkxDtgg8d5c=.3a374ec4-d80a-4c49-994f-75b411c001c1@github.com>

On Mon, 30 Nov 2020 09:55:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Improving getPermittedSubclasses javadoc.
>>  - Merge branch 'master' into JDK-8246778
>>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>>  - Improving getPermittedSubclasses() javadoc.
>>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>>  - Removing unnecessary file.
>>  - Tweaking javadoc.
>>  - Reflecting review comments w.r.t. narrowing conversion.
>>  - Improving checks in getPermittedSubclasses()
>>  - Merging master into JDK-8246778
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179
>
> src/java.base/share/classes/java/lang/Class.java line 4420:
> 
>> 4418:      * {@linkplain #getClassLoader() the defining class loader} of the current
>> 4419:      * {@code Class} object. If a name cannot be converted to the {@code Class}
>> 4420:      * instance, it is silently excluded from the result.
> 
> I think this paragraph will need a little bit of wordsmithing. The 3rd paragraph of getNestMembers might be useful to examine as it more clearly describes how the method attempts to "obtain" the Class object for each of the class names in the NestMembers attribute and maybe some of that wording could be used instead of using the term "convert".
> 
> Minor nit but the prevailing style for the @throws SecurityException is to align the description with the exception, probably best to keep it consistent if you can.

Thanks, I've tried to improve the javadoc here:
https://github.com/openjdk/jdk/pull/1483/commits/4d484179e6e4d64ed460b997d25b4dca5d964016

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Nov 30 16:03:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 30 Nov 2020 16:03:55 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
 <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
Message-ID: <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>

On Mon, 30 Nov 2020 12:33:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Polish
>
> I think the fix seems in spirit with respect to what happens for ordinary constructor resolution. I guess there is a question as to whether we should check for these warnings during resolution or after (probably checking for warning after resolution might be a better idea) - as there is some duplication between the code in `findConstructor` and the new `findDiamond` and what goes on in `Attr::checkId` which also check for these warnings (and some more) but doesn't apply checks on constructors.
> 
> Just for fun, I tried this patch:
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> index df21524229c..05d56136000 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> @@ -4459,15 +4459,11 @@ public class Attr extends JCTree.Visitor {
>              }
>  
>              // Emit a `deprecation' warning if symbol is deprecated.
> -            // (for constructors (but not for constructor references), the error
> -            // was given when the constructor was resolved)
>  
> -            if (sym.name != names.init || tree.hasTag(REFERENCE)) {
> -                chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
> -                chk.checkSunAPI(tree.pos(), sym);
> -                chk.checkProfile(tree.pos(), sym);
> -                chk.checkPreview(tree.pos(), sym);
> -            }
> +            chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
> +            chk.checkSunAPI(tree.pos(), sym);
> +            chk.checkProfile(tree.pos(), sym);
> +            chk.checkPreview(tree.pos(), sym);
>  
>              // If symbol is a variable, check that its type and
>              // kind are compatible with the prototype and protokind.
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> index 727d2989adf..9bb37fc23b8 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> @@ -2859,8 +2859,6 @@ public class Resolve {
>                                      names.init, argtypes,
>                                      typeargtypes, allowBoxing,
>                                      useVarargs);
> -        chk.checkDeprecated(pos, env.info.scope.owner, sym);
> -        chk.checkPreview(pos, sym);
>          return sym;
>      }
>  
> @@ -2937,6 +2935,7 @@ public class Resolve {
>                              return sym;
>                          }
>                      };
> +                    newConstr.setAttributes(sym);
>                      bestSoFar = selectBest(env, site, argtypes, typeargtypes,
>                              newConstr,
>                              bestSoFar,
> This fixes your issues, and removes the warning code duplication between `Attr` and `Resolve`, as well as adding checks for all the remaining kinds of warnings (sunAPI, deprecation, preview and profile) - although I believe most of those are not as important.
> 
> I guess I'll leave you to decide how you want to tackle this. As I said, the patch you wrote remains within the spirit of the original code - my only minor quibble is that this "spirit" is questionable, as it involves issuing same warnings in different places, this enforcing developers to replicate code (and forgetting to do so, as it already happened) in multiple places.

Thank you for the comment and suggestion.

I had seen and paid attention to the following code in `Attr.java` when being solved this bug.

            // (for constructors (but not for constructor references), the error
            // was given when the constructor was resolved)

            if (sym.name != names.init || tree.hasTag(REFERENCE)) {
                chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
                chk.checkSunAPI(tree.pos(), sym);
                chk.checkProfile(tree.pos(), sym);
                chk.checkPreview(tree.pos(), sym);
            }

These code confused me. Because the comments `(for constructors, the error was given when the constructor was resolved)`  and the conditional expression `sym.name != names.init` were submitted at 2007(submit log: Initial load). And nobody raises suggestion to it over these years though this code snippet had been revised many times.

In order not to generate unknown issues, I chose not to revise these code when being solved this bug.

@mcimadamore  I test your patch locally by using the following command. All the tests passed.

make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release

Your patch is a better solution if no any unknown regression occurs. But I have no idea about the unknown regressions now.
I would like to accept your suggestion and revise my code. **And we should think more situations which could generate regressions to avoid unknown issues occur.**

----
Finally, I have a little question.
Is the code `newConstr.setAttributes(sym);` necessary in `Resolve.findDiamond`?
I delete it in your patch, and test locally by using  the following command. All the tests passed.

make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release

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

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

From alanb at openjdk.java.net  Mon Nov 30 17:46:04 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 Nov 2020 17:46:04 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <mcAIojzyR_RFcd5Hyu_Cc4JXNEYl4hRCwJBi3znQiI4=.19c71b67-d1bf-40be-9d4b-f1ee72f6832b@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

src/java.base/share/classes/java/lang/Class.java line 4412:

> 4410:      * The {@code Class} objects which can be obtained using this procedure
> 4411:      * are indicated by elements of the returned array. If a {@code Class} object
> 4412:      * cannot be obtained, it is silently ignored, and not included in the result

Thanks for the update, this reads much better.

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

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

From mchung at openjdk.java.net  Mon Nov 30 19:36:02 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 30 Nov 2020 19:36:02 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <1b8GH2EQDJvztsMclvskMZrsYcjnapSyqqGMGcutLTY=.b2ef4f3c-0e0d-43a9-9890-cdfbd12f53e9@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

src/java.base/share/classes/java/lang/Class.java line 4463:

> 4461:      * @apiNote
> 4462:      * Sealed class or interface has no relationship with
> 4463:      * {@linkplain Package#isSealed package sealing}.

Package sealing is legacy.  Remi suggests to take out this api note which sounds good to me.   

The API note in Package::isSealed has made this clear which has no relationship with sealed class or interface.

src/java.base/share/classes/java/lang/Class.java line 4415:

> 4413:      * array.
> 4414:      *
> 4415:      * @return an array of class objects of the permitted subclasses of this class or interface

Nit: s/class objects/{@code Class} objects/

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

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

From mchung at openjdk.java.net  Mon Nov 30 19:48:00 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 30 Nov 2020 19:48:00 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

src/java.base/share/classes/java/lang/Class.java line 4480:

> 4478:     }
> 4479: 
> 4480:     private native Class<?>[] getPermittedSubclasses0();

Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS:

   - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C
   - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C

Should the library implementation of `Class::getPermittedSubclasses` filter that if not done by `getPermittedSubclasses0`?

If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified.

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

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

From mchung at openjdk.java.net  Mon Nov 30 20:49:02 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 30 Nov 2020 20:49:02 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <bxzzTy1Ak8k5oJ1WjXPS17gNpz4JGzeV0stkZgOe7Kk=.123245b5-22ed-4477-b0a3-5e1b3d5bcdec@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

src/java.base/share/classes/java/lang/Class.java line 3042:

> 3040:             for (Class<?> c : classes) {
> 3041:                 // skip the package access check on a proxy class in default proxy package
> 3042:                 if (!Proxy.isProxyClass(c) || ReflectUtil.isNonPublicProxyClass(c)) {

If a sealed class is in a named module, the permitted subclasses/subinterfaces are in the same module as the sealed class.  If a sealed class is in an unnamed module, it will be in the same runtime package as the sealed class.   A proxy class is dynamically generated and not intended for statically named in `permits` clause of a sealed class`.  It can be in a different module or different package.  So a permitted subclass or interface should never be a proxy class. 

So the package access check for permitted subclasses/subinterfaces can be simplified.  I would suggest this check be inlined in `getPermittedSubclasses` as follows:

      SecurityManager sm = System.getSecurityManager();
        if (subclasses.length > 0 && sm != null) {
            ClassLoader ccl = ClassLoader.getClassLoader(Reflection.getCallerClass());
            ClassLoader cl = getClassLoader0();
            if (ReflectUtil.needsPackageAccessCheck(ccl, cl)) {
                Set<String> packages = new HashSet<>();
                for (Class<?> c : subclasses) {
                    if (Proxy.isProxyClass(c))
                        throw new InternalError("a permitted subclass should not be a proxy class: " + c);
                    String pkg = c.getPackageName();
                    if (!pkg.isEmpty())
                        packages.add(pkg);
                }
                for (String pkg : packages) {
                    sm.checkPackageAccess(pkg);
                }
            }
        }

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

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

From hseigel at openjdk.java.net  Mon Nov 30 20:59:59 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 30 Nov 2020 20:59:59 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
Message-ID: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>

On Mon, 30 Nov 2020 19:44:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Improving getPermittedSubclasses javadoc.
>>  - Merge branch 'master' into JDK-8246778
>>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>>  - Improving getPermittedSubclasses() javadoc.
>>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>>  - Removing unnecessary file.
>>  - Tweaking javadoc.
>>  - Reflecting review comments w.r.t. narrowing conversion.
>>  - Improving checks in getPermittedSubclasses()
>>  - Merging master into JDK-8246778
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179
>
> src/java.base/share/classes/java/lang/Class.java line 4480:
> 
>> 4478:     }
>> 4479: 
>> 4480:     private native Class<?>[] getPermittedSubclasses0();
> 
> Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS:
> 
>    - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C
>    - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C
> 
> I didn't check the VM implementation.
> 
> If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified.

The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements.  It returns all the classes listed in the PermittedSubclasses attribute that it is able to load.

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

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

From jjg at openjdk.java.net  Mon Nov 30 23:27:19 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 30 Nov 2020 23:27:19 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v4]
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <pEsXIGTnqj9Jytin6ZYp3qUESJI3OcAhlF0PepdNv9c=.42a639db-9197-43e0-8cb7-6bd7a56f9a72@github.com>

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

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

 - fix test
 - Update for new `@return` tag
 - Merge remote-tracking branch 'upstream/master' into new-return
 - Update DocCommentParser to permit nested inline tags in specified cases: @return
 - Add default impl for new method
 - Fix test failure
 - Fix trailing whitespace in test
 - Merge master
 - JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1355/files
  - new: https://git.openjdk.java.net/jdk/pull/1355/files/87edfb0c..5703d83b

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

  Stats: 94833 lines in 875 files changed: 81326 ins; 5628 del; 7879 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355

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