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 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:39:23 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 13:39:23 GMT
Subject: RFR: 8232856: jshell crashes when pressing up arrow after /! [v2]
In-Reply-To: <2WTMuKHjtn-iYJl4hb4Dj04XhxWU8L1pMxzfhrq9TU8=.85ebae0d-6417-4b8d-8b5f-300d3bcb1b58@github.com>
References: <2WTMuKHjtn-iYJl4hb4Dj04XhxWU8L1pMxzfhrq9TU8=.85ebae0d-6417-4b8d-8b5f-300d3bcb1b58@github.com>
Message-ID: <Igm6I52TEWKyNIJ7pbA6sbLMuIIrulikp77Gmgu8g8c=.d29edbe5-ec67-4e8d-982b-84114d8f3341@github.com>

> When re-running snippets, we remove the last entry (which is e.g. '/!'), and then put the expanded code back. But, while adding the code back, it is detected the entry-to-be-added duplicates the previous entry and is not added. But an internal "index" value is not updated, and still has the value it had before the removal, leading to inconsistency in the history internal data, and eventually, to a crash. Calling resetIndex() should fix the internal data.

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

 - Merge branch 'master' into JDK-8232856
 - 8232856: jshell crashes when pressing up arrow after /!

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/173/files
  - new: https://git.openjdk.java.net/jdk/pull/173/files/334380a4..3d501d51

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

  Stats: 482904 lines in 4786 files changed: 397565 ins; 62200 del; 23139 mod
  Patch: https://git.openjdk.java.net/jdk/pull/173.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/173/head:pull/173

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

From psandoz at openjdk.java.net  Wed Nov  4 15:54:04 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 4 Nov 2020 15:54:04 GMT
Subject: RFR: 8232856: jshell crashes when pressing up arrow after /! [v2]
In-Reply-To: <Igm6I52TEWKyNIJ7pbA6sbLMuIIrulikp77Gmgu8g8c=.d29edbe5-ec67-4e8d-982b-84114d8f3341@github.com>
References: <2WTMuKHjtn-iYJl4hb4Dj04XhxWU8L1pMxzfhrq9TU8=.85ebae0d-6417-4b8d-8b5f-300d3bcb1b58@github.com>
 <Igm6I52TEWKyNIJ7pbA6sbLMuIIrulikp77Gmgu8g8c=.d29edbe5-ec67-4e8d-982b-84114d8f3341@github.com>
Message-ID: <dcfmePwK6DJVFuVR0NqTUJ-inIHvX9jG1NGDHTFCdh4=.db90d4fc-d115-4e56-8d63-7e5098d5a188@github.com>

On Wed, 4 Nov 2020 13:39:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When re-running snippets, we remove the last entry (which is e.g. '/!'), and then put the expanded code back. But, while adding the code back, it is detected the entry-to-be-added duplicates the previous entry and is not added. But an internal "index" value is not updated, and still has the value it had before the removal, leading to inconsistency in the history internal data, and eventually, to a crash. Calling resetIndex() should fix the internal data.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8232856
>  - 8232856: jshell crashes when pressing up arrow after /!

Marked as reviewed by psandoz (Reviewer).

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

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

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 jlahoda at openjdk.java.net  Thu Nov  5 09:14:56 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 09:14:56 GMT
Subject: Integrated: 8232856: jshell crashes when pressing up arrow after /!
In-Reply-To: <2WTMuKHjtn-iYJl4hb4Dj04XhxWU8L1pMxzfhrq9TU8=.85ebae0d-6417-4b8d-8b5f-300d3bcb1b58@github.com>
References: <2WTMuKHjtn-iYJl4hb4Dj04XhxWU8L1pMxzfhrq9TU8=.85ebae0d-6417-4b8d-8b5f-300d3bcb1b58@github.com>
Message-ID: <mrW-YMmObfwcFY4m2yL28zvOB-W5Gw4psUjMkt4A3Ag=.162f1fde-5503-4bb2-89db-3bae7d1d6b1e@github.com>

On Tue, 15 Sep 2020 09:54:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When re-running snippets, we remove the last entry (which is e.g. '/!'), and then put the expanded code back. But, while adding the code back, it is detected the entry-to-be-added duplicates the previous entry and is not added. But an internal "index" value is not updated, and still has the value it had before the removal, leading to inconsistency in the history internal data, and eventually, to a crash. Calling resetIndex() should fix the internal data.

This pull request has now been integrated.

Changeset: cdef186c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cdef186c
Stats:     14 lines in 2 files changed: 13 ins; 0 del; 1 mod

8232856: jshell crashes when pressing up arrow after /!

Reviewed-by: psandoz

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

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

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 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 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.


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 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 jlahoda at openjdk.java.net  Mon Nov  9 13:12:04 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 9 Nov 2020 13:12:04 GMT
Subject: RFR: 8255273: jshell crashes with UnsupportedOperationException:
 Should not get here.
Message-ID: <XEXQzan3zBDX6EaMkZIpfTyYxT5N_I1FofzFPu3J4K8=.e96e1ac5-d364-4a45-a64d-bb04b9c1cc36@github.com>

Consider JShell interaction like:

jshell> import java.time.*;

jshell> new Instant<tab>

This will crash the JShell with an `UnsupportedOperationException`. The ultimately reason is that:
-completions are computed, and are `InstantiationError(` and `InstantiationException(`, with a common prefix `InstantiationE`
-documentation is computed, and is for java.time.Instant

The completion machine then gets into a state where it fills in the common prefix, and that it would like say something along the lines of "Press tab once more to see signature/documentation.", but that does not make much sense (as the documentation is computed for a wrong input - the new input is `new InstantiationE`, not `Instant`, so the documentation is already invalid for that.

(The `UnsupportedOperationException` is in place where the "Press tab once more to see signature/documentation." should happen, because the code should not get into a state like this.)

The proposed solution is to cancel the documentation if a prefix is (to be) filled.

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

Commit messages:
 - 8255273: jshell crashes with UnsupportedOperationException: Should not get here.

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

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

From takiguc at linux.vnet.ibm.com  Tue Nov 10 13:13:54 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 10 Nov 2020 22:13:54 +0900
Subject: [11u] 8256128: Evaluation request to upgrade to JDK11 JLine 3.14.0
Message-ID: <455bfd79944390936ea26cdbe6d51356@linux.vnet.ibm.com>

Hello.

Could you evaluate upgrading JDK11 JLine to 3.14.0 ?

I found regression issue JDK-8256128 [1] on 11.0.9.
Since JLine is too large, I cannot evaluate it by myself for jdk11u fix 
request.

I really appreciate any suggestion from jshell team.

[1] https://bugs.openjdk.java.net/browse/JDK-8256128

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

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 alanb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
Message-ID: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>

This change terminally deprecates the following methods defined by java.lang.ThreadGroup 

- stop 
- destroy 
- isDestroyed 
- setDaemon 
- isDaemon 

The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 

The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.

CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

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

Commit messages:
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

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

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

From serb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
Message-ID: <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>

On Thu, 19 Nov 2020 18:51:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Marked as reviewed by serb (Reviewer).

The changes in the awt are trivial and look fine.

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

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

From mullan at openjdk.java.net  Fri Nov 20 14:10:01 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 14:10:01 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
Message-ID: <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>

On Thu, 19 Nov 2020 18:53:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Marked as reviewed by serb (Reviewer).
>
> The changes in the awt are trivial and look fine.

I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be deprecated in a future release."

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

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

From mullan at openjdk.java.net  Fri Nov 20 14:10:05 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 14:10:05 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

src/java.base/share/classes/java/lang/ThreadGroup.java line 191:

> 189:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 190:      *             operation and is inherently racy with respect to threads that
> 191:      *             have been created but not have started. The concept of daemon

"a daemon group" sounds better to me.

src/java.base/share/classes/java/lang/ThreadGroup.java line 208:

> 206:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 207:      *             operation and is inherently racy with respect to threads that
> 208:      *             have been created but not have started. The ability to explicitly

"have not started"

src/java.base/share/classes/java/lang/ThreadGroup.java line 237:

> 235:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 236:      *             operation and is inherently racy with respect to threads that
> 237:      *             have been created but not have started. The concept of daemon

same comment as above - "a daemon group"

src/java.base/share/classes/java/lang/ThreadGroup.java line 790:

> 788:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 789:      *             operation and is inherently racy with respect to threads that
> 790:      *             have been created but not have started. The ability to explicitly

"have not started"

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

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

From alanb at openjdk.java.net  Fri Nov 20 14:45:07 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 14:45:07 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>
Message-ID: <KAvIXZnGXNYBRq6b5pHas8eRZVibi1SqrFFI-sLBJVE=.ae7983a5-9847-4674-9c3b-6799995f510f@github.com>

On Fri, 20 Nov 2020 14:05:09 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> src/java.base/share/classes/java/lang/ThreadGroup.java line 191:
> 
>> 189:      * @deprecated Destroying a thread group and its subgroups is not an atomic
>> 190:      *             operation and is inherently racy with respect to threads that
>> 191:      *             have been created but not have started. The concept of daemon
> 
> "a daemon group" sounds better to me.

The existing spec uses "daemon thread group" so I'd prefer to stick with that.

> src/java.base/share/classes/java/lang/ThreadGroup.java line 208:
> 
>> 206:      * @deprecated Destroying a thread group and its subgroups is not an atomic
>> 207:      *             operation and is inherently racy with respect to threads that
>> 208:      *             have been created but not have started. The ability to explicitly
> 
> "have not started"

Thanks, there's a typo there.

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

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

From alanb at openjdk.java.net  Fri Nov 20 14:52:07 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 14:52:07 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
 <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
Message-ID: <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>

On Fri, 20 Nov 2020 14:03:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be removed in a future release."

We haven't changed Thread.stop here, I would like to get that done too but as separate issue because it will require wider discussion. The main thing for now is the prep work before proposing to shove ThreadGroup to the side.

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

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

From alanb at openjdk.java.net  Fri Nov 20 15:08:27 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 15:08:27 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

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

 - Fixed typo in @deprecated text
 - Merge
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1318/files
  - new: https://git.openjdk.java.net/jdk/pull/1318/files/c661861a..ca656ba1

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

  Stats: 99634 lines in 382 files changed: 45266 ins; 43186 del; 11182 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1318/head:pull/1318

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

From mullan at openjdk.java.net  Fri Nov 20 15:23:06 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 15:23:06 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
 <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
 <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>
Message-ID: <6PdDak1NVV78CaUuKR8Xl6wVwSvVcCZyPHYcE8LytmY=.3831f142-9fc4-44bf-b0c1-ac45d20b7716@github.com>

On Fri, 20 Nov 2020 14:49:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be removed in a future release."
> 
> We haven't changed Thread.stop here, I would like to get that done too but as separate issue because it will require wider discussion. The main thing for now is the prep work before proposing to shove ThreadGroup to the side.

Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?

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

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

From rriggs at openjdk.java.net  Fri Nov 20 15:30:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 Nov 2020 15:30:06 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/lang/ThreadGroup.java line 194:

> 192:      *             thread group that is automatically destroyed will be removed
> 193:      *             in a future release.
> 194:      */

I would switch the order of the sentences.  Put the action first and the rationale second. $.02
(in all the @ deprecated javadoc).

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

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

From alanb at openjdk.java.net  Fri Nov 20 15:53:10 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 15:53:10 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
Message-ID: <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>

On Fri, 20 Nov 2020 15:27:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Fixed typo in @deprecated text
>>  - Merge
>>  - Update jshell class
>>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon
>
> Marked as reviewed by rriggs (Reviewer).

> Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?

The "modifyThread" and "modifyThreadGroup" permission targets list methods that have been terminally deprecated for some time, are you looking for both permission targets to be updated? I could imagine doing an overall here, also re-visiting SecurityManager checkAccess(ThreadGroup) but it feels like it's beyond the scope of the deprecation proposed here and would be better off being left to when we eventually degrade and/or remove these methods.

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

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

From mullan at openjdk.java.net  Fri Nov 20 16:08:03 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 16:08:03 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
 <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
Message-ID: <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>

On Fri, 20 Nov 2020 15:50:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?
> 
> The "modifyThread" and "modifyThreadGroup" permission targets list methods that have been terminally deprecated for some time, are you looking for both permission targets to be updated? I could imagine doing an overall here, also re-visiting SecurityManager checkAccess(ThreadGroup) but it feels like it's beyond the scope of the deprecation proposed here and would be better off being left to when we eventually degrade and/or remove these methods.

Ok, I see there is a broader context for my comment. I think then it makes sense to open a separate issue to specify these various RuntimePermission targets that are associated with deprecated APIs. In my mind, these permission targets are standard targets and should also be "deprecated" even if there is no annotation that can formally indicate that. For comparison, SecurityPermission puts these in a separate table in the class summary: https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/security/SecurityPermission.html
If you agree, I can file an issue.

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

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

From alanb at openjdk.java.net  Fri Nov 20 17:03:04 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 17:03:04 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
 <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
 <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>
Message-ID: <CIzjSKmsDowUN8Fug1JXYQX-8jjtG-Tq_3rgkoth4gg=.7ef98fa1-64a9-4757-b2dd-ecfab998da1c@github.com>

On Fri, 20 Nov 2020 16:05:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> If you agree, I can file an issue.

Yes, make sense to separate this out, esp. permission targets such as "stopThread" where all usages are in deprecated methods. However, I don't expect "modifyThreadGroup" would be deprecated, at least not yet, because there are usages in several methods that are not deprecated.

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

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

From serb at openjdk.java.net  Fri Nov 20 17:58:10 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 17:58:10 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <sV1eWm3ZqFAQ0yM8ZplcYHqeMx_OK67VcDDVP4Y7rjg=.1124de6a-5992-4937-a849-06d4a3ea8e3b@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by serb (Reviewer).

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

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

From iris at openjdk.java.net  Fri Nov 20 19:28:10 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 20 Nov 2020 19:28:10 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <eWF-EAOrTnAd5-66ObnEMDFMfWb5IEETjlTPHmQqFSE=.eaf8ffbd-c78b-432d-b75d-48cbf9fc0d27@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by iris (Reviewer).

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

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

From mchung at openjdk.java.net  Fri Nov 20 20:03:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 20:03:07 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by mchung (Reviewer).

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

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

From smarks at openjdk.java.net  Fri Nov 20 20:15:08 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 20 Nov 2020 20:15:08 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
Message-ID: <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>

On Fri, 20 Nov 2020 19:59:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Fixed typo in @deprecated text
>>  - Merge
>>  - Update jshell class
>>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon
>
> Marked as reviewed by mchung (Reviewer).

I think the current deprecation wording is actually too specific regarding the raciness between TG destruction and created-but-not-started threads. That's just one of the flaws of thread groups. In fact, I think there are enough weirdnesses and race conditions around all destruction-related operations of thread groups that the whole concept is fundamentally flawed. We should just say that. How about this:

> ThreadGroup's destruction mechanisms are fundamentally flawed. Therefore, the ThreadGroup methods destroy(), isDestroyed(), setDaemon(), and isDaemon(), which relate to ThreadGroup destruction, have been deprecated and may be removed from a future version of the system.

I think there are too many subtle details to include a justification here about why TG destruction is fundamentally flawed, so we just have to assert that. Unfortunately the writeups in the JEP and CSR are in draft state so we can't link to them. Maybe when the JEP is published we can add a link to it from here later.

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

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

From alanb at openjdk.java.net  Sun Nov 22 16:00:45 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Nov 2020 16:00:45 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v3]
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

Alan Bateman 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 six additional commits since the last revision:

 - Tweak wording of @deprecated message to make it more general
 - Merge
 - Fixed typo in @deprecated text
 - Merge
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1318/files
  - new: https://git.openjdk.java.net/jdk/pull/1318/files/ca656ba1..38d951b9

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

  Stats: 1688 lines in 57 files changed: 885 ins; 381 del; 422 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1318/head:pull/1318

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

From alanb at openjdk.java.net  Sun Nov 22 16:05:24 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Nov 2020 16:05:24 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
 <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>
Message-ID: <jTvzKn7GriuFfNKgxLnz0bSa-AWRI0tmIIuPz3l692E=.057ca93b-33fc-42ad-8ede-3103d2a716f1@github.com>

On Fri, 20 Nov 2020 20:12:31 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Marked as reviewed by mchung (Reviewer).
>
> I think the current deprecation wording is actually too specific regarding the raciness between TG destruction and created-but-not-started threads. That's just one of the flaws of thread groups. In fact, I think there are enough weirdnesses and race conditions around all destruction-related operations of thread groups that the whole concept is fundamentally flawed. We should just say that. How about this:
> 
>> ThreadGroup's destruction mechanisms are fundamentally flawed. Therefore, the ThreadGroup methods destroy(), isDestroyed(), setDaemon(), and isDaemon(), which relate to ThreadGroup destruction, have been deprecated and may be removed from a future version of the system.
> 
> I think there are too many subtle details to include a justification here about why TG destruction is fundamentally flawed, so we just have to assert that. Unfortunately the writeups in the JEP and CSR are in draft state so we can't link to them. Maybe when the JEP is published we can add a link to it from here later.

Okay, I think I agree that the first sentence needs to be a bit more general so I've re-worded it. I used "inherently" rather than "fundamentally" to be consistent with the other deprecation text in Thread/ThreadGroup. If you are okay with the updated text then I'll transfer it to the CSR.

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

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

From smarks at openjdk.java.net  Tue Nov 24 20:03:03 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 24 Nov 2020 20:03:03 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v3]
In-Reply-To: <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>
Message-ID: <fv7k_Hj3Wkkx0xIayMan4G8DTJNXfVa_rFipU6jVydo=.1a82f547-ea9c-4a88-a97b-77e2f81f01da@github.com>

On Sun, 22 Nov 2020 16:00:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman 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 six additional commits since the last revision:
> 
>  - Tweak wording of @deprecated message to make it more general
>  - Merge
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

I'm ok with the wording "inherently flawed."

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

Marked as reviewed by smarks (Reviewer).

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

From alanb at openjdk.java.net  Wed Nov 25 08:28:59 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 25 Nov 2020 08:28:59 GMT
Subject: Integrated: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 isDestroyed, setDaemon and isDaemon
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <eZag_nwpvxIv6r1yW69IhT8Vrqu9WkUqEe4ArPvy8OE=.4d84b65f-ca2c-4f6c-af3d-93623fb41b06@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

This pull request has now been integrated.

Changeset: 79e57ace
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/79e57ace
Stats:     26 lines in 4 files changed: 23 ins; 0 del; 3 mod

8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Reviewed-by: serb, rriggs, iris, mchung, smarks

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

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