From prr at openjdk.java.net Mon Nov 2 04:29:10 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 2 Nov 2020 04:29:10 GMT Subject: RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 Message-ID: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library https://bugs.openjdk.java.net/browse/JDK-8247872 This has passed building and headless and headful automated tests on all platforms. ------------- Commit messages: - 8247872: Upgrade HarfBuzz to the latest 2.7.2 Changes: https://git.openjdk.java.net/jdk/pull/993/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=993&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247872 Stats: 44663 lines in 207 files changed: 25198 ins; 12729 del; 6736 mod Patch: https://git.openjdk.java.net/jdk/pull/993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/993/head:pull/993 PR: https://git.openjdk.java.net/jdk/pull/993 From prr at openjdk.java.net Mon Nov 2 04:29:10 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 2 Nov 2020 04:29:10 GMT Subject: RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: On Mon, 2 Nov 2020 04:19:57 GMT, Phil Race wrote: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on all platforms. Aside from the code change there is a small build change is to remove some obsolete defines ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From jlahoda at openjdk.java.net Mon Nov 2 08:15:21 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 2 Nov 2020 08:15:21 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v4] In-Reply-To: References: Message-ID: <1dxDS8NcRcAH9S9p038xQo7zA3RVkKrfn6XHqzkXmzg=.76d60e31-96fb-4cee-b6d4-956d76de64e1@github.com> > Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements across all modules in the module graph, and only return a value when they find exactly one element. This is troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that these unqualified methods would first look for elements visible from the root modules, and would search the internals of other modules only if nothing would be found in the first round. > > The draft of the corresponding CSR is here: https://bugs.openjdk.java.net/browse/JDK-8253168. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8236842 - Linking to root and all modules definition. - Merge branch 'master' into JDK-8236842 - Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. - 8253168: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/200/files - new: https://git.openjdk.java.net/jdk/pull/200/files/33ca56ed..fa0e316a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=02-03 Stats: 462759 lines in 4438 files changed: 385829 ins; 55838 del; 21092 mod Patch: https://git.openjdk.java.net/jdk/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/200/head:pull/200 PR: https://git.openjdk.java.net/jdk/pull/200 From jlahoda at openjdk.java.net Mon Nov 2 10:22:02 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 2 Nov 2020 10:22:02 GMT Subject: Integrated: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 07:57:30 GMT, Jan Lahoda wrote: > Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements across all modules in the module graph, and only return a value when they find exactly one element. This is troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that these unqualified methods would first look for elements visible from the root modules, and would search the internals of other modules only if nothing would be found in the first round. > > The draft of the corresponding CSR is here: https://bugs.openjdk.java.net/browse/JDK-8253168. This pull request has now been integrated. Changeset: d05df7c1 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/d05df7c1 Stats: 551 lines in 4 files changed: 490 ins; 29 del; 32 mod 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/200 From ihse at openjdk.java.net Mon Nov 2 12:35:56 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 2 Nov 2020 12:35:56 GMT Subject: RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: On Mon, 2 Nov 2020 04:19:57 GMT, Phil Race wrote: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on all platforms. Build changes look good. I'm just a bit curious about the added, empty, `src/java.desktop/share/native/libharfbuzz/abc.txt`... If it really is in upstream source, I'm not saying you should remove it. It just looks very odd. It's not a merge artifact? (I could not even add review comments to an empty file in github! ??) ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/993 From jjg at openjdk.java.net Mon Nov 2 17:52:56 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 2 Nov 2020 17:52:56 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: References: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@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 wrote: >> I don't think there should be much interaction with -source . 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: References: Message-ID: On Thu, 29 Oct 2020 09:26:05 GMT, Jan Lahoda 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: References: 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: <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 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: """; > 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: <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 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: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com> Message-ID: On Tue, 27 Oct 2020 16:09:45 GMT, Jan Lahoda wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 88: >> >>> 86: >>> 87: @Override >>> 88: protected Content getDeprecatedOrPreviewLink(Element member) { >> >> This name is a side-effect of the `ElementFlag` question. We should either use explicit field and method names, or we should use `ElementFlag` more consistently. This method name works OK for now, but if if ever gets to have another `orFoo` component in the name, the signature should be parameterized with something like `ElementFlag` or its equivalent. > > Note this method returns the same link for deprecate or preview - it just was named "getDeprecatedLink", and when using it work preview, I renamed it "getDeprecatedOrPreviewLink". We may need to think of a better name. This name is OK for now. Maybe we'll have m ore insight into a better name if/when we add a third variant ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From vromero at openjdk.java.net Mon Nov 2 21:00:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 2 Nov 2020 21:00:58 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Wed, 28 Oct 2020 18:00:18 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> removing duplicated test > > The changes look good, but I have one concern: this patch seem to apply the improvements unconditionally, regardless of the source version - is this what we want? While I understand that the risk is low (this patch makes space of compilable programs bigger), at the same times it feels wrong that when compiling with `--source 14` I can now nest static classes inside member classes (which is not compatible with what the SE 14 spec says). > As @mcimadamore, I think this should only be allowed for -source 16+, right? right but the new goodies are only available if records are allowed. The code is behind `allowRecords` which should only be true for source >= 16, shouldn't that be enough? ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Tue Nov 3 17:20:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 3 Nov 2020 17:20:58 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Wed, 28 Oct 2020 18:00:18 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> removing duplicated test > > The changes look good, but I have one concern: this patch seem to apply the improvements unconditionally, regardless of the source version - is this what we want? While I understand that the risk is low (this patch makes space of compilable programs bigger), at the same times it feels wrong that when compiling with `--source 14` I can now nest static classes inside member classes (which is not compatible with what the SE 14 spec says). > As @mcimadamore, I think this should only be allowed for -source 16+, right? I agree, I'm working on another iteration to fix the issue, thanks for the comments ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From alex.buckley at oracle.com Tue Nov 3 18:30:36 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 3 Nov 2020 10:30:36 -0800 Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v6] In-Reply-To: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> References: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> Message-ID: <78c1d663-f2e3-e805-a05e-f14537f0d2ac@oracle.com> I saw Jon had a comment about terminology in jdk.javadoc -> resources/standard.properties, lines 280-290. Those lines look good to me. For javadoc's purposes, there are (a) preview features of the Java platform which are either (b) preview features of the Java language or (c) [reflective] preview APIs [of the Java platform]. When we refer to one of the (b) features, it's enough to mention "the Java language" and assume that people know the language, like the APIs, is a part of the platform. In theory, it would be right for javadoc output to be specific about which release of the Java language/platform defines the preview features in question. This is especially true when `javadoc` is run over user code (i.e., not JDK code) that happens to use preview language features. Referring to a specific release is easier with "Java SE" phrasing than "the Java platform" phrasing, which is why jdk.compiler -> resources/compiler.properties says "preview features of Java SE {1}". All that said, I think the jdk.javadoc -> resources/standard.properties file is fine as-is. Anyone running `javadoc` should know which JDK release they're getting it from, and anyone reading javadoc output must have some sense of the era that the output dates from. Alex On 11/2/2020 10:15 AM, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: > > - Removing trailing whitespace. > - Merging master into JDK-8250768. > - Updating tests after records are a final feature. > - Fixing tests. > - Finalizing removal of record preview hooks. > - Merging master into JDK-8250768 > - Reflecting review comments. > - Merge branch 'master' into JDK-8250768 > - Removing unnecessary cast. > - Using a more correct way to get URLs. > - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900 > > ------------- > > Changes: https://git.openjdk.java.net/jdk/pull/703/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=05 > Stats: 3012 lines in 142 files changed: 2521 ins; 260 del; 231 mod > Patch: https://git.openjdk.java.net/jdk/pull/703.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 > > PR: https://git.openjdk.java.net/jdk/pull/703 > From vromero at openjdk.java.net Tue Nov 3 19:25:16 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 3 Nov 2020 19:25:16 GMT Subject: RFR: 8254105: allow static nested declarations [v6] In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. > > TIA, > Vicente > > PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/571/files - new: https://git.openjdk.java.net/jdk/pull/571/files/1b478303..7dfca333 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=04-05 Stats: 488 lines in 25 files changed: 134 ins; 340 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571 PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Tue Nov 3 19:25:17 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 3 Nov 2020 19:25:17 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Tue, 3 Nov 2020 17:18:36 GMT, Vicente Romero wrote: >> The changes look good, but I have one concern: this patch seem to apply the improvements unconditionally, regardless of the source version - is this what we want? While I understand that the risk is low (this patch makes space of compilable programs bigger), at the same times it feels wrong that when compiling with `--source 14` I can now nest static classes inside member classes (which is not compatible with what the SE 14 spec says). > >> As @mcimadamore, I think this should only be allowed for -source 16+, right? > > I agree, I'm working on another iteration to fix the issue, thanks for the comments I have pushed a commit addressing the review comments so far. I have re-added code in Attr but this time behind a guard checking if records are allowed in the current source and I have added back some tests I removed before. The tests are now executed with current source and with source 15. Thanks for the comments so far. ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From jjg at openjdk.java.net Wed Nov 4 00:50:55 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 4 Nov 2020 00:50:55 GMT Subject: RFR: 8253385: annotation processors remove varargs information from record components In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 19:50:31 GMT, Vicente Romero wrote: > Please review this fix for a corner case bug. Essentially for code like: > > import java.lang.annotation.*; > > @Target({ElementType.TYPE_USE}) > @interface Simple {} > > record R(@Simple int ...val) { > static void test() { > R rec = new R(10, 20); > } > } > > assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed. > > TIA, > Vicente minor suggestions in comments src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1788: > 1786: private final int pos; > 1787: > 1788: private boolean isVarargs; field can be final? test/langtools/tools/javac/records/RecordCompilationTests.java line 1694: > 1692: @interface Simple {} > 1693: > 1694: record R(@Simple int ...val) { (minor) unusual typography for "int ...val". Suggest "int... val" test/langtools/tools/javac/records/RecordCompilationTests.java line 1712: > 1710: @interface Simple {} > 1711: > 1712: record R(@Simple int ...val) { (minor) unusual typography for "int ...val". Suggest "int... val" ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/709 From jlahoda at openjdk.java.net Wed Nov 4 10:35:02 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 4 Nov 2020 10:35:02 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v6] In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> References: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> Message-ID: On Mon, 2 Nov 2020 18:39:59 GMT, Jonathan Gibbons 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: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> Message-ID: On Mon, 2 Nov 2020 19:37:39 GMT, Jonathan Gibbons 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: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> Message-ID: On Mon, 2 Nov 2020 19:41:08 GMT, Jonathan Gibbons 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: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> Message-ID: On Mon, 2 Nov 2020 19:59:10 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: >> >> - Removing trailing whitespace. >> - Merging master into JDK-8250768. >> - Updating tests after records are a final feature. >> - Fixing tests. >> - Finalizing removal of record preview hooks. >> - Merging master into JDK-8250768 >> - Reflecting review comments. >> - Merge branch 'master' into JDK-8250768 >> - Removing unnecessary cast. >> - Using a more correct way to get URLs. >> - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900 > > test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java line 28: > >> 26: import jdk.internal.javac.PreviewFeature.Feature; >> 27: >> 28: @PreviewFeature(feature=Feature.TEST) > > Yeah, I remember `Feature.TEST` from earlier. I guess it's OK for now, as a workaround for a testing a feature which is inherently, by design, a moving target across releases. > > These days, javadoc tests are trending towards generating small sample test programs, instead of having small static side-files dominated by a legal header. I wonder if there is a possibility of having a "generator class" in the `javadoc.tester` package that can generate sample code using one or more of the current set of preview features, as a way of reducing the need for the TEST feature. I have intentionally added Feature.TEST to improve testability. Before, tests were using one of the constants (typically whatever was the first constant), but that seems somewhat problematic - what if (at some point, transiently) we have no preview features? ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Wed Nov 4 13:29:10 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 4 Nov 2020 13:29:10 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v6] In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: > This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. > > A summary of changes: > -making the feature permanent (non-preview) > -making the binding variables non-final (as per current specification proposal) > -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal) > -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc. > > This change will not be integrated until JEP 394 is targetted. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into patterns-instanceof3 - Merging master into patterns-instanceof3 - Removing the preview deprecated methods from BindingPatternTree. - Merge branch 'master' into patterns-instanceof3 - Fixing review comments. - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask - Merge branch 'master' into patterns-instanceof3 - Fixing more tests. - Correcting positions. - Improve the AST model. - ... and 10 more: https://git.openjdk.java.net/jdk/compare/7f4d873d...325f96ad ------------- Changes: https://git.openjdk.java.net/jdk/pull/559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=05 Stats: 651 lines in 90 files changed: 228 ins; 310 del; 113 mod Patch: https://git.openjdk.java.net/jdk/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559 PR: https://git.openjdk.java.net/jdk/pull/559 From hannesw at openjdk.java.net Wed Nov 4 15:53:59 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 4 Nov 2020 15:53:59 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> Message-ID: On Thu, 22 Oct 2020 02:40:44 GMT, Jonathan Gibbons wrote: > This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box. > > As an inline tag, the format is `{@spec url label}`, which is roughly translated to `label` in the generated docs. > > As a block tag, the format is simply > > @spec url label > > which is handled in a manner analogous to > > @see label > > The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here. > > This change is only the _support_ for the new tag; it does _not_ include any changes to API docs to _use_ the new tag. It's very instructive to see a new tag introduced from scratch with all the accompanying infrastructure and tests. The changes looks good to me, but I need to stress than I'm not an expert on some of the affected areas such as the jdk.compiler parts. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/790 From mcimadamore at openjdk.java.net Wed Nov 4 16:19:56 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 Nov 2020 16:19:56 GMT Subject: RFR: 8254105: allow static nested declarations [v6] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Tue, 3 Nov 2020 19:25:16 GMT, Vicente Romero wrote: >> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. >> >> TIA, >> Vicente >> >> PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Wed Nov 4 16:33:04 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 4 Nov 2020 16:33:04 GMT Subject: RFR: 8254105: allow static nested declarations [v6] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Wed, 4 Nov 2020 16:17:16 GMT, Maurizio Cimadamore wrote: > Changes look good thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Wed Nov 4 17:13:07 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 4 Nov 2020 17:13:07 GMT Subject: RFR: 8253385: annotation processors remove varargs information from record components [v2] In-Reply-To: References: Message-ID: > Please review this fix for a corner case bug. Essentially for code like: > > import java.lang.annotation.*; > > @Target({ElementType.TYPE_USE}) > @interface Simple {} > > record R(@Simple int ...val) { > static void test() { > R rec = new R(10, 20); > } > } > > assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed. > > TIA, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/709/files - new: https://git.openjdk.java.net/jdk/pull/709/files/379ee616..21e26551 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=709&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=709&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/709/head:pull/709 PR: https://git.openjdk.java.net/jdk/pull/709 From vromero at openjdk.java.net Wed Nov 4 17:13:08 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 4 Nov 2020 17:13:08 GMT Subject: RFR: 8253385: annotation processors remove varargs information from record components [v2] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 00:46:25 GMT, Jonathan Gibbons wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> addressing review comments > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1788: > >> 1786: private final int pos; >> 1787: >> 1788: private boolean isVarargs; > > field can be final? sure will do ------------- PR: https://git.openjdk.java.net/jdk/pull/709 From vromero at openjdk.java.net Wed Nov 4 18:21:15 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 4 Nov 2020 18:21:15 GMT Subject: RFR: 8253385: annotation processors remove varargs information from record components [v3] In-Reply-To: References: Message-ID: > Please review this fix for a corner case bug. Essentially for code like: > > import java.lang.annotation.*; > > @Target({ElementType.TYPE_USE}) > @interface Simple {} > > record R(@Simple int ...val) { > static void test() { > R rec = new R(10, 20); > } > } > > assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed. > > TIA, > Vicente Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8253385 - addressing review comments - 8253385: annotation processors remove varargs information from record components ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/709/files - new: https://git.openjdk.java.net/jdk/pull/709/files/21e26551..787196a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=709&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=709&range=01-02 Stats: 91449 lines in 1574 files changed: 64459 ins; 19529 del; 7461 mod Patch: https://git.openjdk.java.net/jdk/pull/709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/709/head:pull/709 PR: https://git.openjdk.java.net/jdk/pull/709 From jlahoda at openjdk.java.net Wed Nov 4 19:36:11 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 4 Nov 2020 19:36:11 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v7] In-Reply-To: References: Message-ID: > 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: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> Message-ID: On Mon, 2 Nov 2020 20:21:44 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: >> >> - Removing trailing whitespace. >> - Merging master into JDK-8250768. >> - Updating tests after records are a final feature. >> - Fixing tests. >> - Finalizing removal of record preview hooks. >> - Merging master into JDK-8250768 >> - Reflecting review comments. >> - Merge branch 'master' into JDK-8250768 >> - Removing unnecessary cast. >> - Using a more correct way to get URLs. >> - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900 > > I have read all the files. > > I have added a n umber of various minor non-blocking comments (no need for re-review( to fix these. But I have a couple of comments/questions before finally giving approval. > There's a comment in `PreviewListWriter` about annotation members that needs too be addressed, and I wonder is RECORD and RECORD_COMPONENT need to be added into PreviewElementKind. Thanks @jonathan-gibbons for your comments! I've tried to update the code based on them, mostly in https://github.com/lahodaj/jdk/commit/743f516c660b577035cdda4510a0bb97937fd9b2 and https://github.com/lahodaj/jdk/commit/e4b02827998fc2e8f19f983aabfb3d720b03d111 A big chunk of the update is generalization of the deprecated and preview list builders and writers into a "summary" list builder and writer. These should also now handle records. For record components, those are a little tricky, as (AFAIK) can't currently have deprecation/preview-ness for them (and hence there is no good way to test any support for record components in these). But the summary build and writer are looking for record components and will fail in case a record component is sent into them. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jjg at openjdk.java.net Wed Nov 4 20:57:06 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 4 Nov 2020 20:57:06 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v2] In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> Message-ID: > This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box. > > As an inline tag, the format is `{@spec url label}`, which is roughly translated to `label` in the generated docs. > > As a block tag, the format is simply > > @spec url label > > which is handled in a manner analogous to > > @see label > > The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here. > > This change is only the _support_ for the new tag; it does _not_ include any changes to API docs to _use_ the new tag. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Fix merge issues; review feedback - Merge with master - allow rich content in createAnchorAndSearchIndex - update Docs.gmk to stop disabling spec tag - fix TestSpecTag.testEncodedURI - fix tests - remove support to workaround legacy @spec tag - Merge remote-tracking branch 'upstream/master' into new-spec-tag - fix trailing whitespace in test - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51` - ... and 1 more: https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=790&range=01 Stats: 1374 lines in 42 files changed: 1337 ins; 14 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/790/head:pull/790 PR: https://git.openjdk.java.net/jdk/pull/790 From vromero at openjdk.java.net Wed Nov 4 23:34:00 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 4 Nov 2020 23:34:00 GMT Subject: Integrated: 8253385: annotation processors remove varargs information from record components In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 19:50:31 GMT, Vicente Romero wrote: > Please review this fix for a corner case bug. Essentially for code like: > > import java.lang.annotation.*; > > @Target({ElementType.TYPE_USE}) > @interface Simple {} > > record R(@Simple int ...val) { > static void test() { > R rec = new R(10, 20); > } > } > > assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed. > > TIA, > Vicente This pull request has now been integrated. Changeset: 97a81cee Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/97a81cee Stats: 44 lines in 2 files changed: 43 ins; 0 del; 1 mod 8253385: annotation processors remove varargs information from record components Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/709 From jlahoda at openjdk.java.net Thu Nov 5 08:04:55 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 5 Nov 2020 08:04:55 GMT Subject: Integrated: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: On Thu, 8 Oct 2020 11:49:17 GMT, Jan Lahoda wrote: > This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. > > A summary of changes: > -making the feature permanent (non-preview) > -making the binding variables non-final (as per current specification proposal) > -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal) > -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc. > > This change will not be integrated until JEP 394 is targetted. This pull request has now been integrated. Changeset: 18bc95ba Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/18bc95ba Stats: 651 lines in 90 files changed: 228 ins; 310 del; 113 mod 8250625: Compiler implementation of Pattern Matching for instanceof (Final) Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Thu Nov 5 09:31:20 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 5 Nov 2020 09:31:20 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v8] In-Reply-To: References: Message-ID: > 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: References: Message-ID: > 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: References: 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: References: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@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 wrote: >> I have read all the files. >> >> I have added a n umber of various minor non-blocking comments (no need for re-review( to fix these. But I have a couple of comments/questions before finally giving approval. >> There's a comment in `PreviewListWriter` about annotation members that needs too be addressed, and I wonder is RECORD and RECORD_COMPONENT need to be added into PreviewElementKind. > > Thanks @jonathan-gibbons for your comments! I've tried to update the code based on them, mostly in https://github.com/lahodaj/jdk/commit/743f516c660b577035cdda4510a0bb97937fd9b2 and https://github.com/lahodaj/jdk/commit/e4b02827998fc2e8f19f983aabfb3d720b03d111 > > A big chunk of the update is generalization of the deprecated and preview list builders and writers into a "summary" list builder and writer. These should also now handle records. For record components, those are a little tricky, as (AFAIK) can't currently have deprecation/preview-ness for them (and hence there is no good way to test any support for record components in these). But the summary build and writer are looking for record components and will fail in case a record component is sent into them. FWIW, a javadoc generated with the current version of the patch: http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html And a specdiff comparing it to the javadoc built from the corresponding master: http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.specdiff.01/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From prappo at openjdk.java.net Thu Nov 5 13:15:59 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 5 Nov 2020 13:15:59 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v2] In-Reply-To: References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> Message-ID: On Wed, 4 Nov 2020 20:57:06 GMT, Jonathan Gibbons wrote: >> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box. >> >> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `label` in the generated docs. >> >> As a block tag, the format is simply >> >> @spec url label >> >> which is handled in a manner analogous to >> >> @see label >> >> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here. >> >> This change is only the _support_ for the new tag; it does _not_ include any changes to API docs to _use_ the new tag. > > Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Fix merge issues; review feedback > - Merge with master > - allow rich content in createAnchorAndSearchIndex > - update Docs.gmk to stop disabling spec tag > - fix TestSpecTag.testEncodedURI > - fix tests > - remove support to workaround legacy @spec tag > - Merge remote-tracking branch 'upstream/master' into new-spec-tag > - fix trailing whitespace in test > - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51` > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9 src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 309: > 307: * Creates a new {@code SpecTree} object, to represent a {@code @spec} tag. > 308: * > 309: * @param inline whether this is instance is an inline tag Should be: `* @param inline whether this instance is an inline tag` ------------- PR: https://git.openjdk.java.net/jdk/pull/790 From vromero at openjdk.java.net Thu Nov 5 14:09:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 5 Nov 2020 14:09:58 GMT Subject: RFR: 8253385: annotation processors remove varargs information from record components [v3] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 00:48:02 GMT, Jonathan Gibbons wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8253385 >> - addressing review comments >> - 8253385: annotation processors remove varargs information from record components > > minor suggestions in comments thanks for the review ------------- PR: https://git.openjdk.java.net/jdk/pull/709 From vicente.romero at oracle.com Thu Nov 5 14:32:44 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Nov 2020 09:32:44 -0500 Subject: RFR: JDK-8254784: javac should reject records with @SafeVarargs applied to varargs record component Message-ID: <2da3a4bb-e4c9-28a8-831c-064738a9f808@oracle.com> Hi, Just a kind reminder, please review [1], Thanks, Vicente [1] https://github.com/openjdk/jdk/pull/690 From prappo at openjdk.java.net Thu Nov 5 16:19:59 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 5 Nov 2020 16:19:59 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v2] In-Reply-To: References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> Message-ID: On Wed, 4 Nov 2020 20:57:06 GMT, Jonathan Gibbons wrote: >> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box. >> >> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `label` in the generated docs. >> >> As a block tag, the format is simply >> >> @spec url label >> >> which is handled in a manner analogous to >> >> @see label >> >> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here. >> >> This change is only the _support_ for the new tag; it does _not_ include any changes to API docs to _use_ the new tag. > > Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Fix merge issues; review feedback > - Merge with master > - allow rich content in createAnchorAndSearchIndex > - update Docs.gmk to stop disabling spec tag > - fix TestSpecTag.testEncodedURI > - fix tests > - remove support to workaround legacy @spec tag > - Merge remote-tracking branch 'upstream/master' into new-spec-tag > - fix trailing whitespace in test > - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51` > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9 1. Thanks for incorporating my previous offline feedback. 2. Since Hannes and Erik seem to have looked at everything else, I looked mostly at changes in `src/jdk.compiler/share/classes/com/sun/source/**`, which are good! 3. There should be a corresponding but separate change to "Documentation Comment Specification for the Standard Doclet". 4. Can we use this new `@since` tag to refer to the spec at `com/sun/tools/javac/parser/DocCommentParser.java:1116`? 5. Should we specify in `com.sun.source.doctree.SpecTree` that both `url` and `label` parts are mandatory? 6. `DCSpec extends DCEndPosTree`, sigh... Although that is not a public API, this design suggests we could improve that abstraction sometime later. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1104: > 1102: > 1103: DCTree parse(int pos, Kind kind) throws ParseException { > 1104: if (kind != this.kind && this.kind != Kind.EITHER) { This condition looks right, but shouldn't we add another one to guard against accidental passing of `kind == EITHER`? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 306: > 304: * The {@code ref} argument will be URL-encoded for use as the attribute value. > 305: * > 306: * @param ref the value for the {@code href} attribute} Since you are here, could you please remove that trailing `}`? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 322: > 320: * {@link URI#toASCIIString() converted} to ASCII for use as the attribute value. > 321: * > 322: * @param ref the value for the {@code href} attribute} One more, perhaps copy-pasted, trailing `}`. test/langtools/tools/javac/diags/examples/NoLabel.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2020 Oracle and/or its affiliates. All rights reserved. Should be: `Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 266: > 264: } > 265: > 266: String textOf(List trees) { I wonder if this method should work **recursively** rather than shallowly. Consider the following example: @spec http://example.com Some code: {@code text} I reckon we'll end up with only `Some code: `. src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 81: > 79: return list.stream().allMatch(DCTree::isBlank); > 80: } > 81: Adding these two methods **here** might be overkill. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java line 737: > 735: > 736: for (Taglet t : taglets) { > 737: String name = t.isBlockTag() ? "@" + t.getName() : "{@" + t.getName() + "}"; Out of curiosity, why did you flip that? ------------- Changes requested by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/790 From vromero at openjdk.java.net Thu Nov 5 17:13:12 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 5 Nov 2020 17:13:12 GMT Subject: RFR: 8254784: javac should reject records with @SafeVarargs applied to varargs record component [v2] In-Reply-To: References: Message-ID: > Please review this fix for issue [1]. This is the background, for a record defined like: > > record R(@SafeVarargs String... s) {} > > an the following accessor will be generated: > > `@SafeVararags public String[] s() { return s; }` > > this code is incorrect as the accessor is not a varargs method. But still the compiler is not generating a compiler error. The reason for this is that the method defining the accessor is not generated until the compiler get to its backend phase (at Lower to be more specific) and the check for incorrect @SafeVarargs use in the compiler happen before that, in Attr. > > We decided to do not generate record related code until late phases in order to avoid generating code in the compiler frontend and because if code is generated in early stages then APs could see ASTs not created from user defined code. > > The proposed fix is to issue an error as soon as the compiler finds out that the @SafeVarargs annotation is applied to a compiler generated accessor because in other case the compiler would be forced to generate incorrect code. > > TIA for the reviews, > Vicente > > [1] [https://bugs.openjdk.java.net/browse/JDK-8254784](https://bugs.openjdk.java.net/browse/JDK-8254784) Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - manual merge with master - 8254784: javac should reject records with @SafeVarargs applied to varargs record component ------------- Changes: https://git.openjdk.java.net/jdk/pull/690/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=690&range=01 Stats: 62 lines in 4 files changed: 58 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/690/head:pull/690 PR: https://git.openjdk.java.net/jdk/pull/690 From alex.buckley at oracle.com Thu Nov 5 18:11:00 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 5 Nov 2020 10:11:00 -0800 Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v6] In-Reply-To: <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com> References: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com> Message-ID: On 11/5/2020 4:45 AM, Jan Lahoda wrote: > FWIW, a javadoc generated with the current version of the patch: > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html Allow me to draw people's attention to the PREVIEW link in the banner of the generated javadoc. It shows all the preview APIs in the release on one page. This is very helpful for understanding the surface area of a preview feature. For example, with Sealed Classes being the only preview feature likely to target JDK 16, the PREVIEW page shows that the feature's API is solely about reflection. It's clear that Sealed Classes do not introduce, say, a java.lang.Sealed class analogous to the java.lang.Record class introduced by Records in JDK 14/15 (and which would have appeared on the PREVIEW page had it existed then). Alex From vromero at openjdk.java.net Thu Nov 5 21:37:02 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 5 Nov 2020 21:37:02 GMT Subject: RFR: 8255561: add tests to check binary compatibility rules for records Message-ID: Hi all, Please review this change. It is providing compatibility tests for records in particular section: (13.4.27 Evolution of Record Classes)[http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27]. Thanks, Vicente ------------- Commit messages: - minor edit - Merge branch 'master' into JDK-8255561 - 8255561: add tests to check binary compatibility rules for records Changes: https://git.openjdk.java.net/jdk/pull/1082/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1082&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255561 Stats: 307 lines in 1 file changed: 307 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1082/head:pull/1082 PR: https://git.openjdk.java.net/jdk/pull/1082 From jjg at openjdk.java.net Thu Nov 5 22:14:02 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 5 Nov 2020 22:14:02 GMT Subject: RFR: 8255561: add tests to check binary compatibility rules for records In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 18:55:12 GMT, Vicente Romero wrote: > Hi all, > > Please review this change. It is providing compatibility tests for records. The tests are covering the assertions at section: [13.4.27 Evolution of Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27). > > Thanks, > Vicente A coupe of suggestions, one more significant that the other test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 277: > 275: > 276: // let's first check that it runs wo issues > 277: if (!output.contains("0")) { This is a very weak test that may easily fail for the wrong reasons. Can you make the reference value more distinctive, like 12345, or "Hello World" that could never appear accidentally test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 251: > 249: String clientCode, > 250: boolean shouldFail, > 251: String expectedError) throws Exception { Since the expected error always seems to be the name of a class, you could make the type of the parameter be `Class` and then pass class literals as arguments. Inside the method, you get use `getName()` to get the name you expect to see. ------------- PR: https://git.openjdk.java.net/jdk/pull/1082 From vromero at openjdk.java.net Fri Nov 6 05:18:10 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 6 Nov 2020 05:18:10 GMT Subject: RFR: 8255561: add tests to check binary compatibility rules for records [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review this change. It is providing compatibility tests for records. The tests are covering the assertions at section: [13.4.27 Evolution of Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27). > > Thanks, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1082/files - new: https://git.openjdk.java.net/jdk/pull/1082/files/d1e377c3..16a30015 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1082&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1082&range=00-01 Stats: 31 lines in 1 file changed: 0 ins; 0 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1082/head:pull/1082 PR: https://git.openjdk.java.net/jdk/pull/1082 From vromero at openjdk.java.net Fri Nov 6 05:18:11 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 6 Nov 2020 05:18:11 GMT Subject: RFR: 8255561: add tests to check binary compatibility rules for records [v2] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 22:08:22 GMT, Jonathan Gibbons wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> addressing review comments > > test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 251: > >> 249: String clientCode, >> 250: boolean shouldFail, >> 251: String expectedError) throws Exception { > > Since the expected error always seems to be the name of a class, you could make the type of the parameter be `Class` and then pass class literals as arguments. Inside the method, you get use `getName()` to get the name you expect to see. I have uploaded a new iteration addressing your comments, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/1082 From chris.hegarty at oracle.com Fri Nov 6 15:12:45 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 6 Nov 2020 15:12:45 +0000 Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v6] In-Reply-To: References: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com> Message-ID: > On 5 Nov 2020, at 18:11, Alex Buckley 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 There appears to be a very minor bug; when I click on the PREVIEW link in the banner, the page that lists the preview API points loads, but the banner does not ?highlight? that PREVIEW is ?selected?, but rather it ?highlights? DEPRECATED. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com> Message-ID: On Thu, 5 Nov 2020 12:43:03 GMT, Jan Lahoda 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 > on kulla-dev > :/ > > 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 > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jjg at openjdk.java.net Fri Nov 6 16:21:55 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 6 Nov 2020 16:21:55 GMT Subject: RFR: 8255561: add tests to check binary compatibility rules for records [v2] In-Reply-To: References: Message-ID: On Fri, 6 Nov 2020 05:18:10 GMT, Vicente Romero wrote: >> Hi all, >> >> Please review this change. It is providing compatibility tests for records. The tests are covering the assertions at section: [13.4.27 Evolution of Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27). >> >> Thanks, >> Vicente > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1082 From vromero at openjdk.java.net Fri Nov 6 16:42:56 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 6 Nov 2020 16:42:56 GMT Subject: RFR: 8255561: add tests to check binary compatibility rules for records [v2] In-Reply-To: References: Message-ID: On Fri, 6 Nov 2020 16:19:27 GMT, Jonathan Gibbons wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> addressing review comments > > Marked as reviewed by jjg (Reviewer). thanks for the approval ------------- PR: https://git.openjdk.java.net/jdk/pull/1082 From vromero at openjdk.java.net Fri Nov 6 16:42:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 6 Nov 2020 16:42:58 GMT Subject: Integrated: 8255561: add tests to check binary compatibility rules for records In-Reply-To: References: Message-ID: <8sF3ZTfrD9h_PIPE5XmByNijZqbUa0yhupzyuBTHYJo=.2483cba0-267f-47a6-9600-b268a58e2134@github.com> On Thu, 5 Nov 2020 18:55:12 GMT, Vicente Romero wrote: > Hi all, > > Please review this change. It is providing compatibility tests for records. The tests are covering the assertions at section: [13.4.27 Evolution of Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html#jls-13.4.27). > > Thanks, > Vicente This pull request has now been integrated. Changeset: 688b10b9 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/688b10b9 Stats: 307 lines in 1 file changed: 307 ins; 0 del; 0 mod 8255561: add tests to check binary compatibility rules for records Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/1082 From jlahoda at openjdk.java.net Fri Nov 6 18:41:15 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 6 Nov 2020 18:41:15 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v11] In-Reply-To: References: Message-ID: > 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: References: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com> <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com> <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com> Message-ID: On Fri, 6 Nov 2020 15:32:16 GMT, Jonathan Gibbons 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 >> on kulla-dev >> :/ >> >> 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 >> , >> or unsubscribe >> . >> Thanks for noticing Chris and @jonathan-gibbons. Fixed in 61264fe, updated javadoc: http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.02/api/preview-list.html ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From sirinath1978m at gmail.com Sun Nov 8 06:16:40 2020 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Sun, 8 Nov 2020 11:46:40 +0530 Subject: Interface Related Improvements Message-ID: Hello, I am not sure where to post this, hope some one interested picks this up for consideration. With the introduction of default methods, private methods and static methods in interfaces a few more changes are desirable to improve usability. *Private fields* Since interfaces currently can have private methods it would be much desirable to have private fields also. These can static or instance fields, but minimally at least private static fields initially. If they are instance fields they will be only initialised once regardless of how many places the interface is extended. *Initializers* Interfaces can add initialisers. These will only run one. Minimally at least static initialisers initially. *Reuse of Default Interface Methods* Default methods can improve code reuse in anonymous inner classes and enums. *Improvements to Annonymous Inner Classes to work with the new Java Interfaces* In order to reuse default methods, it will be convenient if something like the following can be valid code. This is similar to what Scala and Groovy does with traits. class X {} interface P { default void f() {} } ... X x = new X() implements P; *Improving Enums to work with the new Java Interfaces* In Enums there are times one does not need to share all implementations like in: enum E { X { f() {} }, Y { g() {} }; } In such cases some times the implementation of f and g can be shared if following is allowed: interface P { default void f() {} } interface Q { default void g() {} } enum E { X impliments P, Y impliments Q; } *Protected Methods* Protected methods could be considered to control what can be accessed on interfaces. *Allow this* Make the meaning of this pointer special in interfaces so features in the implementing classes can be accessed: interface P { X this; default void f() { x(); } } interface Q { X this; default void g() { x(); } } class X implements P, Q { void x() {} } Groovy and Scala has ways to implement something similar with traits. Suminda -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.java.net Mon Nov 9 12:54:06 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 9 Nov 2020 12:54:06 GMT Subject: RFR: 8231599: NPE when loading a preview classfile from a future Java version Message-ID: The javac's ClassReader accepts class files with major version that is +1 higher than the current platform's major version. See https://bugs.openjdk.java.net/browse/JDK-6330997 for more information. A problem is that when this too-new class file is a preview class file, the Preview class will attempt to produce a warning (or error) which includes the user-readable name of the Java platform, and it cannot find the name of the future platform name. If the major version of the class file is >+1 higher than the current platform's, there is no such problem: ClassReader will reject to analyze the class file right away. The proposed (middle ground) fix here is that ClassReader will reject all preview class files with major version > current platform's major version. It will keep accepting non-preview class files with major version +1 than the current. With this patch, the standard error is produced: brokenMajorVersionWithPreview/test/Test.java:1: error: cannot access C class Test extends C {} ^ bad class file: brokenMajorVersionWithPreview/classes/C.class class file has wrong version 61.65535, should be 60.0 Please remove or make sure it appears in the correct subdirectory of the classpath. 1 error Alternatives include: * reject all class files with major version > current * accept preview class files with major version +1 than the current, and attempt the generate a sensible (future) platform name ------------- Commit messages: - 8231599: NPE when loading a preview classfile from a future Java version Changes: https://git.openjdk.java.net/jdk/pull/1123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1123&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231599 Stats: 137 lines in 2 files changed: 135 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1123.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1123/head:pull/1123 PR: https://git.openjdk.java.net/jdk/pull/1123 From vromero at openjdk.java.net Mon Nov 9 17:34:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 9 Nov 2020 17:34:58 GMT Subject: RFR: 8231599: NPE when loading a preview classfile from a future Java version In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 12:47:30 GMT, Jan Lahoda wrote: > The javac's ClassReader accepts class files with major version that is +1 higher than the current platform's major version. See https://bugs.openjdk.java.net/browse/JDK-6330997 for more information. > > A problem is that when this too-new class file is a preview class file, the Preview class will attempt to produce a warning (or error) which includes the user-readable name of the Java platform, and it cannot find the name of the future platform name. > > If the major version of the class file is >+1 higher than the current platform's, there is no such problem: ClassReader will reject to analyze the class file right away. > > The proposed (middle ground) fix here is that ClassReader will reject all preview class files with major version > current platform's major version. It will keep accepting non-preview class files with major version +1 than the current. > > With this patch, the standard error is produced: > brokenMajorVersionWithPreview/test/Test.java:1: error: cannot access C > class Test extends C {} > ^ > bad class file: brokenMajorVersionWithPreview/classes/C.class > class file has wrong version 61.65535, should be 60.0 > Please remove or make sure it appears in the correct subdirectory of the classpath. > 1 error > > Alternatives include: > > * reject all class files with major version > current > * accept preview class files with major version +1 than the current, and attempt the generate a sensible (future) platform name looks sensible to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1123 From jjg at openjdk.java.net Wed Nov 11 02:25:04 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 11 Nov 2020 02:25:04 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v11] In-Reply-To: References: Message-ID: On Fri, 6 Nov 2020 18:41:15 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing navigator for the PREVIEW page. I have a mild queasiness about this new overloaded use of the word "Summary", since "summary tables" are normally the summary of the contents of a declaration, like fields and methods of a class. That being said, the usage is primarily internal, and I have no overwhelmingly wonderful alternative, and (overloading aside) the term is accurate. So, OK for now. We can change it later if we want to. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2949: > 2947: > 2948: /** > 2949: * Return the set of preview language features used to declare the given element. "Returns" ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Wed Nov 11 09:08:00 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 11 Nov 2020 09:08:00 GMT Subject: RFR: 8256149: Weird AST structure for incomplete member select Message-ID: Consider code like: int i1 = "". @Deprecated void t1() {} In current master, this will produce a somewhat twisted AST, and compile-time errors like: E.java:2: error: expected int i = "". ^ E.java:3: error: illegal start of expression @Deprecated void t() {} ^ E.java:3: error: ';' expected @Deprecated void t() {} ^ 3 errors The reason is that `@Deprecated` is parsed as a type annotation following `"".`, which does not make much sense. With this proposed patch, the AST is effectively the same as AST for: int i1 = "".; //note the semicolon here @Deprecated void t1() {} And the errors are much better as well: E.java:2: error: expected int i = "". ^ 1 error ------------- Commit messages: - 8256149: Weird AST structure for incomplete member select Changes: https://git.openjdk.java.net/jdk/pull/1159/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1159&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256149 Stats: 61 lines in 2 files changed: 60 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1159.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1159/head:pull/1159 PR: https://git.openjdk.java.net/jdk/pull/1159 From jlahoda at openjdk.java.net Wed Nov 11 09:13:59 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 11 Nov 2020 09:13:59 GMT Subject: Integrated: 8231599: NPE when loading a preview classfile from a future Java version In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 12:47:30 GMT, Jan Lahoda wrote: > The javac's ClassReader accepts class files with major version that is +1 higher than the current platform's major version. See https://bugs.openjdk.java.net/browse/JDK-6330997 for more information. > > A problem is that when this too-new class file is a preview class file, the Preview class will attempt to produce a warning (or error) which includes the user-readable name of the Java platform, and it cannot find the name of the future platform name. > > If the major version of the class file is >+1 higher than the current platform's, there is no such problem: ClassReader will reject to analyze the class file right away. > > The proposed (middle ground) fix here is that ClassReader will reject all preview class files with major version > current platform's major version. It will keep accepting non-preview class files with major version +1 than the current. > > With this patch, the standard error is produced: > brokenMajorVersionWithPreview/test/Test.java:1: error: cannot access C > class Test extends C {} > ^ > bad class file: brokenMajorVersionWithPreview/classes/C.class > class file has wrong version 61.65535, should be 60.0 > Please remove or make sure it appears in the correct subdirectory of the classpath. > 1 error > > Alternatives include: > > * reject all class files with major version > current > * accept preview class files with major version +1 than the current, and attempt the generate a sensible (future) platform name This pull request has now been integrated. Changeset: 129ff97f Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/129ff97f Stats: 137 lines in 2 files changed: 135 ins; 0 del; 2 mod 8231599: NPE when loading a preview classfile from a future Java version Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/1123 From shade at openjdk.java.net Thu Nov 12 17:49:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 12 Nov 2020 17:49:10 GMT Subject: RFR: 8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32 Message-ID: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com> Observe: $ CONF=linux-x86_64-server-fastdebug make images run-test TEST=tools/javac/lambda/T8031967.java STDOUT: STDERR: GroupLayout l = new GroupLayout(); ^ symbol: class GroupLayout location: class Test GroupLayout l = new GroupLayout(); ^ symbol: class GroupLayout location: class Test java.lang.IllegalStateException: java.lang.StackOverflowError at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) at T8031967.runTestCase(T8031967.java:108) at T8031967.run(T8031967.java:55) at T8031967.main(T8031967.java:49) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) Caused by: java.lang.StackOverflowError at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2651) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:4020) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2407) x86_32 defaults to 320K stack size, x86_64 (and pretty much every other platform) defaults to 1M stack size. Setting -Xss1M explicitly makes the test pass. ------------- Commit messages: - 8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32 Changes: https://git.openjdk.java.net/jdk/pull/1193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1193&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256290 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1193/head:pull/1193 PR: https://git.openjdk.java.net/jdk/pull/1193 From mcimadamore at openjdk.java.net Thu Nov 12 18:13:56 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 Nov 2020 18:13:56 GMT Subject: RFR: 8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32 In-Reply-To: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com> References: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com> Message-ID: On Thu, 12 Nov 2020 17:44:59 GMT, Aleksey Shipilev wrote: > Observe: > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/javac/lambda/T8031967.java > > STDOUT: > STDERR: > > GroupLayout l = new GroupLayout(); > ^ > symbol: class GroupLayout > location: class Test > > GroupLayout l = new GroupLayout(); > ^ > symbol: class GroupLayout > location: class Test > java.lang.IllegalStateException: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) > at T8031967.runTestCase(T8031967.java:108) > at T8031967.run(T8031967.java:55) > at T8031967.main(T8031967.java:49) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2651) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:4020) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2407) > > x86_32 defaults to 320K stack size, x86_64 (and pretty much every other platform) defaults to 1M stack size. Setting -Xss1M explicitly makes the test pass. Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1193 From ihse at openjdk.java.net Thu Nov 12 22:23:02 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 12 Nov 2020 22:23:02 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file Message-ID: Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) ------------- Commit messages: - 8256308: Send arguments to javac server in a config file Changes: https://git.openjdk.java.net/jdk/pull/1195/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256308 Stats: 118 lines in 3 files changed: 48 ins; 33 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/1195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195 PR: https://git.openjdk.java.net/jdk/pull/1195 From ihse at openjdk.java.net Thu Nov 12 22:54:13 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 12 Nov 2020 22:54:13 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v2] In-Reply-To: References: Message-ID: > Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. > > Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. > > So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. > > Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. > > I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix race where multiple compilations overwrite the config file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1195/files - new: https://git.openjdk.java.net/jdk/pull/1195/files/26e5efdd..0a613f55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=00-01 Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195 PR: https://git.openjdk.java.net/jdk/pull/1195 From ihse at openjdk.java.net Fri Nov 13 00:12:12 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 Nov 2020 00:12:12 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v3] In-Reply-To: References: Message-ID: > Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. > > Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. > > So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. > > Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. > > I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Paths on Windows must be converted before being written to the config file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1195/files - new: https://git.openjdk.java.net/jdk/pull/1195/files/0a613f55..c47f7c2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=01-02 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195 PR: https://git.openjdk.java.net/jdk/pull/1195 From ihse at openjdk.java.net Fri Nov 13 01:04:15 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 Nov 2020 01:04:15 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v4] In-Reply-To: References: Message-ID: > Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. > > Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. > > So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. > > Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. > > I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Some rules had identical names which still caused races, so move config file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1195/files - new: https://git.openjdk.java.net/jdk/pull/1195/files/c47f7c2a..ba312950 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195 PR: https://git.openjdk.java.net/jdk/pull/1195 From ihse at openjdk.java.net Fri Nov 13 01:08:09 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 Nov 2020 01:08:09 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v5] In-Reply-To: References: Message-ID: > Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. > > Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. > > So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. > > Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. > > I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: MODULE_SUBDIR must be defined before using ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1195/files - new: https://git.openjdk.java.net/jdk/pull/1195/files/ba312950..44507d25 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=03-04 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195 PR: https://git.openjdk.java.net/jdk/pull/1195 From shade at openjdk.java.net Fri Nov 13 07:43:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 13 Nov 2020 07:43:00 GMT Subject: Integrated: 8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32 In-Reply-To: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com> References: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com> Message-ID: On Thu, 12 Nov 2020 17:44:59 GMT, Aleksey Shipilev wrote: > Observe: > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/javac/lambda/T8031967.java > > STDOUT: > STDERR: > > GroupLayout l = new GroupLayout(); > ^ > symbol: class GroupLayout > location: class Test > > GroupLayout l = new GroupLayout(); > ^ > symbol: class GroupLayout > location: class Test > java.lang.IllegalStateException: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) > at T8031967.runTestCase(T8031967.java:108) > at T8031967.run(T8031967.java:55) > at T8031967.main(T8031967.java:49) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: java.lang.StackOverflowError > at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2651) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:4020) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2407) > > x86_32 defaults to 320K stack size, x86_64 (and pretty much every other platform) defaults to 1M stack size. Setting -Xss1M explicitly makes the test pass. This pull request has now been integrated. Changeset: 05b82456 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/05b82456 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32 Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/1193 From shade at openjdk.java.net Fri Nov 13 07:42:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 13 Nov 2020 07:42:58 GMT Subject: RFR: 8256290: javac/lambda/T8031967.java fails with StackOverflowError on x86_32 In-Reply-To: References: <0BSDm0n3f96EtFNUOOo5cmC6HYx8OW7NbMu6sAZr9nM=.53a5c745-4af9-41a0-a29c-666a0b53560e@github.com> Message-ID: On Thu, 12 Nov 2020 18:11:30 GMT, Maurizio Cimadamore wrote: >> Observe: >> >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/javac/lambda/T8031967.java >> >> STDOUT: >> STDERR: >> >> GroupLayout l = new GroupLayout(); >> ^ >> symbol: class GroupLayout >> location: class Test >> >> GroupLayout l = new GroupLayout(); >> ^ >> symbol: class GroupLayout >> location: class Test >> java.lang.IllegalStateException: java.lang.StackOverflowError >> at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383) >> at T8031967.runTestCase(T8031967.java:108) >> at T8031967.run(T8031967.java:55) >> at T8031967.main(T8031967.java:49) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: java.lang.StackOverflowError >> at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2651) >> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:4020) >> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2407) >> >> x86_32 defaults to 320K stack size, x86_64 (and pretty much every other platform) defaults to 1M stack size. Setting -Xss1M explicitly makes the test pass. > > Looks good Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1193 From mcimadamore at openjdk.java.net Fri Nov 13 12:47:06 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 Nov 2020 12:47:06 GMT Subject: RFR: 8254784: javac should reject records with @SafeVarargs applied to varargs record component [v2] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 17:13:12 GMT, Vicente Romero wrote: >> Please review this fix for issue [1]. This is the background, for a record defined like: >> >> record R(@SafeVarargs String... s) {} >> >> an the following accessor will be generated: >> >> `@SafeVararags public String[] s() { return s; }` >> >> this code is incorrect as the accessor is not a varargs method. But still the compiler is not generating a compiler error. The reason for this is that the method defining the accessor is not generated until the compiler get to its backend phase (at Lower to be more specific) and the check for incorrect @SafeVarargs use in the compiler happen before that, in Attr. >> >> We decided to do not generate record related code until late phases in order to avoid generating code in the compiler frontend and because if code is generated in early stages then APs could see ASTs not created from user defined code. >> >> The proposed fix is to issue an error as soon as the compiler finds out that the @SafeVarargs annotation is applied to a compiler generated accessor because in other case the compiler would be forced to generate incorrect code. >> >> TIA for the reviews, >> Vicente >> >> [1] [https://bugs.openjdk.java.net/browse/JDK-8254784](https://bugs.openjdk.java.net/browse/JDK-8254784) > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - manual merge with master > - 8254784: javac should reject records with @SafeVarargs applied to varargs record component Seems sensible. A possible alternative would be to err immediately when we see (e.g. in TypeEnter?) that a record header contains a SafeVarargs annotation, in which case we know we can't support it. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/690 From erikj at openjdk.java.net Fri Nov 13 14:32:03 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 13 Nov 2020 14:32:03 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v5] In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 01:08:09 GMT, Magnus Ihse Bursie wrote: >> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. >> >> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. >> >> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. >> >> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. >> >> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > MODULE_SUBDIR must be defined before using make/common/JavaCompilation.gmk line 237: > 235: $1_JAVAC_SERVER_CMD := $$(JAVA_DETACH) $$($1_JAVA_FLAGS) $$($1_JAVAC) > 236: > 237: $1_CONFIG_VARDEPS :=$$($1_JAVAC_PORT_FILE) $$($1_JAVAC_SERVER_CMD) Space make/common/JavaCompilation.gmk line 239: > 237: $1_CONFIG_VARDEPS :=$$($1_JAVAC_PORT_FILE) $$($1_JAVAC_SERVER_CMD) > 238: $1_CONFIG_VARDEPS_FILE := $$(call DependOnVariable, $1_CONFIG_VARDEPS, \ > 239: $$($1_BIN)$$($1_MODULE_SUBDIR)/_the.$1.config_vardeps) Indentation 4 make/common/JavaCompilation.gmk line 246: > 244: $1_ECHO_COMMAND := $(ECHO) > 245: endif > 246: $$($1_JAVAC_SERVER_CONFIG): $$($1_CONFIG_VARDEPS_FILE) Indentation? ------------- PR: https://git.openjdk.java.net/jdk/pull/1195 From erikj at openjdk.java.net Fri Nov 13 14:31:59 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 13 Nov 2020 14:31:59 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 22:13:37 GMT, Magnus Ihse Bursie wrote: > Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. > > Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. > > So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. > > Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. > > I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) Looks good in general, just some whitespace issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/1195 From sormuras at gmail.com Fri Nov 13 15:07:43 2020 From: sormuras at gmail.com (Christian Stein) Date: Fri, 13 Nov 2020 16:07:43 +0100 Subject: jlink'ed javac misses --release support and numbers Message-ID: Hi, When creating a custom runtime image via jlink that includes module jdk.compiler and its dependencies, the resulting javac tool of that image doesn't support the --release option. The error message reads, using 16-ea+24 as the basis and --release 16 on the command: release version 16 not supported Usage: javac use --help for a list of possible options Running javac --help from within the custom image lacks all numbers: [...] --release Compile for the specified Java SE release. Supported releases: -s Specify where to place generated source files --source , -source Provide source compatibility with the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 [...] The help texts for options --source and --target do show all numbers. Am I missing something? Perhaps an internal(?) module that contains the API definitions used by javac? Cheers, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Nov 13 16:11:51 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Nov 2020 08:11:51 -0800 Subject: jlink'ed javac misses --release support and numbers In-Reply-To: References: Message-ID: <292a772b-f56a-cf7a-0925-6cfdcf1924ca@oracle.com> Hi Christian, This seems worthy of a bug to track this issue. -- Jon On 11/13/20 7:07 AM, Christian Stein wrote: > Hi, > > When creating a custom runtime image via jlink that includes > module?jdk.compiler and its dependencies, the resulting javac tool of > that image doesn't support the --release option. > > The error message reads, using 16-ea+24 as the basis and --release 16 > on the command: > > ? release version 16 not supported > ? ? Usage: javac > ? ? use --help for a list of possible options > > Running javac --help from within the custom image lacks all numbers: > [...] > ? --release > ? ? ? ? Compile for the specified Java SE release. Supported releases: > ? -s ? ? ? ? ? ? ? Specify where to place generated source > files > ? --source , -source > ? ? ? ? Provide source compatibility with the specified Java SE > release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 > [...] > > The help texts for options --source and --target do show all numbers. > > Am I missing something? Perhaps an internal(?) module that contains > the API definitions used by javac? > > Cheers, > Christian From jonathan.gibbons at oracle.com Fri Nov 13 16:18:08 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Nov 2020 08:18:08 -0800 Subject: jlink'ed javac misses --release support and numbers In-Reply-To: References: Message-ID: Filed as https://bugs.openjdk.java.net/browse/JDK-8256343 -- Jon On 11/13/20 7:07 AM, Christian Stein wrote: > When creating a custom runtime image via jlink that includes > module?jdk.compiler and its dependencies, the resulting javac tool of > that image doesn't support the --release option. > > The error message reads, using 16-ea+24 as the basis and --release 16 > on the command: > > ? release version 16 not supported > ? ? Usage: javac > ? ? use --help for a list of possible options > > Running javac --help from within the custom image lacks all numbers: > [...] > ? --release > ? ? ? ? Compile for the specified Java SE release. Supported releases: > ? -s ? ? ? ? ? ? ? Specify where to place generated source > files > ? --source , -source > ? ? ? ? Provide source compatibility with the specified Java SE > release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 > [...] > > The help texts for options --source and --target do show all numbers. From jlahoda at openjdk.java.net Fri Nov 13 16:52:07 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 13 Nov 2020 16:52:07 GMT Subject: RFR: 8256266: Declaration annotations don't work properly for binding variables Message-ID: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com> Basically, javac does not handle code like this properly: import java.lang.annotation.*; public class B { public void test(Object o) { if (o instanceof @A String s) {} } } @Target(ElementType.LOCAL_VARIABLE) @interface A {} The parser needs to allow declaration annotations on binding variables, see: http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1 ------------- Commit messages: - Removing an extra whitespace. - 8256266: Declaration annotations don't work properly for binding variables Changes: https://git.openjdk.java.net/jdk/pull/1192/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1192&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256266 Stats: 201 lines in 6 files changed: 198 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1192.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1192/head:pull/1192 PR: https://git.openjdk.java.net/jdk/pull/1192 From neshkeev at yandex.ru Sat Nov 14 21:44:11 2020 From: neshkeev at yandex.ru (Nikita Eshkeev) Date: Sun, 15 Nov 2020 00:44:11 +0300 Subject: Extend Sealed Types to support GADT Message-ID: <2701151605389322@mail.yandex.ru> An HTML attachment was scrubbed... URL: From neshkeev at yandex.ru Sat Nov 14 21:58:53 2020 From: neshkeev at yandex.ru (Nikita Eshkeev) Date: Sun, 15 Nov 2020 00:58:53 +0300 Subject: Adding Do notaion/For comprehension Message-ID: <876231605390259@mail.yandex.ru> An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Nov 15 17:02:58 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 15 Nov 2020 18:02:58 +0100 (CET) Subject: Records, Intersection type and lambda Message-ID: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr> I've found this bug trying to refactor existing classes to records but it's not directly related to record, i believe. It's an issue with intersection type and lambdas, Weirdly, i seen to recall alreadu seeing this bug ?? For me it's a compiler error, the compiler choose the first type of the intersection type (Record & Foo) instead of choosing the second, the one allowing m(Foo) to be called. regards, R?mi ---- import java.util.List; public class RecordIntersectionTypeAndLambda { interface Foo { } record Bar1() implements Foo { } record Bar2() implements Foo { } static class Hello { void m(Foo foo) { } } public static void main(String[] args) { var list = List.of(new Bar1(), new Bar2()); list.forEach(new Hello()::m); } } [forax at localhost java-fun]$ ~/jdk/jdk-16/bin/java --version openjdk 16-ea 2021-03-16 OpenJDK Runtime Environment (build 16-ea+24-1553) OpenJDK 64-Bit Server VM (build 16-ea+24-1553, mixed mode, sharing) [forax at localhost java-fun]$ cd src/ [forax at localhost src]$ ~/jdk/jdk-16/bin/javac RecordIntersectionTypeAndLambda.java [forax at localhost src]$ ~/jdk/jdk-16/bin/java RecordIntersectionTypeAndLambda Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method initialization exception at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194) at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:315) at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280) at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270) at RecordIntersectionTypeAndLambda.main(RecordIntersectionTypeAndLambda.java:14) Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for lambda argument 1: class java.lang.Record is not convertible to interface RecordIntersectionTypeAndLambda$Foo at java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:293) at java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:327) at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127) ... 4 more From jan.lahoda at oracle.com Mon Nov 16 10:33:35 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 16 Nov 2020 11:33:35 +0100 Subject: Experimental fix for capturing anonymous classes inside lambda (JDK-8229862) In-Reply-To: References: Message-ID: Hi Bernard, Sorry for belated answer. I've filled: https://github.com/openjdk/jdk/pull/1221 based on your patch. Hope that is fine. Any feedback is welcome! Thanks, Jan On 20. 10. 20 20:46, B. Blaser wrote: > Hi, > > JDK-8229862 reveals that capturing anonymous classes inside lambda > seem not to be properly implemented yet, although the opposite > currently works fine in JDK-16 (see [1] or [2], for example). > > The following experimental fix (on jdk14u) searches for local > variables captured by anonymous classes inside lambda (in > LambdaToMethod) and translates them according to corresponding proxies > (in Lower). > > What do you think (langtools:tier1 is OK)? > > Thanks, > Bernard > > [1] test/langtools/tools/javac/lambda/T8209407/VerifierErrorInnerPlusLambda.java > [2] test/langtools/tools/javac/lambda/methodReference/ProtectedInaccessibleMethodRefTest.java > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > @@ -1380,9 +1380,18 @@ > super.visitIdent(tree); > } > > + boolean inLambda = false; > + > @Override > public void visitLambda(JCLambda tree) { > - analyzeLambda(tree, "lambda.stat"); > + boolean prevInLambda = inLambda; > + try { > + inLambda = true; > + analyzeLambda(tree, "lambda.stat"); > + } > + finally { > + inLambda = prevInLambda; > + } > } > > private void analyzeLambda(JCLambda tree, JCExpression > methodReferenceReceiver) { > @@ -1430,6 +1439,16 @@ > > @Override > public void visitNewClass(JCNewClass tree) { > + if (tree.def != null && inLambda) { > + try { > + inLambda = false; > + visitClassDef(tree.def); > + } > + finally { > + inLambda = true; > + } > + } > + > TypeSymbol def = tree.type.tsym; > boolean inReferencedClass = currentlyInClass(def); > boolean isLocal = def.isLocal(); > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > @@ -2812,7 +2812,14 @@ > // If we have an anonymous class, create its flat version, rather > // than the class or interface following new. > if (tree.def != null) { > - translate(tree.def); > + Map prevLambdaTranslationMap = > lambdaTranslationMap; > + try { > + lambdaTranslationMap = null; > + translate(tree.def); > + } finally { > + lambdaTranslationMap = prevLambdaTranslationMap; > + } > + > tree.clazz = access(make_at(tree.clazz.pos()).Ident(tree.def.sym)); > tree.def = null; > } else { > From jlahoda at openjdk.java.net Mon Nov 16 10:38:03 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 16 Nov 2020 10:38:03 GMT Subject: RFR: 8229862: NPE in jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570) Message-ID: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com> Based on Bernard's code from: http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015225.html Capturing anonymous classes inside lambdas may fail to compile, because: -the captured variables are not detected correctly, because `LambdaToMethod...captureLocalClassDefs` needs to find the AST node for the given `ClassSymbol`, but it has not yet been added into the `localClassDefs`. The proposed solution is to re-order the tasks done for JCNewClass, and call the super implementation sooner. This will enter the `ClassSymbol` and corresponding AST node into `localClassDefs` before the capture variables detection. -inside the anonymous class definition, some references to the captured variables are replaced using a map that maps captured variables for lambdas (`lambdaTranslationMap`) - but inside the anonymous class, there the captured variables should be mapped using the anonymous class' map/proxies (to fields). The proposed solution is to clear `lambdaTranslationMap` before processing the anonymous class body. ------------- Commit messages: - 8229862: NPE in jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570) Changes: https://git.openjdk.java.net/jdk/pull/1221/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1221&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8229862 Stats: 64 lines in 3 files changed: 62 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1221.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1221/head:pull/1221 PR: https://git.openjdk.java.net/jdk/pull/1221 From magnus.ihse.bursie at oracle.com Mon Nov 16 12:43:53 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Nov 2020 13:43:53 +0100 Subject: RFR: 8256308: Send arguments to javac server in a config file In-Reply-To: References: Message-ID: I would appreciate if someone from langtools could have a look at this as well. Thanks! /Magnus On 2020-11-12 23:23, Magnus Ihse Bursie wrote: > Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. > > Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. > > So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. > > Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. > > I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) > > ------------- > > Commit messages: > - 8256308: Send arguments to javac server in a config file > > Changes: https://git.openjdk.java.net/jdk/pull/1195/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8256308 > Stats: 118 lines in 3 files changed: 48 ins; 33 del; 37 mod > Patch: https://git.openjdk.java.net/jdk/pull/1195.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195 > > PR: https://git.openjdk.java.net/jdk/pull/1195 From ihse at openjdk.java.net Mon Nov 16 12:44:08 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 16 Nov 2020 12:44:08 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v6] In-Reply-To: References: Message-ID: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> > Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. > > Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. > > So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. > > Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. > > I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1195/files - new: https://git.openjdk.java.net/jdk/pull/1195/files/44507d25..3015d5e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1195/head:pull/1195 PR: https://git.openjdk.java.net/jdk/pull/1195 From vromero at openjdk.java.net Mon Nov 16 13:36:13 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 16 Nov 2020 13:36:13 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) Message-ID: Please review the code for the second iteration of sealed classes. In this iteration we are: - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies. - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface ------------- Commit messages: - 8246778: Compiler implementation for Sealed Classes (Second Preview) Changes: https://git.openjdk.java.net/jdk/pull/1227/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246778 Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod Patch: https://git.openjdk.java.net/jdk/pull/1227.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1227/head:pull/1227 PR: https://git.openjdk.java.net/jdk/pull/1227 From erikj at openjdk.java.net Mon Nov 16 13:43:07 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 16 Nov 2020 13:43:07 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v6] In-Reply-To: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> References: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> Message-ID: On Mon, 16 Nov 2020 12:44:08 GMT, Magnus Ihse Bursie wrote: >> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. >> >> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. >> >> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. >> >> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. >> >> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace issues Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1195 From alanb at openjdk.java.net Mon Nov 16 13:52:06 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 16 Nov 2020 13:52:06 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero wrote: > Please review the code for the second iteration of sealed classes. In this iteration we are: > > - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies > - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface > - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] > - adding code to make sure that annotations can't be sealed > - improving some tests > > TIA > > Related specs: > [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) > [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) > [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) src/java.base/share/classes/java/lang/Package.java line 227: > 225: * This method reports on a distinct concept of sealing from > 226: * {@link Class#isSealed() Class::isSealed}. > 227: * This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1227 From mcimadamore at openjdk.java.net Mon Nov 16 14:01:04 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 16 Nov 2020 14:01:04 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero wrote: > Please review the code for the second iteration of sealed classes. In this iteration we are: > > - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies > - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface > - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] > - adding code to make sure that annotations can't be sealed > - improving some tests > > TIA > > Related specs: > [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) > [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) > [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) I left some comments re. the changes in cast conversion routine src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1659: > 1657: result = isCastable.visit(t,s); > 1658: } > 1659: if ((t.tsym.isSealed() || s.tsym.isSealed())) { It would probably be better to only run this extra check if `result == true`, to minimize compatibility impact. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1672: > 1670: } > 1671: // if both are classes or both are interfaces, shortcut > 1672: if (ts.isInterface() == ss.isInterface()) { What happens with code like this? interface A permits B { } non-sealed interface B extends A { } interface C { } class D implements C, B { } // this is a valid witness for both A and C, but A and C are unrelated with subtyping class Test { void m(A a, C c) { a = (A)c; } }``` Note that, w/o sealed types, the above snippet compiles ok - e.g. casting C to A is not going to give problems (as there could be a common subtype D <: A, C). ------------- PR: https://git.openjdk.java.net/jdk/pull/1227 From bsrbnd at gmail.com Mon Nov 16 17:06:12 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Nov 2020 18:06:12 +0100 Subject: Experimental fix for capturing anonymous classes inside lambda (JDK-8229862) In-Reply-To: References: Message-ID: Thanks Jan, your improvement in LambdaToMethod seems reasonable to me. Cheers, Bernard On Mon, 16 Nov 2020 at 11:33, Jan Lahoda wrote: > > Hi Bernard, > > Sorry for belated answer. > > I've filled: > https://github.com/openjdk/jdk/pull/1221 > > based on your patch. Hope that is fine. Any feedback is welcome! > > Thanks, > Jan From bsrbnd at gmail.com Mon Nov 16 17:13:55 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Nov 2020 18:13:55 +0100 Subject: Records, Intersection type and lambda In-Reply-To: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr> References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr> Message-ID: Probably related to: http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015185.html Regards, Bernard On Sun, 15 Nov 2020 at 18:03, Remi Forax wrote: > > I've found this bug trying to refactor existing classes to records but it's not directly related to record, i believe. > > It's an issue with intersection type and lambdas, > Weirdly, i seen to recall alreadu seeing this bug ?? > > For me it's a compiler error, the compiler choose the first type of the intersection type (Record & Foo) instead of choosing the second, the one allowing m(Foo) to be called. > > regards, > R?mi > > ---- > > import java.util.List; > > public class RecordIntersectionTypeAndLambda { > interface Foo { } > record Bar1() implements Foo { } > record Bar2() implements Foo { } > > static class Hello { > void m(Foo foo) { } > } > > public static void main(String[] args) { > var list = List.of(new Bar1(), new Bar2()); > list.forEach(new Hello()::m); > } > } > > [forax at localhost java-fun]$ ~/jdk/jdk-16/bin/java --version > openjdk 16-ea 2021-03-16 > OpenJDK Runtime Environment (build 16-ea+24-1553) > OpenJDK 64-Bit Server VM (build 16-ea+24-1553, mixed mode, sharing) > > [forax at localhost java-fun]$ cd src/ > [forax at localhost src]$ ~/jdk/jdk-16/bin/javac RecordIntersectionTypeAndLambda.java > [forax at localhost src]$ ~/jdk/jdk-16/bin/java RecordIntersectionTypeAndLambda > Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method initialization exception > at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194) > at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:315) > at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280) > at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270) > at RecordIntersectionTypeAndLambda.main(RecordIntersectionTypeAndLambda.java:14) > Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for lambda argument 1: class java.lang.Record is not convertible to interface RecordIntersectionTypeAndLambda$Foo > at java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:293) > at java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:327) > at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127) > ... 4 more From jlahoda at openjdk.java.net Mon Nov 16 18:17:09 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 16 Nov 2020 18:17:09 GMT Subject: RFR: 8256411: Based anonymous classes have a weird end position Message-ID: <7aKd4Z5-b2wrbXxf5Kz2ZRjPKyl4Zw0JRVTt6e9hA2M=.71073831-380f-4a99-ad8d-1112a05af229@github.com> Consider code like this: package t; class Test { class I {} static Object S = new Test().new I() {}; } There is a synthetically generated `Test.I` in the extends clause of the anonymous class. The current end position for it is the end of the whole anonymous class (i.e. at '}'), which does not make much sense. The proposal is that the end position should be the end position of the "I" identifier, which is the same as if the anonymous class would not be based on an enclosing instance. ------------- Commit messages: - 8256411: Based anonymous classes have a weird end position Changes: https://git.openjdk.java.net/jdk/pull/1232/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1232&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256411 Stats: 39 lines in 3 files changed: 35 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1232/head:pull/1232 PR: https://git.openjdk.java.net/jdk/pull/1232 From mchung at openjdk.java.net Tue Nov 17 00:29:03 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 17 Nov 2020 00:29:03 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com> On Mon, 16 Nov 2020 13:49:26 GMT, Alan Bateman wrote: >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> - adding code to make sure that annotations can't be sealed >> - improving some tests >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > src/java.base/share/classes/java/lang/Package.java line 227: > >> 225: * This method reports on a distinct concept of sealing from >> 226: * {@link Class#isSealed() Class::isSealed}. >> 227: * > > This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing. I agree. This @apiNote needs more clarification to help the readers to understand the context here. One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes". ------------- PR: https://git.openjdk.java.net/jdk/pull/1227 From mchung at openjdk.java.net Tue Nov 17 02:07:06 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 17 Nov 2020 02:07:06 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero wrote: > Please review the code for the second iteration of sealed classes. In this iteration we are: > > - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies > - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface > - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] > - adding code to make sure that annotations can't be sealed > - improving some tests > > TIA > > Related specs: > [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) > [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) > [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) src/java.base/share/classes/java/lang/Class.java line 4381: > 4379: */ > 4380: @jdk.internal.PreviewFeature(feature=jdk.internal.PreviewFeature.Feature.SEALED_CLASSES, essentialAPI=false) > 4381: public Class[] getPermittedSubclasses() { What happens if a permitted subclass is not found? I see that `getPermittedSubclasses0` ignores the entry if the class is not found. Should that be specified? Have you considered whether security package access is needed (now that this method returns `Class` objects the caller may not have access to)? This needs to be discussed with the security team. If someone gets a hold of a sealed class (e.g. `obj.getClass()`), this method could leak other `Class` objects. ------------- PR: https://git.openjdk.java.net/jdk/pull/1227 From forax at univ-mlv.fr Tue Nov 17 07:46:20 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 17 Nov 2020 08:46:20 +0100 (CET) Subject: Records, Intersection type and lambda In-Reply-To: References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr> Message-ID: <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "B. Blaser" > ?: "Remi Forax" , "Vicente Romero" > Cc: "amber-dev" , "compiler-dev" > Envoy?: Lundi 16 Novembre 2020 18:13:55 > Objet: Re: Records, Intersection type and lambda > Probably related to: > http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015185.html yes, thanks ! still not fixed :( > > Regards, > Bernard regards, R?mi > > On Sun, 15 Nov 2020 at 18:03, Remi Forax wrote: >> >> I've found this bug trying to refactor existing classes to records but it's not >> directly related to record, i believe. >> >> It's an issue with intersection type and lambdas, >> Weirdly, i seen to recall alreadu seeing this bug ?? >> >> For me it's a compiler error, the compiler choose the first type of the >> intersection type (Record & Foo) instead of choosing the second, the one >> allowing m(Foo) to be called. >> >> regards, >> R?mi >> >> ---- >> >> import java.util.List; >> >> public class RecordIntersectionTypeAndLambda { >> interface Foo { } >> record Bar1() implements Foo { } >> record Bar2() implements Foo { } >> >> static class Hello { >> void m(Foo foo) { } >> } >> >> public static void main(String[] args) { >> var list = List.of(new Bar1(), new Bar2()); >> list.forEach(new Hello()::m); >> } >> } >> >> [forax at localhost java-fun]$ ~/jdk/jdk-16/bin/java --version >> openjdk 16-ea 2021-03-16 >> OpenJDK Runtime Environment (build 16-ea+24-1553) >> OpenJDK 64-Bit Server VM (build 16-ea+24-1553, mixed mode, sharing) >> >> [forax at localhost java-fun]$ cd src/ >> [forax at localhost src]$ ~/jdk/jdk-16/bin/javac >> RecordIntersectionTypeAndLambda.java >> [forax at localhost src]$ ~/jdk/jdk-16/bin/java RecordIntersectionTypeAndLambda >> Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method >> initialization exception >> at >> java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194) >> at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:315) >> at >> java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280) >> at >> java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270) >> at RecordIntersectionTypeAndLambda.main(RecordIntersectionTypeAndLambda.java:14) >> Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for lambda >> argument 1: class java.lang.Record is not convertible to interface >> RecordIntersectionTypeAndLambda$Foo >> at >> java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:293) >> at >> java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:327) >> at >> java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127) > > ... 4 more From fw at deneb.enyo.de Tue Nov 17 17:01:17 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 17 Nov 2020 18:01:17 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> (Phil Race's message of "Mon, 2 Nov 2020 04:29:10 GMT") References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: <87o8jv6hpe.fsf@mid.deneb.enyo.de> * Phil Race: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - > an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on > all platforms. Is it just me, or does the new Harfbuzz build *significantly* slower? It adds about 20 seconds to the build, compared to using the system Harfbuzz, whereas before it was around 5 seconds. From philip.race at oracle.com Tue Nov 17 17:56:47 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 17 Nov 2020 09:56:47 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <87o8jv6hpe.fsf@mid.deneb.enyo.de> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <87o8jv6hpe.fsf@mid.deneb.enyo.de> Message-ID: <5FB40EDF.4090300@oracle.com> There is more code in the newer version but not 4 times as much ! Harfbuzz now requires c++11 features (-std=c++11) Possibly the C++ compiler you are using (you don't mention platform) is slower in this mode. -phil. On 11/17/20, 9:01 AM, Florian Weimer wrote: > * Phil Race: > >> This upgrades JDK to import the current 2.7.2 version of harfbuzz - >> an OpenType text shaping library >> >> https://bugs.openjdk.java.net/browse/JDK-8247872 >> >> This has passed building and headless and headful automated tests on >> all platforms. > Is it just me, or does the new Harfbuzz build *significantly* slower? > > It adds about 20 seconds to the build, compared to using the system > Harfbuzz, whereas before it was around 5 seconds. From fw at deneb.enyo.de Tue Nov 17 18:00:02 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 17 Nov 2020 19:00:02 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <5FB40EDF.4090300@oracle.com> (Philip Race's message of "Tue, 17 Nov 2020 09:56:47 -0800") References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com> Message-ID: <87y2iz50f1.fsf@mid.deneb.enyo.de> * Philip Race: > There is more code in the newer version but not 4 times as much ! > Harfbuzz now requires c++11 features (-std=c++11) > Possibly the C++ compiler you are using (you don't mention platform) is > slower in this mode. It's GCC 8 on Debian buster, which defaults to C++14. And it's possible to write slow-to-compile C++ in all language modes. Is the Harfbuzz build parallelized? From philip.race at oracle.com Tue Nov 17 18:08:08 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 17 Nov 2020 10:08:08 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <87y2iz50f1.fsf@mid.deneb.enyo.de> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com> <87y2iz50f1.fsf@mid.deneb.enyo.de> Message-ID: <5FB41188.30704@oracle.com> So maybe the actual *usage* of C++11 features slows it down. I found this :- https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98 I really did not even think to measure the build time and I don't think there's any JDK build parallelism in building a specific native library. The build is parallel at a higher level but not at that lower level. -phil On 11/17/20, 10:00 AM, Florian Weimer wrote: > * Philip Race: > >> There is more code in the newer version but not 4 times as much ! >> Harfbuzz now requires c++11 features (-std=c++11) >> Possibly the C++ compiler you are using (you don't mention platform) is >> slower in this mode. > It's GCC 8 on Debian buster, which defaults to C++14. And it's > possible to write slow-to-compile C++ in all language modes. > > Is the Harfbuzz build parallelized? From magnus.ihse.bursie at oracle.com Tue Nov 17 21:40:33 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 17 Nov 2020 22:40:33 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <5FB41188.30704@oracle.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com> <87y2iz50f1.fsf@mid.deneb.enyo.de> <5FB41188.30704@oracle.com> Message-ID: <608e514f-8299-46bd-6821-be17ff7aedf5@oracle.com> On 2020-11-17 19:08, Philip Race wrote: > So maybe the actual *usage* of C++11 features slows it down. > > I found this :- > https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98 > > > I really did not even think to measure the build time and I don't > think there's any JDK build parallelism in building a specific native > library. > The build is parallel at a higher level but not at that lower level. There is build parallelism on multiple levels. When building an individual library, make is free to parallelize the compile task; only the link task is done singlethreaded. When determining which libraries to build, make is free to chose those available depending on tasks already finished. For instance, to build java.desktop-libs, we need to have finished java.desktop-java (since javac generates the header files needed by JNI integration). But after that, it can be compiled whenever make think it's suitable. This freedom for make to reorganize the order also means that it is hard to determine the additional cost for building a specific part. You could try to build java.desktop-java, and then run "make LOG=info java.desktop-libs" JOBS=1 to get a somewhat proper assessment of the time spent building all native libs for java.desktop. If this changes with the HarfBuzz upgrade, the HB upgrade is likely to blame. /Magnus > > -phil > > On 11/17/20, 10:00 AM, Florian Weimer wrote: >> * Philip Race: >> >>> There is more code in the newer version but not 4 times as much ! >>> Harfbuzz now requires c++11 features (-std=c++11) >>> Possibly the C++ compiler you are using (you don't mention platform) is >>> slower in this mode. >> It's GCC 8 on Debian buster, which defaults to C++14.? And it's >> possible to write slow-to-compile C++ in all language modes. >> >> Is the Harfbuzz build parallelized? From jjg at openjdk.java.net Tue Nov 17 23:03:08 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 17 Nov 2020 23:03:08 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v6] In-Reply-To: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> References: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> Message-ID: <2dyPy7yPtxW7Xo0R1yFx958RE2viLNNd5eWMS-SICMk=.cb7adb60-9e0c-43d0-a945-88d3ede6953c@github.com> On Mon, 16 Nov 2020 12:44:08 GMT, Magnus Ihse Bursie wrote: >> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. >> >> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. >> >> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. >> >> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. >> >> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace issues There seems to be much more here than there needs to be. If the issue is just long command lines, then the obvious/conventional solution would be to use @files, which would be a tiny change to the sjavac source code, to insert a single call to `CommandLine.parse` to expand any @file arguments on the command line. So, before reading all the various details in this proposed change, is there any reason why the simple @file solution cannot be used? ------------- PR: https://git.openjdk.java.net/jdk/pull/1195 From ihse at openjdk.java.net Wed Nov 18 00:07:11 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 18 Nov 2020 00:07:11 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v6] In-Reply-To: <2dyPy7yPtxW7Xo0R1yFx958RE2viLNNd5eWMS-SICMk=.cb7adb60-9e0c-43d0-a945-88d3ede6953c@github.com> References: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> <2dyPy7yPtxW7Xo0R1yFx958RE2viLNNd5eWMS-SICMk=.cb7adb60-9e0c-43d0-a945-88d3ede6953c@github.com> Message-ID: On Tue, 17 Nov 2020 23:00:26 GMT, Jonathan Gibbons wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace issues > > There seems to be much more here than there needs to be. > > If the issue is just long command lines, then the obvious/conventional solution would be to use @files, which would be a tiny change to the sjavac source code, to insert a single call to `CommandLine.parse` to expand any @file arguments on the command line. > > So, before reading all the various details in this proposed change, is there any reason why the simple @file solution cannot be used? The main issue is not the long command lines. Getting shorter command lines is nice, but more a side-effect. The real driver here is the awkward encoding of the command line, with spaces replaced by %20. This makes it impossible to parse the --server option to Java and properly replace unix paths with Windows paths, in the way that is needed by the upcoming changes to how we build on Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/1195 From david.holmes at oracle.com Wed Nov 18 05:31:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Nov 2020 15:31:11 +1000 Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com> Hi Vincente, On 16/11/2020 11:36 pm, Vicente Romero wrote: > Please review the code for the second iteration of sealed classes. In this iteration we are: > > - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies. > - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface The major change here seems to be that getPermittedSubclasses() now returns actual Class objects instead of ClassDesc. My recollection from earlier discussions here was that the use of ClassDesc was very deliberate as the permitted subclasses may not actually exist and there may be security concerns with returning them! Cheers, David ----- > ------------- > > Commit messages: > - 8246778: Compiler implementation for Sealed Classes (Second Preview) > > Changes: https://git.openjdk.java.net/jdk/pull/1227/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8246778 > Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod > Patch: https://git.openjdk.java.net/jdk/pull/1227.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1227/head:pull/1227 > > PR: https://git.openjdk.java.net/jdk/pull/1227 > From bsrbnd at gmail.com Wed Nov 18 15:21:44 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 18 Nov 2020 16:21:44 +0100 Subject: Records, Intersection type and lambda In-Reply-To: <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr> References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr> <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr> Message-ID: On Tue, 17 Nov 2020 at 08:46, wrote: > > yes, thanks ! > still not fixed :( Probably not a frequent issue with usual classes but I believe this might be a rather common use case with records, so I verified that my initial fix is still working fine with your latest example. However, Vicente seems to be investigating something else in the same area but I'd suggest to eventually file a separate issue for that in order to go ahead with my proposal, what do you think? Thanks, Bernard From jjg at openjdk.java.net Wed Nov 18 20:09:15 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 18 Nov 2020 20:09:15 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v3] In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> Message-ID: > This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box. > > As an inline tag, the format is `{@spec url label}`, which is roughly translated to `label` in the generated docs. > > As a block tag, the format is simply > > @spec url label > > which is handled in a manner analogous to > > @see label > > The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here. > > This change is only the _support_ for the new tag; it does _not_ include any changes to API docs to _use_ the new tag. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge master - Fix merge issues; review feedback - Merge with master - allow rich content in createAnchorAndSearchIndex - update Docs.gmk to stop disabling spec tag - fix TestSpecTag.testEncodedURI - fix tests - remove support to workaround legacy @spec tag - Merge remote-tracking branch 'upstream/master' into new-spec-tag - fix trailing whitespace in test - ... and 2 more: https://git.openjdk.java.net/jdk/compare/300cbaa6...69595e04 ------------- Changes: https://git.openjdk.java.net/jdk/pull/790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=790&range=02 Stats: 1374 lines in 42 files changed: 1337 ins; 14 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/790/head:pull/790 PR: https://git.openjdk.java.net/jdk/pull/790 From jlahoda at openjdk.java.net Thu Nov 19 18:30:21 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 19 Nov 2020 18:30:21 GMT Subject: RFR: 7194212: NPE in Flow.visitIdent Message-ID: A somewhat corner-case issue, but consider a case where classfiles for: public class Outer { public class Inner { } } Are on a classpath while compiling: public class Outer$Inner extends Outer { } This leads to a crash in javac (in Flow), because when Outer is completed, its InnerClasses attribute is read, and, based on it, the flags_field of Outer$Inner is (re)set (and it is put as an nested class to Outer, although that is not correct). But the flags_field used to contain UNATTRIBUTED flag. As this flag is cleared, the method bodies for Outer$Inner are never attributed (its default constructor in this case), which ultimately leads to the crash in Flow. The proposed patch is to ensure the InnerClasses entry is ignored if we are compiling a same-named class from source. The cost is yet another Flag bit. ------------- Commit messages: - Fixing FlagsTest. - 7194212: NPE in Flow.visitIdent Changes: https://git.openjdk.java.net/jdk/pull/1326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-7194212 Stats: 116 lines in 6 files changed: 110 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1326/head:pull/1326 PR: https://git.openjdk.java.net/jdk/pull/1326 From jjg at openjdk.java.net Fri Nov 20 17:56:15 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 20 Nov 2020 17:56:15 GMT Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. Message-ID: This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description. The goal is to be able to simplify the following common pattern: /** * Returns the result. Optional additional text. * @return the result */ int method() { by /** * {@return the result} Optional additional text. */ int method() { Note: * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere. * The expansion of the inline tag is `Returns " _content_ `.` where _content_ is the content of the tag. * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description * The inline tag can be inherited into overriding methods as if it was provided as a block tag. ------------- Commit messages: - Fix trailing whitespace in test - Merge master - JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. Changes: https://git.openjdk.java.net/jdk/pull/1355/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8075778 Stats: 526 lines in 15 files changed: 441 ins; 20 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/1355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355 PR: https://git.openjdk.java.net/jdk/pull/1355 From jjg at openjdk.java.net Fri Nov 20 18:51:17 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 20 Nov 2020 18:51:17 GMT Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. [v2] In-Reply-To: References: Message-ID: > This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description. > > The goal is to be able to simplify the following common pattern: > > /** > * Returns the result. Optional additional text. > * @return the result > */ > int method() { > > by > > /** > * {@return the result} Optional additional text. > */ > int method() { > > Note: > > * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere. > * The expansion of the inline tag is `Returns " _content_ `.` where _content_ is the content of the tag. > * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description > * The inline tag can be inherited into overriding methods as if it was provided as a block tag. Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision: - Add default impl for new method - Fix test failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1355/files - new: https://git.openjdk.java.net/jdk/pull/1355/files/483ede11..89846ff1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=00-01 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355 PR: https://git.openjdk.java.net/jdk/pull/1355 From vromero at openjdk.java.net Fri Nov 20 19:03:25 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 20 Nov 2020 19:03:25 GMT Subject: RFR: 8254105: allow static nested declarations [v7] In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. > > TIA, > Vicente > > PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8254105 - addressing review comments - manual merge with master branch - removing duplicated test - test cleanup - Merge branch 'master' into JDK-8254105 - 8254105: allow static members in inner classes, add binary compatibility tests ------------- Changes: https://git.openjdk.java.net/jdk/pull/571/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=06 Stats: 758 lines in 26 files changed: 313 ins; 191 del; 254 mod Patch: https://git.openjdk.java.net/jdk/pull/571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571 PR: https://git.openjdk.java.net/jdk/pull/571 From ebaron at openjdk.java.net Fri Nov 20 22:27:15 2020 From: ebaron at openjdk.java.net (Elliott Baron) Date: Fri, 20 Nov 2020 22:27:15 GMT Subject: RFR: 8256809: Annotation processing causes NPE during flow analysis Message-ID: If an error is found in JavacProcessingEnvironment.newRound, the erroneous ClassSymbols are meant to have their types replaced with new ClassTypes. There is a bug here where the check for whether a ClassSymbol is erroneous happens after the ClassSymbol is reset, replacing its kind with `TYP`. This means the check always fails, and the `kind == ERR` branch is never taken. This can lead to a NullPointerException later on during flow analysis, which I've captured with the included test. ------------- Commit messages: - Remove debug output from test - 8256809: Annotation processing causes NPE during flow analysis Changes: https://git.openjdk.java.net/jdk/pull/1359/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1359&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256809 Stats: 160 lines in 2 files changed: 159 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1359.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1359/head:pull/1359 PR: https://git.openjdk.java.net/jdk/pull/1359 From jjg at openjdk.java.net Sat Nov 21 00:34:22 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 21 Nov 2020 00:34:22 GMT Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. [v3] In-Reply-To: References: Message-ID: <_9Wkj9PHga5Y5GTI2RpJqyCtdYJs3PXI2R8falBJYlA=.26b53df7-c507-4242-8973-f7af82a25213@github.com> > This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description. > > The goal is to be able to simplify the following common pattern: > > /** > * Returns the result. Optional additional text. > * @return the result > */ > int method() { > > by > > /** > * {@return the result} Optional additional text. > */ > int method() { > > Note: > > * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere. > * The expansion of the inline tag is `Returns " _content_ `.` where _content_ is the content of the tag. > * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description > * The inline tag can be inherited into overriding methods as if it was provided as a block tag. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update DocCommentParser to permit nested inline tags in specified cases: @return ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1355/files - new: https://git.openjdk.java.net/jdk/pull/1355/files/89846ff1..87edfb0c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=01-02 Stats: 88 lines in 3 files changed: 82 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355 PR: https://git.openjdk.java.net/jdk/pull/1355 From ebaron at openjdk.java.net Sat Nov 21 02:06:20 2020 From: ebaron at openjdk.java.net (Elliott Baron) Date: Sat, 21 Nov 2020 02:06:20 GMT Subject: RFR: 8256809: Annotation processing causes NPE during flow analysis [v2] In-Reply-To: References: Message-ID: > If an error is found in JavacProcessingEnvironment.newRound, the erroneous ClassSymbols are meant to have their types replaced with new ClassTypes. There is a bug here where the check for whether a ClassSymbol is erroneous happens after the ClassSymbol is reset, replacing its kind with `TYP`. This means the check always fails, and the `kind == ERR` branch is never taken. > > This can lead to a NullPointerException later on during flow analysis, which I've captured with the included test. Elliott Baron has updated the pull request incrementally with one additional commit since the last revision: Fix processor-path in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1359/files - new: https://git.openjdk.java.net/jdk/pull/1359/files/69372295..2ca76c32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1359&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1359&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1359.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1359/head:pull/1359 PR: https://git.openjdk.java.net/jdk/pull/1359 From vromero at openjdk.java.net Sat Nov 21 03:22:11 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sat, 21 Nov 2020 03:22:11 GMT Subject: Integrated: 8254105: allow static nested declarations In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Fri, 9 Oct 2020 00:01:12 GMT, Vicente Romero wrote: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. > > TIA, > Vicente > > PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. This pull request has now been integrated. Changeset: 9a19eb69 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/9a19eb69 Stats: 758 lines in 26 files changed: 313 ins; 191 del; 254 mod 8254105: allow static nested declarations Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From kbarrett at openjdk.java.net Sat Nov 21 16:06:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 21 Nov 2020 16:06:10 GMT Subject: RFR: 8256824: test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java has a bad copyright Message-ID: Add missing comma in copyright text for test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java ------------- Commit messages: - fix copyright Changes: https://git.openjdk.java.net/jdk/pull/1366/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1366&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256824 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1366.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1366/head:pull/1366 PR: https://git.openjdk.java.net/jdk/pull/1366 From dcubed at openjdk.java.net Sat Nov 21 16:06:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 21 Nov 2020 16:06:10 GMT Subject: RFR: 8256824: test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java has a bad copyright In-Reply-To: References: Message-ID: <-1h-ua5JLs0hvhPKDAXbuYddI7kKnwEavaOVsoL9Faw=.ea5b272c-e64c-49c4-9b66-6e4e6272fb32@github.com> On Sat, 21 Nov 2020 15:57:07 GMT, Kim Barrett wrote: > Add missing comma in copyright text for test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1366 From kbarrett at openjdk.java.net Sat Nov 21 16:12:59 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 21 Nov 2020 16:12:59 GMT Subject: Integrated: 8256824: test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java has a bad copyright In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 15:57:07 GMT, Kim Barrett wrote: > Add missing comma in copyright text for test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java This pull request has now been integrated. Changeset: edf72f06 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/edf72f06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256824: test/langtools/tools/javac/diags/examples/InnerClassCantHaveStatic.java has a bad copyright Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1366 From jlahoda at openjdk.java.net Mon Nov 23 08:23:59 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 23 Nov 2020 08:23:59 GMT Subject: RFR: 8256809: Annotation processing causes NPE during flow analysis [v2] In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 02:06:20 GMT, Elliott Baron wrote: >> If an error is found in JavacProcessingEnvironment.newRound, the erroneous ClassSymbols are meant to have their types replaced with new ClassTypes. There is a bug here where the check for whether a ClassSymbol is erroneous happens after the ClassSymbol is reset, replacing its kind with `TYP`. This means the check always fails, and the `kind == ERR` branch is never taken. >> >> This can lead to a NullPointerException later on during flow analysis, which I've captured with the included test. > > Elliott Baron has updated the pull request incrementally with one additional commit since the last revision: > > Fix processor-path in test Looks good! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1359 From magnus.ihse.bursie at oracle.com Mon Nov 23 12:57:56 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 23 Nov 2020 13:57:56 +0100 Subject: RFR: 8256308: Send arguments to javac server in a config file In-Reply-To: References: Message-ID: I hope I could adequately answer why @files is not a solution to the problem I need to solve. Since this is a blocker for the winenv rewrite, I'd very much like to have this integrated. And I'd very much like to have a review from anyone in the lang tools team, and not just Erik's. Anyone, please? /Magnus On 2020-11-16 13:43, Magnus Ihse Bursie wrote: > I would appreciate if someone from langtools could have a look at this > as well. Thanks! > > /Magnus > > On 2020-11-12 23:23, Magnus Ihse Bursie wrote: >> Currently, to use the javac server, a horrendously long command line >> option is created, looking like this: `--server:portfile=> portfile>:sjavac=`, where the sjavac >> command has had all spaces replaced by %20. Since Project Jigsaw, the >> set of module arguments needed is huge to begin with, making this >> command line incomprehensible after mangling. >> >> Apart from making java command lines hard to read (and copy/paste!) >> by developers, it also makes it hard for scripts to parse. The >> upcoming winenv rewrite is dependent on being able to differentiate >> between path names and other arguments, which is not possible in this >> mess. >> >> So, instead, let's write it to a file, without any escaping, and just >> pass the configuration file name to the server. >> >> Note that this will change the behavior of the javac server, but as >> the source code states this is not a documented or externally >> supported API no CSR is needed. >> >> I also cleaned up some code in SjavacClient, in particular code >> relating to the passing of arguments. (We never change poolsize or >> keepalive when we call it.) >> >> ------------- >> >> Commit messages: >> ? - 8256308: Send arguments to javac server in a config file >> >> Changes: https://git.openjdk.java.net/jdk/pull/1195/files >> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1195&range=00 >> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8256308 >> ?? Stats: 118 lines in 3 files changed: 48 ins; 33 del; 37 mod >> ?? Patch: https://git.openjdk.java.net/jdk/pull/1195.diff >> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >> pull/1195/head:pull/1195 >> >> PR: https://git.openjdk.java.net/jdk/pull/1195 > From github.com+13688759+lgxbslgx at openjdk.java.net Mon Nov 23 15:28:20 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Mon, 23 Nov 2020 15:28:20 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor Message-ID: Hi all, When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. This patch solves this bug, regardless of the construction order, compiler can always output expected message. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8255968: Confusing error message for inaccessible constructor Changes: https://git.openjdk.java.net/jdk/pull/1389/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1389&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255968 Stats: 202 lines in 12 files changed: 201 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1389.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1389/head:pull/1389 PR: https://git.openjdk.java.net/jdk/pull/1389 From mcimadamore at openjdk.java.net Mon Nov 23 15:45:57 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 23 Nov 2020 15:45:57 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 15:22:26 GMT, Guoxiong Li wrote: > Hi all, > > When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. > This patch solves this bug, regardless of the construction order, compiler can always output expected message. > Thank you for taking the time to review. > > Best Regards. While I somewhat sympathize with the problem you are trying to solve, note that, by doing this, the output of the compiler will regress in case where not _all_ the overload candidates are not accessible. E.g. m(1): //client m(); private m(int); In this case I guess it's less clear as what "should" happen: does the user want to call the first, or second version of `m` ? Both cases are possible - e.g. the user might accidentally call the private version of some method (in which the compiler is right in pointing out that the callsite is wrong), or the user indeed might want to access the private method (in which case your patch to shift the focus onto the access error might seem more appropriate). I'm a bit skeptical that there exist a silver bullet for these kind of mixed cases. Technically speaking, from a JLS perspective, non-accessible methods should not even take place in overload resolution - so the current compiler behavior is cases where both accessible and inaccessible methods are present seems more appropriate. In other words, if we really want to improve the status quo, we should detect cases where _all_ candidates are not accessible. Or, we should question whether javac's behavior of tagging inaccessible methods with the kind `WRONG_MTH`/`WRONG_MTHS` is correct in the first place. It would be nice, I guess, if we could make the inaccessible error more powerful, so that we could keep adding inaccessble symbols as we go along, so that javac could display something like "cannot resolve symbol `m` - but some inaccessible symbols have been found ". ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From ebaron at openjdk.java.net Mon Nov 23 16:06:00 2020 From: ebaron at openjdk.java.net (Elliott Baron) Date: Mon, 23 Nov 2020 16:06:00 GMT Subject: Integrated: 8256809: Annotation processing causes NPE during flow analysis In-Reply-To: References: Message-ID: <2GQZsNUAQY2F1qTd0xGWptSEwh77paq4x-GDL-k3-6A=.927c2c68-205d-45e2-bc7e-884e2f38904c@github.com> On Fri, 20 Nov 2020 22:22:17 GMT, Elliott Baron wrote: > If an error is found in JavacProcessingEnvironment.newRound, the erroneous ClassSymbols are meant to have their types replaced with new ClassTypes. There is a bug here where the check for whether a ClassSymbol is erroneous happens after the ClassSymbol is reset, replacing its kind with `TYP`. This means the check always fails, and the `kind == ERR` branch is never taken. > > This can lead to a NullPointerException later on during flow analysis, which I've captured with the included test. This pull request has now been integrated. Changeset: 8ddf5e17 Author: Elliott Baron Committer: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/8ddf5e17 Stats: 160 lines in 2 files changed: 159 ins; 0 del; 1 mod 8256809: Annotation processing causes NPE during flow analysis Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/1359 From david.holmes at oracle.com Tue Nov 24 01:04:55 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Nov 2020 11:04:55 +1000 Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com> Message-ID: <96418b57-12fe-208e-c642-b04efeedca24@oracle.com> Hi Harold, On 24/11/2020 6:27 am, Harold Seigel wrote: > Hi David, > > Thanks for looking at this. > > The intent was for method Class.permittedSubclasses() to be implemented > similarly to Class.getNestMembers().? Are you suggesting that a security > manager check be added to permittedSubclasses() similar to the security > manager check in getNestMembers()? No I'm suggesting the change to the API is plain wrong. :) Please see discussion in the CSR. Cheers, David > Thanks, Harold > > On 11/18/2020 12:31 AM, David Holmes wrote: >> Hi Vincente, >> >> On 16/11/2020 11:36 pm, Vicente Romero wrote: >>> Please review the code for the second iteration of sealed classes. In >>> this iteration we are: >>> >>> - Enhancing narrowing reference conversion to allow for stricter >>> checking of cast conversions with respect to sealed type hierarchies. >>> - Also local classes are not considered when determining implicitly >>> declared permitted direct subclasses of a sealed class or sealed >>> interface >> >> The major change here seems to be that getPermittedSubclasses() now >> returns actual Class objects instead of ClassDesc. My recollection >> from earlier discussions here was that the use of ClassDesc was very >> deliberate as the permitted subclasses may not actually exist and >> there may be security concerns with returning them! >> >> Cheers, >> David >> ----- >> >>> ------------- >>> >>> Commit messages: >>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview) >>> >>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files >>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00 >>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778 >>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod >>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff >>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>> pull/1227/head:pull/1227 >>> >>> PR: https://git.openjdk.java.net/jdk/pull/1227 >>> From forax at univ-mlv.fr Tue Nov 24 09:45:14 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 24 Nov 2020 10:45:14 +0100 (CET) Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: <96418b57-12fe-208e-c642-b04efeedca24@oracle.com> References: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com> <96418b57-12fe-208e-c642-b04efeedca24@oracle.com> Message-ID: <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David Holmes" > ?: "Harold David Seigel" , "Vicente Romero" , "compiler-dev" > , "core-libs-dev" , "hotspot-dev" > > Envoy?: Mardi 24 Novembre 2020 02:04:55 > Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) > Hi Harold, > > On 24/11/2020 6:27 am, Harold Seigel wrote: >> Hi David, >> >> Thanks for looking at this. >> >> The intent was for method Class.permittedSubclasses() to be implemented >> similarly to Class.getNestMembers().? Are you suggesting that a security >> manager check be added to permittedSubclasses() similar to the security >> manager check in getNestMembers()? > > No I'm suggesting the change to the API is plain wrong. :) Please see > discussion in the CSR. Given that the CSR is closed, i will answer here. There are two issues with the previous implementation of permittedSubclasses, first it's the only method that using method desc which means that people has to be aware on another non trivial concept (object that describes constant pool constant) to understand how to use the method then i've tested this API with my students, all but one what able to correctly derives the Class from a ClassDesc, so instead of asking every users of permittedSubclasses to go through the oops of getting Class from a ClassDesc, i think we can agree that it's better to move the burden from the user to the JDK implementors. > > Cheers, > David regards, R?mi > >> Thanks, Harold >> >> On 11/18/2020 12:31 AM, David Holmes wrote: >>> Hi Vincente, >>> >>> On 16/11/2020 11:36 pm, Vicente Romero wrote: >>>> Please review the code for the second iteration of sealed classes. In >>>> this iteration we are: >>>> >>>> - Enhancing narrowing reference conversion to allow for stricter >>>> checking of cast conversions with respect to sealed type hierarchies. >>>> - Also local classes are not considered when determining implicitly >>>> declared permitted direct subclasses of a sealed class or sealed >>>> interface >>> >>> The major change here seems to be that getPermittedSubclasses() now >>> returns actual Class objects instead of ClassDesc. My recollection >>> from earlier discussions here was that the use of ClassDesc was very >>> deliberate as the permitted subclasses may not actually exist and >>> there may be security concerns with returning them! >>> >>> Cheers, >>> David >>> ----- >>> >>>> ------------- >>>> >>>> Commit messages: >>>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview) >>>> >>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files >>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00 >>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778 >>>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod >>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff >>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>>> pull/1227/head:pull/1227 >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/1227 From jfranck at openjdk.java.net Tue Nov 24 09:57:58 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 24 Nov 2020 09:57:58 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v6] In-Reply-To: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> References: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> Message-ID: On Mon, 16 Nov 2020 12:44:08 GMT, Magnus Ihse Bursie wrote: >> Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. >> >> Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. >> >> So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. >> >> Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. >> >> I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace issues Marked as reviewed by jfranck (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java line 96: > 94: > 95: public static String extractStringOptionLine(String opName, String s, String deflt) { > 96: return extractStringOptionWithDelimiter(opName, s, deflt, '\n').strip(); Is '\n' going to be problematic due to differences in line endings on various platforms? ------------- PR: https://git.openjdk.java.net/jdk/pull/1195 From chegar at openjdk.java.net Tue Nov 24 10:06:09 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 24 Nov 2020 10:06:09 GMT Subject: RFR: 8256755: Update build.tools.depend.Depend to handle record components in API signatures Message-ID: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com> The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records. The components of a public record class, that is a member of an exported package, are logically part of the module's API. The name, type, and order are significant. This issue updates the build tool to include the aforementioned component characteristics. This issue is a blocker to adding any public record types to the JDK - since the build will fail. ------------- Commit messages: - Update the Depend(ency) build tool to handle the record attribute Changes: https://git.openjdk.java.net/jdk/pull/1405/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1405&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256755 Stats: 33 lines in 2 files changed: 31 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1405/head:pull/1405 PR: https://git.openjdk.java.net/jdk/pull/1405 From jlahoda at openjdk.java.net Tue Nov 24 10:13:56 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 24 Nov 2020 10:13:56 GMT Subject: RFR: 8256755: Update build.tools.depend.Depend to handle record components in API signatures In-Reply-To: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com> References: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com> Message-ID: <3Qt6HXmLkLPC3EEKz1NZa00iwS8z2c3bzHTbszLg3n0=.b8798de1-2b51-44b4-8e73-403de15ee98b@github.com> On Tue, 24 Nov 2020 09:59:44 GMT, Chris Hegarty wrote: > The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records. > > The components of a public record class, that is a member of an exported package, are logically part of the module's API. The name, type, and order are significant. This issue updates the build tool to include the aforementioned component characteristics. > > This issue is a blocker to adding any public record types to the JDK - since the build will fail. Looks great, thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1405 From ihse at openjdk.java.net Tue Nov 24 11:17:06 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 24 Nov 2020 11:17:06 GMT Subject: Integrated: 8256308: Send arguments to javac server in a config file In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 22:13:37 GMT, Magnus Ihse Bursie wrote: > Currently, to use the javac server, a horrendously long command line option is created, looking like this: `--server:portfile=:sjavac=`, where the sjavac command has had all spaces replaced by %20. Since Project Jigsaw, the set of module arguments needed is huge to begin with, making this command line incomprehensible after mangling. > > Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess. > > So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server. > > Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed. > > I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.) This pull request has now been integrated. Changeset: 9e4944f7 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/9e4944f7 Stats: 136 lines in 3 files changed: 59 ins; 40 del; 37 mod 8256308: Send arguments to javac server in a config file Reviewed-by: erikj, jfranck ------------- PR: https://git.openjdk.java.net/jdk/pull/1195 From ihse at openjdk.java.net Tue Nov 24 11:17:05 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 24 Nov 2020 11:17:05 GMT Subject: RFR: 8256308: Send arguments to javac server in a config file [v6] In-Reply-To: References: <7NBBom9s8IWvbkdHOFdk4-uaLeVqobEInNq4g2jL8U4=.c180727d-4fdf-444b-b748-a9854e4115ee@github.com> Message-ID: On Tue, 24 Nov 2020 09:52:34 GMT, Joel Borggr?n-Franck wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace issues > > src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java line 96: > >> 94: >> 95: public static String extractStringOptionLine(String opName, String s, String deflt) { >> 96: return extractStringOptionWithDelimiter(opName, s, deflt, '\n').strip(); > > Is '\n' going to be problematic due to differences in line endings on various platforms? The JDK project is limited to unix-style line endings only. No other styles are supported, and any attempt to use such will break the build (often early on). ------------- PR: https://git.openjdk.java.net/jdk/pull/1195 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Nov 24 11:46:57 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 24 Nov 2020 11:46:57 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 15:42:50 GMT, Maurizio Cimadamore wrote: >> Hi all, >> >> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. >> This patch solves this bug, regardless of the construction order, compiler can always output expected message. >> Thank you for taking the time to review. >> >> Best Regards. > > While I somewhat sympathize with the problem you are trying to solve, note that, by doing this, the output of the compiler will regress in case where not _all_ the overload candidates are not accessible. E.g. > > m(1): //client > > m(); > private m(int); > > In this case I guess it's less clear as what "should" happen: does the user want to call the first, or second version of `m` ? Both cases are possible - e.g. the user might accidentally call the private version of some method (in which the compiler is right in pointing out that the callsite is wrong), or the user indeed might want to access the private method (in which case your patch to shift the focus onto the access error might seem more appropriate). > > I'm a bit skeptical that there exist a silver bullet for these kind of mixed cases. Technically speaking, from a JLS perspective, non-accessible methods should not even take place in overload resolution - so the current compiler behavior is cases where both accessible and inaccessible methods are present seems more appropriate. > > In other words, if we really want to improve the status quo, we should detect cases where _all_ candidates are not accessible. Or, we should question whether javac's behavior of tagging inaccessible methods with the kind `WRONG_MTH`/`WRONG_MTHS` is correct in the first place. > > It would be nice, I guess, if we could make the inaccessible error more powerful, so that we could keep adding inaccessble symbols as we go along, so that javac could display something like "cannot resolve symbol `m` - but some inaccessible symbols have been found ". Currently, the compiler output the error message depending on the order of the methods. Please see the below test cases. - the `private Test(int x) {}` is at the end of other(one or more) method(s). class T8255968 { Test c = new Test(0); } class Test { private Test(String[] x) {} Test(String x) {} private Test(int x) {} // at the end } current output: error: Test(int) has private access in Test Test c = new Test(0); ^ 1 error - the `private Test(int x) {}` is not at the end of other(only one) method. class T8255968 { Test c = new Test(0); } class Test { private Test(int x) {} // not at the end Test(String x) {} // can be private, output same error message } current output: error: incompatible types: int cannot be converted to String Test c = new Test(0); ^ Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 1 error - the `private Test(int x) {}` is not at the end of other(more than one) methods. class T8255968 { Test c = new Test(0); } class Test { private Test(String x) {} private Test(int x) {} // not at the end Test(String[] x) {} } current output: error: no suitable constructor found for Test(int) Test c = new Test(0); ^ constructor Test.Test(String) is not applicable (argument mismatch; int cannot be converted to String) constructor Test.Test(String[]) is not applicable (argument mismatch; int cannot be converted to String[]) 1 error These output messages which depending on the order of the methods would confuse users. Because the order of the methods should not have any influence. @mcimadamore According to your comment, I want to unify the output messages as below. - the `private Test(int x) {}` is at the end of other(one or more) method(s). class T8255968 { Test c = new Test(0); } class Test { private Test(String[] x) {} Test(String x) {} private Test(int x) {} // at the end } expected output: error: no suitable constructor found for Test(int) Test c = new Test(0); ^ constructor Test.Test(String[]) is not applicable (argument mismatch; int cannot be converted to String[]) constructor Test.Test(int) is not applicable (Test(int) has private access in Test) constructor Test.Test(String) is not applicable (argument mismatch; int cannot be converted to String) 1 error - the `private Test(int x) {}` is not at the end of other(only one) method. class T8255968 { Test c = new Test(0); } class Test { private Test(int x) {} // not at the end Test(String x) {} // can be private, output same error message } expected output: error: no suitable constructor found for Test(int) Test c = new Test(0); ^ constructor Test.Test(int) is not applicable (Test(int) has private access in Test) constructor Test.Test(String) is not applicable (argument mismatch; int cannot be converted to String) 1 error - the `private Test(int x) {}` is not at the end of other(more than one) methods. class T8255968 { Test c = new Test(0); } class Test { private Test(String x) {} private Test(int x) {} // not at the end Test(String[] x) {} } expected output: error: no suitable constructor found for Test(int) Test c = new Test(0); ^ constructor Test.Test(String) is not applicable (argument mismatch; int cannot be converted to String) constructor Test.Test(int) is not applicable (Test(int) has private access in Test) constructor Test.Test(String[]) is not applicable (argument mismatch; int cannot be converted to String[]) 1 error And the following two situations are not modified. class T8255968 { Test c = new Test(0); } class Test { private Test(int x) {} } current and expected output: error: Test(int) has private access in Test Test c = new Test(0); ^ 1 error class T8255968 { Test c = new Test(0); } class Test { Test(String x) {} } current and expected output: error: incompatible types: int cannot be converted to String Test c = new Test(0); ^ Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 1 error I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From mcimadamore at openjdk.java.net Tue Nov 24 12:03:56 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 24 Nov 2020 12:03:56 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor In-Reply-To: References: Message-ID: <_H4ahKkEA4ya6WeJoA82pW2OM_dcLx3SxTz12B6iT50=.29fecbd1-c61c-4f1f-a190-2a5bd7db5a5e@github.com> On Tue, 24 Nov 2020 11:44:06 GMT, Guoxiong Li wrote: > > I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing. This seems a good direction - but there are few dragons in there. As I said in my previous message, inaccessible members are just not overload resolution candidates and are "skipped" over by the overload selection logic. This is visible in examples like these: class Sup { private void m(String s); } class Outer { void m() { ... } void m(Integer s) { ... } class Inner extends Sup { void test() { m(); } } } In this example, overload selection should look for `m` candidates inside the `Outer` class. If, with a patch, you make access errors more similar to `WRONG_MTH`, or `WRONG_MTHS` kinds (by unifying them) chances are that overload selection will start thinking that it found a candidate in `Sup` and stop there - which would be against the JLS. I'm not saying it cannot be done, but more that it has to be done in a careful way - that is, you can only unify the error messages in situation where you know there's a mix of inaccessible and inapplicable methods, so you know already that overload selection will stop at that class. Another aspect to look out for/test is method references - whatever we say here for plain method calls, has to hold for method reference selection - so you'll want to create specific tests which aims at showing that whatever change is applied, it also improves the situation with method references (or at least does not cause unwanted regressions there). ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From david.holmes at oracle.com Tue Nov 24 12:16:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Nov 2020 22:16:39 +1000 Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr> References: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com> <96418b57-12fe-208e-c642-b04efeedca24@oracle.com> <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, On 24/11/2020 7:45 pm, Remi Forax wrote: > ----- Mail original ----- >> De: "David Holmes" >> ?: "Harold David Seigel" , "Vicente Romero" , "compiler-dev" >> , "core-libs-dev" , "hotspot-dev" >> >> Envoy?: Mardi 24 Novembre 2020 02:04:55 >> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) > >> Hi Harold, >> >> On 24/11/2020 6:27 am, Harold Seigel wrote: >>> Hi David, >>> >>> Thanks for looking at this. >>> >>> The intent was for method Class.permittedSubclasses() to be implemented >>> similarly to Class.getNestMembers().? Are you suggesting that a security >>> manager check be added to permittedSubclasses() similar to the security >>> manager check in getNestMembers()? >> >> No I'm suggesting the change to the API is plain wrong. :) Please see >> discussion in the CSR. > > Given that the CSR is closed, i will answer here. > There are two issues with the previous implementation of permittedSubclasses, first it's the only method that using method desc which means that people has to be aware on another non trivial concept (object that describes constant pool constant) to understand how to use the method then i've tested this API with my students, all but one what able to correctly derives the Class from a ClassDesc, so instead of asking every users of permittedSubclasses to go through the oops of getting Class from a ClassDesc, i think we can agree that it's better to move the burden from the user to the JDK implementors. Why is the objective to get the Class objects? What purpose does that serve? The original API provided a descriptor for the contents of the permittedSubclasses attribute. I find it totally bizarre to have an API whose role is now to attempt to load all the subclasses of a sealed class. YMMV. David >> >> Cheers, >> David > > regards, > R?mi > >> >>> Thanks, Harold >>> >>> On 11/18/2020 12:31 AM, David Holmes wrote: >>>> Hi Vincente, >>>> >>>> On 16/11/2020 11:36 pm, Vicente Romero wrote: >>>>> Please review the code for the second iteration of sealed classes. In >>>>> this iteration we are: >>>>> >>>>> - Enhancing narrowing reference conversion to allow for stricter >>>>> checking of cast conversions with respect to sealed type hierarchies. >>>>> - Also local classes are not considered when determining implicitly >>>>> declared permitted direct subclasses of a sealed class or sealed >>>>> interface >>>> >>>> The major change here seems to be that getPermittedSubclasses() now >>>> returns actual Class objects instead of ClassDesc. My recollection >>>> from earlier discussions here was that the use of ClassDesc was very >>>> deliberate as the permitted subclasses may not actually exist and >>>> there may be security concerns with returning them! >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>>> ------------- >>>>> >>>>> Commit messages: >>>>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview) >>>>> >>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files >>>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00 >>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778 >>>>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod >>>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff >>>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>>>> pull/1227/head:pull/1227 >>>>> >>>>> PR: https://git.openjdk.java.net/jdk/pull/1227 From forax at univ-mlv.fr Tue Nov 24 13:56:22 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 24 Nov 2020 14:56:22 +0100 (CET) Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com> <96418b57-12fe-208e-c642-b04efeedca24@oracle.com> <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr> Message-ID: <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David Holmes" > ?: "Remi Forax" > Cc: "Harold David Seigel" , "Vicente Romero" , "compiler-dev" > , "core-libs-dev" , "hotspot-dev" > > Envoy?: Mardi 24 Novembre 2020 13:16:39 > Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) > Hi Remi, > > On 24/11/2020 7:45 pm, Remi Forax wrote: >> ----- Mail original ----- >>> De: "David Holmes" >>> ?: "Harold David Seigel" , "Vicente Romero" >>> , "compiler-dev" >>> , "core-libs-dev" >>> , "hotspot-dev" >>> >>> Envoy?: Mardi 24 Novembre 2020 02:04:55 >>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second >>> Preview) >> >>> Hi Harold, >>> >>> On 24/11/2020 6:27 am, Harold Seigel wrote: >>>> Hi David, >>>> >>>> Thanks for looking at this. >>>> >>>> The intent was for method Class.permittedSubclasses() to be implemented >>>> similarly to Class.getNestMembers().? Are you suggesting that a security >>>> manager check be added to permittedSubclasses() similar to the security >>>> manager check in getNestMembers()? >>> >>> No I'm suggesting the change to the API is plain wrong. :) Please see >>> discussion in the CSR. >> >> Given that the CSR is closed, i will answer here. >> There are two issues with the previous implementation of permittedSubclasses, >> first it's the only method that using method desc which means that people has >> to be aware on another non trivial concept (object that describes constant pool >> constant) to understand how to use the method then i've tested this API with my >> students, all but one what able to correctly derives the Class from a >> ClassDesc, so instead of asking every users of permittedSubclasses to go >> through the oops of getting Class from a ClassDesc, i think we can agree that >> it's better to move the burden from the user to the JDK implementors. > > Why is the objective to get the Class objects? What purpose does that > serve? The whole idea of the reflection is to provide the runtime view of Java the language. Even if such thing does not exist. > The original API provided a descriptor for the contents of the > permittedSubclasses attribute. I find it totally bizarre to have an API > whose role is now to attempt to load all the subclasses of a sealed class. It's as bizarre as Class.getClasses() loading all the member classes. You are discovering that the reflection API is bizarre, and it is :) It's not the view of the JVM, it's the view of Java at runtime, whatever it means. > > YMMV. > > David R?mi [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Class.html#getClasses() > >>> >>> Cheers, >>> David >> >> regards, >> R?mi >> >>> >>>> Thanks, Harold >>>> >>>> On 11/18/2020 12:31 AM, David Holmes wrote: >>>>> Hi Vincente, >>>>> >>>>> On 16/11/2020 11:36 pm, Vicente Romero wrote: >>>>>> Please review the code for the second iteration of sealed classes. In >>>>>> this iteration we are: >>>>>> >>>>>> - Enhancing narrowing reference conversion to allow for stricter >>>>>> checking of cast conversions with respect to sealed type hierarchies. >>>>>> - Also local classes are not considered when determining implicitly >>>>>> declared permitted direct subclasses of a sealed class or sealed >>>>>> interface >>>>> >>>>> The major change here seems to be that getPermittedSubclasses() now >>>>> returns actual Class objects instead of ClassDesc. My recollection >>>>> from earlier discussions here was that the use of ClassDesc was very >>>>> deliberate as the permitted subclasses may not actually exist and >>>>> there may be security concerns with returning them! >>>>> >>>>> Cheers, >>>>> David >>>>> ----- >>>>> >>>>>> ------------- >>>>>> >>>>>> Commit messages: >>>>>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview) >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files >>>>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00 >>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778 >>>>>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod >>>>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff >>>>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>>>>> pull/1227/head:pull/1227 >>>>>> > >>>>> PR: https://git.openjdk.java.net/jdk/pull/1227 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Nov 24 15:32:31 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 24 Nov 2020 15:32:31 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v2] In-Reply-To: References: Message-ID: <0F2zSzccgh53MnY3qH8jVfFQR6U3B5Q7RNWqmLOWPGY=.d507497f-c6bc-459c-953a-5e911ebfad47@github.com> > Hi all, > > When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. > This patch solves this bug, regardless of the construction order, compiler can always output expected message. > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Unify error messages for inaccessible constructor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1389/files - new: https://git.openjdk.java.net/jdk/pull/1389/files/020311a1..a9a68149 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1389&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1389&range=00-01 Stats: 87 lines in 16 files changed: 75 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1389.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1389/head:pull/1389 PR: https://git.openjdk.java.net/jdk/pull/1389 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Nov 24 15:37:58 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 24 Nov 2020 15:37:58 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v2] In-Reply-To: <_H4ahKkEA4ya6WeJoA82pW2OM_dcLx3SxTz12B6iT50=.29fecbd1-c61c-4f1f-a190-2a5bd7db5a5e@github.com> References: <_H4ahKkEA4ya6WeJoA82pW2OM_dcLx3SxTz12B6iT50=.29fecbd1-c61c-4f1f-a190-2a5bd7db5a5e@github.com> Message-ID: On Tue, 24 Nov 2020 12:00:50 GMT, Maurizio Cimadamore wrote: >> Currently, the compiler output the error message depending on the order of the methods. Please see the below test cases. >> >> - the `private Test(int x) {}` is at the end of other(one or more) method(s). >> class T8255968 { >> Test c = new Test(0); >> } >> class Test { >> private Test(String[] x) {} >> Test(String x) {} >> private Test(int x) {} // at the end >> } >> >> current output: >> error: Test(int) has private access in Test >> Test c = new Test(0); >> ^ >> 1 error >> - the `private Test(int x) {}` is not at the end of other(only one) method. >> class T8255968 { >> Test c = new Test(0); >> } >> class Test { >> private Test(int x) {} // not at the end >> Test(String x) {} // can be private, output same error message >> } >> >> current output: >> error: incompatible types: int cannot be converted to String >> Test c = new Test(0); >> ^ >> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output >> 1 error >> >> - the `private Test(int x) {}` is not at the end of other(more than one) methods. >> class T8255968 { >> Test c = new Test(0); >> } >> class Test { >> private Test(String x) {} >> private Test(int x) {} // not at the end >> Test(String[] x) {} >> } >> >> current output: >> error: no suitable constructor found for Test(int) >> Test c = new Test(0); >> ^ >> constructor Test.Test(String) is not applicable >> (argument mismatch; int cannot be converted to String) >> constructor Test.Test(String[]) is not applicable >> (argument mismatch; int cannot be converted to String[]) >> 1 error >> These output messages which depending on the order of the methods would confuse users. Because the order of the methods should not have any influence. >> >> @mcimadamore According to your comment, I want to unify the output messages as below. >> >> - the `private Test(int x) {}` is at the end of other(one or more) method(s). >> class T8255968 { >> Test c = new Test(0); >> } >> class Test { >> private Test(String[] x) {} >> Test(String x) {} >> private Test(int x) {} // at the end >> } >> >> expected output: >> error: no suitable constructor found for Test(int) >> Test c = new Test(0); >> ^ >> constructor Test.Test(String[]) is not applicable >> (argument mismatch; int cannot be converted to String[]) >> constructor Test.Test(int) is not applicable >> (Test(int) has private access in Test) >> constructor Test.Test(String) is not applicable >> (argument mismatch; int cannot be converted to String) >> 1 error >> - the `private Test(int x) {}` is not at the end of other(only one) method. >> class T8255968 { >> Test c = new Test(0); >> } >> class Test { >> private Test(int x) {} // not at the end >> Test(String x) {} // can be private, output same error message >> } >> >> expected output: >> error: no suitable constructor found for Test(int) >> Test c = new Test(0); >> ^ >> constructor Test.Test(int) is not applicable >> (Test(int) has private access in Test) >> constructor Test.Test(String) is not applicable >> (argument mismatch; int cannot be converted to String) >> 1 error >> >> - the `private Test(int x) {}` is not at the end of other(more than one) methods. >> class T8255968 { >> Test c = new Test(0); >> } >> class Test { >> private Test(String x) {} >> private Test(int x) {} // not at the end >> Test(String[] x) {} >> } >> >> expected output: >> error: no suitable constructor found for Test(int) >> Test c = new Test(0); >> ^ >> constructor Test.Test(String) is not applicable >> (argument mismatch; int cannot be converted to String) >> constructor Test.Test(int) is not applicable >> (Test(int) has private access in Test) >> constructor Test.Test(String[]) is not applicable >> (argument mismatch; int cannot be converted to String[]) >> 1 error >> >> And the following two situations are not modified. >> class T8255968 { >> Test c = new Test(0); >> } >> class Test { >> private Test(int x) {} >> } >> >> current and expected output: >> error: Test(int) has private access in Test >> Test c = new Test(0); >> ^ >> 1 error >> class T8255968 { >> Test c = new Test(0); >> } >> class Test { >> Test(String x) {} >> } >> >> current and expected output: >> error: incompatible types: int cannot be converted to String >> Test c = new Test(0); >> ^ >> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output >> 1 error >> >> I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing. > >> >> I implement this unified format and test the feature locally. @mcimadamore If you agree with these unified output messages, I would update my code for reviewing. > > This seems a good direction - but there are few dragons in there. As I said in my previous message, inaccessible members are just not overload resolution candidates and are "skipped" over by the overload selection logic. This is visible in examples like these: > > class Sup { > private void m(String s); > } > > class Outer { > void m() { ... } > void m(Integer s) { ... } > > class Inner extends Sup { > void test() { > m(); > } > } > } > In this example, overload selection should look for `m` candidates inside the `Outer` class. If, with a patch, you make access errors more similar to `WRONG_MTH`, or `WRONG_MTHS` kinds (by unifying them) chances are that overload selection will start thinking that it found a candidate in `Sup` and stop there - which would be against the JLS. I'm not saying it cannot be done, but more that it has to be done in a careful way - that is, you can only unify the error messages in situation where you know there's a mix of inaccessible and inapplicable methods, so you know already that overload selection will stop at that class. > > Another aspect to look out for/test is method references - whatever we say here for plain method calls, has to hold for method reference selection - so you'll want to create specific tests which aims at showing that whatever change is applied, it also improves the situation with method references (or at least does not cause unwanted regressions there). I update the code which unifies the error messages. I use the following command to run test locally and all the test passed. make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release JOBS=8 output: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/langtools/tools/javac 3503 3503 0 0 ============================== TEST SUCCESS Finished building target 'test' in configuration 'linux-x86_64-server-release' Thank you for taking the time to review. Best Regards. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From mcimadamore at openjdk.java.net Tue Nov 24 18:45:00 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 24 Nov 2020 18:45:00 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v2] In-Reply-To: <0F2zSzccgh53MnY3qH8jVfFQR6U3B5Q7RNWqmLOWPGY=.d507497f-c6bc-459c-953a-5e911ebfad47@github.com> References: <0F2zSzccgh53MnY3qH8jVfFQR6U3B5Q7RNWqmLOWPGY=.d507497f-c6bc-459c-953a-5e911ebfad47@github.com> Message-ID: On Tue, 24 Nov 2020 15:32:31 GMT, Guoxiong Li wrote: >> Hi all, >> >> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. >> This patch solves this bug, regardless of the construction order, compiler can always output expected message. >> Thank you for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Unify error messages for inaccessible constructor Looks a nice generalization. However I still have some concerns: * the logic, as I feared, is turning `ABSENT` into `WRONG_MTHS` - note that AccessError and InapplicableSymbol/s have different properties when it comes to method lookup - more specifically look at ResolveError::exists which return `false` in one case and `true` in the other. This is used, among other things, to shortcircuit method lookups (see `Resolve::findFun`) - so flipping from `AccessError` to `InapplicableSymbols` is almost guaranteed to cause a change in behavior in the compiler. That said, given the nature of the code involved, is not super trivial to come up with an example which demonstrates the difference - but I'll keep thinking. * While the tests you add are good, I don't see the corresponding tests for the method reference case. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1590: > 1588: return new InapplicableSymbolError(currentResolutionContext); > 1589: case HIDDEN: > 1590: if (bestSoFar instanceof AccessError) { These changes are a bit convoluted - but that's the nature of the code in here. I also see that you special case AccessError (since now we have, from modules, different kind of HIDDEN error class, which is probably worth another cleanup). If an access error shows up and we already have an access error, you add that to the list of "candidates", and return a WRONG_MTHS kind. Sounds logical. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1609: > 1607: AccessError curAccessError = new AccessError(env, site, sym); > 1608: JCDiagnostic curDiagnostic = curAccessError.getDiagnostic(JCDiagnostic.DiagnosticType.FRAGMENT, null, null, site, null, argtypes, typeargtypes); > 1609: if (bestSoFar.kind == ABSENT_MTH) { This seems like a good generalization of existing code. Give a new access error, we have following cases: * best was `ABSENT` - in which case we return the access error * best was `WRONG_MTH/WRONG_MTHS/HIDDEN` in which case we return `WRONG_MTHS` with access error added to the list ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From david.holmes at oracle.com Tue Nov 24 22:49:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Nov 2020 08:49:25 +1000 Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr> References: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com> <96418b57-12fe-208e-c642-b04efeedca24@oracle.com> <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr> <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr> Message-ID: On 24/11/2020 11:56 pm, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "David Holmes" >> ?: "Remi Forax" >> Cc: "Harold David Seigel" , "Vicente Romero" , "compiler-dev" >> , "core-libs-dev" , "hotspot-dev" >> >> Envoy?: Mardi 24 Novembre 2020 13:16:39 >> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) > >> Hi Remi, >> >> On 24/11/2020 7:45 pm, Remi Forax wrote: >>> ----- Mail original ----- >>>> De: "David Holmes" >>>> ?: "Harold David Seigel" , "Vicente Romero" >>>> , "compiler-dev" >>>> , "core-libs-dev" >>>> , "hotspot-dev" >>>> >>>> Envoy?: Mardi 24 Novembre 2020 02:04:55 >>>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second >>>> Preview) >>> >>>> Hi Harold, >>>> >>>> On 24/11/2020 6:27 am, Harold Seigel wrote: >>>>> Hi David, >>>>> >>>>> Thanks for looking at this. >>>>> >>>>> The intent was for method Class.permittedSubclasses() to be implemented >>>>> similarly to Class.getNestMembers().? Are you suggesting that a security >>>>> manager check be added to permittedSubclasses() similar to the security >>>>> manager check in getNestMembers()? >>>> >>>> No I'm suggesting the change to the API is plain wrong. :) Please see >>>> discussion in the CSR. >>> >>> Given that the CSR is closed, i will answer here. >>> There are two issues with the previous implementation of permittedSubclasses, >>> first it's the only method that using method desc which means that people has >>> to be aware on another non trivial concept (object that describes constant pool >>> constant) to understand how to use the method then i've tested this API with my >>> students, all but one what able to correctly derives the Class from a >>> ClassDesc, so instead of asking every users of permittedSubclasses to go >>> through the oops of getting Class from a ClassDesc, i think we can agree that >>> it's better to move the burden from the user to the JDK implementors. >> >> Why is the objective to get the Class objects? What purpose does that >> serve? > > The whole idea of the reflection is to provide the runtime view of Java the language. > Even if such thing does not exist. And providing some kind of descriptor for an attribute fulfills that role. Nothing says it has to produce Class objects. >> The original API provided a descriptor for the contents of the >> permittedSubclasses attribute. I find it totally bizarre to have an API >> whose role is now to attempt to load all the subclasses of a sealed class. > > It's as bizarre as Class.getClasses() loading all the member classes. Not at all. Nested types are considered to be part of the same implementation as the outer type. They are intimately related and all part of the same accessibility domain. Loading subtypes that likely exist outside of the current package (else why would you need to be using sealed types) is a completely different matter. > You are discovering that the reflection API is bizarre, and it is :) I don't find it that bizarre. > It's not the view of the JVM, it's the view of Java at runtime, whatever it means. It means whatever we implement it to mean. So if we implement it in bizarre ways then it will be perceived as bizarre. David ----- >> >> YMMV. >> >> David > > R?mi > > [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Class.html#getClasses() > >> >>>> >>>> Cheers, >>>> David >>> >>> regards, >>> R?mi >>> >>>> >>>>> Thanks, Harold >>>>> >>>>> On 11/18/2020 12:31 AM, David Holmes wrote: >>>>>> Hi Vincente, >>>>>> >>>>>> On 16/11/2020 11:36 pm, Vicente Romero wrote: >>>>>>> Please review the code for the second iteration of sealed classes. In >>>>>>> this iteration we are: >>>>>>> >>>>>>> - Enhancing narrowing reference conversion to allow for stricter >>>>>>> checking of cast conversions with respect to sealed type hierarchies. >>>>>>> - Also local classes are not considered when determining implicitly >>>>>>> declared permitted direct subclasses of a sealed class or sealed >>>>>>> interface >>>>>> >>>>>> The major change here seems to be that getPermittedSubclasses() now >>>>>> returns actual Class objects instead of ClassDesc. My recollection >>>>>> from earlier discussions here was that the use of ClassDesc was very >>>>>> deliberate as the permitted subclasses may not actually exist and >>>>>> there may be security concerns with returning them! >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> ------------- >>>>>>> >>>>>>> Commit messages: >>>>>>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview) >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files >>>>>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00 >>>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778 >>>>>>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod >>>>>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff >>>>>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>>>>>> pull/1227/head:pull/1227 >>>>>>> >>>>>>> PR: https://git.openjdk.java.net/jdk/pull/1227 From mchung at openjdk.java.net Tue Nov 24 23:02:53 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 24 Nov 2020 23:02:53 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com> References: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com> Message-ID: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com> On Tue, 17 Nov 2020 00:25:51 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/Package.java line 227: >> >>> 225: * This method reports on a distinct concept of sealing from >>> 226: * {@link Class#isSealed() Class::isSealed}. >>> 227: * >> >> This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing. > > I agree. This @apiNote needs more clarification to help the readers to understand the context here. One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes". I added an API note in `Package::isSealed` [1] to clarify sealed package vs sealed class or interface. The API note you added in `Class::isSealed` can be clarified in a similar fashion like: "Sealed class or interface has no relationship with {@linkplain Package#isSealed package sealing}". [1] https://github.com/openjdk/jdk/commit/3c230b8a ------------- PR: https://git.openjdk.java.net/jdk/pull/1227 From forax at univ-mlv.fr Tue Nov 24 23:18:55 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 Nov 2020 00:18:55 +0100 (CET) Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com> References: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com> <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com> Message-ID: <1050079243.1769685.1606259935502.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mandy Chung" > ?: "compiler-dev" , "core-libs-dev" , "hotspot-dev" > > Envoy?: Mercredi 25 Novembre 2020 00:02:53 > Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) > On Tue, 17 Nov 2020 00:25:51 GMT, Mandy Chung wrote: > >>> src/java.base/share/classes/java/lang/Package.java line 227: >>> >>>> 225: * This method reports on a distinct concept of sealing from >>>> 226: * {@link Class#isSealed() Class::isSealed}. >>>> 227: * >>> >>> This API note will be very confusing to readers. I think the javadoc will need >>> to be fleshed out and probably will need to link to a section the Package class >>> description that defines the legacy concept of sealing. >> >> I agree. This @apiNote needs more clarification to help the readers to >> understand the context here. One thing we could do in the Package class >> description to add a "Package Sealing" section that can also explain that it >> has no relationship to "sealed classes". > > I added an API note in `Package::isSealed` [1] to clarify sealed package vs > sealed class or interface. > > The API note you added in `Class::isSealed` can be clarified in a similar > fashion like: "Sealed class or interface has no relationship with {@linkplain > Package#isSealed package sealing}". Hi Mandy, given that almost nobody knows about sealed packages, i'm not sure that adding a reference to Package::isSealed in Class::isSealed actually helps, it might be confusing. > > [1] https://github.com/openjdk/jdk/commit/3c230b8a > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1227 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Nov 25 07:03:14 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 25 Nov 2020 07:03:14 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: > Hi all, > > When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. > This patch solves this bug, regardless of the construction order, compiler can always output expected message. > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision: - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability. - Add corresponding tests for the method reference cases. - Add comments to state the situations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1389/files - new: https://git.openjdk.java.net/jdk/pull/1389/files/a9a68149..98ee2f2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1389&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1389&range=01-02 Stats: 268 lines in 23 files changed: 250 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1389.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1389/head:pull/1389 PR: https://git.openjdk.java.net/jdk/pull/1389 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Nov 25 07:22:56 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 25 Nov 2020 07:22:56 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v2] In-Reply-To: References: <0F2zSzccgh53MnY3qH8jVfFQR6U3B5Q7RNWqmLOWPGY=.d507497f-c6bc-459c-953a-5e911ebfad47@github.com> Message-ID: On Tue, 24 Nov 2020 18:42:11 GMT, Maurizio Cimadamore wrote: > That said, given the nature of the code involved, is not super trivial to come up with an example which demonstrates the difference I can't find a example to demonstrate the differences too. > While the tests you add are good, I don't see the corresponding tests for the method reference case. I add corresponding tests about the method reference cases. > If an access error shows up and we already have an access error, you add that to the list of "candidates", and return a WRONG_MTHS kind. It should be: If an **InapplicableMethodException** occurs and we already have an access error I add some comments to state the situations and improve readability. Thank you for taking the time to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From chegar at openjdk.java.net Wed Nov 25 11:08:19 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 25 Nov 2020 11:08:19 GMT Subject: RFR: 8256755: Update build.tools.depend.Depend to handle record components in API signatures [v2] In-Reply-To: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com> References: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com> Message-ID: > The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records. > > The components of a public record class, that is a member of an exported package, are logically part of the module's API. The name, type, and order are significant. This issue updates the build tool to include the aforementioned component characteristics. > > This issue is a blocker to adding any public record types to the JDK - since the build will fail. Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Additional tests for explicit constructors - Merge branch 'master' into depends - Update the Depend(ency) build tool to handle the record attribute ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1405/files - new: https://git.openjdk.java.net/jdk/pull/1405/files/ce0089d4..9ff3b10c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1405&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1405&range=00-01 Stats: 295440 lines in 2312 files changed: 182698 ins; 87418 del; 25324 mod Patch: https://git.openjdk.java.net/jdk/pull/1405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1405/head:pull/1405 PR: https://git.openjdk.java.net/jdk/pull/1405 From chegar at openjdk.java.net Wed Nov 25 11:39:55 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 25 Nov 2020 11:39:55 GMT Subject: Integrated: 8256755: Update build.tools.depend.Depend to handle record components in API signatures In-Reply-To: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com> References: <3lErqjFlNDVjsKubxd0HVv-PaL100WLOObgSQTXm3m8=.dabdfd0a-d1a2-407e-8172-ce2d1028ced8@github.com> Message-ID: <66B56fY1kM9aCoTSxCYVs0g_KJsV7lirZv63ujJ32V8=.502db1ba-003a-45eb-9d63-93becab0afe9@github.com> On Tue, 24 Nov 2020 09:59:44 GMT, Chris Hegarty wrote: > The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records. > > The components of a public record class, that is a member of an exported package, are logically part of the module's API. The name, type, and order are significant. This issue updates the build tool to include the aforementioned component characteristics. > > This issue is a blocker to adding any public record types to the JDK - since the build will fail. This pull request has now been integrated. Changeset: b0bd0c24 Author: Chris Hegarty URL: https://git.openjdk.java.net/jdk/commit/b0bd0c24 Stats: 41 lines in 2 files changed: 39 ins; 0 del; 2 mod 8256755: Update build.tools.depend.Depend to handle record components in API signatures Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/1405 From jlahoda at openjdk.java.net Wed Nov 25 12:43:59 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 25 Nov 2020 12:43:59 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com> References: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com> <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com> Message-ID: On Tue, 24 Nov 2020 23:00:05 GMT, Mandy Chung wrote: >> I agree. This @apiNote needs more clarification to help the readers to understand the context here. One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes". > > I added an API note in `Package::isSealed` [1] to clarify sealed package vs sealed class or interface. > > The API note you added in `Class::isSealed` can be clarified in a similar fashion like: "Sealed class or interface has no relationship with {@linkplain Package#isSealed package sealing}". > > [1] https://github.com/openjdk/jdk/commit/3c230b8a Thanks for that update, Mandy! I've tweaked the API note as per your recommendation. I'll publish a fixed PR later, reflecting the other review comments as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1227 From mcimadamore at openjdk.java.net Wed Nov 25 13:47:00 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 25 Nov 2020 13:47:00 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 07:03:14 GMT, Guoxiong Li wrote: >> Hi all, >> >> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. >> This patch solves this bug, regardless of the construction order, compiler can always output expected message. >> Thank you for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision: > > - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability. > - Add corresponding tests for the method reference cases. > - Add comments to state the situations I left some additional comments on tests. I plan to do some experiments to validate that we are not going to introduce bad regressions. test/langtools/tools/javac/T8255968/T8255968_10.java line 24: > 22: */ > 23: > 24: class T8255968 { Can you please disambiguate all these class names? Having the same class name in multiple tests can create havocs, especially when running in concurrent mode. Please make sure that classes have different names, and that the auxiliary classes defined in these test are, instead, defined as nested classes (so that, again, everything will be encapsulated on a test-by-test basis, w/o any risk of a test picking up a class from another test). test/langtools/tools/javac/T8255968/T8255968.java line 27: > 25: * @test > 26: * @bug 8255968 > 27: * @summary Confusing error message for inaccessible constructor Any reason as to why you went for this single file which lists all tests rather than adding jtreg tags in all the various test cases? AFAIK, in the javac code base the latter style is often preferred. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Nov 25 16:43:58 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 25 Nov 2020 16:43:58 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 13:42:01 GMT, Maurizio Cimadamore wrote: >> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision: >> >> - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability. >> - Add corresponding tests for the method reference cases. >> - Add comments to state the situations > > test/langtools/tools/javac/T8255968/T8255968_10.java line 24: > >> 22: */ >> 23: >> 24: class T8255968 { > > Can you please disambiguate all these class names? Having the same class name in multiple tests can create havocs, especially when running in concurrent mode. Please make sure that classes have different names, and that the auxiliary classes defined in these test are, instead, defined as nested classes (so that, again, everything will be encapsulated on a test-by-test basis, w/o any risk of a test picking up a class from another test). It sounds a great way to avoid some problem. I would revise my code to meet this style. Thanks for the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Nov 25 17:00:59 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 25 Nov 2020 17:00:59 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 13:42:48 GMT, Maurizio Cimadamore wrote: >> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision: >> >> - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability. >> - Add corresponding tests for the method reference cases. >> - Add comments to state the situations > > test/langtools/tools/javac/T8255968/T8255968.java line 27: > >> 25: * @test >> 26: * @bug 8255968 >> 27: * @summary Confusing error message for inaccessible constructor > > Any reason as to why you went for this single file which lists all tests rather than adding jtreg tags in all the various test cases? AFAIK, in the javac code base the latter style is often preferred. I have seem these two styles in the test code base. I don't prefer any style because these two styles both work well. It is better to have a standard style to guide developers. But now it has no such standard. > AFAIK, in the javac code base the latter style is often preferred. According to your comment, I would revise the tests to meets the latter style. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Nov 25 17:34:57 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 25 Nov 2020 17:34:57 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 13:44:31 GMT, Maurizio Cimadamore wrote: >> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision: >> >> - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability. >> - Add corresponding tests for the method reference cases. >> - Add comments to state the situations > > I left some additional comments on tests. I plan to do some experiments to validate that we are not going to introduce bad regressions. The old style which is shown below is not good. class T8255968 { Test c = new Test(0); } class Test { private Test(int x) {} } > and that the auxiliary classes defined in these test are, instead, defined as nested classes I change it to the following style according to the comment. But the compiler compiles it successfully because the outer class can visit private method of its inner class. class T8255968_1 { Test c = new Test(0); class Test { private Test(int x) {} } } So I would like to use the following style(don't use nested classes). class T8255968_1 { T8255968Test1 c = new T8255968Test1(0); } class T8255968Test1 { private T8255968Test1(int x) {} } @mcimadamore Do you agree with this style? ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From mcimadamore at openjdk.java.net Wed Nov 25 18:53:53 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 25 Nov 2020 18:53:53 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 13:44:31 GMT, Maurizio Cimadamore wrote: >> Guoxiong Li has updated the pull request incrementally with three additional commits since the last revision: >> >> - Change the `Test(String x)` from private to default. Add comments in test cases to improve readability. >> - Add corresponding tests for the method reference cases. >> - Add comments to state the situations > > I left some additional comments on tests. I plan to do some experiments to validate that we are not going to introduce bad regressions. > @mcimadamore Do you agree with this style? Yeah - of course nesting things is gonna mess up with access checks - sorry for sending you down the wrong direction! You could prefix every class in the test with `T8255968_1` e.g. class T8255968_1 { T8255968Test1 c = new T8255968_1_Test(0); } class T8255968_1_Test { private T8255968_1_Test(int x) {} } ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From joe.darcy at oracle.com Wed Nov 25 23:49:39 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 25 Nov 2020 15:49:39 -0800 Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. [v3] In-Reply-To: <_9Wkj9PHga5Y5GTI2RpJqyCtdYJs3PXI2R8falBJYlA=.26b53df7-c507-4242-8973-f7af82a25213@github.com> References: <_9Wkj9PHga5Y5GTI2RpJqyCtdYJs3PXI2R8falBJYlA=.26b53df7-c507-4242-8973-f7af82a25213@github.com> Message-ID: FYI, I had a good experience taking a trial run of this patch to update the java.compiler APIs to use the new feature. I didn't find any issues; a specdiff comparing with and without use of the new tag didn't have any unexpected diffs. (There were cases where small wording differences existed and were regularized in the patch.) After this goes back, looking forward to pushing a fix for JDK-8256917: Use combo @returns tag in java.compiler javadoc. Cheers, -Joe On 11/20/2020 4:34 PM, Jonathan Gibbons wrote: >> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description. >> >> The goal is to be able to simplify the following common pattern: >> >> /** >> * Returns the result. Optional additional text. >> * @return the result >> */ >> int method() { >> >> by >> >> /** >> * {@return the result} Optional additional text. >> */ >> int method() { >> >> Note: >> >> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere. >> * The expansion of the inline tag is `Returns " _content_ `.` where _content_ is the content of the tag. >> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description >> * The inline tag can be inherited into overriding methods as if it was provided as a block tag. > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Update DocCommentParser to permit nested inline tags in specified cases: @return > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/1355/files > - new: https://git.openjdk.java.net/jdk/pull/1355/files/89846ff1..87edfb0c > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=02 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=01-02 > > Stats: 88 lines in 3 files changed: 82 ins; 3 del; 3 mod > Patch: https://git.openjdk.java.net/jdk/pull/1355.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355 > > PR: https://git.openjdk.java.net/jdk/pull/1355 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Nov 26 03:36:53 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 26 Nov 2020 03:36:53 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v4] In-Reply-To: References: Message-ID: <6-LVKf_d0EqzNytbRg1FQ-JZYSYX55HpGpzCJMBacXY=.79ed53cd-27d4-4802-b816-b27a7e562228@github.com> > Hi all, > > When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. > This patch solves this bug, regardless of the construction order, compiler can always output expected message. > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Revise test cases. Rename classes and divide the jtreg tags by unit. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1389/files - new: https://git.openjdk.java.net/jdk/pull/1389/files/98ee2f2a..dc029923 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1389&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1389&range=02-03 Stats: 269 lines in 31 files changed: 113 ins; 44 del; 112 mod Patch: https://git.openjdk.java.net/jdk/pull/1389.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1389/head:pull/1389 PR: https://git.openjdk.java.net/jdk/pull/1389 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Nov 26 15:21:55 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 26 Nov 2020 15:21:55 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 18:51:21 GMT, Maurizio Cimadamore wrote: >> I left some additional comments on tests. I plan to do some experiments to validate that we are not going to introduce bad regressions. > >> @mcimadamore Do you agree with this style? > > Yeah - of course nesting things is gonna mess up with access checks - sorry for sending you down the wrong direction! > > You could prefix every class in the test with `T8255968_1` e.g. > > class T8255968_1 { > T8255968Test1 c = new T8255968_1_Test(0); > } > > class T8255968_1_Test { > private T8255968_1_Test(int x) {} > } I update the code about test cases. Thank you for taking the time to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From hannesw at openjdk.java.net Thu Nov 26 16:54:06 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 26 Nov 2020 16:54:06 GMT Subject: RFR: 8242652: Throw SkippedException if no JS engine availabe in TestSearchScript [v2] In-Reply-To: References: Message-ID: > This is a simple change to throw jtreg.SkippedException if no JavaScript engine is available to run the TestSearchScript test. In my previous attempt I tried to use the SkippedException class already present elsewhere in the test tree, not realizing I couuld just copy/create the exception in the javadoc test library. > > Note that while the test is skipped correctly if no JS engine is available, the test will currently fail in the presence of a JS engine such as GraalJS. This is fixed by JDK-8244535. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Use existing SkippedException class in TestSearchScript.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1412/files - new: https://git.openjdk.java.net/jdk/pull/1412/files/d6bc3b79..02ab014b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1412&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1412&range=00-01 Stats: 39 lines in 3 files changed: 5 ins; 34 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1412.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1412/head:pull/1412 PR: https://git.openjdk.java.net/jdk/pull/1412 From prappo at openjdk.java.net Thu Nov 26 16:59:00 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 26 Nov 2020 16:59:00 GMT Subject: RFR: 8242652: Throw SkippedException if no JS engine availabe in TestSearchScript [v2] In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 16:54:06 GMT, Hannes Walln?fer wrote: >> This is a simple change to throw jtreg.SkippedException if no JavaScript engine is available to run the TestSearchScript test. In my previous attempt I tried to use the SkippedException class already present elsewhere in the test tree, not realizing I couuld just copy/create the exception in the javadoc test library. >> >> Note that while the test is skipped correctly if no JS engine is available, the test will currently fail in the presence of a JS engine such as GraalJS. This is fixed by JDK-8244535. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Use existing SkippedException class in TestSearchScript.java This change looks good to me. Since you've changed `test/langtools/TEST.ROOT`, please make sure all the langtools tests pass (not just `TestSearchScript.java`) before integrating this change. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1412 From hannesw at openjdk.java.net Fri Nov 27 09:46:58 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 27 Nov 2020 09:46:58 GMT Subject: Integrated: 8242652: Throw SkippedException if no JS engine availabe in TestSearchScript In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 15:08:27 GMT, Hannes Walln?fer wrote: > This is a simple change to throw jtreg.SkippedException if no JavaScript engine is available to run the TestSearchScript test. In my previous attempt I tried to use the SkippedException class already present elsewhere in the test tree, not realizing I couuld just copy/create the exception in the javadoc test library. > > Note that while the test is skipped correctly if no JS engine is available, the test will currently fail in the presence of a JS engine such as GraalJS. This is fixed by JDK-8244535. This pull request has now been integrated. Changeset: f2f3ba92 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/f2f3ba92 Stats: 20 lines in 2 files changed: 8 ins; 10 del; 2 mod 8242652: Throw SkippedException if no JS engine availabe in TestSearchScript Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/1412 From github.com+3896345+hltj at openjdk.java.net Fri Nov 27 13:19:56 2020 From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei) Date: Fri, 27 Nov 2020 13:19:56 GMT Subject: RFR: 8229862: NPE in jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570) In-Reply-To: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com> References: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com> Message-ID: On Mon, 16 Nov 2020 10:32:00 GMT, Jan Lahoda wrote: > Based on Bernard's code from: > http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015225.html > > Capturing anonymous classes inside lambdas may fail to compile, because: > -the captured variables are not detected correctly, because `LambdaToMethod...captureLocalClassDefs` needs to find the AST node for the given `ClassSymbol`, but it has not yet been added into the `localClassDefs`. The proposed solution is to re-order the tasks done for JCNewClass, and call the super implementation sooner. This will enter the `ClassSymbol` and corresponding AST node into `localClassDefs` before the capture variables detection. > -inside the anonymous class definition, some references to the captured variables are replaced using a map that maps captured variables for lambdas (`lambdaTranslationMap`) - but inside the anonymous class, there the captured variables should be mapped using the anonymous class' map/proxies (to fields). The proposed solution is to clear `lambdaTranslationMap` before processing the anonymous class body. Great! It fix the issue I have met when I trying to fix another issue (#1479). My minimal reproducing code is: java class Main { static Runnable runnable = () -> { String s0 = "hello"; class Local { int i = s0.length(); } Runnable dummy = () -> new Local() { }; }; } ------------- PR: https://git.openjdk.java.net/jdk/pull/1221 From jlahoda at openjdk.java.net Fri Nov 27 15:45:12 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 27 Nov 2020 15:45:12 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols Message-ID: Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: -updating and moving tests into test/langtools, so that it is easier to run them. -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). -fixing the -Xprint annotation processor to print record component annotations. Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. ------------- Commit messages: - Update CreateSymbolsTest.java - Cleaning TODO. - Cleaning TODO. - Adding test verifying javac can read Record attribute properly. - Cleanup. - JDK-8256950: Add record attribute support to symbol generator CreateSymbols Changes: https://git.openjdk.java.net/jdk/pull/1480/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256950 Stats: 1910 lines in 12 files changed: 1147 ins; 745 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/1480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480 PR: https://git.openjdk.java.net/jdk/pull/1480 From rriggs at openjdk.java.net Fri Nov 27 16:35:55 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 27 Nov 2020 16:35:55 GMT Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 17:15:22 GMT, Jonathan Gibbons wrote: > This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description. > > The goal is to be able to simplify the following common pattern: > > /** > * Returns the result. Optional additional text. > * @return the result > */ > int method() { > > by > > /** > * {@return the result} Optional additional text. > */ > int method() { > > Note: > > * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere. > * The expansion of the inline tag is `Returns " _content_ `.` where _content_ is the content of the tag. > * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description > * The inline tag can be inherited into overriding methods as if it was provided as a block tag. /** * {@return the result} Optional additional text. */ ``` The java source looks a bit odd/unusual because the "first sentence" does not appear to end with a period. Though it seems like a convenience to include the '.' in the expansion, the source might be clearer if it did not, as in: /** * {@return the result}. Optional additional text. */ Similarly, prepending the "Returns", forces the verb, which is conventional but always the most appropriate word. Changing the expansion to be only the contents of @ return would allow more flexible use. It would put more responsibility on the developer to form the first sentence. (With "Returns"... and the "." outside the tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/1355 From jlahoda at openjdk.java.net Fri Nov 27 17:06:03 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 27 Nov 2020 17:06:03 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) Message-ID: This pull request replaces https://github.com/openjdk/jdk/pull/1227. >From the original PR: > Please review the code for the second iteration of sealed classes. In this iteration we are: > > * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies > > * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface > > * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] > > * adding code to make sure that annotations can't be sealed > > * improving some tests > > > TIA > > Related specs: > [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) > [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) > [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) This PR strives to reflect the review comments from 1227: * adjustments to javadoc of j.l.Class methods * package access checks in Class.getPermittedSubclasses() * fixed to the narrowing conversion/castability as pointed out by Maurizio ------------- Commit messages: - Moving checkPackageAccess from getPermittedSubclasses to a separate method. - Improving getPermittedSubclasses() javadoc. - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. - Removing unnecessary file. - Tweaking javadoc. - Reflecting review comments w.r.t. narrowing conversion. - Improving checks in getPermittedSubclasses() - Merging master into JDK-8246778 - Adding checkPackageAccess to Class.getPermittedSubclasses(). - 8246778: Compiler implementation for Sealed Classes (Second Preview) Changes: https://git.openjdk.java.net/jdk/pull/1483/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246778 Stats: 915 lines in 12 files changed: 834 ins; 9 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/1483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483 PR: https://git.openjdk.java.net/jdk/pull/1483 From jjg at openjdk.java.net Fri Nov 27 17:29:56 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 27 Nov 2020 17:29:56 GMT Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 16:33:27 GMT, Roger Riggs wrote: >> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description. >> >> The goal is to be able to simplify the following common pattern: >> >> /** >> * Returns the result. Optional additional text. >> * @return the result >> */ >> int method() { >> >> by >> >> /** >> * {@return the result} Optional additional text. >> */ >> int method() { >> >> Note: >> >> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere. >> * The expansion of the inline tag is `Returns " _content_ `.` where _content_ is the content of the tag. >> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description >> * The inline tag can be inherited into overriding methods as if it was provided as a block tag. > > /** > * {@return the result} Optional additional text. > */ > ``` > The java source looks a bit odd/unusual because the "first sentence" does not appear to end with a period. > Though it seems like a convenience to include the '.' in the expansion, the source might be clearer if it did not, as in: > /** > * {@return the result}. Optional additional text. > */ > Similarly, prepending the "Returns", forces the verb, which is conventional but always the most appropriate word. > Changing the expansion to be only the contents of @ return would allow more flexible use. > It would put more responsibility on the developer to form the first sentence. (With "Returns"... and the "." outside the tag. @RogerRiggs I think that having to write `Returns {@return the result}.` would look more weird than the current proposal to omit the `.`. Note also that the proposed form matches the existing `{@summary ...}` tag which can be used to explicit define the "first sentence" that appears in summary tables. ------------- PR: https://git.openjdk.java.net/jdk/pull/1355 From mcimadamore at openjdk.java.net Fri Nov 27 18:35:55 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 27 Nov 2020 18:35:55 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 15:18:48 GMT, Guoxiong Li wrote: >>> @mcimadamore Do you agree with this style? >> >> Yeah - of course nesting things is gonna mess up with access checks - sorry for sending you down the wrong direction! >> >> You could prefix every class in the test with `T8255968_1` e.g. >> >> class T8255968_1 { >> T8255968Test1 c = new T8255968_1_Test(0); >> } >> >> class T8255968_1_Test { >> private T8255968_1_Test(int x) {} >> } > > I update the code about test cases. Thank you for taking the time to review. I haven't forgotten about this - we're running some extensive corpus analysis to make sure that the patch won't introduce any unwanted regressions. Please bear with us :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From github.com+13688759+lgxbslgx at openjdk.java.net Sat Nov 28 09:51:08 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 28 Nov 2020 09:51:08 GMT Subject: RFR: 8257037: No javac warning when calling deprecated constructor with diamond Message-ID: Hi all, When calling deprecated constructor with diamond, the compiler doesn't output warning. The test case is shown below. GenericClass o2 = new GenericClass<>(); public class GenericClass { @Deprecated public GenericClass() {} } This patch solves the bug and adds corresponding test case. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8257037: No javac warning when calling deprecated constructor with diamond Changes: https://git.openjdk.java.net/jdk/pull/1490/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1490&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257037 Stats: 77 lines in 3 files changed: 67 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1490/head:pull/1490 PR: https://git.openjdk.java.net/jdk/pull/1490 From github.com+13688759+lgxbslgx at openjdk.java.net Sat Nov 28 10:54:56 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 28 Nov 2020 10:54:56 GMT Subject: Withdrawn: 8257037: No javac warning when calling deprecated constructor with diamond In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 09:46:06 GMT, Guoxiong Li wrote: > Hi all, > > When calling deprecated constructor with diamond, the compiler doesn't output warning. > The test case is shown below. > > GenericClass o2 = new GenericClass<>(); > > public class GenericClass { > @Deprecated > public GenericClass() {} > } > > This patch solves the bug and adds corresponding test case. > Thank you for taking the time to review. > > Best Regards. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1490 From github.com+13688759+lgxbslgx at openjdk.java.net Sat Nov 28 11:46:08 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 28 Nov 2020 11:46:08 GMT Subject: RFR: 8257037: No javac warning when calling deprecated constructor with diamond [v2] In-Reply-To: References: Message-ID: <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com> > Hi all, > > When calling deprecated constructor with diamond, the compiler doesn't output warning. > The test case is shown below. > > GenericClass o2 = new GenericClass<>(); > > public class GenericClass { > @Deprecated > public GenericClass() {} > } > > This patch solves the bug and adds corresponding test case. > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Polish ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1490/files - new: https://git.openjdk.java.net/jdk/pull/1490/files/1ceb9993..1d2a73c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1490&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1490&range=00-01 Stats: 22 lines in 1 file changed: 0 ins; 4 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/1490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1490/head:pull/1490 PR: https://git.openjdk.java.net/jdk/pull/1490 From github.com+13688759+lgxbslgx at openjdk.java.net Sat Nov 28 11:46:08 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 28 Nov 2020 11:46:08 GMT Subject: RFR: 8257037: No javac warning when calling deprecated constructor with diamond In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 09:46:06 GMT, Guoxiong Li wrote: > Hi all, > > When calling deprecated constructor with diamond, the compiler doesn't output warning. > The test case is shown below. > > GenericClass o2 = new GenericClass<>(); > > public class GenericClass { > @Deprecated > public GenericClass() {} > } > > This patch solves the bug and adds corresponding test case. > Thank you for taking the time to review. > > Best Regards. Sorry for closing the PR accidentally. ------------- PR: https://git.openjdk.java.net/jdk/pull/1490 From alanb at openjdk.java.net Mon Nov 30 09:58:58 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 30 Nov 2020 09:58:58 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 16:57:54 GMT, Jan Lahoda wrote: > This pull request replaces https://github.com/openjdk/jdk/pull/1227. > > From the original PR: > >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> >> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> >> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> >> * adding code to make sure that annotations can't be sealed >> >> * improving some tests >> >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > This PR strives to reflect the review comments from 1227: > * adjustments to javadoc of j.l.Class methods > * package access checks in Class.getPermittedSubclasses() > * fixed to the narrowing conversion/castability as pointed out by Maurizio src/java.base/share/classes/java/lang/Class.java line 4420: > 4418: * {@linkplain #getClassLoader() the defining class loader} of the current > 4419: * {@code Class} object. If a name cannot be converted to the {@code Class} > 4420: * instance, it is silently excluded from the result. I think this paragraph will need a little bit of wordsmithing. The 3rd paragraph of getNestMembers might be useful to examine as it more clearly describes how the method attempts to "obtain" the Class object for each of the class names in the NestMembers attribute and maybe some of that wording could be used instead of using the term "convert". Minor nit but the prevailing style for the @throws SecurityException is to align the description with the exception, probably best to keep it consistent if you can. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mcimadamore at openjdk.java.net Mon Nov 30 11:46:58 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 30 Nov 2020 11:46:58 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v4] In-Reply-To: <6-LVKf_d0EqzNytbRg1FQ-JZYSYX55HpGpzCJMBacXY=.79ed53cd-27d4-4802-b816-b27a7e562228@github.com> References: <6-LVKf_d0EqzNytbRg1FQ-JZYSYX55HpGpzCJMBacXY=.79ed53cd-27d4-4802-b816-b27a7e562228@github.com> Message-ID: On Thu, 26 Nov 2020 03:36:53 GMT, Guoxiong Li wrote: >> Hi all, >> >> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information. >> This patch solves this bug, regardless of the construction order, compiler can always output expected message. >> Thank you for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Revise test cases. Rename classes and divide the jtreg tags by unit. Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1389 From mcimadamore at openjdk.java.net Mon Nov 30 11:46:58 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 30 Nov 2020 11:46:58 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v3] In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 18:32:54 GMT, Maurizio Cimadamore wrote: >> I update the code about test cases. Thank you for taking the time to review. > > I haven't forgotten about this - we're running some extensive corpus analysis to make sure that the patch won't introduce any unwanted regressions. Please bear with us :-) All the internal testing went ok. At this point I see no reason to delay this further. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From chegar at openjdk.java.net Mon Nov 30 12:20:59 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 30 Nov 2020 12:20:59 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda wrote: > Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 965: > 963: new NestMembers_attribute(attributeString, nestMembers)); > 964: } > 965: if (header.recordComponents != null && !header.recordComponents.isEmpty()) { I am not sure of the exact logic here, but it is perfectly fine for a record attribute to contain zero components, and for the class to still be considered a "record class". But maybe that is not all that significant here? I just want to call it out so that it is considered. ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From mcimadamore at openjdk.java.net Mon Nov 30 12:35:56 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 30 Nov 2020 12:35:56 GMT Subject: RFR: 8257037: No javac warning when calling deprecated constructor with diamond [v2] In-Reply-To: <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com> References: <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com> Message-ID: On Sat, 28 Nov 2020 11:46:08 GMT, Guoxiong Li wrote: >> Hi all, >> >> When calling deprecated constructor with diamond, the compiler doesn't output warning. >> The test case is shown below. >> >> GenericClass o2 = new GenericClass<>(); >> >> public class GenericClass { >> @Deprecated >> public GenericClass() {} >> } >> >> This patch solves the bug and adds corresponding test case. >> Thank you for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Polish I think the fix seems in spirit with respect to what happens for ordinary constructor resolution. I guess there is a question as to whether we should check for these warnings during resolution or after (probably checking for warning after resolution might be a better idea) - as there is some duplication between the code in `findConstructor` and the new `findDiamond` and what goes on in `Attr::checkId` which also check for these warnings (and some more) but doesn't apply checks on constructors. Just for fun, I tried this patch: diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java index df21524229c..05d56136000 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java @@ -4459,15 +4459,11 @@ public class Attr extends JCTree.Visitor { } // Emit a `deprecation' warning if symbol is deprecated. - // (for constructors (but not for constructor references), the error - // was given when the constructor was resolved) - if (sym.name != names.init || tree.hasTag(REFERENCE)) { - chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym); - chk.checkSunAPI(tree.pos(), sym); - chk.checkProfile(tree.pos(), sym); - chk.checkPreview(tree.pos(), sym); - } + chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym); + chk.checkSunAPI(tree.pos(), sym); + chk.checkProfile(tree.pos(), sym); + chk.checkPreview(tree.pos(), sym); // If symbol is a variable, check that its type and // kind are compatible with the prototype and protokind. diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java index 727d2989adf..9bb37fc23b8 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java @@ -2859,8 +2859,6 @@ public class Resolve { names.init, argtypes, typeargtypes, allowBoxing, useVarargs); - chk.checkDeprecated(pos, env.info.scope.owner, sym); - chk.checkPreview(pos, sym); return sym; } @@ -2937,6 +2935,7 @@ public class Resolve { return sym; } }; + newConstr.setAttributes(sym); bestSoFar = selectBest(env, site, argtypes, typeargtypes, newConstr, bestSoFar, This fixes your issues, and removes the warning code duplication between `Attr` and `Resolve`, as well as adding checks for all the remaining kinds of warnings (sunAPI, deprecation, preview and profile) - although I believe most of those are not as important. I guess I'll leave you to decide how you want to tackle this. As I said, the patch you wrote remains within the spirit of the original code - my only minor quibble is that this "spirit" is questionable, as it involves issuing same warnings in different places, this enforcing developers to replicate code (and forgetting to do so, as it already happened) in multiple places. ------------- PR: https://git.openjdk.java.net/jdk/pull/1490 From github.com+13688759+lgxbslgx at openjdk.java.net Mon Nov 30 12:50:56 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Mon, 30 Nov 2020 12:50:56 GMT Subject: RFR: 8255968: Confusing error message for inaccessible constructor [v4] In-Reply-To: References: <6-LVKf_d0EqzNytbRg1FQ-JZYSYX55HpGpzCJMBacXY=.79ed53cd-27d4-4802-b816-b27a7e562228@github.com> Message-ID: On Mon, 30 Nov 2020 11:43:50 GMT, Maurizio Cimadamore wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise test cases. Rename classes and divide the jtreg tags by unit. > > Looks good Thank you for the review. @mcimadamore Could you please sponsor this patch? Thanks again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1389 From jlahoda at openjdk.java.net Mon Nov 30 14:21:16 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 30 Nov 2020 14:21:16 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v2] In-Reply-To: References: Message-ID: <0IU-_p6RHP0YTRd5q17XiSKjstg63aZBK4GcvliVvTM=.0caf6919-4eb3-4c13-8447-a953e1185153@github.com> > Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8256950' of https://github.com/lahodaj/jdk into JDK-8256950 - CreateSymbols should support records with no components. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1480/files - new: https://git.openjdk.java.net/jdk/pull/1480/files/c3696e72..7ce38709 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=00-01 Stats: 54 lines in 2 files changed: 51 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480 PR: https://git.openjdk.java.net/jdk/pull/1480 From jlahoda at openjdk.java.net Mon Nov 30 14:27:13 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 30 Nov 2020 14:27:13 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v3] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 12:17:46 GMT, Chris Hegarty wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing tests on Windows - normalizing line endings. > > make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 965: > >> 963: new NestMembers_attribute(attributeString, nestMembers)); >> 964: } >> 965: if (header.recordComponents != null && !header.recordComponents.isEmpty()) { > > I am not sure of the exact logic here, but it is perfectly fine for a record attribute to contain zero components, and for the class to still be considered a "record class". But maybe that is not all that significant here? I just want to call it out so that it is considered. Ah, right - fixed in: https://github.com/openjdk/jdk/pull/1480/commits/e1ec2b7ff49e1307a348ad58b12e5ed39ebe7224 Thanks for the comment! ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From jlahoda at openjdk.java.net Mon Nov 30 14:27:11 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 30 Nov 2020 14:27:11 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v3] In-Reply-To: References: Message-ID: > Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing tests on Windows - normalizing line endings. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1480/files - new: https://git.openjdk.java.net/jdk/pull/1480/files/7ce38709..a3f79aba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=01-02 Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480 PR: https://git.openjdk.java.net/jdk/pull/1480 From jlahoda at openjdk.java.net Mon Nov 30 15:59:07 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 30 Nov 2020 15:59:07 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: Message-ID: > This pull request replaces https://github.com/openjdk/jdk/pull/1227. > > From the original PR: > >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> >> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> >> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> >> * adding code to make sure that annotations can't be sealed >> >> * improving some tests >> >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > This PR strives to reflect the review comments from 1227: > * adjustments to javadoc of j.l.Class methods > * package access checks in Class.getPermittedSubclasses() > * fixed to the narrowing conversion/castability as pointed out by Maurizio Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Improving getPermittedSubclasses javadoc. - Merge branch 'master' into JDK-8246778 - Moving checkPackageAccess from getPermittedSubclasses to a separate method. - Improving getPermittedSubclasses() javadoc. - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. - Removing unnecessary file. - Tweaking javadoc. - Reflecting review comments w.r.t. narrowing conversion. - Improving checks in getPermittedSubclasses() - Merging master into JDK-8246778 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1483/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=01 Stats: 918 lines in 12 files changed: 837 ins; 9 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/1483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483 PR: https://git.openjdk.java.net/jdk/pull/1483 From jlahoda at openjdk.java.net Mon Nov 30 15:59:09 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 30 Nov 2020 15:59:09 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 09:55:56 GMT, Alan Bateman wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Improving getPermittedSubclasses javadoc. >> - Merge branch 'master' into JDK-8246778 >> - Moving checkPackageAccess from getPermittedSubclasses to a separate method. >> - Improving getPermittedSubclasses() javadoc. >> - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. >> - Removing unnecessary file. >> - Tweaking javadoc. >> - Reflecting review comments w.r.t. narrowing conversion. >> - Improving checks in getPermittedSubclasses() >> - Merging master into JDK-8246778 >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179 > > src/java.base/share/classes/java/lang/Class.java line 4420: > >> 4418: * {@linkplain #getClassLoader() the defining class loader} of the current >> 4419: * {@code Class} object. If a name cannot be converted to the {@code Class} >> 4420: * instance, it is silently excluded from the result. > > I think this paragraph will need a little bit of wordsmithing. The 3rd paragraph of getNestMembers might be useful to examine as it more clearly describes how the method attempts to "obtain" the Class object for each of the class names in the NestMembers attribute and maybe some of that wording could be used instead of using the term "convert". > > Minor nit but the prevailing style for the @throws SecurityException is to align the description with the exception, probably best to keep it consistent if you can. Thanks, I've tried to improve the javadoc here: https://github.com/openjdk/jdk/pull/1483/commits/4d484179e6e4d64ed460b997d25b4dca5d964016 ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From github.com+13688759+lgxbslgx at openjdk.java.net Mon Nov 30 16:03:55 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Mon, 30 Nov 2020 16:03:55 GMT Subject: RFR: 8257037: No javac warning when calling deprecated constructor with diamond [v2] In-Reply-To: References: <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com> Message-ID: On Mon, 30 Nov 2020 12:33:15 GMT, Maurizio Cimadamore wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Polish > > I think the fix seems in spirit with respect to what happens for ordinary constructor resolution. I guess there is a question as to whether we should check for these warnings during resolution or after (probably checking for warning after resolution might be a better idea) - as there is some duplication between the code in `findConstructor` and the new `findDiamond` and what goes on in `Attr::checkId` which also check for these warnings (and some more) but doesn't apply checks on constructors. > > Just for fun, I tried this patch: > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > index df21524229c..05d56136000 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > @@ -4459,15 +4459,11 @@ public class Attr extends JCTree.Visitor { > } > > // Emit a `deprecation' warning if symbol is deprecated. > - // (for constructors (but not for constructor references), the error > - // was given when the constructor was resolved) > > - if (sym.name != names.init || tree.hasTag(REFERENCE)) { > - chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym); > - chk.checkSunAPI(tree.pos(), sym); > - chk.checkProfile(tree.pos(), sym); > - chk.checkPreview(tree.pos(), sym); > - } > + chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym); > + chk.checkSunAPI(tree.pos(), sym); > + chk.checkProfile(tree.pos(), sym); > + chk.checkPreview(tree.pos(), sym); > > // If symbol is a variable, check that its type and > // kind are compatible with the prototype and protokind. > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > index 727d2989adf..9bb37fc23b8 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > @@ -2859,8 +2859,6 @@ public class Resolve { > names.init, argtypes, > typeargtypes, allowBoxing, > useVarargs); > - chk.checkDeprecated(pos, env.info.scope.owner, sym); > - chk.checkPreview(pos, sym); > return sym; > } > > @@ -2937,6 +2935,7 @@ public class Resolve { > return sym; > } > }; > + newConstr.setAttributes(sym); > bestSoFar = selectBest(env, site, argtypes, typeargtypes, > newConstr, > bestSoFar, > This fixes your issues, and removes the warning code duplication between `Attr` and `Resolve`, as well as adding checks for all the remaining kinds of warnings (sunAPI, deprecation, preview and profile) - although I believe most of those are not as important. > > I guess I'll leave you to decide how you want to tackle this. As I said, the patch you wrote remains within the spirit of the original code - my only minor quibble is that this "spirit" is questionable, as it involves issuing same warnings in different places, this enforcing developers to replicate code (and forgetting to do so, as it already happened) in multiple places. Thank you for the comment and suggestion. I had seen and paid attention to the following code in `Attr.java` when being solved this bug. // (for constructors (but not for constructor references), the error // was given when the constructor was resolved) if (sym.name != names.init || tree.hasTag(REFERENCE)) { chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym); chk.checkSunAPI(tree.pos(), sym); chk.checkProfile(tree.pos(), sym); chk.checkPreview(tree.pos(), sym); } These code confused me. Because the comments `(for constructors, the error was given when the constructor was resolved)` and the conditional expression `sym.name != names.init` were submitted at 2007(submit log: Initial load). And nobody raises suggestion to it over these years though this code snippet had been revised many times. In order not to generate unknown issues, I chose not to revise these code when being solved this bug. @mcimadamore I test your patch locally by using the following command. All the tests passed. make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release Your patch is a better solution if no any unknown regression occurs. But I have no idea about the unknown regressions now. I would like to accept your suggestion and revise my code. **And we should think more situations which could generate regressions to avoid unknown issues occur.** ---- Finally, I have a little question. Is the code `newConstr.setAttributes(sym);` necessary in `Resolve.findDiamond`? I delete it in your patch, and test locally by using the following command. All the tests passed. make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release ------------- PR: https://git.openjdk.java.net/jdk/pull/1490 From alanb at openjdk.java.net Mon Nov 30 17:46:04 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 30 Nov 2020 17:46:04 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Improving getPermittedSubclasses javadoc. > - Merge branch 'master' into JDK-8246778 > - Moving checkPackageAccess from getPermittedSubclasses to a separate method. > - Improving getPermittedSubclasses() javadoc. > - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. > - Removing unnecessary file. > - Tweaking javadoc. > - Reflecting review comments w.r.t. narrowing conversion. > - Improving checks in getPermittedSubclasses() > - Merging master into JDK-8246778 > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179 src/java.base/share/classes/java/lang/Class.java line 4412: > 4410: * The {@code Class} objects which can be obtained using this procedure > 4411: * are indicated by elements of the returned array. If a {@code Class} object > 4412: * cannot be obtained, it is silently ignored, and not included in the result Thanks for the update, this reads much better. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Mon Nov 30 19:36:02 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 30 Nov 2020 19:36:02 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: Message-ID: <1b8GH2EQDJvztsMclvskMZrsYcjnapSyqqGMGcutLTY=.b2ef4f3c-0e0d-43a9-9890-cdfbd12f53e9@github.com> On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Improving getPermittedSubclasses javadoc. > - Merge branch 'master' into JDK-8246778 > - Moving checkPackageAccess from getPermittedSubclasses to a separate method. > - Improving getPermittedSubclasses() javadoc. > - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. > - Removing unnecessary file. > - Tweaking javadoc. > - Reflecting review comments w.r.t. narrowing conversion. > - Improving checks in getPermittedSubclasses() > - Merging master into JDK-8246778 > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179 src/java.base/share/classes/java/lang/Class.java line 4463: > 4461: * @apiNote > 4462: * Sealed class or interface has no relationship with > 4463: * {@linkplain Package#isSealed package sealing}. Package sealing is legacy. Remi suggests to take out this api note which sounds good to me. The API note in Package::isSealed has made this clear which has no relationship with sealed class or interface. src/java.base/share/classes/java/lang/Class.java line 4415: > 4413: * array. > 4414: * > 4415: * @return an array of class objects of the permitted subclasses of this class or interface Nit: s/class objects/{@code Class} objects/ ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Mon Nov 30 19:48:00 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 30 Nov 2020 19:48:00 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Improving getPermittedSubclasses javadoc. > - Merge branch 'master' into JDK-8246778 > - Moving checkPackageAccess from getPermittedSubclasses to a separate method. > - Improving getPermittedSubclasses() javadoc. > - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. > - Removing unnecessary file. > - Tweaking javadoc. > - Reflecting review comments w.r.t. narrowing conversion. > - Improving checks in getPermittedSubclasses() > - Merging master into JDK-8246778 > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179 src/java.base/share/classes/java/lang/Class.java line 4480: > 4478: } > 4479: > 4480: private native Class[] getPermittedSubclasses0(); Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS: - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C Should the library implementation of `Class::getPermittedSubclasses` filter that if not done by `getPermittedSubclasses0`? If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Mon Nov 30 20:49:02 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 30 Nov 2020 20:49:02 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Improving getPermittedSubclasses javadoc. > - Merge branch 'master' into JDK-8246778 > - Moving checkPackageAccess from getPermittedSubclasses to a separate method. > - Improving getPermittedSubclasses() javadoc. > - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. > - Removing unnecessary file. > - Tweaking javadoc. > - Reflecting review comments w.r.t. narrowing conversion. > - Improving checks in getPermittedSubclasses() > - Merging master into JDK-8246778 > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179 src/java.base/share/classes/java/lang/Class.java line 3042: > 3040: for (Class c : classes) { > 3041: // skip the package access check on a proxy class in default proxy package > 3042: if (!Proxy.isProxyClass(c) || ReflectUtil.isNonPublicProxyClass(c)) { If a sealed class is in a named module, the permitted subclasses/subinterfaces are in the same module as the sealed class. If a sealed class is in an unnamed module, it will be in the same runtime package as the sealed class. A proxy class is dynamically generated and not intended for statically named in `permits` clause of a sealed class`. It can be in a different module or different package. So a permitted subclass or interface should never be a proxy class. So the package access check for permitted subclasses/subinterfaces can be simplified. I would suggest this check be inlined in `getPermittedSubclasses` as follows: SecurityManager sm = System.getSecurityManager(); if (subclasses.length > 0 && sm != null) { ClassLoader ccl = ClassLoader.getClassLoader(Reflection.getCallerClass()); ClassLoader cl = getClassLoader0(); if (ReflectUtil.needsPackageAccessCheck(ccl, cl)) { Set packages = new HashSet<>(); for (Class c : subclasses) { if (Proxy.isProxyClass(c)) throw new InternalError("a permitted subclass should not be a proxy class: " + c); String pkg = c.getPackageName(); if (!pkg.isEmpty()) packages.add(pkg); } for (String pkg : packages) { sm.checkPackageAccess(pkg); } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From hseigel at openjdk.java.net Mon Nov 30 20:59:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 30 Nov 2020 20:59:59 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: Message-ID: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> On Mon, 30 Nov 2020 19:44:52 GMT, Mandy Chung wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Improving getPermittedSubclasses javadoc. >> - Merge branch 'master' into JDK-8246778 >> - Moving checkPackageAccess from getPermittedSubclasses to a separate method. >> - Improving getPermittedSubclasses() javadoc. >> - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. >> - Removing unnecessary file. >> - Tweaking javadoc. >> - Reflecting review comments w.r.t. narrowing conversion. >> - Improving checks in getPermittedSubclasses() >> - Merging master into JDK-8246778 >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179 > > src/java.base/share/classes/java/lang/Class.java line 4480: > >> 4478: } >> 4479: >> 4480: private native Class[] getPermittedSubclasses0(); > > Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS: > > - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C > - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C > > I didn't check the VM implementation. > > If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified. The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements. It returns all the classes listed in the PermittedSubclasses attribute that it is able to load. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From jjg at openjdk.java.net Mon Nov 30 23:27:19 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 30 Nov 2020 23:27:19 GMT Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. [v4] In-Reply-To: References: Message-ID: > This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description. > > The goal is to be able to simplify the following common pattern: > > /** > * Returns the result. Optional additional text. > * @return the result > */ > int method() { > > by > > /** > * {@return the result} Optional additional text. > */ > int method() { > > Note: > > * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere. > * The expansion of the inline tag is `Returns " _content_ `.` where _content_ is the content of the tag. > * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description > * The inline tag can be inherited into overriding methods as if it was provided as a block tag. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - fix test - Update for new `@return` tag - Merge remote-tracking branch 'upstream/master' into new-return - Update DocCommentParser to permit nested inline tags in specified cases: @return - Add default impl for new method - Fix test failure - Fix trailing whitespace in test - Merge master - JDK-8075778: Add javadoc tag to avoid duplication of return information in simple situations. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1355/files - new: https://git.openjdk.java.net/jdk/pull/1355/files/87edfb0c..5703d83b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=02-03 Stats: 94833 lines in 875 files changed: 81326 ins; 5628 del; 7879 mod Patch: https://git.openjdk.java.net/jdk/pull/1355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355 PR: https://git.openjdk.java.net/jdk/pull/1355