From hannesw at openjdk.java.net Mon May 3 17:46:17 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 3 May 2021 17:46:17 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v2] In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> Message-ID: <2Cc6LqVTqC76GLlsAHnJj2UaSzVHjkbgvV1WWfI-pWI=.07358df8-81d1-4a12-ab63-8326907baa49@github.com> > This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. Hannes Walln?fer 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: - JDK-8250766: Improve signature normalization and move it to CommentHelper - Merge branch 'master' into JDK-8250766 - JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3754/files - new: https://git.openjdk.java.net/jdk/pull/3754/files/a64598c2..fa29f553 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=00-01 Stats: 7175 lines in 220 files changed: 4625 ins; 1884 del; 666 mod Patch: https://git.openjdk.java.net/jdk/pull/3754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3754/head:pull/3754 PR: https://git.openjdk.java.net/jdk/pull/3754 From hannesw at openjdk.java.net Mon May 3 17:52:12 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 3 May 2021 17:52:12 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v3] In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> Message-ID: <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com> > This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8250766: Add comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3754/files - new: https://git.openjdk.java.net/jdk/pull/3754/files/fa29f553..3284f1ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3754/head:pull/3754 PR: https://git.openjdk.java.net/jdk/pull/3754 From prappo at openjdk.java.net Tue May 4 17:14:53 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 4 May 2021 17:14:53 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v3] In-Reply-To: <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com> References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com> Message-ID: On Mon, 3 May 2021 17:52:12 GMT, Hannes Walln?fer wrote: >> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8250766: Add comments 1. Is whitespace immediately preceding `(` expected to be retained? For example, in @see java.net.URL#URL (java.lang.String, ... 2. Can ReferenceTree.getSignature return null? I dislike unnecessary null checks. 3. The test should also check for whitespace around `,` and `.` ------------- PR: https://git.openjdk.java.net/jdk/pull/3754 From pavel.rappo at oracle.com Tue May 4 18:24:33 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 4 May 2021 18:24:33 +0000 Subject: JEP 413: Code Snippets in Java API Documentation In-Reply-To: References: Message-ID: <19D11146-C5FD-45DA-84CE-EA6AC8C77695@oracle.com> Thanks for relaying that Twitter discussion. Although we've surveyed multiple systems before agreeing on the snippet markup syntax that satisfies the needs of our initial use case, OpenJDK, it is possible that we've missed some important features. What are the important features of AsciiDoc's Tagged Regions that are impossible to achieve with the proposed JavaDoc snippet markup syntax? I would encourage people to reply to this email thread. javadoc-dev at openjdk.java.net is one of the lower traffic OpenJDK mailing lists. One could subscribe to it for the duration of this discussion without concerns of getting too many unrelated notifications. -Pavel > On 30 Apr 2021, at 11:40, Gunnar Morling wrote: > > Hi all, > > It's with great interest that I've learned about JEP 413, I think this will be a great improvement to the user experience of JavaDoc! > > When sharing this online, there was feedback from several folks [1] that alignment for the region selection syntax with that one of AsciiDoc would be desirable [2]. That way, one could easily include the same snippet into JavaDoc and other documentation like a developer guide at the same time. I believe that'd make lots of sense, so I thought I'd relay this feedback here. > > Best, > > --Gunnar > > [1] https://twitter.com/maxandersen/status/1388018227868049408 > [2] https://docs.asciidoctor.org/asciidoc/latest/directives/include-tagged-regions/ > From hannesw at openjdk.java.net Wed May 5 06:41:51 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 06:41:51 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v3] In-Reply-To: <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com> References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com> Message-ID: On Mon, 3 May 2021 17:52:12 GMT, Hannes Walln?fer wrote: >> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8250766: Add comments Thanks for the review, Pavel. > 1. Is whitespace immediately preceding `(` expected to be retained? For example, in > > > ``` > @see java.net.URL#URL > (java.lang.String, > ... > ``` `DocCommentParser#reference` only accepts whitespace within matching `()` or `<>`. A whitespace character before the parentheses as shown above will result in `java.net.URL#URL` being considered the reference and the part in parentheses being considered the label. > > 1. Can ReferenceTree.getSignature return null? I dislike unnecessary null checks. Yes, it can. This is covered by test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java > 2. The test should also check for whitespace around `,` and `.` Good point, I'll add a commit with a test covering these cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/3754 From hannesw at openjdk.java.net Wed May 5 07:40:25 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 07:40:25 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v4] In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> Message-ID: > This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8250766: Additional test for whitespace normalization in @see signature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3754/files - new: https://git.openjdk.java.net/jdk/pull/3754/files/3284f1ae..1a1ee57d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=02-03 Stats: 15 lines in 3 files changed: 11 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3754/head:pull/3754 PR: https://git.openjdk.java.net/jdk/pull/3754 From prappo at openjdk.java.net Wed May 5 10:33:10 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 5 May 2021 10:33:10 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v3] In-Reply-To: References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com> Message-ID: On Wed, 5 May 2021 06:39:14 GMT, Hannes Walln?fer wrote: > `DocCommentParser#reference` only accepts whitespace within matching `()` or `<>`. A whitespace character before the parentheses as shown above will result in `java.net.URL#URL` being considered the reference and the part in parentheses being considered the label. You are absolutely right. I got immersed in CommentHelper.normalizeSignature so much so that I forgot about separating function of whitespace in positional argument parsing. > Yes, it can. This is covered by test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java I think it's an empty string that ReferenceTree.getSignature can return, not null. To check that, I modified DCReference as follows and ran the tests (including TestTagMisuse), which all passed: DCReference(String signature, JCTree.JCExpression moduleName, JCTree qualExpr, Name member, List paramTypes) { - this.signature = signature; + this.signature = Objects.requireNonNull(signature); ------------- PR: https://git.openjdk.java.net/jdk/pull/3754 From prappo at openjdk.java.net Wed May 5 10:33:10 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 5 May 2021 10:33:10 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v4] In-Reply-To: References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> Message-ID: <8xlDt43hoHUYXaGYjS_hqK2yuaekv-J0jiAgCKic1sc=.46e7e829-3f72-42d7-9915-56d76fa79db7@github.com> On Wed, 5 May 2021 07:40:25 GMT, Hannes Walln?fer wrote: >> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8250766: Additional test for whitespace normalization in @see signature Marked as reviewed by prappo (Reviewer). Almost forgot: trivially update the copyright year in CommentHelper before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3754 From hannesw at openjdk.java.net Wed May 5 12:02:15 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 12:02:15 GMT Subject: RFR: JDK-8263507: Improve structure of package summary pages [v4] In-Reply-To: References: Message-ID: > This adds a feature to add sub-navigation links to the package summary page, but ended up more like a refactoring of the code to generate sub-navigation links. The reason for this is that generation of these links was highly idiosyncratic. Every writer class that wanted to create sub-nav links deposited something of itself in the `Navigation` instance which was then responsible for generating these links. The new code introduces a `Navigation.SubNavLinks` interface that allows writers to provide a list of links into their page content. > > As for the new feature in the package summary page itself, I chose an approach that is a bit different from the one we use for other types of pages. Instead of displaying the inactive label instead of the link when a section is not present on the page, only the active links are displayed. The reason for this is that the package summary page contains so many potential summary tables that the sub-nav area gets quite crowded if they are all shown. Just showing the actually present pieces looked better to me. > > Like in other sub-nav sections, the link labels sometimes use abbreviated terms such as "RELATED" instead of "RELATED PACKAGES" and "ENUMS" instead of "ENUM CLASSES". The full list of potential package sub-nav links is as follows: > > Package: Description | Related | Interfaces | Classes | Enums | Records | Exceptions | Errors | Annotations > > An important implementation note is that I moved the code to compute package summary contents from `PackageSummaryBuilder` to `PackageWriterImpl`. The reason for this is that the contents are required to determine which links to create, and I didn't want to re-compute this information that was previously computed on the fly in the builder class. The various summary items are now stored in collection fields in the writer class. > > I have tried to add all the new properties and constants in a sensible place, which usually means alphabetic order within the sub-group of related entries. > > I chose to keep the markup structure of the package summary page mostly unchanged, adding only `id` attributes to the existing `
  • ` elements for each summary table. I decided against adding `class` attributes as well as it seems very unlikely to me that somebody would want to apply different styles to the various summary tables. Even without them, it could be done using the `id`s. Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - JDK-8263507: Convert string constants in Contents to Content objects, rename INNER_CLASSES to NESTED_CLASSES - Merge branch 'master' into JDK-8263507 - JDK-8263507: Update JBS summary - JDK-8263507: Merge classes and interfaces in package summary into one tabbed table - JDK-8263507: Simplify list creation - JDK-8263507: Rename some methods and add some docs - JDK-8263507: Add links to page sections in sub-navigation of package summaries ------------- Changes: https://git.openjdk.java.net/jdk/pull/3413/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3413&range=03 Stats: 1376 lines in 40 files changed: 529 ins; 672 del; 175 mod Patch: https://git.openjdk.java.net/jdk/pull/3413.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3413/head:pull/3413 PR: https://git.openjdk.java.net/jdk/pull/3413 From hannes.wallnoefer at oracle.com Wed May 5 13:14:38 2021 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 5 May 2021 13:14:38 +0000 Subject: RFR: JDK-8263507: Improve structure of package summary pages [v3] In-Reply-To: References: <6XZXNSLtyLhCJ89InQlEzfSqDQGKynahstvpRZGuFbw=.915f8819-9b25-4635-b9c9-c108fa2e997c@github.com> Message-ID: Thanks for the reivew, Jon. Comments inline below. > Am 30.04.2021 um 06:33 schrieb Jonathan Gibbons : > > On Mon, 19 Apr 2021 09:45:27 GMT, Hannes Walln?fer wrote: > >>> This adds a feature to add sub-navigation links to the package summary page, but ended up more like a refactoring of the code to generate sub-navigation links. The reason for this is that generation of these links was highly idiosyncratic. Every writer class that wanted to create sub-nav links deposited something of itself in the `Navigation` instance which was then responsible for generating these links. The new code introduces a `Navigation.SubNavLinks` interface that allows writers to provide a list of links into their page content. >>> >>> As for the new feature in the package summary page itself, I chose an approach that is a bit different from the one we use for other types of pages. Instead of displaying the inactive label instead of the link when a section is not present on the page, only the active links are displayed. The reason for this is that the package summary page contains so many potential summary tables that the sub-nav area gets quite crowded if they are all shown. Just showing the actually present pieces looked better to me. >>> >>> Like in other sub-nav sections, the link labels sometimes use abbreviated terms such as "RELATED" instead of "RELATED PACKAGES" and "ENUMS" instead of "ENUM CLASSES". The full list of potential package sub-nav links is as follows: >>> >>> Package: Description | Related | Interfaces | Classes | Enums | Records | Exceptions | Errors | Annotations >>> >>> An important implementation note is that I moved the code to compute package summary contents from `PackageSummaryBuilder` to `PackageWriterImpl`. The reason for this is that the contents are required to determine which links to create, and I didn't want to re-compute this information that was previously computed on the fly in the builder class. The various summary items are now stored in collection fields in the writer class. >>> >>> I have tried to add all the new properties and constants in a sensible place, which usually means alphabetic order within the sub-group of related entries. >>> >>> I chose to keep the markup structure of the package summary page mostly unchanged, adding only `id` attributes to the existing `
  • ` elements for each summary table. I decided against adding `class` attributes as well as it seems very unlikely to me that somebody would want to apply different styles to the various summary tables. Even without them, it could be done using the `id`s. >> >> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263507: Update JBS summary > > I've read the source changes, but only skimmed through the tests at this point. > > Various suggestions for your consideration or feedback. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java line 125: > >> 123: .addTab(contents.exceptionsString, e -> utils.isException((TypeElement)e)) >> 124: .addTab(contents.errorsString, e -> utils.isError((TypeElement)e)) >> 125: .addTab(contents.annotationTypesString, utils::isAnnotationType); > > I can't say I'm a big fan of the new-style `String` suffix, but I guess it is OK for now; we need a cleanup on the names of members in `Contents` anyway. More comments in `Contents`. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 194: > >> 192: public final String interfacesString; >> 193: public final String packageSummary; >> 194: public final String recordsString; > > The new-style `String` suffix looks weird, and iut's unexpected to see `String` constants here, but, I see the constants were there before, and (worse) I added them! > I guess we generally need to separate these names from equivalent `Content` objects. OK for now, but worth re-examining in a future cleanup. > I pushed a follow-up commit to change all the String constants in Contents.java to Content objects. These constants are used for tab contents in Table.java which take String arguments. For now I just added a #toString() conversion for these usages, but I can file a JBS issue to convert these parameter types to `Content`, which is what they are converted to anyway. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java line 143: > >> 141: // in doclets.properties >> 142: { "doclet.Annotation_Types_Summary", "doclet.Annotation_Interfaces_Summary" }, >> 143: { "doclet.Enum_Summary", "doclet.Enum_Class_Summary" }, > > given you're changing this table, you should at least check manually if not in a test that you get old-style terminology with `--release 16` or older, and new-style terminology with `--release 17` or later. Instead of the removed messages we are now using the pre-existing messages in plural form without the ?Summary? suffix (e.g. ?Enum Classes? instead of ?Enum Class Summary". The test that checks for correct terminology (TestTerminology.java) only covers the singular form of these messages (e.g. ?Enum Class?) so it only makes sure the mechanism is working, not that each and every use in the docs is correct. I manually checked to make sure the correct terminology is used in the affected summary tables. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java line 209: > >> 207: HtmlTree.LI(links.createLink(HtmlIds.SERVICES, contents.navServices, >> 208: displayServices(uses, usesTrees) || displayServices(provides.keySet(), providesTrees))) >> 209: )); > > In general, I like the new `.setSubNavLinks` method. :-) > Do you need the `HtmlTree.LI` wrappers, or is it enough to pass in a list of `links.createLink` calls? > The `HtmlTree.LI` are really internal detail of the subnavbar implementation ... i.e. a `ul` of `li` elements. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 107: > >> 105: * {@return a list of links to display in the sub-navigation area} >> 106: * Links should be wrapped in {@code HtmlTree.LI} elements as they are >> 107: * displayed within an unordered list. > > As noted above, this class could do the wrapping with `LI` elements. Done. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 144: > >> 142: } >> 143: >> 144: public Navigation setMemberSummaryBuilder(MemberSummaryBuilder memberSummaryBuilder) { > > General comment for this and all the following red lines: yay! > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 343: > >> 341: case PACKAGE: >> 342: case CLASS: >> 343: case HELP: > > style comment ... since you're using new-style switch, do you want to do so here as well? > Will do. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 344: > >> 342: case CLASS: >> 343: case HELP: >> 344: List listContents = subNavLinks.getSubNavLinks(); > > I think this looks like where you could stream the list, wrap the entries in `LI` and convert back to a list. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java line 186: > >> 184: packages.addAll(siblings); >> 185: } >> 186: } > > Hmmm, I foresee downstream JBS issues ... "javadoc bug: I added a package to my code and the table disappeared". Should there be a warning and a way to change the limit? (Eventually?) > Quite possible. Different issue though. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java line 260: > >> 258: .addTab(contents.exceptionsString, e -> utils.isException((TypeElement)e)) >> 259: .addTab(contents.errorsString, e -> utils.isError((TypeElement)e)) >> 260: .addTab(contents.annotationTypesString, utils::isAnnotationType); > > should we normalize the `utils.is...` methods so that we do not need the casts? > I looked into it, but ran into sublte issues (many of these methods are implemented by exclusion, which makes their behaviour depend on its parameter type. So I?d prefer to handle this as a separate issue, if we think it?s worth changing. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PackageSummaryWriter.java line 130: > >> 128: * @param summaryContentTree the content tree to which the summaries will be added >> 129: */ >> 130: void addAnnotationTypeSummary(SortedSet annoTypes, Content summaryContentTree); > > Nice cleanup! > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java line 111: > >> 109: >> 110: private static final EnumSet defaultSummarySet = EnumSet.of( >> 111: INNER_CLASSES, FIELDS, CONSTRUCTORS, METHODS); > > Picky, maybe for another time: the correct term is probably `NESTED_CLASSES`. Inner classes are a subset of nested classes that have an `outer` instance. (i.e. they're not `static` nested classes. I changed the name to `NESTED_CLASSES`. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java line 119: > >> 117: FIELDS, CONSTRUCTORS, METHODS); >> 118: private static final EnumSet enumDetailSet = EnumSet.of( >> 119: ENUM_CONSTANTS, FIELDS, METHODS); > > I'm a bit surprised by this, if only because we've had problems with tables like this in the past. > > Is it possible to have a single combined list where some of the entries will give effectively empty tables which can be suppressed? > Not possible here because these are used for the sub-navigation links, so if a table for some kind is empty the link label is still rendered as plain text. So removing this logic from here means we have to filter out member kinds somewhere else (this was done in the many lines of code in `Navigation` that I was able to remove). I prefer to have it sorted at the source. > Case in point for an issue: why does `enumSummarySet` have `INNER_CLASSES` but `annotationSummarySet` does not. > That is a bug that was present before. It is even baked into a test we have. Obviously it is very uncommon to have nested classes in annotation interfaces, or else somebody would have filed a bug. I?ll do that now. > ------------- > > Changes requested by jjg (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3413 From hannesw at openjdk.java.net Wed May 5 13:21:16 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 13:21:16 GMT Subject: RFR: JDK-8263507: Improve structure of package summary pages [v5] In-Reply-To: References: Message-ID: > This adds a feature to add sub-navigation links to the package summary page, but ended up more like a refactoring of the code to generate sub-navigation links. The reason for this is that generation of these links was highly idiosyncratic. Every writer class that wanted to create sub-nav links deposited something of itself in the `Navigation` instance which was then responsible for generating these links. The new code introduces a `Navigation.SubNavLinks` interface that allows writers to provide a list of links into their page content. > > As for the new feature in the package summary page itself, I chose an approach that is a bit different from the one we use for other types of pages. Instead of displaying the inactive label instead of the link when a section is not present on the page, only the active links are displayed. The reason for this is that the package summary page contains so many potential summary tables that the sub-nav area gets quite crowded if they are all shown. Just showing the actually present pieces looked better to me. > > Like in other sub-nav sections, the link labels sometimes use abbreviated terms such as "RELATED" instead of "RELATED PACKAGES" and "ENUMS" instead of "ENUM CLASSES". The full list of potential package sub-nav links is as follows: > > Package: Description | Related | Interfaces | Classes | Enums | Records | Exceptions | Errors | Annotations > > An important implementation note is that I moved the code to compute package summary contents from `PackageSummaryBuilder` to `PackageWriterImpl`. The reason for this is that the contents are required to determine which links to create, and I didn't want to re-compute this information that was previously computed on the fly in the builder class. The various summary items are now stored in collection fields in the writer class. > > I have tried to add all the new properties and constants in a sensible place, which usually means alphabetic order within the sub-group of related entries. > > I chose to keep the markup structure of the package summary page mostly unchanged, adding only `id` attributes to the existing `
  • ` elements for each summary table. I decided against adding `class` attributes as well as it seems very unlikely to me that somebody would want to apply different styles to the various summary tables. Even without them, it could be done using the `id`s. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8263507: More suggested code cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3413/files - new: https://git.openjdk.java.net/jdk/pull/3413/files/4d8233a9..5da06e72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3413&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3413&range=03-04 Stats: 28 lines in 5 files changed: 0 ins; 5 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/3413.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3413/head:pull/3413 PR: https://git.openjdk.java.net/jdk/pull/3413 From hannesw at openjdk.java.net Wed May 5 13:55:11 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 13:55:11 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v3] In-Reply-To: References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> <4lPjUwsX9noVvjiarkaLU0TTSGHoWZwJSNBU2MZkIV0=.097ff10b-783e-4bf7-809b-a117efa8e21e@github.com> Message-ID: On Wed, 5 May 2021 10:27:57 GMT, Pavel Rappo wrote: > > > Yes, it can. This is covered by test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java > > I think it's an empty string that ReferenceTree.getSignature can return, not null. To check that, I modified DCReference as follows and ran the tests (including TestTagMisuse), which all passed: > > ``` > DCReference(String signature, JCTree.JCExpression moduleName, JCTree qualExpr, Name member, List paramTypes) { > - this.signature = signature; > + this.signature = Objects.requireNonNull(signature); > ``` You are right, it is it is not `DCReference` that returns `null` but `CommentHelper#getReferencedSignature`, which returns null as default value if there is no reference object to get the signature from. Among the uses of this method there is one that doesn't do a null check, but there's also one that handles `null` differently than `""`. I don't think the issue is serious enough to warrant a separate bug, so I'll just add the missing null check in my final commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3754 From hannesw at openjdk.java.net Wed May 5 13:55:10 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 13:55:10 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v5] In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> Message-ID: > This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8250766: Add missing null check and update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3754/files - new: https://git.openjdk.java.net/jdk/pull/3754/files/1a1ee57d..13589ffc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3754&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3754/head:pull/3754 PR: https://git.openjdk.java.net/jdk/pull/3754 From hannesw at openjdk.java.net Wed May 5 14:03:52 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 14:03:52 GMT Subject: Integrated: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped In-Reply-To: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> Message-ID: <1J2INMoFZYbNnp3CxTgxrDGe6l7VqIBlyaRMIULaJ1I=.b9963359-eb3d-43e1-a9b7-bfa1e8749c26@github.com> On Wed, 28 Apr 2021 07:47:23 GMT, Hannes Walln?fer wrote: > This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. This pull request has now been integrated. Changeset: f07bb2f4 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/f07bb2f4b986103bba975de29324c7219c14628d Stats: 84 lines in 5 files changed: 69 ins; 3 del; 12 mod 8250766: javadoc adds redundant spaces when @see program element is wrapped Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/3754 From prappo at openjdk.java.net Wed May 5 14:09:53 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 5 May 2021 14:09:53 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v5] In-Reply-To: References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> Message-ID: On Wed, 5 May 2021 13:55:10 GMT, Hannes Walln?fer wrote: >> This changes reference parsing in `DocCommentParser` to normalize whitespace in signatures to a large extent. In particular, multiple whitespace characters are coalesced into a single space character, and whitespace after opening parentheses and angle brackets are suppressed. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8250766: Add missing null check and update copyright year Marked as reviewed by prappo (Reviewer). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 471: > 469: @SuppressWarnings("fallthrough") > 470: private static String normalizeSignature(String sig) { > 471: if (sig == null Consider removing this null check since we've agreed that ReferenceTree.getSignature() does not return null. ------------- PR: https://git.openjdk.java.net/jdk/pull/3754 From hannesw at openjdk.java.net Wed May 5 14:18:52 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 14:18:52 GMT Subject: RFR: JDK-8250766: javadoc adds redundant spaces when @see program element is wrapped [v5] In-Reply-To: References: <7wye6atnCwJUKEfWuXSLLTEmGbDNn6XAFCgNyjvLViQ=.6e136191-2a46-4168-b1c4-a88f4687fb7a@github.com> Message-ID: <4kLUUPWbEh7gBDMT1v4rUZBRYUHiZxkqsyL-9-UUvNI=.e9ed915f-ed03-46c6-833b-cf4983683425@github.com> On Wed, 5 May 2021 14:03:43 GMT, Pavel Rappo wrote: > Consider removing this null check since we've agreed that ReferenceTree.getSignature() does not return null. Argh... I was all the time thinking about the `Objects.requireNonNullElse` null check in `HtmlDocletWriter`, not this one. Yes, you are absolutely right, this one is superfluous... Unfortunately I already integrated the PR. I guess I can remove it in a future commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3754 From hannesw at openjdk.java.net Wed May 5 15:09:17 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 5 May 2021 15:09:17 GMT Subject: RFR: JDK-8262992: Improve `@see` output [v6] In-Reply-To: References: Message-ID: > This changes the output for `@see` tags to a `
      ` structure. A different CSS style is used if any of the `@see` tag labels are longer than 30 characters or contain a comma. > > The layout for the default CSS style is similar to the one we had so far with multiple links displayed inline and separated by commas. The CSS style for lists containing longer labels displays the list in block mode, but still separated by commas and without list markers. Note that the commas are generated via CSS in both cases. > > As expected, there's a lot of test churn with this change. I converted some tests to text blocks that were still using old style string concatenation. In `TestSingletonLists.java` I had to exclude `@see` lists from the singleton check as javadoc generates a "See also" item for constant field values. Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into JDK-8262992 - Put enum constants into alphabetical order. - Adapt new test - Merge branch 'master' into JDK-8262992 - Update `@see` tag in class java.security.cert.PKIXRevocationChecker - JDK-8262992: Improve `@see` output ------------- Changes: https://git.openjdk.java.net/jdk/pull/2894/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2894&range=05 Stats: 414 lines in 23 files changed: 187 ins; 20 del; 207 mod Patch: https://git.openjdk.java.net/jdk/pull/2894.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2894/head:pull/2894 PR: https://git.openjdk.java.net/jdk/pull/2894 From hannesw at openjdk.java.net Thu May 6 09:51:13 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 6 May 2021 09:51:13 GMT Subject: RFR: JDK-8266044: Nested class summary should show kind of class or interface Message-ID: <5jbEly2F3iKCQzkjlDef3-yZt5IyIOiH6zdCdszlDCo=.6f13069f-b7fb-4b87-b6a4-7ffae5515e2c@github.com> This is a simple fix to display the actual kind of nested class in the nested class summary table. This is not using `Utils#getTypeElementKindName` since we want to display the signature-like source level kind name (e.g. "enum" rather than "enum class"). ------------- Commit messages: - JDK-8266044: Nested class summary should show kind of class or interface Changes: https://git.openjdk.java.net/jdk/pull/3897/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3897&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266044 Stats: 11 lines in 2 files changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3897.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3897/head:pull/3897 PR: https://git.openjdk.java.net/jdk/pull/3897 From jjg at openjdk.java.net Thu May 6 14:31:56 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 6 May 2021 14:31:56 GMT Subject: RFR: JDK-8266044: Nested class summary should show kind of class or interface In-Reply-To: <5jbEly2F3iKCQzkjlDef3-yZt5IyIOiH6zdCdszlDCo=.6f13069f-b7fb-4b87-b6a4-7ffae5515e2c@github.com> References: <5jbEly2F3iKCQzkjlDef3-yZt5IyIOiH6zdCdszlDCo=.6f13069f-b7fb-4b87-b6a4-7ffae5515e2c@github.com> Message-ID: On Thu, 6 May 2021 09:44:44 GMT, Hannes Walln?fer wrote: > This is a simple fix to display the actual kind of nested class in the nested class summary table. This is not using `Utils#getTypeElementKindName` since we want to display the signature-like source level kind name (e.g. "enum" rather than "enum class"). Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3897 From jjg at openjdk.java.net Thu May 6 14:50:56 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 6 May 2021 14:50:56 GMT Subject: RFR: JDK-8232644: bugs in serialized-form.html In-Reply-To: <8-UfnGEMuEtXC-ysMz6gDEFHCi1XO_yuW8nah5YlxUI=.9f6a7196-ceff-41dd-91da-6b05136b53a6@github.com> References: <8-UfnGEMuEtXC-ysMz6gDEFHCi1XO_yuW8nah5YlxUI=.9f6a7196-ceff-41dd-91da-6b05136b53a6@github.com> Message-ID: On Fri, 30 Apr 2021 14:06:13 GMT, Hannes Walln?fer wrote: > This implements most suggestions implemented in the JBS issue. The heading for class entries in the page is shortened to " ", followed by a simplified signature line like "class X extends Y implements Serializable". > > Furthermore, package names in package headings now link to the package page, `@param` info is added to the methods, Externalizable is used for classes that implement it. I also added a check for content in `@serial` tags to avoid spurious empty ` ` lines in the output. > > I increased the font size for headings `h4` to `h6` in the stylesheets because their size was smaller than the default text size, which looked strange. Although the change in font size from `h3` to `h4` and beyond is now smaller I think it's still recognizable. Headings `h4` to `h5` are used very little in Javadoc (mostly static doc files and the serialized-form page). I looked at some of the static files and they looked good to me with the new larger heading fonts. > > Although I didn't end up using the `Signatures` class to generate the class signatures (they're just too simple and too specific in what they list), I left in some cleanup of `Signatures.TypeSignature`, most significantly moving the processing of modifiers from `ClassWriterImpl` to `Signatures.TypeSignature`. > > I only removed the obsolete resources from the English resource file out of habit of not touching the Chinese and Japanese ones. I guess I could remove it there too. Generally: wow, very nice cleanup! That being said, there is a potential conflict/race with a separate review to make sealed cases permanent (not preview.) So, this is approved, with a warning to coordinate with @vicente-romero-oracle about the sealed classes review https://github.com/openjdk/jdk/pull/3613 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 101: > 99: > 100: private static final Set previewModifiers > 101: = Set.of("sealed", "non-sealed"); This needs to be coordinated with the work to make sealed final. In the changes for that, this set is now empty but the code to process the set (lines 110-126) remains, ready for any future preview modifiers. Also, given this code exists elsewhere, we should probably try and pull it in to a shared method. That being said, Signatures is probably conceptually the right place for the shared method (not Utils.) Also, whether or not we make a shared method, we should probably add an explanatory comment explaining why we keep an empty set around, just in case. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 496: > 494: > 495: @SuppressWarnings("preview") > 496: public String modifiersToString(Element e) { Thinking aloud, would this method be better in Signatures? Maybe later... ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3817 From hannesw at openjdk.java.net Thu May 6 14:52:51 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 6 May 2021 14:52:51 GMT Subject: RFR: JDK-8265042: javadoc HTML files not generated for types nested in records In-Reply-To: References: Message-ID: <7rn7gBt6rFwiV2HBgdp_Q0EpzwEz6sNxaZSQINJMcIY=.32470bc9-85f4-4b49-9f33-d1d8e66a682f@github.com> On Fri, 30 Apr 2021 16:39:14 GMT, Jonathan Gibbons wrote: > This addresses an oversight in the support for records. > > The fix could have been as simple as a one-word addition to a list of element kinds to check for nested classes. However, instead of that, the fix is more of a cleanup of a group of methods in `Utils` to fix this issue and to reduce the likelihood of anything similar happening again, when the next new kind of class is added. > > The cleanup uses new code idioms using lambdas, predicates, and generic methods to replace varargs and temporary sets and copying lists. The naming is somewhat cleaned up as well, but it was a self-imposed restriction that the cleanup is limited to the `Utils` class, and does not leak into clients of the class. > > There is a core `getItems` method which is somewhat multi-purpose, supporting recursive and non-recursive use, and examining either just documented members or all members, including members that are not directly documented. (The latter occurs mostly in serialization.) It is possible there is a future refactoring to further improve this method, perhaps to break it into different methods. With that in mind, the signature of some methods was narrowed from accepting any `Element` to a specific kind of element: generally, one of `PackageElement` or `TypeElement`. > > A new test is provided that checks that all the expected files are generated for various kinds of nested classes and interfaces in all kinds of classes and interfaces. The test is designed to fail if a new kind of class or interface is added in future without a corresponding update to the test. I like both the predicate/lambda based methods and the new test a lot! I found some bits that should be cleaned up before integrating. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2149: > 2147: for (TypeElement c : classes) { > 2148: list.addAll(getItems0(c, all, filter, clazz)); > 2149: recursiveGetItems(list, c, all, filter, clazz); It seems you are adding these items twice, directly in the first line of the loop and then again in the recursive invocation. (I think this was carried over from the prior implementation.) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2159: > 2157: * @param select the predicate for the selected members > 2158: * @param clazz the class of the filtered members > 2159: * @param the class of the filtered members Parameter documentation in this and other new methods above is a bit messy/wrong. For example, the `boolean all` is not documented anywhere, and `` is documented as a parameter. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2166: > 2164: return e.getEnclosedElements().stream() > 2165: .filter(e_ -> select.test(e_) && (all || shouldDocument(e_))) > 2166: .map(ee -> clazz.cast(ee)) Could be written as method reference. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3821 From hannesw at openjdk.java.net Thu May 6 14:57:53 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 6 May 2021 14:57:53 GMT Subject: Integrated: JDK-8266044: Nested class summary should show kind of class or interface In-Reply-To: <5jbEly2F3iKCQzkjlDef3-yZt5IyIOiH6zdCdszlDCo=.6f13069f-b7fb-4b87-b6a4-7ffae5515e2c@github.com> References: <5jbEly2F3iKCQzkjlDef3-yZt5IyIOiH6zdCdszlDCo=.6f13069f-b7fb-4b87-b6a4-7ffae5515e2c@github.com> Message-ID: On Thu, 6 May 2021 09:44:44 GMT, Hannes Walln?fer wrote: > This is a simple fix to display the actual kind of nested class in the nested class summary table. This is not using `Utils#getTypeElementKindName` since we want to display the signature-like source level kind name (e.g. "enum" rather than "enum class"). This pull request has now been integrated. Changeset: 2dcbedf9 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/2dcbedf92a31da55299607c006821f22cc72ac0a Stats: 11 lines in 2 files changed: 6 ins; 0 del; 5 mod 8266044: Nested class summary should show kind of class or interface Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/3897 From hannesw at openjdk.java.net Thu May 6 15:12:50 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 6 May 2021 15:12:50 GMT Subject: RFR: JDK-8232644: bugs in serialized-form.html In-Reply-To: References: <8-UfnGEMuEtXC-ysMz6gDEFHCi1XO_yuW8nah5YlxUI=.9f6a7196-ceff-41dd-91da-6b05136b53a6@github.com> Message-ID: On Thu, 6 May 2021 14:37:11 GMT, Jonathan Gibbons wrote: >> This implements most suggestions implemented in the JBS issue. The heading for class entries in the page is shortened to " ", followed by a simplified signature line like "class X extends Y implements Serializable". >> >> Furthermore, package names in package headings now link to the package page, `@param` info is added to the methods, Externalizable is used for classes that implement it. I also added a check for content in `@serial` tags to avoid spurious empty ` ` lines in the output. >> >> I increased the font size for headings `h4` to `h6` in the stylesheets because their size was smaller than the default text size, which looked strange. Although the change in font size from `h3` to `h4` and beyond is now smaller I think it's still recognizable. Headings `h4` to `h5` are used very little in Javadoc (mostly static doc files and the serialized-form page). I looked at some of the static files and they looked good to me with the new larger heading fonts. >> >> Although I didn't end up using the `Signatures` class to generate the class signatures (they're just too simple and too specific in what they list), I left in some cleanup of `Signatures.TypeSignature`, most significantly moving the processing of modifiers from `ClassWriterImpl` to `Signatures.TypeSignature`. >> >> I only removed the obsolete resources from the English resource file out of habit of not touching the Chinese and Japanese ones. I guess I could remove it there too. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 101: > >> 99: >> 100: private static final Set previewModifiers >> 101: = Set.of("sealed", "non-sealed"); > > This needs to be coordinated with the work to make sealed final. > In the changes for that, this set is now empty but the code to process the set (lines 110-126) remains, ready for any future preview modifiers. > > Also, given this code exists elsewhere, we should probably try and pull it in to a shared method. That being said, Signatures is probably conceptually the right place for the shared method (not Utils.) > > Also, whether or not we make a shared method, we should probably add an explanatory comment explaining why we keep an empty set around, just in case. > Generally: wow, very nice cleanup! > > That being said, there is a potential conflict/race with a separate review to make sealed cases permanent (not preview.) So, this is approved, with a warning to coordinate with @vicente-romero-oracle about the sealed classes review #3613 Thanks for the review, Jon. @vicente-romero-oracle please go ahead with your PR, I'll update mine afterwards. (I should have been aware you were removing these sealed preview bits.) ------------- PR: https://git.openjdk.java.net/jdk/pull/3817 From jjg at openjdk.java.net Thu May 6 15:16:57 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 6 May 2021 15:16:57 GMT Subject: RFR: JDK-8263507: Improve structure of package summary pages [v5] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 13:21:16 GMT, Hannes Walln?fer wrote: >> This adds a feature to add sub-navigation links to the package summary page, but ended up more like a refactoring of the code to generate sub-navigation links. The reason for this is that generation of these links was highly idiosyncratic. Every writer class that wanted to create sub-nav links deposited something of itself in the `Navigation` instance which was then responsible for generating these links. The new code introduces a `Navigation.SubNavLinks` interface that allows writers to provide a list of links into their page content. >> >> As for the new feature in the package summary page itself, I chose an approach that is a bit different from the one we use for other types of pages. Instead of displaying the inactive label instead of the link when a section is not present on the page, only the active links are displayed. The reason for this is that the package summary page contains so many potential summary tables that the sub-nav area gets quite crowded if they are all shown. Just showing the actually present pieces looked better to me. >> >> Like in other sub-nav sections, the link labels sometimes use abbreviated terms such as "RELATED" instead of "RELATED PACKAGES" and "ENUMS" instead of "ENUM CLASSES". The full list of potential package sub-nav links is as follows: >> >> Package: Description | Related | Interfaces | Classes | Enums | Records | Exceptions | Errors | Annotations >> >> An important implementation note is that I moved the code to compute package summary contents from `PackageSummaryBuilder` to `PackageWriterImpl`. The reason for this is that the contents are required to determine which links to create, and I didn't want to re-compute this information that was previously computed on the fly in the builder class. The various summary items are now stored in collection fields in the writer class. >> >> I have tried to add all the new properties and constants in a sensible place, which usually means alphabetic order within the sub-group of related entries. >> >> I chose to keep the markup structure of the package summary page mostly unchanged, adding only `id` attributes to the existing `
    • ` elements for each summary table. I decided against adding `class` attributes as well as it seems very unlikely to me that somebody would want to apply different styles to the various summary tables. Even without them, it could be done using the `id`s. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263507: More suggested code cleanup Generally good. There are some minor suggestions for additional cleanup, but we could file those for later and declare victory. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java line 125: > 123: .addTab(contents.exceptions.toString(), e -> utils.isException((TypeElement)e)) > 124: .addTab(contents.errors.toString(), e -> utils.isError((TypeElement)e)) > 125: .addTab(contents.annotationTypes.toString(), utils::isAnnotationType); Maybe the `*Tab` methods could be overloaded to accept `Content` ? Maybe later cleanup? What does `.toString()` do in the malformed case of providing an `HtmlTree` ... should there be a method on `Content`? Maybe later cleanup? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java line 98: > 96: protected void addPackages(Content content) { > 97: Table table = new Table(HtmlStyle.summaryTable) > 98: .setCaption(Text.of(contents.packageSummaryLabel.toString())) This seems a weird round trip: `Text.of(contents.packageSummaryLabel.toString()` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 193: > 191: public final String packageSummary; > 192: public final String recordSummary; > 193: ?? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 606: > 604: > 605: public boolean isOrdinaryClass(TypeElement te) { > 606: if (isEnum(te) || isInterface(te) || isAnnotationType(te) || isRecord(te)) { For your consideration ... thinking aloud, this could be done in a way that is better protected against future changes by if (elementUtils.isClass(te) && te.getKind() != ElementKind.CLASS || elementUtils.isInterface(te) && te.getKind() != ElementKind.INTERFACE) return false; } ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3413 From vromero at openjdk.java.net Thu May 6 19:12:37 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 6 May 2021 19:12:37 GMT Subject: RFR: 8265684: implement Sealed Classes as a standard feature in Java, javadoc changes [v8] In-Reply-To: References: Message-ID: <23ZdhTZQ4Ga9h7K5tNj643QtxliRJuYkm1CCcHKyIjQ=.30b3d0cb-0abc-4be8-bad3-15b486bbdc91@github.com> > Please review the javadoc related changes to make sealed classes a final feature in Java. The patch is mostly removing preview features related code that is not necessary anymore in javadoc. > > TIA 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 ten additional commits since the last revision: - Merge branch 'master' into JDK-8265684 - fixing indentation: review comment - Merge branch 'master' into JDK-8265684 - addressing indentation issues - Merge branch 'master' into JDK-8265684 - additional commit addressing review comments - addressing review comments - Merge branch 'master' into JDK-8265684 - 8265684: implement Sealed Classes as a standard feature in Java, javadoc changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3613/files - new: https://git.openjdk.java.net/jdk/pull/3613/files/688d5647..875a7ed8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3613&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3613&range=06-07 Stats: 18908 lines in 391 files changed: 9887 ins; 4814 del; 4207 mod Patch: https://git.openjdk.java.net/jdk/pull/3613.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3613/head:pull/3613 PR: https://git.openjdk.java.net/jdk/pull/3613 From jjg at openjdk.java.net Thu May 6 19:54:01 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 6 May 2021 19:54:01 GMT Subject: RFR: 8265684: implement Sealed Classes as a standard feature in Java, javadoc changes [v8] In-Reply-To: <23ZdhTZQ4Ga9h7K5tNj643QtxliRJuYkm1CCcHKyIjQ=.30b3d0cb-0abc-4be8-bad3-15b486bbdc91@github.com> References: <23ZdhTZQ4Ga9h7K5tNj643QtxliRJuYkm1CCcHKyIjQ=.30b3d0cb-0abc-4be8-bad3-15b486bbdc91@github.com> Message-ID: On Thu, 6 May 2021 19:12:37 GMT, Vicente Romero wrote: >> Please review the javadoc related changes to make sealed classes a final feature in Java. The patch is mostly removing preview features related code that is not necessary anymore in javadoc. >> >> TIA > > 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 ten additional commits since the last revision: > > - Merge branch 'master' into JDK-8265684 > - fixing indentation: review comment > - Merge branch 'master' into JDK-8265684 > - addressing indentation issues > - Merge branch 'master' into JDK-8265684 > - additional commit addressing review comments > - addressing review comments > - Merge branch 'master' into JDK-8265684 > - 8265684: implement Sealed Classes as a standard feature in Java, javadoc changes Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3613 From jjg at openjdk.java.net Thu May 6 20:12:58 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 6 May 2021 20:12:58 GMT Subject: RFR: JDK-8262992: Improve `@see` output [v6] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 15:09:17 GMT, Hannes Walln?fer wrote: >> This changes the output for `@see` tags to a `
        ` structure. A different CSS style is used if any of the `@see` tag labels are longer than 30 characters or contain a comma. >> >> The layout for the default CSS style is similar to the one we had so far with multiple links displayed inline and separated by commas. The CSS style for lists containing longer labels displays the list in block mode, but still separated by commas and without list markers. Note that the commas are generated via CSS in both cases. >> >> As expected, there's a lot of test churn with this change. I converted some tests to text blocks that were still using old style string concatenation. In `TestSingletonLists.java` I had to exclude `@see` lists from the singleton check as javadoc generates a "See also" item for constant field values. > > Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into JDK-8262992 > - Put enum constants into alphabetical order. > - Adapt new test > - Merge branch 'master' into JDK-8262992 > - Update `@see` tag in class java.security.cert.PKIXRevocationChecker > - JDK-8262992: Improve `@see` output Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2894 From jjg at openjdk.java.net Fri May 7 03:37:50 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 7 May 2021 03:37:50 GMT Subject: RFR: JDK-8265042: javadoc HTML files not generated for types nested in records In-Reply-To: <7rn7gBt6rFwiV2HBgdp_Q0EpzwEz6sNxaZSQINJMcIY=.32470bc9-85f4-4b49-9f33-d1d8e66a682f@github.com> References: <7rn7gBt6rFwiV2HBgdp_Q0EpzwEz6sNxaZSQINJMcIY=.32470bc9-85f4-4b49-9f33-d1d8e66a682f@github.com> Message-ID: On Thu, 6 May 2021 13:34:17 GMT, Hannes Walln?fer wrote: >> This addresses an oversight in the support for records. >> >> The fix could have been as simple as a one-word addition to a list of element kinds to check for nested classes. However, instead of that, the fix is more of a cleanup of a group of methods in `Utils` to fix this issue and to reduce the likelihood of anything similar happening again, when the next new kind of class is added. >> >> The cleanup uses new code idioms using lambdas, predicates, and generic methods to replace varargs and temporary sets and copying lists. The naming is somewhat cleaned up as well, but it was a self-imposed restriction that the cleanup is limited to the `Utils` class, and does not leak into clients of the class. >> >> There is a core `getItems` method which is somewhat multi-purpose, supporting recursive and non-recursive use, and examining either just documented members or all members, including members that are not directly documented. (The latter occurs mostly in serialization.) It is possible there is a future refactoring to further improve this method, perhaps to break it into different methods. With that in mind, the signature of some methods was narrowed from accepting any `Element` to a specific kind of element: generally, one of `PackageElement` or `TypeElement`. >> >> A new test is provided that checks that all the expected files are generated for various kinds of nested classes and interfaces in all kinds of classes and interfaces. The test is designed to fail if a new kind of class or interface is added in future without a corresponding update to the test. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2159: > >> 2157: * @param select the predicate for the selected members >> 2158: * @param clazz the class of the filtered members >> 2159: * @param the class of the filtered members > > Parameter documentation in this and other new methods above is a bit messy/wrong. For example, the `boolean all` is not documented anywhere, and `` is documented as a parameter. Will fix the docs for `all`. `` is supposed to be documented when it is in the signature of a generic method. ------------- PR: https://git.openjdk.java.net/jdk/pull/3821 From jjg at openjdk.java.net Fri May 7 04:09:24 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 7 May 2021 04:09:24 GMT Subject: RFR: JDK-8265042: javadoc HTML files not generated for types nested in records [v2] In-Reply-To: References: Message-ID: > This addresses an oversight in the support for records. > > The fix could have been as simple as a one-word addition to a list of element kinds to check for nested classes. However, instead of that, the fix is more of a cleanup of a group of methods in `Utils` to fix this issue and to reduce the likelihood of anything similar happening again, when the next new kind of class is added. > > The cleanup uses new code idioms using lambdas, predicates, and generic methods to replace varargs and temporary sets and copying lists. The naming is somewhat cleaned up as well, but it was a self-imposed restriction that the cleanup is limited to the `Utils` class, and does not leak into clients of the class. > > There is a core `getItems` method which is somewhat multi-purpose, supporting recursive and non-recursive use, and examining either just documented members or all members, including members that are not directly documented. (The latter occurs mostly in serialization.) It is possible there is a future refactoring to further improve this method, perhaps to break it into different methods. With that in mind, the signature of some methods was narrowed from accepting any `Element` to a specific kind of element: generally, one of `PackageElement` or `TypeElement`. > > A new test is provided that checks that all the expected files are generated for various kinds of nested classes and interfaces in all kinds of classes and interfaces. The test is designed to fail if a new kind of class or interface is added in future without a corresponding update to the test. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3821/files - new: https://git.openjdk.java.net/jdk/pull/3821/files/23940d05..39014cab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3821&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3821&range=00-01 Stats: 12 lines in 1 file changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3821/head:pull/3821 PR: https://git.openjdk.java.net/jdk/pull/3821 From jjg at openjdk.java.net Fri May 7 04:12:53 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 7 May 2021 04:12:53 GMT Subject: RFR: JDK-8265042: javadoc HTML files not generated for types nested in records [v2] In-Reply-To: <7rn7gBt6rFwiV2HBgdp_Q0EpzwEz6sNxaZSQINJMcIY=.32470bc9-85f4-4b49-9f33-d1d8e66a682f@github.com> References: <7rn7gBt6rFwiV2HBgdp_Q0EpzwEz6sNxaZSQINJMcIY=.32470bc9-85f4-4b49-9f33-d1d8e66a682f@github.com> Message-ID: On Thu, 6 May 2021 13:47:13 GMT, Hannes Walln?fer wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2149: > >> 2147: for (TypeElement c : classes) { >> 2148: list.addAll(getItems0(c, all, filter, clazz)); >> 2149: recursiveGetItems(list, c, all, filter, clazz); > > It seems you are adding these items twice, directly in the first line of the loop and then again in the recursive invocation. (I think this was carried over from the prior implementation.) fixed > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2166: > >> 2164: return e.getEnclosedElements().stream() >> 2165: .filter(e_ -> select.test(e_) && (all || shouldDocument(e_))) >> 2166: .map(ee -> clazz.cast(ee)) > > Could be written as method reference. done ------------- PR: https://git.openjdk.java.net/jdk/pull/3821 From hannesw at openjdk.java.net Fri May 7 10:43:00 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 7 May 2021 10:43:00 GMT Subject: RFR: JDK-8263507: Improve structure of package summary pages [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 14:54:11 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263507: More suggested code cleanup > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java line 125: > >> 123: .addTab(contents.exceptions.toString(), e -> utils.isException((TypeElement)e)) >> 124: .addTab(contents.errors.toString(), e -> utils.isError((TypeElement)e)) >> 125: .addTab(contents.annotationTypes.toString(), utils::isAnnotationType); > > Maybe the `*Tab` methods could be overloaded to accept `Content` ? Maybe later cleanup? > What does `.toString()` do in the malformed case of providing an `HtmlTree` ... should there be a method on `Content`? Maybe later cleanup? The `*Tab` methods could and should be converted to accept `Content`. I didn't want to pack too many unrelated changes into this issue so I have filed a separate one for it: https://bugs.openjdk.java.net/browse/JDK-8266651 ------------- PR: https://git.openjdk.java.net/jdk/pull/3413 From hannesw at openjdk.java.net Fri May 7 10:46:56 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 7 May 2021 10:46:56 GMT Subject: Integrated: JDK-8263507: Improve structure of package summary pages In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 12:20:09 GMT, Hannes Walln?fer wrote: > This adds a feature to add sub-navigation links to the package summary page, but ended up more like a refactoring of the code to generate sub-navigation links. The reason for this is that generation of these links was highly idiosyncratic. Every writer class that wanted to create sub-nav links deposited something of itself in the `Navigation` instance which was then responsible for generating these links. The new code introduces a `Navigation.SubNavLinks` interface that allows writers to provide a list of links into their page content. > > As for the new feature in the package summary page itself, I chose an approach that is a bit different from the one we use for other types of pages. Instead of displaying the inactive label instead of the link when a section is not present on the page, only the active links are displayed. The reason for this is that the package summary page contains so many potential summary tables that the sub-nav area gets quite crowded if they are all shown. Just showing the actually present pieces looked better to me. > > Like in other sub-nav sections, the link labels sometimes use abbreviated terms such as "RELATED" instead of "RELATED PACKAGES" and "ENUMS" instead of "ENUM CLASSES". The full list of potential package sub-nav links is as follows: > > Package: Description | Related | Interfaces | Classes | Enums | Records | Exceptions | Errors | Annotations > > An important implementation note is that I moved the code to compute package summary contents from `PackageSummaryBuilder` to `PackageWriterImpl`. The reason for this is that the contents are required to determine which links to create, and I didn't want to re-compute this information that was previously computed on the fly in the builder class. The various summary items are now stored in collection fields in the writer class. > > I have tried to add all the new properties and constants in a sensible place, which usually means alphabetic order within the sub-group of related entries. > > I chose to keep the markup structure of the package summary page mostly unchanged, adding only `id` attributes to the existing `
      • ` elements for each summary table. I decided against adding `class` attributes as well as it seems very unlikely to me that somebody would want to apply different styles to the various summary tables. Even without them, it could be done using the `id`s. This pull request has now been integrated. Changeset: d2b53509 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/d2b53509c0f6b8c6fd0a34ccdd7ad630af0db93a Stats: 1381 lines in 40 files changed: 529 ins; 677 del; 175 mod 8263507: Improve structure of package summary pages Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/3413 From hannesw at openjdk.java.net Fri May 7 10:49:04 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 7 May 2021 10:49:04 GMT Subject: Integrated: JDK-8262992: Improve `@see` output In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 15:04:35 GMT, Hannes Walln?fer wrote: > This changes the output for `@see` tags to a `
          ` structure. A different CSS style is used if any of the `@see` tag labels are longer than 30 characters or contain a comma. > > The layout for the default CSS style is similar to the one we had so far with multiple links displayed inline and separated by commas. The CSS style for lists containing longer labels displays the list in block mode, but still separated by commas and without list markers. Note that the commas are generated via CSS in both cases. > > As expected, there's a lot of test churn with this change. I converted some tests to text blocks that were still using old style string concatenation. In `TestSingletonLists.java` I had to exclude `@see` lists from the singleton check as javadoc generates a "See also" item for constant field values. This pull request has now been integrated. Changeset: e0c86884 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/e0c86884e56c0f826f7c1626abdcbb9926b297fb Stats: 414 lines in 23 files changed: 187 ins; 20 del; 207 mod 8262992: Improve `@see` output Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/2894 From hannesw at openjdk.java.net Fri May 7 13:38:46 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 7 May 2021 13:38:46 GMT Subject: RFR: JDK-8232644: bugs in serialized-form.html [v2] In-Reply-To: <8-UfnGEMuEtXC-ysMz6gDEFHCi1XO_yuW8nah5YlxUI=.9f6a7196-ceff-41dd-91da-6b05136b53a6@github.com> References: <8-UfnGEMuEtXC-ysMz6gDEFHCi1XO_yuW8nah5YlxUI=.9f6a7196-ceff-41dd-91da-6b05136b53a6@github.com> Message-ID: <3scTtxzJMbzWY5G4OuA0aYNoVGcnhM-UiXzLk99Sbjo=.c1248fd5-4b80-4eb8-82f1-c94e14eceeb1@github.com> > This implements most suggestions implemented in the JBS issue. The heading for class entries in the page is shortened to " ", followed by a simplified signature line like "class X extends Y implements Serializable". > > Furthermore, package names in package headings now link to the package page, `@param` info is added to the methods, Externalizable is used for classes that implement it. I also added a check for content in `@serial` tags to avoid spurious empty ` ` lines in the output. > > I increased the font size for headings `h4` to `h6` in the stylesheets because their size was smaller than the default text size, which looked strange. Although the change in font size from `h3` to `h4` and beyond is now smaller I think it's still recognizable. Headings `h4` to `h5` are used very little in Javadoc (mostly static doc files and the serialized-form page). I looked at some of the static files and they looked good to me with the new larger heading fonts. > > Although I didn't end up using the `Signatures` class to generate the class signatures (they're just too simple and too specific in what they list), I left in some cleanup of `Signatures.TypeSignature`, most significantly moving the processing of modifiers from `ClassWriterImpl` to `Signatures.TypeSignature`. > > I only removed the obsolete resources from the English resource file out of habit of not touching the Chinese and Japanese ones. I guess I could remove it there too. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8232644: Back out of signature cleanup conflicting with sealed classes changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3817/files - new: https://git.openjdk.java.net/jdk/pull/3817/files/9a9e4a49..092af734 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3817&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3817&range=00-01 Stats: 70 lines in 5 files changed: 26 ins; 17 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/3817.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3817/head:pull/3817 PR: https://git.openjdk.java.net/jdk/pull/3817 From hannesw at openjdk.java.net Fri May 7 13:55:02 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 7 May 2021 13:55:02 GMT Subject: RFR: JDK-8232644: bugs in serialized-form.html [v2] In-Reply-To: <3scTtxzJMbzWY5G4OuA0aYNoVGcnhM-UiXzLk99Sbjo=.c1248fd5-4b80-4eb8-82f1-c94e14eceeb1@github.com> References: <8-UfnGEMuEtXC-ysMz6gDEFHCi1XO_yuW8nah5YlxUI=.9f6a7196-ceff-41dd-91da-6b05136b53a6@github.com> <3scTtxzJMbzWY5G4OuA0aYNoVGcnhM-UiXzLk99Sbjo=.c1248fd5-4b80-4eb8-82f1-c94e14eceeb1@github.com> Message-ID: On Fri, 7 May 2021 13:38:46 GMT, Hannes Walln?fer wrote: >> This implements most suggestions implemented in the JBS issue. The heading for class entries in the page is shortened to " ", followed by a simplified signature line like "class X extends Y implements Serializable". >> >> Furthermore, package names in package headings now link to the package page, `@param` info is added to the methods, Externalizable is used for classes that implement it. I also added a check for content in `@serial` tags to avoid spurious empty ` ` lines in the output. >> >> I increased the font size for headings `h4` to `h6` in the stylesheets because their size was smaller than the default text size, which looked strange. Although the change in font size from `h3` to `h4` and beyond is now smaller I think it's still recognizable. Headings `h4` to `h5` are used very little in Javadoc (mostly static doc files and the serialized-form page). I looked at some of the static files and they looked good to me with the new larger heading fonts. >> >> Although I didn't end up using the `Signatures` class to generate the class signatures (they're just too simple and too specific in what they list), I left in some cleanup of `Signatures.TypeSignature`, most significantly moving the processing of modifiers from `ClassWriterImpl` to `Signatures.TypeSignature`. >> >> I only removed the obsolete resources from the English resource file out of habit of not touching the Chinese and Japanese ones. I guess I could remove it there too. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8232644: Back out of signature cleanup conflicting with sealed classes changes I decided to back out of the signature/preview related cleanup changes in this PR, which are unrelated to the actual issue. I'll file a separate issue for the signature cleanup. The remaining changes are identical to the reviewed changes and should not conflict with any other pending PRs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3817 From jjg at openjdk.java.net Fri May 7 14:54:10 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 7 May 2021 14:54:10 GMT Subject: Integrated: JDK-8265042: javadoc HTML files not generated for types nested in records In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 16:39:14 GMT, Jonathan Gibbons wrote: > This addresses an oversight in the support for records. > > The fix could have been as simple as a one-word addition to a list of element kinds to check for nested classes. However, instead of that, the fix is more of a cleanup of a group of methods in `Utils` to fix this issue and to reduce the likelihood of anything similar happening again, when the next new kind of class is added. > > The cleanup uses new code idioms using lambdas, predicates, and generic methods to replace varargs and temporary sets and copying lists. The naming is somewhat cleaned up as well, but it was a self-imposed restriction that the cleanup is limited to the `Utils` class, and does not leak into clients of the class. > > There is a core `getItems` method which is somewhat multi-purpose, supporting recursive and non-recursive use, and examining either just documented members or all members, including members that are not directly documented. (The latter occurs mostly in serialization.) It is possible there is a future refactoring to further improve this method, perhaps to break it into different methods. With that in mind, the signature of some methods was narrowed from accepting any `Element` to a specific kind of element: generally, one of `PackageElement` or `TypeElement`. > > A new test is provided that checks that all the expected files are generated for various kinds of nested classes and interfaces in all kinds of classes and interfaces. The test is designed to fail if a new kind of class or interface is added in future without a corresponding update to the test. This pull request has now been integrated. Changeset: 947d69df Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/947d69df045fa97f56f4eeb5de7f338e169441fc Stats: 490 lines in 2 files changed: 270 ins; 105 del; 115 mod 8265042: javadoc HTML files not generated for types nested in records Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/3821 From hannesw at openjdk.java.net Fri May 7 15:37:59 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 7 May 2021 15:37:59 GMT Subject: Integrated: JDK-8232644: bugs in serialized-form.html In-Reply-To: <8-UfnGEMuEtXC-ysMz6gDEFHCi1XO_yuW8nah5YlxUI=.9f6a7196-ceff-41dd-91da-6b05136b53a6@github.com> References: <8-UfnGEMuEtXC-ysMz6gDEFHCi1XO_yuW8nah5YlxUI=.9f6a7196-ceff-41dd-91da-6b05136b53a6@github.com> Message-ID: On Fri, 30 Apr 2021 14:06:13 GMT, Hannes Walln?fer wrote: > This implements most suggestions implemented in the JBS issue. The heading for class entries in the page is shortened to " ", followed by a simplified signature line like "class X extends Y implements Serializable". > > Furthermore, package names in package headings now link to the package page, `@param` info is added to the methods, Externalizable is used for classes that implement it. I also added a check for content in `@serial` tags to avoid spurious empty ` ` lines in the output. > > I increased the font size for headings `h4` to `h6` in the stylesheets because their size was smaller than the default text size, which looked strange. Although the change in font size from `h3` to `h4` and beyond is now smaller I think it's still recognizable. Headings `h4` to `h5` are used very little in Javadoc (mostly static doc files and the serialized-form page). I looked at some of the static files and they looked good to me with the new larger heading fonts. > > Although I didn't end up using the `Signatures` class to generate the class signatures (they're just too simple and too specific in what they list), I left in some cleanup of `Signatures.TypeSignature`, most significantly moving the processing of modifiers from `ClassWriterImpl` to `Signatures.TypeSignature`. > > I only removed the obsolete resources from the English resource file out of habit of not touching the Chinese and Japanese ones. I guess I could remove it there too. This pull request has now been integrated. Changeset: c6aa8f19 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/c6aa8f19aca13d30c7a0340dc64da1214b76550f Stats: 103 lines in 14 files changed: 35 ins; 13 del; 55 mod 8232644: bugs in serialized-form.html Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/3817 From hannesw at openjdk.java.net Mon May 10 13:31:19 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 May 2021 13:31:19 GMT Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE Message-ID: This replaces usages of the zero-width space character (ZWSP, entity `​`) with the HTML5 `` element. `` acts as a word break opportunity without adding characters to the text content like ZWSP does. It is supported in all modern browsers, the only browser I know of which doesn't support is are old versions of Internet Explorer. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr https://caniuse.com/wbr-element I have tested the output (both layout and copy-paste behaviour) on Firefox, Safari, and Chrome on Mac OS X. ------------- Commit messages: - JDK-8266779: Use instead of ZERO_WIDTH_SPACE Changes: https://git.openjdk.java.net/jdk/pull/3946/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3946&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266779 Stats: 374 lines in 25 files changed: 16 ins; 9 del; 349 mod Patch: https://git.openjdk.java.net/jdk/pull/3946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3946/head:pull/3946 PR: https://git.openjdk.java.net/jdk/pull/3946 From hannesw at openjdk.java.net Mon May 10 13:56:54 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 May 2021 13:56:54 GMT Subject: RFR: JDK-8266808: Search label still uses old search field id Message-ID: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> Trivial change to fix value of `for` attribute in javadoc search label. ------------- Commit messages: - JDK-8266808: Search label still uses old search field id Changes: https://git.openjdk.java.net/jdk/pull/3949/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3949&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266808 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3949/head:pull/3949 PR: https://git.openjdk.java.net/jdk/pull/3949 From hannesw at openjdk.java.net Mon May 10 14:01:46 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 May 2021 14:01:46 GMT Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v2] In-Reply-To: References: Message-ID: > This replaces usages of the zero-width space character (ZWSP, entity `​`) with the HTML5 `` element. `` acts as a word break opportunity without adding characters to the text content like ZWSP does. It is supported in all modern browsers, the only browser I know of which doesn't support is are old versions of Internet Explorer. > > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr > https://caniuse.com/wbr-element > > I have tested the output (both layout and copy-paste behaviour) on Firefox, Safari, and Chrome on Mac OS X. Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8266779 - JDK-8266779: Use instead of ZERO_WIDTH_SPACE ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3946/files - new: https://git.openjdk.java.net/jdk/pull/3946/files/095f16d2..a5508d09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3946&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3946&range=00-01 Stats: 191 lines in 6 files changed: 86 ins; 91 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3946/head:pull/3946 PR: https://git.openjdk.java.net/jdk/pull/3946 From prappo at openjdk.java.net Mon May 10 14:21:01 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 10 May 2021 14:21:01 GMT Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v2] In-Reply-To: References: Message-ID: <72YG8fLJnAjs0sIw85-LnQYgjF5Eeh272BehoKp46CQ=.13222e9e-2f67-49d7-9413-90fdd66acc0a@github.com> On Mon, 10 May 2021 14:01:46 GMT, Hannes Walln?fer wrote: >> This replaces usages of the zero-width space character (ZWSP, entity `​`) with the HTML5 `` element. `` acts as a word break opportunity without adding characters to the text content like ZWSP does. It is supported in all modern browsers, the only browser I know of which doesn't support is are old versions of Internet Explorer. >> >> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr >> https://caniuse.com/wbr-element >> >> I have tested the output (both layout and copy-paste behaviour) on Firefox, Safari, and Chrome on Mac OS X. > > Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8266779 > - JDK-8266779: Use instead of ZERO_WIDTH_SPACE It's unfortunate that the text blocks in tests are formatted for a fixed width; diffs are filled with unrelated changes. Update copyright years and you're good to go. Thanks for fixing this, Hannes. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 213: > 211: Content paramTree = getParameters(member, false); > 212: if (paramTree.charCount() > 2) { > 213: // only add zero-width-space for non-empty parameters Update this comment. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3946 From prappo at openjdk.java.net Mon May 10 14:40:55 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 10 May 2021 14:40:55 GMT Subject: RFR: JDK-8266808: Search label still uses old search field id In-Reply-To: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> References: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> Message-ID: On Mon, 10 May 2021 13:44:50 GMT, Hannes Walln?fer wrote: > Trivial change to fix value of `for` attribute in javadoc search label. What was that label's intended effect? I'm looking at the API documentation for JDK 16 and that of the mainline and cannot seem to spot any visual difference. ------------- PR: https://git.openjdk.java.net/jdk/pull/3949 From hannesw at openjdk.java.net Mon May 10 19:16:38 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 May 2021 19:16:38 GMT Subject: RFR: JDK-8266808: Search label still uses old search field id In-Reply-To: References: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> Message-ID: On Mon, 10 May 2021 14:38:01 GMT, Pavel Rappo wrote: > What was that label's intended effect? I'm looking at the API documentation for JDK 16 and that of the mainline and cannot seem to spot any visual difference. There isn't a visual difference. The purpose of associating a label with an input is mostly to improve accessibility and user experience, e.g.: - A screen reader can read the label when the input field gets the focus. - Clicking on the label puts the focus on the input field. ------------- PR: https://git.openjdk.java.net/jdk/pull/3949 From prappo at openjdk.java.net Mon May 10 19:20:24 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 10 May 2021 19:20:24 GMT Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v2] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 14:01:46 GMT, Hannes Walln?fer wrote: >> This replaces usages of the zero-width space character (ZWSP, entity `​`) with the HTML5 `` element. `` acts as a word break opportunity without adding characters to the text content like ZWSP does. It is supported in all modern browsers, the only browser I know of which doesn't support is are old versions of Internet Explorer. >> >> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr >> https://caniuse.com/wbr-element >> >> I have tested the output (both layout and copy-paste behaviour) on Firefox, Safari, and Chrome on Mac OS X. > > Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8266779 > - JDK-8266779: Use instead of ZERO_WIDTH_SPACE Come to think of it, consider obtaining an instance of a `` tag indirectly through a static factory method `HtmlTree.WBR()` rather than through a direct allocation `new HtmlTree(TagName.WBR)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3946 From jjg at openjdk.java.net Mon May 10 19:22:26 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 10 May 2021 19:22:26 GMT Subject: RFR: JDK-8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence Message-ID: Please review a change for JavaDoc, for the Standard Doclet to copy legal header files into the generated docs from a default or designated directory. ------------- Commit messages: - JDK-8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence Changes: https://git.openjdk.java.net/jdk/pull/3954/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3954&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259530 Stats: 253 lines in 7 files changed: 249 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3954.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3954/head:pull/3954 PR: https://git.openjdk.java.net/jdk/pull/3954 From prappo at openjdk.java.net Mon May 10 20:06:02 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 10 May 2021 20:06:02 GMT Subject: RFR: JDK-8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence In-Reply-To: References: Message-ID: On Mon, 10 May 2021 19:10:15 GMT, Jonathan Gibbons wrote: > Please review a change for JavaDoc, for the Standard Doclet to copy legal header files into the generated docs from a default or designated directory. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java line 361: > 359: try (OutputStream out = df.openOutputStream()) { > 360: Files.copy(entry, out); > 361: } I'm surprised to see you using `Files.copy(Path source, OutputStream out)` instead of `DocFile.copyFile(DocFile)`. Last time I suggested we use Files.copy instead of the DocFile.copyFile in jdk.javadoc, you argued that the latter is more helpful to an end-user: > In terms of general philosophy, when any IO problem occurs, I think it is important to specify the file involved, to give the end-user the best information for that person to diagnose the external condition. To me, that is better and more specific than saying "error copying from A to B, something went wrong with one of them". ------------- PR: https://git.openjdk.java.net/jdk/pull/3954 From hannes.wallnoefer at oracle.com Mon May 10 20:12:01 2021 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 10 May 2021 20:12:01 +0000 Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v2] In-Reply-To: <72YG8fLJnAjs0sIw85-LnQYgjF5Eeh272BehoKp46CQ=.13222e9e-2f67-49d7-9413-90fdd66acc0a@github.com> References: <72YG8fLJnAjs0sIw85-LnQYgjF5Eeh272BehoKp46CQ=.13222e9e-2f67-49d7-9413-90fdd66acc0a@github.com> Message-ID: <5A312761-5C65-471F-B3C6-34D462816E45@ORACLE.COM> Thanks for the review, Pavel. > Am 10.05.2021 um 16:21 schrieb Pavel Rappo : > > > It's unfortunate that the text blocks in tests are formatted for a fixed width; diffs are filled with unrelated changes. Update copyright years and you're good to go. Thanks for fixing this, Hannes. It?s not great to look at a ?brick? of text, but it?s much easier for spotting changes than in a huge line several hundred of characters long. Not to mention traditional string literals with their escaped quotes. So even though it?s still bulky, it?s much better than what we had before. Hannes From prappo at openjdk.java.net Mon May 10 20:13:54 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 10 May 2021 20:13:54 GMT Subject: RFR: JDK-8266808: Search label still uses old search field id In-Reply-To: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> References: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> Message-ID: On Mon, 10 May 2021 13:44:50 GMT, Hannes Walln?fer wrote: > Trivial change to fix value of `for` attribute in javadoc search label. I wonder if a more robust fix would be to associate these elements by nesting rather than by id: ------------- PR: https://git.openjdk.java.net/jdk/pull/3949 From hannesw at openjdk.java.net Mon May 10 20:19:58 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 May 2021 20:19:58 GMT Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v2] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 14:01:46 GMT, Hannes Walln?fer wrote: >> This replaces usages of the zero-width space character (ZWSP, entity `​`) with the HTML5 `` element. `` acts as a word break opportunity without adding characters to the text content like ZWSP does. It is supported in all modern browsers, the only browser I know of which doesn't support is are old versions of Internet Explorer. >> >> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr >> https://caniuse.com/wbr-element >> >> I have tested the output (both layout and copy-paste behaviour) on Firefox, Safari, and Chrome on Mac OS X. > > Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8266779 > - JDK-8266779: Use instead of ZERO_WIDTH_SPACE I?d rather not. I don?t think it?s a huge improvement, there?s only 4 usages of this tag, and ? it?s late and I?d like to close the issue :) I think there are some elements that are much more often used that don?t have a factory method. Maybe another cleanup task? Hannes > Am 10.05.2021 um 21:16 schrieb Pavel Rappo ***@***.***>: > > > Come to think of it, consider obtaining an instance of a tag indirectly through a static factory method HtmlTree.WBR() rather than through a direct allocation new HtmlTree(TagName.WBR). > > ? > 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/3946 From hannesw at openjdk.java.net Mon May 10 20:30:33 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 May 2021 20:30:33 GMT Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v3] In-Reply-To: References: Message-ID: > This replaces usages of the zero-width space character (ZWSP, entity `​`) with the HTML5 `` element. `` acts as a word break opportunity without adding characters to the text content like ZWSP does. It is supported in all modern browsers, the only browser I know of which doesn't support is are old versions of Internet Explorer. > > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr > https://caniuse.com/wbr-element > > I have tested the output (both layout and copy-paste behaviour) on Firefox, Safari, and Chrome on Mac OS X. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8266779: Update comment and copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3946/files - new: https://git.openjdk.java.net/jdk/pull/3946/files/a5508d09..3433a4ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3946&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3946&range=01-02 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3946/head:pull/3946 PR: https://git.openjdk.java.net/jdk/pull/3946 From prappo at openjdk.java.net Mon May 10 20:30:35 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 10 May 2021 20:30:35 GMT Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v2] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 20:17:03 GMT, Hannes Walln?fer wrote: > I?d rather not. I don?t think it?s a huge improvement, there?s only 4 usages of this tag, and ? it?s late and I?d like to close the issue :) I think there are some elements that are much more often used that don?t have a factory method. Maybe another cleanup task? Hannes Up to you. I have reviewed it already. ------------- PR: https://git.openjdk.java.net/jdk/pull/3946 From hannesw at openjdk.java.net Mon May 10 20:30:37 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 May 2021 20:30:37 GMT Subject: Integrated: JDK-8266779: Use instead of ZERO_WIDTH_SPACE In-Reply-To: References: Message-ID: <0pvrtA8ys14QvwfPHgOlJx8IgFd9CqOVAXo-z8Ct6ZQ=.ba8a2e47-b285-46ad-9816-122e45de7bd1@github.com> On Mon, 10 May 2021 10:20:47 GMT, Hannes Walln?fer wrote: > This replaces usages of the zero-width space character (ZWSP, entity `​`) with the HTML5 `` element. `` acts as a word break opportunity without adding characters to the text content like ZWSP does. It is supported in all modern browsers, the only browser I know of which doesn't support is are old versions of Internet Explorer. > > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr > https://caniuse.com/wbr-element > > I have tested the output (both layout and copy-paste behaviour) on Firefox, Safari, and Chrome on Mac OS X. This pull request has now been integrated. Changeset: 8851cb65 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/8851cb653ff932758ef6408ff010b67200954eff Stats: 380 lines in 25 files changed: 16 ins; 9 del; 355 mod 8266779: Use instead of ZERO_WIDTH_SPACE Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/3946 From hannesw at openjdk.java.net Mon May 10 20:47:52 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 10 May 2021 20:47:52 GMT Subject: RFR: JDK-8266808: Search label still uses old search field id In-Reply-To: References: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> Message-ID: On Mon, 10 May 2021 20:11:27 GMT, Pavel Rappo wrote: > I wonder if a more robust fix would be to associate these elements by nesting rather than by id: > > ``` > > ``` Yes, that would be an option. It would have prevented the current bug, but it's also a structural change that is not as easily made (might affect layout or, even though unlikely, script behaviour). ------------- PR: https://git.openjdk.java.net/jdk/pull/3949 From jjg at openjdk.java.net Mon May 10 23:44:03 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 10 May 2021 23:44:03 GMT Subject: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v3] In-Reply-To: References: Message-ID: <4OhpeqdFrrZPkVhzXikdN4X1L08iBQqpFhLplUni3-I=.1fb977ca-4c2e-4fef-a2f5-759adda9a8fe@github.com> On Mon, 10 May 2021 20:30:33 GMT, Hannes Walln?fer wrote: >> This replaces usages of the zero-width space character (ZWSP, entity `​`) with the HTML5 `` element. `` acts as a word break opportunity without adding characters to the text content like ZWSP does. It is supported in all modern browsers, the only browser I know of which doesn't support is are old versions of Internet Explorer. >> >> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr >> https://caniuse.com/wbr-element >> >> I have tested the output (both layout and copy-paste behaviour) on Firefox, Safari, and Chrome on Mac OS X. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266779: Update comment and copyright years Nice ------------- PR: https://git.openjdk.java.net/jdk/pull/3946 From prappo at openjdk.java.net Tue May 11 10:30:52 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 11 May 2021 10:30:52 GMT Subject: RFR: JDK-8266808: Search label still uses old search field id In-Reply-To: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> References: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> Message-ID: On Mon, 10 May 2021 13:44:50 GMT, Hannes Walln?fer wrote: > Trivial change to fix value of `for` attribute in javadoc search label. Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3949 From jlahoda at openjdk.java.net Tue May 11 13:42:32 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 11 May 2021 13:42:32 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) Message-ID: This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): https://bugs.openjdk.java.net/browse/JDK-8213076 The current draft of the specification is here: http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html A summary of notable parts of the patch: -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. The specdiff for the change is here (to be updated): http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html ------------- Commit messages: - Trailing whitespaces. - Cleanup, reflecting review comments. - Merge branch 'master' into JDK-8262891 - JDK-8262891: Compiler implementation for Pattern Matching for switch Changes: https://git.openjdk.java.net/jdk/pull/3863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262891 Stats: 3927 lines in 70 files changed: 3636 ins; 97 del; 194 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Tue May 11 13:42:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 11 May 2021 13:42:50 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 100: > 98: * the {@code NameAndType} of the {@code InvokeDynamic} > 99: * structure and is stacked automatically by the VM. > 100: * @param labels non-null case labels - {@code String} and {@code Integer} constants Can these types be mixed? E.g. can I pass, as static args: `42`, `Runnable.class`, `"hello"` ? If not, should be document, and throw? src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 102: > 100: * @param labels non-null case labels - {@code String} and {@code Integer} constants > 101: * and {@code Class} instances > 102: * @return the index into {@code labels} of the target value, if the target Doesn't return an index. Returns a CallSite which, when invoked with an argument of type E (where E is the type of the target expression), returns the index into... src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 306: > 304: > 305: /** > 306: * Visits an GuardPatternTree node. Suggestion: * Visits a GuardPatternTree node. src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 316: > 314: > 315: /** > 316: * Visits an AndPatternTree node. Is this comment correct? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1685: > 1683: log.error(DiagnosticFlag.SOURCE_LEVEL, selector.pos(), > 1684: Feature.PATTERN_SWITCH.error(this.sourceName)); > 1685: allowPatternSwitch = true; I assume this logic is to show only one error in case we're compiling multiple methods with pattern switches and preview features are not enabled? Is this consistent with what happens with other preview features though? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1725: > 1723: log.error(DiagnosticFlag.SOURCE_LEVEL, expr.pos(), > 1724: Feature.CASE_NULL.error(this.sourceName)); > 1725: allowCaseNull = true; Same here about error recovery and minimize messages - if this is what we'd like to do, perhaps centralizing the check in Preview would be better (so that e.g. we'd return that a given preview feature is not supported only once). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1790: > 1788: if (isTotal) { > 1789: if (hasTotalPattern) { > 1790: log.error(pat.pos(), Errors.DuplicateTotalPattern); Hard to explain - but a lot of the code here feels more like it belongs to `Flow` than to `Attr`. E.g. these "duplicateXYZ" labels really want to say "unreachable code", I think. Is there a strong reason as to why all this code shouldn't (apart from code computing bindings) move to Flow? Seems that the logic is partially duplicated anyway... src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1861: > 1859: return null; > 1860: } > 1861: private Pair primaryType(JCPattern pat) { Maybe a record here would lead for better code (no boxing of Boolean, but, more importantly, better field names for fst/snd). More generally, now that we have records I think we should think twice before using Pairs :-) src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 757: > 755: } > 756: > 757: private TypeSymbol patternType(JCPattern p) { If we need to keep duplicated code, this could move to TreeInfo src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 757: > 755: } > 756: > 757: private TypeSymbol patternType(JCPattern p) { If we need to keep duplicated code, this could move to TreeInfo src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2917: > 2915: void reportEffectivelyFinalError(DiagnosticPosition pos, Symbol sym) { > 2916: String subKey = switch (currentTree.getTag()) { > 2917: case LAMBDA -> "lambda"; Can we make the switch return the fragment constant (e.g. Fragments.XYZ) rather than a String which is then re-wrapped? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3649: > 3647: if (!enumSwitch && !stringSwitch && !selector.type.isPrimitive() && > 3648: cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) { > 3649: //a switch over a boxed primitive, with a null case. Pick two constants that are Is this comment correct? If we're here, can't this be just any pattern switch? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3729: > 3727: if (cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) { > 3728: //for enum switches with case null, do: > 3729: //switch ($selector != null ? $mapVar[$selector.ordinal()] : -1) {...} Very clever trick to handle away null treatment with just an extra default label. I wonder if this logic isn't big enough to deserve its own `visitXYZSwitch` method, as we do for strings and enums in switch. It seems asymmetric that we do some bits of null handling here (in certain cases) but then enum switches will deal with null in a different way. We should probably test what kind of switch we're dealing with earlier, and then branch out to completely disjoint pieces of code, each with its own null handling src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MatchBindingsComputer.java line 124: > 122: // e.T = union(x.T, y.T) > 123: // e.F = intersection(x.F, y.F) (error recovery) > 124: List bindingsWhenTrue = Is this duplicate code for MatchBindingComputer::binary(AND) ? If so, should at least the impl delegate to that? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 193: > 191: : tree.expr.type; > 192: VarSymbol prevCurrentValue = currentValue; > 193: try { IIUC, the changes here are to handle recursion of pattern in the instanceof case - e.g. `x instanceof (Foo foo)`. If so, it would be nice to have that reflected in the comment above. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 305: > 303: selector = make.Ident(temp); > 304: } else { > 305: List staticArgTypes = List.of(syms.methodHandleLookupType, I guess strategy here is to convert the various labels into loadable constants and then pass them up to the bootstrap method which will give us back an int, which we'll use for a plain switch. If so, all this needs to be documented somehow. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 368: > 366: JCContinue continueSwitch = make.Continue(null); > 367: continueSwitch.target = tree; > 368: c.stats = c.stats.prepend(make.If(makeUnary(Tag.NOT, test).setType(syms.booleanType), I assume this is code which "resumes" to the following `case` if the pattern doesn't match. I guess in most cases the bootstrap method would do the check anyway - but I suppose that with guards, the bootstrap method, alone, cannot guarantee the match. Also, it seems like this requires backend support for `continue` in switch. Again, all this needs to be better documented, it's pretty hard to infer all this by looking at the code. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 776: > 774: } else { > 775: JCPattern pattern; > 776: JCExpression e = parsedType == null ? term(EXPR | TYPE | NOLAMBDA/* | NOINVOCATION*/) : parsedType; what's up with NO_INVOCATION? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3004: > 3002: JCCaseLabel label = parseCaseLabel(); > 3003: > 3004: //TODO: final What does this `todo` refers to? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3078: > 3076: } > 3077: Token twoBack; > 3078: boolean pattern = S.token(lookahead - 1).kind == IDENTIFIER && ((twoBack = S.token(lookahead - 2)).kind == IDENTIFIER || twoBack.kind == GT || twoBack.kind == GTGT || twoBack.kind == GTGTGT); tricky - but I think correct. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3085: > 3083: } > 3084: } > 3085: //XXX: modifiers! Another todo here src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 501: > 499: > 500: compiler.err.pattern.dominated=\ > 501: this pattern is dominated by a preceding pattern Not sure whether the concept of "dominance" is the one that will work best here. As I said elsewhere, this is, morally, unreachable code. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 520: > 518: > 519: compiler.err.multiple.patterns=\ > 520: multiple pattern declarations This text is very terse and doesn't really say what's wrong with the code. I think the point here is that we don't want code like this: case String s, Integer i: ... because this is morally: case String s: case Integer i: ... which is, again, fall-through to a pattern. Maybe, just reusing the same "fall-through" message would be ok here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Tue May 11 13:42:54 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 11 May 2021 13:42:54 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. > > In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. @mcimadamore, thanks a lot for the comments! I tried to reflect most of them in https://github.com/openjdk/jdk/pull/3863/commits/1a5a424139a52d0f93e16980c6b42cf29dd908ef - please let me know how that looks. Thanks! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1790: > >> 1788: if (isTotal) { >> 1789: if (hasTotalPattern) { >> 1790: log.error(pat.pos(), Errors.DuplicateTotalPattern); > > Hard to explain - but a lot of the code here feels more like it belongs to `Flow` than to `Attr`. E.g. these "duplicateXYZ" labels really want to say "unreachable code", I think. Is there a strong reason as to why all this code shouldn't (apart from code computing bindings) move to Flow? Seems that the logic is partially duplicated anyway... `Attr` was always checking duplicated constants and duplicated default, so checking for pattern dominance (which could be seen as an extension to duplicate constant labels) and total patterns (which is an extension to duplicated default) here seemed reasonable. We also have a couple of other similar checks performed by `Attr`, like duplicated statement labels, or that exception types in multicatch are disjoint. These are checks that don't need DA/DU, while I think `Flow` does mostly checks that require DA/DU. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3649: > >> 3647: if (!enumSwitch && !stringSwitch && !selector.type.isPrimitive() && >> 3648: cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) { >> 3649: //a switch over a boxed primitive, with a null case. Pick two constants that are > > Is this comment correct? If we're here, can't this be just any pattern switch? Patterns switches are resolved before Lower, so in Lower there should be no pattern switches. I'll add a comment in this sense at an appropriate place. > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 501: > >> 499: >> 500: compiler.err.pattern.dominated=\ >> 501: this pattern is dominated by a preceding pattern > > Not sure whether the concept of "dominance" is the one that will work best here. As I said elsewhere, this is, morally, unreachable code. The specification uses "dominance", so it seemed appropriate to use the same term that is used by the specification. We can say "unreachable code", of course, but it will not be consistent with what the specification says, and also with what we do for duplicate constant labels. Also considering code like: switch (o) { case A a -> {} case B b -> {} //error on this line } It may not be obvious why the code is "unreachable", while saying "dominated" might be more helpful/clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Tue May 11 13:42:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 11 May 2021 13:42:55 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:35:45 GMT, Maurizio Cimadamore wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 102: > >> 100: * @param labels non-null case labels - {@code String} and {@code Integer} constants >> 101: * and {@code Class} instances >> 102: * @return the index into {@code labels} of the target value, if the target > > Doesn't return an index. Returns a CallSite which, when invoked with an argument of type E (where E is the type of the target expression), returns the index into... It should also mention that the handle returned accepts a start index (which is used by the continue logic) ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From erikj at openjdk.java.net Tue May 11 13:56:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 11 May 2021 13:56:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: <5tkFlMzpxFP1UFGuwI7u0mpFCt_hExf6SLwQVCJnfJs=.8878adb9-f423-408a-9a62-41334467e49f@github.com> On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html make/CompileInterimLangtools.gmk line 52: > 50: > 51: $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ > 52: FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java $(TOPDIR)/src/java.base/share/classes/jdk/internal/javac/NoPreview.java, \ Please break this line (adding 4 additional space indent from the original line). Otherwise build changes ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From github.com+828220+forax at openjdk.java.net Tue May 11 14:24:54 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 11 May 2021 14:24:54 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 77: > 75: } > 76: > 77: private static MethodHandle typeInitHook(T receiver) { There is no point to have a type parameter here, private static MethodHandle typeInitHook(CallSite receiver) { will work the same src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 131: > 129: > 130: private static void verifyLabel(Object label) { > 131: if (Objects.isNull(label)) { `if (label == true) {` is more readable as said in the javadoc of `Objects.isNull` ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From hannesw at openjdk.java.net Wed May 12 08:35:56 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 12 May 2021 08:35:56 GMT Subject: Integrated: JDK-8266808: Search label still uses old search field id In-Reply-To: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> References: <_Eg9w1JK3n1X30HFllHKlVCW1bLd2B_AtIxo40Dy7dQ=.91be962e-ee09-4d94-9be8-0cda5a7a8e4d@github.com> Message-ID: On Mon, 10 May 2021 13:44:50 GMT, Hannes Walln?fer wrote: > Trivial change to fix value of `for` attribute in javadoc search label. This pull request has now been integrated. Changeset: 97367c01 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/97367c01c13261ccf9b6f3032213bbf3e342fbae Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod 8266808: Search label still uses old search field id Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/3949 From hannesw at openjdk.java.net Wed May 12 12:51:20 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 12 May 2021 12:51:20 GMT Subject: RFR: JDK-8266651: Convert Table method parameters from String to Content Message-ID: This changes the parameter type for the tab label from `String` to `Content` in the `formats.html.Table` `addTab` and `setDefaultTab` methods. The change is straightforward because the tab name was converted to `Content` anyway, and all resources are readily available in `Content` form. I briefly considered overriding the `hashCode` and `equals` methods in `Text` to be depend on content instead of object identity, but decided against it. This would just cover up bugs where we generate the same content twice. (In the process I made sure we currently don't have any such cases where a `Text` instance is compared to another one with the same string content.) ------------- Commit messages: - JDK-8266651: Convert Table method parameters from String to Content Changes: https://git.openjdk.java.net/jdk/pull/3994/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3994&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266651 Stats: 60 lines in 8 files changed: 1 ins; 3 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/3994.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3994/head:pull/3994 PR: https://git.openjdk.java.net/jdk/pull/3994 From jjg at openjdk.java.net Wed May 12 23:47:01 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 12 May 2021 23:47:01 GMT Subject: RFR: JDK-8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence In-Reply-To: References: Message-ID: <-vTAxbySfQFxtw0Kqfjy-tXpfBDMgqjQCx1mnT6uIB8=.e520c957-881a-4db6-9ec0-cdbca5b89d24@github.com> On Mon, 10 May 2021 19:57:41 GMT, Pavel Rappo wrote: >> Please review a change for JavaDoc, for the Standard Doclet to copy legal header files into the generated docs from a default or designated directory. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java line 361: > >> 359: try (OutputStream out = df.openOutputStream()) { >> 360: Files.copy(entry, out); >> 361: } > > I'm surprised to see you using `Files.copy(Path source, OutputStream out)` instead of `DocFile.copyFile(DocFile)`. > > Last time I suggested we use Files.copy instead of the DocFile.copyFile in jdk.javadoc, you argued that the latter is more helpful to an end-user: > >> In terms of general philosophy, when any IO problem occurs, I think it is important to specify the file involved, to give the end-user the best information for that person to diagnose the external condition. To me, that is better and more specific than saying "error copying from A to B, something went wrong with one of them". Yeah, good call. It required some tweaks to `DocFile` and `DocFileFactory` to make it happen, but it's a move in the right direction. `DocFileFactory` used to be new and clever and encapsulated the different kinds of file system. Now, NIO is accepted and standard. I would still keep `DocFile` to encapsulate `Path` vs. `FileObject`, but there is potential cleanup to improve this part of the code, and (most notably) convert command-line options to use `Path` instead of `String` where that is appropriate. But that is a different PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3954 From github.com+828220+forax at openjdk.java.net Thu May 13 19:29:38 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 13 May 2021 19:29:38 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 127: > 125: Stream.of(labels).forEach(SwitchBootstraps::verifyLabel); > 126: > 127: return new TypeSwitchCallSite(invocationType, labels); See why below MethodHandle target = MethodHandles.insertArguments(DO_SWITCH, 2, labels); return new ConstantCallsite(target); src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 134: > 132: throw new IllegalArgumentException("null label found"); > 133: } > 134: if (label.getClass() != Class.class && store `label.getClass` in a local variable, it's too bad that you can no use pattern matching here :) src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 141: > 139: } > 140: > 141: static class TypeSwitchCallSite extends ConstantCallSite { That's weird, having a callsite extending MutableCallSite is expected but having a callsite extending constant callsite is useless because you can not change it after being constructed. As an interesting trivia, the VM does not store the CallSite returned by the BSM, but only the target inside it. So there is no point of keeping a ConstantCallSite around. So `doSwitch()` should be static and takes the array of Object[] as parameter, will array will be injected with an insertArguments(). src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 157: > 155: Class targetClass = target.getClass(); > 156: for (int i = startIndex; i < labels.length; i++) { > 157: if (labels[i] instanceof Class) { label[i] should be stored is a local variable and using `instanceof Class c` (like the other instanceof below) will make the code more readable ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jjg at openjdk.java.net Fri May 14 21:05:01 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 14 May 2021 21:05:01 GMT Subject: RFR: JDK-8267187: Remove deprecated constructor for Log Message-ID: In the course of other work, I came across this deprecated constructor in Log which just existed for a public entry point in javadoc which has already been removed. There is one remaining use in javadoc, which can be changed to use an alternate non-deprecated constructor. ------------- Commit messages: - JDK-8267187: Remove deprecated constructor for Log Changes: https://git.openjdk.java.net/jdk/pull/4037/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4037&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267187 Stats: 15 lines in 2 files changed: 0 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4037.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4037/head:pull/4037 PR: https://git.openjdk.java.net/jdk/pull/4037 From iris at openjdk.java.net Fri May 14 21:16:51 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 14 May 2021 21:16:51 GMT Subject: RFR: JDK-8267187: Remove deprecated constructor for Log In-Reply-To: References: Message-ID: On Fri, 14 May 2021 20:49:35 GMT, Jonathan Gibbons wrote: > In the course of other work, I came across this deprecated constructor in Log which just existed for a public entry point in javadoc which has already been removed. > > There is one remaining use in javadoc, which can be changed to use an alternate non-deprecated constructor. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4037 From hannesw at openjdk.java.net Mon May 17 09:38:23 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 May 2021 09:38:23 GMT Subject: RFR: JDK-8263438: Unused method AbstractMemberWriter.isInherited Message-ID: Trivial change to remove unused method. ------------- Commit messages: - JDK-8263438: Unused method AbstractMemberWriter.isInherited Changes: https://git.openjdk.java.net/jdk/pull/4049/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4049&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263438 Stats: 14 lines in 1 file changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4049.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4049/head:pull/4049 PR: https://git.openjdk.java.net/jdk/pull/4049 From hannesw at openjdk.java.net Mon May 17 10:20:48 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 May 2021 10:20:48 GMT Subject: RFR: JDK-8267236: Versioned platform link in TestMemberSummary.java Message-ID: <0xJXwPA4ay0n9MNY5lQfLE-KB163GixX7ZywvNDEcNU=.881a3f1a-7045-4a6f-9483-80416305d699@github.com> Simple change to disable platform links in TestMemberSummary.java tests. ------------- Commit messages: - JDK-8267236: Versioned platform link in TestMemberSummary.java Changes: https://git.openjdk.java.net/jdk/pull/4051/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4051&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267236 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4051.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4051/head:pull/4051 PR: https://git.openjdk.java.net/jdk/pull/4051 From prappo at openjdk.java.net Mon May 17 11:39:42 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 17 May 2021 11:39:42 GMT Subject: RFR: JDK-8267236: Versioned platform link in TestMemberSummary.java In-Reply-To: <0xJXwPA4ay0n9MNY5lQfLE-KB163GixX7ZywvNDEcNU=.881a3f1a-7045-4a6f-9483-80416305d699@github.com> References: <0xJXwPA4ay0n9MNY5lQfLE-KB163GixX7ZywvNDEcNU=.881a3f1a-7045-4a6f-9483-80416305d699@github.com> Message-ID: On Mon, 17 May 2021 10:10:38 GMT, Hannes Walln?fer wrote: > Simple change to disable platform links in TestMemberSummary.java tests. The change looks good. That said, should we be concerned about proliferation of `--no-platform-links` in tests? ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4051 From prappo at openjdk.java.net Mon May 17 11:40:41 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 17 May 2021 11:40:41 GMT Subject: RFR: JDK-8263438: Unused method AbstractMemberWriter.isInherited In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:30:17 GMT, Hannes Walln?fer wrote: > Trivial change to remove unused method. Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4049 From hannesw at openjdk.java.net Mon May 17 14:20:38 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 May 2021 14:20:38 GMT Subject: RFR: JDK-8267236: Versioned platform link in TestMemberSummary.java In-Reply-To: References: <0xJXwPA4ay0n9MNY5lQfLE-KB163GixX7ZywvNDEcNU=.881a3f1a-7045-4a6f-9483-80416305d699@github.com> Message-ID: <9oM2aHToSILMakhrfStMXWqHHK0xzFngeni11wCBS74=.8147f73f-3553-4ef7-9e08-488e7bfe5f45@github.com> On Mon, 17 May 2021 11:36:53 GMT, Pavel Rappo wrote: > The change looks good. That said, should we be concerned about proliferation of `--no-platform-links` in tests? If I remember correctly, back when we did the platform link feature @jonathan-gibbons suggested disabling the feature by default in `JavadocTester`. That would help avoid this kind of mistake. However, I don't think we have a mechanism to tweak standard options in `JavadocTester`, and I'm not sure how we would then enable the feature in order to test it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4051 From hannesw at openjdk.java.net Mon May 17 14:24:53 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 May 2021 14:24:53 GMT Subject: Integrated: JDK-8263438: Unused method AbstractMemberWriter.isInherited In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:30:17 GMT, Hannes Walln?fer wrote: > Trivial change to remove unused method. This pull request has now been integrated. Changeset: d5a15f74 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/d5a15f74207f14c8c6928c9d20aff8dcc2a714cc Stats: 14 lines in 1 file changed: 0 ins; 14 del; 0 mod 8263438: Unused method AbstractMemberWriter.isInherited Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4049 From hannesw at openjdk.java.net Mon May 17 14:47:41 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 May 2021 14:47:41 GMT Subject: Integrated: JDK-8267236: Versioned platform link in TestMemberSummary.java In-Reply-To: <0xJXwPA4ay0n9MNY5lQfLE-KB163GixX7ZywvNDEcNU=.881a3f1a-7045-4a6f-9483-80416305d699@github.com> References: <0xJXwPA4ay0n9MNY5lQfLE-KB163GixX7ZywvNDEcNU=.881a3f1a-7045-4a6f-9483-80416305d699@github.com> Message-ID: On Mon, 17 May 2021 10:10:38 GMT, Hannes Walln?fer wrote: > Simple change to disable platform links in TestMemberSummary.java tests. This pull request has now been integrated. Changeset: ea368365 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/ea36836573d2ee1b734075596f1afb9b1302d6c6 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8267236: Versioned platform link in TestMemberSummary.java Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4051 From github.com+7806504+liach at openjdk.java.net Mon May 17 17:00:09 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Mon, 17 May 2021 17:00:09 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent Message-ID: This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. ------------- Commit messages: - JDK-8267219 : Javadoc method summary breaks when {@inheritDoc} from an empty parent Changes: https://git.openjdk.java.net/jdk/pull/4066/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4066&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267219 Stats: 124 lines in 4 files changed: 118 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4066/head:pull/4066 PR: https://git.openjdk.java.net/jdk/pull/4066 From hannesw at openjdk.java.net Mon May 17 17:03:02 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 May 2021 17:03:02 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link Message-ID: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). Here's a list of what references now cause what error messages: - `#foo(int` `unterminated signature` - `#foo((int))` `unexpected parenthesis` - `#foo(int))` `unexpected parenthesis` - `#foo(int)x` `unexpected parenthesis` - `F>` `unexpected input` I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". ------------- Commit messages: - JDK-8264181: javadoc tool Incorrect error message about malformed link Changes: https://git.openjdk.java.net/jdk/pull/4068/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4068&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264181 Stats: 38 lines in 4 files changed: 33 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4068/head:pull/4068 PR: https://git.openjdk.java.net/jdk/pull/4068 From hannesw at openjdk.java.net Mon May 17 17:15:49 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 May 2021 17:15:49 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent In-Reply-To: References: Message-ID: On Mon, 17 May 2021 16:51:54 GMT, liach wrote: > This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. > > This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. > > All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. test/langtools/jdk/javadoc/doclet/testEmptyInheritDoc/Second.java line 24: > 22: */ > 23: > 24: public class Second { Shouldn't this class extend `First`? ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Mon May 17 17:39:19 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Mon, 17 May 2021 17:39:19 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: References: Message-ID: > This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. > > This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. > > All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4066/files - new: https://git.openjdk.java.net/jdk/pull/4066/files/bb5c9376..13d78642 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4066&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4066&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4066/head:pull/4066 PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Mon May 17 17:39:23 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Mon, 17 May 2021 17:39:23 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 17:12:50 GMT, Hannes Walln?fer wrote: >> liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent > > test/langtools/jdk/javadoc/doclet/testEmptyInheritDoc/Second.java line 24: > >> 22: */ >> 23: >> 24: public class Second { > > Shouldn't this class extend `First`? Right. Turns out this bug can be replicated with just one file as well: public class Second { /** * {@inheritDoc} */ public void act() {} public void bite() {} } Somehow javadoc still replaces `{@inheritDoc}` tag with empty output (tested with 16), and this serious bug doesn't affect the validity of the test ?? in an unexpected way. Pushing the fixed version of test classes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From prappo at openjdk.java.net Mon May 17 18:37:40 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 17 May 2021 18:37:40 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: On Mon, 17 May 2021 16:54:07 GMT, Hannes Walln?fer wrote: > The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). > > I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". > > A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). > > Here's a list of what references now cause what error messages: > > - `#foo(int` `unterminated signature` > - `#foo((int))` `unexpected parenthesis` > - `#foo(int))` `unexpected parenthesis` > - `#foo(int)x` `unexpected parenthesis` > - `F - `F>` `unexpected input` > > I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". 1. I think this error is a counterintuitive: #foo(int)x error: unexpected parenthesis It's `x` that is unexpected, not the parenthesis. It looks correct here, but only coincidentally: #foo(int)) error: unexpected parenthesis 2. The latter case in your list, `F>`, yields "unexpected text", not "unexpected input". 3. Why is there an asymmetry between wording for angle brackets and that of parenthesis? ------------- PR: https://git.openjdk.java.net/jdk/pull/4068 From jlahoda at openjdk.java.net Mon May 17 19:04:11 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 17 May 2021 19:04:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: - Reflecting recent spec changes. - Reflecting review comments. - Reflecting review comments on SwitchBootstraps. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/5e663d70..54ba974e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=00-01 Stats: 544 lines in 18 files changed: 431 ins; 68 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Mon May 17 19:04:11 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 17 May 2021 19:04:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: >> >> - Reflecting recent spec changes. >> - Reflecting review comments. >> - Reflecting review comments on SwitchBootstraps. > > Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. > > In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested changes in recent commits (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 ). I've also tried to update the implementation for the latest spec changes here: https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b The spec changes are: total patterns are nullable; pattern matching ("new") statement switches must be complete (as switch expressions). Any further feedback is welcome! ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From github.com+828220+forax at openjdk.java.net Mon May 17 19:21:41 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 17 May 2021 19:21:41 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: <4O-2pD_4PUl_DRDCLvPO6nNwOvqN-j0GvQzogPTJ0hE=.d5009f6b-72a8-4a96-80b9-4a3a73178e1e@github.com> On Mon, 17 May 2021 19:04:11 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: > > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. It's not clear to me if it's the first change and several will follow or not. The code looks good but the metaprotocol is not the right one IMO, i would prefer the one we discuss in April https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002992.html But this can be tackle in another PR ------------- Marked as reviewed by forax at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/3863 From jjg at openjdk.java.net Mon May 17 20:13:25 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 17 May 2021 20:13:25 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. Message-ID: Please review a change to overhaul the javadoc support for diagnostics to better leverage the support available in javac. This includes the ability for all javadoc diagnostics to show a "source line and caret" to indicate the position of a reported issue. As a side-effect, it normalizes the formatting of javadoc messages, to be consistent with javac messages. The primary changes are in the javadoc `Messager` class, and are primarily focussed "downward" on the internal use of the javac `Log.report` method, which is the nexus for reporting methods. There is additional cleanup that could be done in `Messager` in the API it provides to clients, but (for the most part) that is not done in this work. Additional changes are done to facilitate writing a test for this work, and reflect the current shortcomings of the existing `Doclet` API. Most notably: * changes in `Utils` to allow a user-defined taglet to override a built-in taglet * changes in `TagletManager` and `Workarounds` to allow a user-defined taglet to access internal API, to workaround API that would be useful to provide on `StandardDoclet` There are a few minor specific cleanup changes in code style and/or improved comments. There is one primary new test, `TestDiagsLineCaret.java` which exercises different kinds of diagnostics at different positions in a file, to verify that the source line and a caret are produced as appropriate. There are additional test changes triggered by the slight change in the format of error messages. Most notably, prefixes like `error -` and `warning -` become `error:` and `warning:`. ------------- Commit messages: - JDK-8267126: javadoc should show "line and caret" for diagnostics. Changes: https://git.openjdk.java.net/jdk/pull/4074/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4074&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267126 Stats: 906 lines in 37 files changed: 598 ins; 132 del; 176 mod Patch: https://git.openjdk.java.net/jdk/pull/4074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4074/head:pull/4074 PR: https://git.openjdk.java.net/jdk/pull/4074 From prappo at openjdk.java.net Mon May 17 20:28:42 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 17 May 2021 20:28:42 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: References: Message-ID: <5CZjpnamYjmfmP9v3aliZuz-BwigJFniPbWUKY4PTyE=.5af4003b-6488-43ce-b996-11f3b4797dd6@github.com> On Mon, 17 May 2021 17:39:19 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Right off the bat: I'd be interested to know why an empty content demands special treatment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From jjg at openjdk.java.net Mon May 17 20:40:18 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 17 May 2021 20:40:18 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v2] In-Reply-To: References: Message-ID: > Please review a change to overhaul the javadoc support for diagnostics to better leverage the support available in javac. This includes the ability for all javadoc diagnostics to show a "source line and caret" to indicate the position of a reported issue. As a side-effect, it normalizes the formatting of javadoc messages, to be consistent with javac messages. > > The primary changes are in the javadoc `Messager` class, and are primarily focussed "downward" on the internal use of the javac `Log.report` method, which is the nexus for reporting methods. There is additional cleanup that could be done in `Messager` in the API it provides to clients, but (for the most part) that is not done in this work. > > Additional changes are done to facilitate writing a test for this work, and reflect the current shortcomings of the existing `Doclet` API. Most notably: > * changes in `Utils` to allow a user-defined taglet to override a built-in taglet > * changes in `TagletManager` and `Workarounds` to allow a user-defined taglet to access internal API, to workaround API that would be useful to provide on `StandardDoclet` > > There are a few minor specific cleanup changes in code style and/or improved comments. > > There is one primary new test, `TestDiagsLineCaret.java` which exercises different kinds of diagnostics at different positions in a file, to verify that the source line and a caret are produced as appropriate. > > There are additional test changes triggered by the slight change in the format of error messages. Most notably, prefixes like `error -` and `warning -` become `error:` and `warning:`. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: minor cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4074/files - new: https://git.openjdk.java.net/jdk/pull/4074/files/78ba02f9..c57d93a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4074&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4074&range=00-01 Stats: 71 lines in 3 files changed: 59 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4074/head:pull/4074 PR: https://git.openjdk.java.net/jdk/pull/4074 From weijun at openjdk.java.net Mon May 17 22:01:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:49 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) ``` The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. ------------- Commit messages: - test for awt - test for hotspot-gc - test for compiler - test for net - test for core-libs - test for beans - test for xml - test for nio - test for hotspot-runtime - test for security - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0 Changes: https://git.openjdk.java.net/jdk/pull/4071/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267184 Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From jjg at openjdk.java.net Tue May 18 00:48:12 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 00:48:12 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment Message-ID: Please review a relatively simple update to expose the 1 or 2 streams available within javadoc for writing expected or diagnostic output. The change at this time is just to _expose_ the streams; followup work may change how we _use_ them. There are two points of note: * `JavadocTester` is extended to provided access to the javadoc entry point used by the launcher. This is simpler than exec-ing the tool to invoke the entry point, and allows us to use the existing code to capture and analyze the output. * The initialization of the default streams in `Messager` is deferred, to allow `Messager` to use the values of `System.out` and `System.err` at the time that javadoc is started, instead of when the class was loaded. This is part of the problems described separately in JDK-8267203, but which needs to be addressed here as part of this work. ------------- Commit messages: - JDK-8267204: Expose access to underlying streams in DocletEnvironment Changes: https://git.openjdk.java.net/jdk/pull/4077/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4077&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267204 Stats: 244 lines in 6 files changed: 236 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4077.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4077/head:pull/4077 PR: https://git.openjdk.java.net/jdk/pull/4077 From github.com+7806504+liach at openjdk.java.net Tue May 18 01:45:52 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 18 May 2021 01:45:52 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: <5CZjpnamYjmfmP9v3aliZuz-BwigJFniPbWUKY4PTyE=.5af4003b-6488-43ce-b996-11f3b4797dd6@github.com> References: <5CZjpnamYjmfmP9v3aliZuz-BwigJFniPbWUKY4PTyE=.5af4003b-6488-43ce-b996-11f3b4797dd6@github.com> Message-ID: On Mon, 17 May 2021 20:26:02 GMT, Pavel Rappo wrote: > Right off the bat: I'd be interested to know why an empty content demands special treatment. if an empty content stays empty, it's handled like htmltree.empty in a special case (just like what happens to nocomment) and included in table output. if it's wrapped in a div class=block, the check will not be triggered as it's not empty but yet invalid content, so when the table converts to content that row is lost. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From jjg at openjdk.java.net Tue May 18 04:42:56 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 04:42:56 GMT Subject: RFR: JDK-8263684: Avoid wrapping into BufferedWriter twice Message-ID: Please review a trivial fix to avoid creating an unnecessary `BufferedWriter`. `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test. ------------- Commit messages: - JDK-8263684: Avoid wrapping into BufferedWriter twice Changes: https://git.openjdk.java.net/jdk/pull/4080/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4080&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263684 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4080.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4080/head:pull/4080 PR: https://git.openjdk.java.net/jdk/pull/4080 From dholmes at openjdk.java.net Tue May 18 05:01:46 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 May 2021 05:01:46 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Changes to hotspot-* and serviceability look good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From alanb at openjdk.java.net Tue May 18 05:51:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 05:51:41 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Marked as reviewed by alanb (Reviewer). The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g. test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after. test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters. For uses using ProcessTools then it seems to be very random. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From hannesw at openjdk.java.net Tue May 18 06:59:39 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 18 May 2021 06:59:39 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: On Mon, 17 May 2021 16:54:07 GMT, Hannes Walln?fer wrote: > The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). > > I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". > > A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). > > Here's a list of what references now cause what error messages: > > - `#foo(int` `unterminated signature` > - `#foo((int))` `unexpected parenthesis` > - `#foo(int))` `unexpected parenthesis` > - `#foo(int)x` `unexpected parenthesis` > - `F - `F>` `unexpected input` > > I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". Thanks for reviewing, Pavel! > 1. I think this error is a counterintuitive: > ``` > #foo(int)x > error: unexpected parenthesis > ``` > > > It's `x` that is unexpected, not the parenthesis. It looks correct here, but only coincidentally: > > ``` > #foo(int)) > error: unexpected parenthesis > ``` Yes, you can look at it both ways, either there is a closing parenthesis where it shouldn't be, or there is text following a correctly placed closing parenthesis. We tend to see one or the other depending on whether the text up to the closing parenthesis looks like a proper signature, but it's not as clear to the parser. I still like the more specific message. We can use a more generic "unexpected text" message, but I think it is less useful. > 1. The latter case in your list, `F>`, yields "unexpected text", not "unexpected input". That's my mistake, the resource key ends with `unexpected.input` but the English message is "unexpected text". > 2. Why is there an asymmetry between wording for angle brackets and that of parenthesis? See my answer to point 1, I like the message to be as specific as possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/4068 From hannesw at openjdk.java.net Tue May 18 07:05:42 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 18 May 2021 07:05:42 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link In-Reply-To: References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: On Tue, 18 May 2021 06:56:51 GMT, Hannes Walln?fer wrote: > I still like the more specific message. We can use a more generic "unexpected text" message, but I think it is less useful. Maybe something like "unexpected text after parenthesis"? ------------- PR: https://git.openjdk.java.net/jdk/pull/4068 From prappo at openjdk.java.net Tue May 18 09:06:42 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 18 May 2021 09:06:42 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link In-Reply-To: References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: On Tue, 18 May 2021 06:56:51 GMT, Hannes Walln?fer wrote: > Yes, you can look at it both ways, either there is a closing parenthesis where it shouldn't be, or there is text following a correctly placed closing parenthesis. We tend to see one or the other depending on whether the text up to the closing parenthesis looks like a proper signature, but it's not as clear to the parser. I'd expect the parser to report the leftmost problematic character. ------------- PR: https://git.openjdk.java.net/jdk/pull/4068 From jlahoda at openjdk.java.net Tue May 18 10:00:10 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 18 May 2021 10:00:10 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v3] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/54ba974e..5fa8005a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=01-02 Stats: 22 lines in 2 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From prappo at openjdk.java.net Tue May 18 10:39:40 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 18 May 2021 10:39:40 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: References: <5CZjpnamYjmfmP9v3aliZuz-BwigJFniPbWUKY4PTyE=.5af4003b-6488-43ce-b996-11f3b4797dd6@github.com> Message-ID: <4MXH-9CbFl7rBO0oY8UTbEQbk2jc4-pLi_YrPqaHOwI=.3a84935d-f219-4ba1-9896-51d6a899881e@github.com> On Tue, 18 May 2021 01:42:57 GMT, liach wrote: > if an empty content stays empty, it's handled like htmltree.empty in a special case (just like what happens to nocomment) and included in table output. if it's wrapped in a div class=block, the check will not be triggered as it's not empty but yet invalid content, so when the table converts to content that row is lost. Your analysis together with the fact that this PR changes code that presumably had no such issue in JDK 15 leaves me with more questions. For example, (1) Why does the lower level that prints out HTML leave out pieces of structure? (2) Why does the higher level that creates this structure knows about and works around that behavior of the lower level? ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From prappo at openjdk.java.net Tue May 18 11:03:42 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 18 May 2021 11:03:42 GMT Subject: RFR: JDK-8263684: Avoid wrapping into BufferedWriter twice In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:33:52 GMT, Jonathan Gibbons wrote: > Please review a trivial fix to avoid creating an unnecessary `BufferedWriter`. > > `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test. Changes requested by prappo (Reviewer). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ElementListWriter.java line 79: > 77: try (Writer fileWriter = file.openWriter(); > 78: BufferedWriter out = (fileWriter instanceof BufferedWriter b) ? b > 79: : new BufferedWriter(file.openWriter())) { Don't call `file.openWriter()` second time, reuse `fileWriter` that you already have. ------------- PR: https://git.openjdk.java.net/jdk/pull/4080 From dfuchs at openjdk.java.net Tue May 18 11:33:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 18 May 2021 11:33:44 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too. test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34: > 32: * @run clean NotificationEmissionTest > 33: * @run build NotificationEmissionTest > 34: * @run main NotificationEmissionTest 1 This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From prappo at openjdk.java.net Tue May 18 11:42:38 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 18 May 2021 11:42:38 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: On Tue, 18 May 2021 00:38:40 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to expose the 1 or 2 streams available within javadoc for writing expected or diagnostic output. > > The change at this time is just to _expose_ the streams; followup work may change how we _use_ them. > > There are two points of note: > > * `JavadocTester` is extended to provided access to the javadoc entry point used by the launcher. This is simpler than exec-ing the tool to invoke the entry point, and allows us to use the existing code to capture and analyze the output. > * The initialization of the default streams in `Messager` is deferred, to allow `Messager` to use the values of `System.out` and `System.err` at the time that javadoc is started, instead of when the class was loaded. This is part of the problems described separately in JDK-8267203, but which needs to be addressed here as part of this work. I have two high-level questions: (1) Why would Doclet API expose standard streams given that it already has `jdk.javadoc.doclet.Reporter`? (2) Is `PrintStream` the most appropriate abstraction for a standard stream? (For example, the `javax.tools.Tool` API uses `OutputStream` for that purpose.) ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From github.com+7806504+liach at openjdk.java.net Tue May 18 13:18:52 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 18 May 2021 13:18:52 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 17:39:19 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. So I will share how I reached this as the solution than patching at somewhere else in the code path: First, I directly modified https://github.com/openjdk/jdk/blob/894547d2c102dcbe1f9ec8a1edb11c6b31e4270e/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java#L1293 check to include the case when the contents generated by first-sentence inline tags are invalid (not just empty, so `
          ` would be included). However, this inserts extraneous no-break whitespaces to all-package index and fails one test. Then, I patched at https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java#L145 to make it insert a no-break whitespace in order to prevent cell deletion. However, this breaks `-nocomment`, and I figured that reusing `-nocomment`'s code path would be the best approach as a result, which is the current PR. ---------- > (1) Why does the lower level that prints out HTML leave out pieces of structure? https://github.com/openjdk/jdk/blob/894547d2c102dcbe1f9ec8a1edb11c6b31e4270e/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java#L330-L331 It's done by this piece of code afai see. > (2) Why does the higher level that creates this structure knows about and works around that behavior of the lower level? This would be more fascinating. In that method, there is a whitespace insertion, which is used for like methods without `/** */` comments. So there are two ways to handle the empty comments, and I find out for resolving this issue, reusing the one used by `-nocomment` is easier and more compatible than reusing that used by regular empty methods. -------- So this check in `Table` introduced in [JDK-8256580](https://bugs.openjdk.java.net/browse/JDK-8256580) (#1438) might have been the culprit. If we seek a more comprehensive change, I personally would keep the change introduced in 8256580 and remove the original no-break whitespace insertion, so we consistently yield empty content for empty comments, and we can then properly handle these empty comments downstream. What are your thoughts? Another update: just checked 8256580, and the problem is exactly the same as what we see here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From jjg at openjdk.java.net Tue May 18 13:55:43 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 13:55:43 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: References: Message-ID: <_l9s7wHlsicJIugJQjBBkHnGm6E7VJ9WLsSpD2GtBmM=.37399932-de29-40e0-b4dd-d5d5ef4d190d@github.com> On Mon, 17 May 2021 17:39:19 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. As a matter of style, these days we avoid small files like `First.java` and `Second.java` and put the source instead in a text block in the main test file and write the file(s) on the fly, typically using `ToolBox.writeJavaFiles`. This makes it easier to read the test all at once, instead of switching between small files that are dominated by a legal header. ------------- Changes requested by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4066 From weijun at openjdk.java.net Tue May 18 14:01:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 14:01:41 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs wrote: >> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). >> >> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). >> >> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: >> >> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. >> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. >> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. >> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. >> >> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. >> >> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. >> >> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. >> >> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). >> >> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). >> >> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: >> >> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) >> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) >> ``` >> >> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. > > test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34: > >> 32: * @run clean NotificationEmissionTest >> 33: * @run build NotificationEmissionTest >> 34: * @run main NotificationEmissionTest 1 > > This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well? Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Tue May 18 14:07:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 14:07:38 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman wrote: > The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g. > > test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after. > > test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters. > > For uses using ProcessTools then it seems to be very random. I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From hannesw at openjdk.java.net Tue May 18 14:36:44 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 18 May 2021 14:36:44 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: References: Message-ID: <-_Gmcv_pQ73NjxaH8WBkhax-p3kKIj2nP7BylCJHqIM=.bd8e36e3-c1f8-403a-9496-9f973ecbe216@github.com> On Mon, 17 May 2021 17:39:19 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Thanks for looking into this and doing all the detective work, @liach! Your fix is a viable workaround, but I think we must fix the problem in `Table.java`, which is caused by the maybe surprising behaviour of `isEmpty()` and `isValid()` in `HtmlTree`. At least I find it surprising that a `
          ` with attributes but no content is considered empty but not valid. But regardless of this question, the only safe fix is to replace the `!isEmpty()` check in line 331 of `Table.java` with an `isValid()` check. It's a bit counter-intuitive that a div with an attribute and no content will be "lost" in the process, and maybe the implementation of `HtmlTree.isValid()` should be changed to consider that as valid. But the important thing is to make the `Table` class safe against similar problems in the future. ------------- Changes requested by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4066 From prappo at openjdk.java.net Tue May 18 14:49:44 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 18 May 2021 14:49:44 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 20:40:18 GMT, Jonathan Gibbons wrote: >> Please review a change to overhaul the javadoc support for diagnostics to better leverage the support available in javac. This includes the ability for all javadoc diagnostics to show a "source line and caret" to indicate the position of a reported issue. As a side-effect, it normalizes the formatting of javadoc messages, to be consistent with javac messages. >> >> The primary changes are in the javadoc `Messager` class, and are primarily focussed "downward" on the internal use of the javac `Log.report` method, which is the nexus for reporting methods. There is additional cleanup that could be done in `Messager` in the API it provides to clients, but (for the most part) that is not done in this work. >> >> Additional changes are done to facilitate writing a test for this work, and reflect the current shortcomings of the existing `Doclet` API. Most notably: >> * changes in `Utils` to allow a user-defined taglet to override a built-in taglet >> * changes in `TagletManager` and `Workarounds` to allow a user-defined taglet to access internal API, to workaround API that would be useful to provide on `StandardDoclet` >> >> There are a few minor specific cleanup changes in code style and/or improved comments. >> >> There is one primary new test, `TestDiagsLineCaret.java` which exercises different kinds of diagnostics at different positions in a file, to verify that the source line and a caret are produced as appropriate. >> >> There are additional test changes triggered by the slight change in the format of error messages. Most notably, prefixes like `error -` and `warning -` become `error:` and `warning:`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup This is not a review, but preliminary comments to help me get started with the review. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java line 264: > 262: "jdk.javadoc.internal.doclets.formats.html"); > 263: pkgs.forEach(p -> thisModule.addOpens(p, tagletLoaderUnnamedModule)); > 264: } What's that and the corresponding WorkArounds.accessInternalAPI about? src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 474: > 472: */ > 473: private DiagnosticPosition getDiagnosticPosition(DocTreePath path) { > 474: ToolEnvironment toolEnv = getToolEnv(); toolEnv is unused. src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java line 147: > 145: enter = JavadocEnter.instance(context); > 146: names = Names.instance(context); > 147: externalizableSym = syms.enterClass(syms.java_base, names.fromString("java.io.Externalizable")); What was externalizableSym about and why have you deleted it? test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java line 377: > 375: > 376: // make sure the doclet indeed emits the warning > 377: checkOutput(Output.OUT, true, "C.java:31: warning: invalid usage of tag <"); This is interesting: while the line coordinate of an error has changed in this test, those of [TestSearch.java L676-L679](https://github.com/openjdk/jdk/pull/4074/files#diff-79c641910bccd3bfabdf3912fd24f4858edcd17bdd325555930fd85fba580593L676-L679) from this same PR have not. Mind you, I haven't investigated it yet. test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java line 422: > 420: "--javafx", > 421: "--disable-javafx-strict-checks", > 422: "--no-platform-links", It just happens so that yesterday I [asked](https://github.com/openjdk/jdk/pull/4051#pullrequestreview-660862882) Hannes about proliferation of `--no-platform-links` in tests and now we have 3 more of those in this PR alone. ------------- PR: https://git.openjdk.java.net/jdk/pull/4074 From github.com+7806504+liach at openjdk.java.net Tue May 18 15:36:26 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 18 May 2021 15:36:26 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: > This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. > > This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. > > All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4066/files - new: https://git.openjdk.java.net/jdk/pull/4066/files/13d78642..6e4435cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4066&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4066&range=01-02 Stats: 112 lines in 6 files changed: 40 ins; 59 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4066/head:pull/4066 PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Tue May 18 15:36:30 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 18 May 2021 15:36:30 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: <_l9s7wHlsicJIugJQjBBkHnGm6E7VJ9WLsSpD2GtBmM=.37399932-de29-40e0-b4dd-d5d5ef4d190d@github.com> References: <_l9s7wHlsicJIugJQjBBkHnGm6E7VJ9WLsSpD2GtBmM=.37399932-de29-40e0-b4dd-d5d5ef4d190d@github.com> Message-ID: On Tue, 18 May 2021 13:52:25 GMT, Jonathan Gibbons wrote: >> liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > As a matter of style, these days we avoid small files like `First.java` and `Second.java` and put the source instead in a text block in the main test file and write the file(s) on the fly, typically using `ToolBox.writeJavaFiles`. This makes it easier to read the test all at once, instead of switching between small files that are dominated by a legal header. Addressed both comments from @jonathan-gibbons and @hns. Turns out the `isValid` check is way better, though it took me a bit of time to debug because the row supplied to the table was wrapped in a `ContentBuilder`, which did not have a proper implementation of `isValid` (so when it has an invalid but non-empty content, it reports itself as valid) ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From prappo at openjdk.java.net Tue May 18 15:47:42 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 18 May 2021 15:47:42 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 15:36:26 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Meta: I would appreciate it if next time you could update your PR normally rather than forcefully. Pushing forcefully makes it harder to follow the progression of a PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Tue May 18 16:25:43 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 18 May 2021 16:25:43 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 15:44:31 GMT, Pavel Rappo wrote: > > > Meta: I would appreciate it if next time you could update your PR normally rather than forcefully. Pushing forcefully makes it harder to follow the progression of a PR. For this change, in fact, you can pretty much discard all previous change; the current commit is not related to the previous commit contents, as the way of approach and the test both got rewritten. For squashing and pushing, I thought it was a requirement for JDK pull requests to be merged; maybe the openjdk bot prompted me so before since I cannot find the reference on http://openjdk.java.net/contribute/. Would you mind enlightening me on how to keep commit histories while adhering to the bot's requirements? ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From hannesw at openjdk.java.net Tue May 18 16:42:46 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 18 May 2021 16:42:46 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v2] In-Reply-To: <_l9s7wHlsicJIugJQjBBkHnGm6E7VJ9WLsSpD2GtBmM=.37399932-de29-40e0-b4dd-d5d5ef4d190d@github.com> References: <_l9s7wHlsicJIugJQjBBkHnGm6E7VJ9WLsSpD2GtBmM=.37399932-de29-40e0-b4dd-d5d5ef4d190d@github.com> Message-ID: On Tue, 18 May 2021 13:52:25 GMT, Jonathan Gibbons wrote: >> liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > As a matter of style, these days we avoid small files like `First.java` and `Second.java` and put the source instead in a text block in the main test file and write the file(s) on the fly, typically using `ToolBox.writeJavaFiles`. This makes it easier to read the test all at once, instead of switching between small files that are dominated by a legal header. > Addressed both comments from @jonathan-gibbons and @hns. > > Turns out the `isValid` check is way better, though it took me a bit of time to debug because the row supplied to the table was wrapped in a `ContentBuilder`, which did not have a proper implementation of `isValid` (so when it has an invalid but non-empty content, it reports itself as valid) Thanks @liach. I think I agree with your `ContentBuilder.isValid()` implementation, but this problem shows that the area is a bit of a mine field. It's very easy to have some content dropped silently because some `isValid()` implementation decided it was ok to do so. I'm not sure we need to be protected from ourselves in this way. Unfortunately, we rely on this mechanism quite heavily to suppress unwanted output. I think I want to spend a bit more time looking into this, although I think yours is the proper fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From prappo at openjdk.java.net Tue May 18 17:11:40 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 18 May 2021 17:11:40 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 16:22:56 GMT, liach wrote: > For this change, in fact, you can pretty much discard all previous change; the current commit is not related to the previous commit contents, as the way of approach and the test both got rewritten. Yet, it is preferable to have preceding commits. GitHub and Webrev links refer to commits by their hashes. If you spare these commits, links will break. Broken links make it harder to follow the history. > For squashing and pushing, I thought it was a requirement for JDK pull requests to be merged; maybe the openjdk bot prompted me so before since I cannot find the reference on [http://openjdk.java.net/contribute](http://openjdk.java.net/contribute/). Would you mind enlightening me on how to keep commit histories while adhering to the bot's requirements? The page you refer to, http://openjdk.java.net/contribute/, is somewhat outdated. While it is being updated, may I refer you to https://wiki.openjdk.java.net/display/SKARA instead? In particular, please read https://wiki.openjdk.java.net/display/SKARA/FAQ. As a PR author the only thing you need to be concerned with, from a VCS perspective, is that your PR has no conflicts with the master. If that's the case, all the rebasing and squashing will be done for you automatically. Your best course of action is to respond to feedback normally by adding commits to your PR branch, not by overwriting them. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From jjg at openjdk.java.net Tue May 18 17:23:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 17:23:04 GMT Subject: RFR: JDK-8266856 Make element void Message-ID: Please review a simple fix to treat `war` as a void element. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into wbr - JDK-8266856: Make element void Changes: https://git.openjdk.java.net/jdk/pull/4098/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4098&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266856 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4098.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4098/head:pull/4098 PR: https://git.openjdk.java.net/jdk/pull/4098 From vromero at openjdk.java.net Tue May 18 17:39:40 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 18 May 2021 17:39:40 GMT Subject: RFR: JDK-8266856 Make element void In-Reply-To: References: Message-ID: On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons wrote: > Please review a simple fix to treat `war` as a void element. test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java line 154: > 152: * > 153: *

          Test current time is at night

          > 154: *

          Testtext

          this is a positive test shouldnt we have negative tests too? ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From mchung at openjdk.java.net Tue May 18 17:43:39 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 18 May 2021 17:43:39 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. I reviewed non-client areas. Looks okay. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From prappo at openjdk.java.net Tue May 18 18:00:45 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 18 May 2021 18:00:45 GMT Subject: RFR: JDK-8266856 Make element void In-Reply-To: References: Message-ID: On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons wrote: > Please review a simple fix to treat `war` as a void element. I wonder if we could teach JavaDoc types that model HTML that void elements do not require end tags. Before this change, WBR required an end tag despite being void: https://github.com/jonathan-gibbons/jdk/blob/8a96c703771224990504cd258dd737e10d325f68/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java#L954-L968 Failing that, we could have a test to catch such inconsistencies. ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Tue May 18 18:01:19 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 18:01:19 GMT Subject: RFR: JDK-8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence [v2] In-Reply-To: References: Message-ID: > Please review a change for JavaDoc, for the Standard Doclet to copy legal header files into the generated docs from a default or designated directory. 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 four additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8259530 - use DocFile.copy to install files - Merge remote-tracking branch 'upstream/master' into JDK-8259530 - JDK-8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3954/files - new: https://git.openjdk.java.net/jdk/pull/3954/files/eb4b9d5a..00b62ef6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3954&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3954&range=00-01 Stats: 25260 lines in 823 files changed: 9594 ins; 10115 del; 5551 mod Patch: https://git.openjdk.java.net/jdk/pull/3954.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3954/head:pull/3954 PR: https://git.openjdk.java.net/jdk/pull/3954 From jjg at openjdk.java.net Tue May 18 18:05:37 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 18:05:37 GMT Subject: RFR: JDK-8266651: Convert Table method parameters from String to Content In-Reply-To: References: Message-ID: On Wed, 12 May 2021 12:43:48 GMT, Hannes Walln?fer wrote: > This changes the parameter type for the tab label from `String` to `Content` in the `formats.html.Table` `addTab` and `setDefaultTab` methods. The change is straightforward because the tab name was converted to `Content` anyway, and all resources are readily available in `Content` form. > > I briefly considered overriding the `hashCode` and `equals` methods in `Text` to be depend on content instead of object identity, but decided against it. This would just cover up bugs where we generate the same content twice. (In the process I made sure we currently don't have any such cases where a `Text` instance is compared to another one with the same string content.) NIce. At some point, we should have a design discussion on the relative merits of `Contents.getContent` vs shared fields. FWIW, the current set of shared fields is based on the evolution of history, and to some extent restricted by what was possible at the time. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3994 From weijun at openjdk.java.net Tue May 18 21:44:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:44:43 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: adjust order of VM options ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4071/files - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00-01 Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From iris at openjdk.java.net Tue May 18 22:45:39 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 18 May 2021 22:45:39 GMT Subject: RFR: JDK-8266856 Make element void In-Reply-To: References: Message-ID: On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons wrote: > Please review a simple fix to treat `war` as a void element. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Tue May 18 23:30:42 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 23:30:42 GMT Subject: RFR: JDK-8266856 Make element void In-Reply-To: References: Message-ID: On Tue, 18 May 2021 17:36:44 GMT, Vicente Romero wrote: >> Please review a simple fix to treat `war` as a void element. > > test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java line 154: > >> 152: * >> 153: *

          Test current time is at night

          >> 154: *

          Testtext

          > > this is a positive test shouldnt we have negative tests too? I guess I felt this was close to a `noreg-trivial` change to an element that is rarely used, at least in doc comments. The only reason there's a test at at is because it is a holdover from the HTML5 conversion. ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Tue May 18 23:44:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 23:44:38 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: On Tue, 18 May 2021 11:39:45 GMT, Pavel Rappo wrote: > I have two high-level questions: (1) Why would Doclet API expose standard streams given that it already has `jdk.javadoc.doclet.Reporter`? (2) Is `PrintStream` the most appropriate abstraction for a standard stream? (For example, the `javax.tools.Tool` API uses `OutputStream` for that purpose.) 1. Reporter says nothing about streams. javadoc is inconsistent with javac and when run with two streams, it sends warnings and errors to one stream and notes to the other. javac now sends all diagnostics to the error stream, leaving stdout for command-line help etc. This PR is part 1 of 2; having made both streams explicitly available here, part 2 will align javadoc with javac. Also, DocletEnvironment seemed a more appropriate place to expose the streams. 2. For passing in streams/writers, higher level types, like OutputStream and Writer, are OK, because they can be wrapped into the more convenient forms. For passing out streams/writers, you want to pass out the Print--- forms, to save the user having to wrap and flush and close them. ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From jjg at openjdk.java.net Tue May 18 23:50:40 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 23:50:40 GMT Subject: RFR: JDK-8266856 Make element void In-Reply-To: References: Message-ID: <4mjIMLrxK1oiJjDi3StlMTZuUvXFrOQzDglnBZlqd2s=.73967117-bd13-4d9b-8596-b6081612f7d0@github.com> On Tue, 18 May 2021 17:57:59 GMT, Pavel Rappo wrote: > I wonder if we could teach JavaDoc types that model HTML that void elements do not require end tags. Before this change, WBR required an end tag despite being void: https://github.com/jonathan-gibbons/jdk/blob/8a96c703771224990504cd258dd737e10d325f68/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java#L954-L968 > > Failing that, we could have a test to catch such inconsistencies. I'm not sure I completely understand your question. There are two different distinct type systems in play. 1. There is doclint's HtmlTag, which provides declarations and properties for *checking* HTML. 2. There is the Standard Doclet's TagName, which provides declarations and properties for *writing* HTML. For better or worse, these two systems are distinct and do not fully overlap. The set of tags is different, and the properties you need when parsing/checking are somewhat different from those needed when generating HTML. And while it is easier to imagine merging them now than 6 months ago (they used to be in separate modules) it would still be a big architectural change to try and merge them, and way bigger than the current problem warrants. The output case was OK, as shown in the link you gave. It was the input side that was broken, and that is now fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Tue May 18 23:53:41 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 18 May 2021 23:53:41 GMT Subject: RFR: JDK-8263684: Avoid wrapping into BufferedWriter twice In-Reply-To: References: Message-ID: On Tue, 18 May 2021 11:00:19 GMT, Pavel Rappo wrote: >> Please review a trivial fix to avoid creating an unnecessary `BufferedWriter`. >> >> `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ElementListWriter.java line 79: > >> 77: try (Writer fileWriter = file.openWriter(); >> 78: BufferedWriter out = (fileWriter instanceof BufferedWriter b) ? b >> 79: : new BufferedWriter(file.openWriter())) { > > Don't call `file.openWriter()` second time, reuse `fileWriter` that you already have. oops. that's what I meant; thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/4080 From jjg at openjdk.java.net Wed May 19 00:00:15 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 00:00:15 GMT Subject: RFR: JDK-8263684: Avoid wrapping into BufferedWriter twice [v2] In-Reply-To: References: Message-ID: > Please review a trivial fix to avoid creating an unnecessary `BufferedWriter`. > > `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: address review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4080/files - new: https://git.openjdk.java.net/jdk/pull/4080/files/938ca902..11be026f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4080&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4080&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4080.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4080/head:pull/4080 PR: https://git.openjdk.java.net/jdk/pull/4080 From igraves at openjdk.java.net Wed May 19 03:50:52 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 19 May 2021 03:50:52 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching Message-ID: 8267329: Modernize Javadoc code to use instanceof with pattern matching ------------- Commit messages: - Updating javadoc to use instanceof patterns Changes: https://git.openjdk.java.net/jdk/pull/4105/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267329 Stats: 85 lines in 25 files changed: 0 ins; 11 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/4105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4105/head:pull/4105 PR: https://git.openjdk.java.net/jdk/pull/4105 From igraves at openjdk.java.net Wed May 19 04:03:03 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 19 May 2021 04:03:03 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v2] In-Reply-To: References: Message-ID: > 8267329: Modernize Javadoc code to use instanceof with pattern matching Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4105/files - new: https://git.openjdk.java.net/jdk/pull/4105/files/e09bbf4c..d4634500 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=00-01 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4105/head:pull/4105 PR: https://git.openjdk.java.net/jdk/pull/4105 From jlahoda at openjdk.java.net Wed May 19 08:00:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 19 May 2021 08:00:12 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing various error-related bugs. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/5fa8005a..0875377b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=02-03 Stats: 117 lines in 6 files changed: 94 ins; 13 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From prappo at openjdk.java.net Wed May 19 08:16:38 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 08:16:38 GMT Subject: RFR: JDK-8263684: Avoid wrapping into BufferedWriter twice [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:00:15 GMT, Jonathan Gibbons wrote: >> Please review a trivial fix to avoid creating an unnecessary `BufferedWriter`. >> >> `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > address review feedback Update the copyright year and you're good to go. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4080 From prappo at openjdk.java.net Wed May 19 09:56:40 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 09:56:40 GMT Subject: RFR: JDK-8266856 Make element void In-Reply-To: <4mjIMLrxK1oiJjDi3StlMTZuUvXFrOQzDglnBZlqd2s=.73967117-bd13-4d9b-8596-b6081612f7d0@github.com> References: <4mjIMLrxK1oiJjDi3StlMTZuUvXFrOQzDglnBZlqd2s=.73967117-bd13-4d9b-8596-b6081612f7d0@github.com> Message-ID: On Tue, 18 May 2021 23:48:14 GMT, Jonathan Gibbons wrote: > I'm not sure I completely understand your question. I would like to have a mechanism to guard us from inconsistencies like this, is all. Consider adding something like the below white-box test.
          Test import jdk.javadoc.internal.doclets.formats.html.markup.HtmlTree; import jdk.javadoc.internal.doclets.formats.html.markup.TagName; import jdk.javadoc.internal.doclint.HtmlTag; /* * @test * @bug 8266856 * @modules jdk.javadoc/jdk.javadoc.internal.doclint * jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.markup * @run main TestVoidHtmlElements */ public class TestVoidHtmlElements { public static void main(String[] args) { int checks = 0; for (HtmlTag htmlTag : HtmlTag.values()) { TagName tagName = tagNameOf(htmlTag); if (tagName == null) { continue; } checks++; boolean elementIsVoid = new HtmlTree(tagName).isVoid(); boolean elementHasNoEndTag = htmlTag.endKind == HtmlTag.EndKind.NONE; if (elementIsVoid != elementHasNoEndTag) { throw new AssertionError(htmlTag + ", " + elementIsVoid + ", " + elementHasNoEndTag); } } if (checks == 0) { // suspicious throw new AssertionError(); } } private static TagName tagNameOf(HtmlTag htmlTag) { TagName tagName; try { tagName = TagName.valueOf(htmlTag.name()); // map HtmlTag to TagName } catch (IllegalArgumentException ignored) { return null; } return tagName; } }
          ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From hannesw at openjdk.java.net Wed May 19 09:57:41 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 19 May 2021 09:57:41 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 15:36:26 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Looks good! I briefly thought we might want to make `isValid()` a bit more liberal in what it considers a valid HTML element, but after taking a closer look I think it's fine as it is. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4066 From prappo at openjdk.java.net Wed May 19 10:05:42 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 10:05:42 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 15:36:26 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Changes requested by prappo (Reviewer). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java line 99: > 97: for (Content content: contents) { > 98: if (content.isValid()) > 99: return true; If this is correct, then it deserves a comment. The reason is that it looks counterintuitive: I would expect isValid to have the semantics of &&, not ||. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Wed May 19 10:43:29 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 19 May 2021 10:43:29 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v4] In-Reply-To: References: Message-ID: > This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. > > This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. > > All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. liach has updated the pull request incrementally with one additional commit since the last revision: Specify further what isValid expects and how it is used ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4066/files - new: https://git.openjdk.java.net/jdk/pull/4066/files/6e4435cd..93c50905 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4066&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4066&range=02-03 Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4066/head:pull/4066 PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Wed May 19 10:43:31 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 19 May 2021 10:43:31 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 10:02:47 GMT, Pavel Rappo wrote: >> liach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java line 99: > >> 97: for (Content content: contents) { >> 98: if (content.isValid()) >> 99: return true; > > If this is correct, then it deserves a comment. The reason is that it looks counterintuitive: I would expect isValid to have the semantics of &&, not ||. I looked at the usages of `isValid`; all of them are guarding the calls to `HtmlTree.add`, in `SerialFieldWriter`, `TagletWriter`, and `HtmlTree.add` itself. Hence, if a content builder has both valid and invalid parts, I still believe it should be added to the html tree, where only the valid subparts can be accepted. I shall document the reasons in an `implSpec` section. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From hannesw at openjdk.java.net Wed May 19 11:05:06 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 19 May 2021 11:05:06 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link [v2] In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: > The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). > > I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". > > A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). > > Here's a list of what references now cause what error messages: > > - `#foo(int` `unterminated signature` > - `#foo((int))` `unexpected parenthesis` > - `#foo(int))` `unexpected parenthesis` > - `#foo(int)x` `unexpected parenthesis` > - `F - `F>` `unexpected input` > > I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8264181: Change error message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4068/files - new: https://git.openjdk.java.net/jdk/pull/4068/files/8c3ab58b..a122027e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4068&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4068&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4068/head:pull/4068 PR: https://git.openjdk.java.net/jdk/pull/4068 From hannesw at openjdk.java.net Wed May 19 11:08:39 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 19 May 2021 11:08:39 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link [v2] In-Reply-To: References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: On Wed, 19 May 2021 11:05:06 GMT, Hannes Walln?fer wrote: >> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). >> >> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". >> >> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). >> >> Here's a list of what references now cause what error messages: >> >> - `#foo(int` `unterminated signature` >> - `#foo((int))` `unexpected parenthesis` >> - `#foo(int))` `unexpected parenthesis` >> - `#foo(int)x` `unexpected parenthesis` >> - `F> - `F>` `unexpected input` >> >> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8264181: Change error message I changed the error message to "unexpected text after parenthesis". This is a more informative variant of the existing "unexpected text" and always correct as the error is thrown when there is text following the first closing parenthesis. ------------- PR: https://git.openjdk.java.net/jdk/pull/4068 From hannesw at openjdk.java.net Wed May 19 11:30:39 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 19 May 2021 11:30:39 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 10:38:02 GMT, liach wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java line 99: >> >>> 97: for (Content content: contents) { >>> 98: if (content.isValid()) >>> 99: return true; >> >> If this is correct, then it deserves a comment. The reason is that it looks counterintuitive: I would expect isValid to have the semantics of &&, not ||. > > I looked at the usages of `isValid`; all of them are guarding the calls to `HtmlTree.add`, in `SerialFieldWriter`, `TagletWriter`, and `HtmlTree.add` itself. Hence, if a content builder has both valid and invalid parts, I still believe it should be added to the html tree, where only the valid subparts can be accepted. I shall document the reasons in an `implSpec` section. I was initially unsure about this, too. But take a look at `HtmlTree.add(Content)` which handles `ContentBuilder` arguments in the following way: if (content instanceof ContentBuilder) { ((ContentBuilder) content).contents.forEach(this::add); } Thus, if a ContentBuilder contains any valid Content objects, they will be added, while the invalid ones will be silently dropped. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From prappo at openjdk.java.net Wed May 19 11:31:42 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 11:31:42 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 04:03:03 GMT, Ian Graves wrote: >> 8267329: Modernize Javadoc code to use instanceof with pattern matching > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Typos Ian, thanks for doing this carefully and for getting rid of superfluous null checks. Opinion: prefer shorter binder names. `instanceof AVeryLongTypeName aVeryLongTypeName` feels verbose given the small scope of a binder. (You don't need to change anything.) Update the copyright year. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkOutputImpl.java line 55: > 53: public void append(Object o) { > 54: output.append(o instanceof String str ? > 55: str : o.toString()); A briefer equivalent would look like this: output.append(o.toString); src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 71: > 69: if (!(instance instanceof Messager messenger)) > 70: throw new InternalError("no messager instance!"); > 71: return messenger; Every project has quirks. Out of many quirks of JavaDoc, we love this one the most. Perhaps you misread that type's name: it's Messager [sic!]. Please rename the variable either to `messager` or to a shorter one. ------------- Changes requested by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4105 From prappo at openjdk.java.net Wed May 19 12:11:41 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 12:11:41 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 11:27:39 GMT, Hannes Walln?fer wrote: >> I looked at the usages of `isValid`; all of them are guarding the calls to `HtmlTree.add`, in `SerialFieldWriter`, `TagletWriter`, and `HtmlTree.add` itself. Hence, if a content builder has both valid and invalid parts, I still believe it should be added to the html tree, where only the valid subparts can be accepted. I shall document the reasons in an `implSpec` section. > > I was initially unsure about this, too. But take a look at `HtmlTree.add(Content)` which handles `ContentBuilder` arguments in the following way: > > if (content instanceof ContentBuilder) { > ((ContentBuilder) content).contents.forEach(this::add); > } > > Thus, if a ContentBuilder contains any valid Content objects, they will be added, while the invalid ones will be silently dropped. Something is wrong, but I cannot quite put my finger on it. I think this PR merely highlights a pre-existing issue that should be investigated separately. I'm surprised by the concept of validity for the **generated** content. I'm also surprised by the fact that a part of the content can be silently omitted depending on whether or not that part is valid. This suggests that javadoc uses instances of HtmlTree as its data model which it shouldn't do. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Wed May 19 12:34:42 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 19 May 2021 12:34:42 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: Message-ID: <9uCbuyW44Zkar9tC-uBCY59YhqQ1vJHTfSqzWAAOFJ4=.845a7691-89cf-4706-91ca-ff02e87d4884@github.com> On Wed, 19 May 2021 12:08:27 GMT, Pavel Rappo wrote: >> I was initially unsure about this, too. But take a look at `HtmlTree.add(Content)` which handles `ContentBuilder` arguments in the following way: >> >> if (content instanceof ContentBuilder) { >> ((ContentBuilder) content).contents.forEach(this::add); >> } >> >> Thus, if a ContentBuilder contains any valid Content objects, they will be added, while the invalid ones will be silently dropped. > > Something is wrong, but I cannot quite put my finger on it. I think this PR merely highlights a pre-existing issue that should be investigated separately. > > I'm surprised by the concept of validity for the **generated** content. I'm also surprised by the fact that a part of the content can be silently omitted depending on whether or not that part is valid. This suggests that javadoc uses instances of HtmlTree as its data model which it shouldn't do. This special path for `ContentBuilder` was added in [JDK-8026370](https://bugs.openjdk.java.net/browse/JDK-8026370), commit 99e02c21cdb25bd113dd751f63f0c1fd27f07b57, which, surprisingly, is like the opposite of this missing empty tag issue; the `isValid` was not touched since its addition from long ago in [JDK-6851834](https://bugs.openjdk.java.net/browse/JDK-6851834). ContentBuilder itself was introduced in [JDK-8011642](https://bugs.openjdk.java.net/browse/JDK-8011642) or commit f961eafe351c24536e539819e9efb14272701195. It is not quite clear to me the original intentions of `isValid` from over one decade ago. One of the clue may be that when `ContentBuilder` was added, jonathan maybe did not have `isValid` handling in mind? And we are now in a somewhat weird shape. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From hannesw at openjdk.java.net Wed May 19 13:04:40 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 19 May 2021 13:04:40 GMT Subject: Integrated: JDK-8266651: Convert Table method parameters from String to Content In-Reply-To: References: Message-ID: On Wed, 12 May 2021 12:43:48 GMT, Hannes Walln?fer wrote: > This changes the parameter type for the tab label from `String` to `Content` in the `formats.html.Table` `addTab` and `setDefaultTab` methods. The change is straightforward because the tab name was converted to `Content` anyway, and all resources are readily available in `Content` form. > > I briefly considered overriding the `hashCode` and `equals` methods in `Text` to be depend on content instead of object identity, but decided against it. This would just cover up bugs where we generate the same content twice. (In the process I made sure we currently don't have any such cases where a `Text` instance is compared to another one with the same string content.) This pull request has now been integrated. Changeset: 12050f04 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/12050f04ca1a170d9dece1fd902dc8306c746eb8 Stats: 60 lines in 8 files changed: 1 ins; 3 del; 56 mod 8266651: Convert Table method parameters from String to Content Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/3994 From prappo at openjdk.java.net Wed May 19 13:32:58 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 13:32:58 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link [v2] In-Reply-To: References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: On Wed, 19 May 2021 11:05:06 GMT, Hannes Walln?fer wrote: >> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). >> >> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". >> >> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). >> >> Here's a list of what references now cause what error messages: >> >> - `#foo(int` `unterminated signature` >> - `#foo((int))` `unexpected parenthesis` >> - `#foo(int))` `unexpected parenthesis` >> - `#foo(int)x` `unexpected parenthesis` >> - `F> - `F>` `unexpected input` >> >> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8264181: Change error message Thanks for updating the error message, Hannes. This PR adds tests for 2 out of 6 items from your list. I think it makes sense to ensure that the remaining 4 items are also tested. I can see that one more item is covered by the existing RefBadParens. That said, I couldn't find tests that cover these 3 cases: #foo(int #foo(int)x F References: Message-ID: On Sun, 21 Feb 2021 18:11:06 GMT, Jonathan Gibbons wrote: > The standard doclet works by creating `HtmlDocument` objects and then writing them out. Writing them can be safely done on a separate thread, and doing so results in about an 8% speedup, by overlapping the write/IO time with the time to generate the next page to be written. > > The overall impact on the codebase is deliberately small, coming down to a critical `if` statement in `HtmlDocletWriter` to "write now" or "write later". As such, it is easy to disable the feature if necessary, although no issues have been found in practice. The background writer uses an `ExecutorService`, which provides a lot of flexibility, but experiments show that it is sufficient to use a single background thread and to block if new tasks come available while writing a file. > > The feature is "default on", with a hidden option to disable it if necessary. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2665 From duke at openjdk.java.net Wed May 19 15:50:44 2021 From: duke at openjdk.java.net (duke) Date: Wed, 19 May 2021 15:50:44 GMT Subject: Withdrawn: 8241356: Use a more reliable way to encode Symbol flags In-Reply-To: References: Message-ID: <0cdjiuSuy37cJp7SH1ogwlz5bRqvxI9YRKMsimK4kNY=.54c34a52-fb82-4266-8057-feba255d38a3@github.com> On Fri, 29 Jan 2021 17:31:20 GMT, Jan Lahoda wrote: > [This is a GitHub copy of: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014389.html ] > > Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol. > > We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy. > > We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile. > > My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows: > -the current long-based Flags are split into 4 groups: > --"flat" Flags, long based, work exactly as before. > --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well. > > There are ~~37~~ 40 "flat" flags and ~~16~~ 17 TypeSymbolFlags (methods and vars have less flags), 57 in total. This gives us at least 7 new flags before we run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like: > -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable) > -split TypeSymbolFlags into Class/Package/MethodSymbolFlags > > The positives of this solution include: > -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe > -improves the abstractions at least for some flags > -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments) > -the performances appears to be acceptable. > > The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code. > > Some more alternatives: > -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags). > -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it . > > Any feedback is welcome! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2316 From hannesw at openjdk.java.net Wed May 19 16:03:19 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 19 May 2021 16:03:19 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link [v3] In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: > The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). > > I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". > > A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). > > Here's a list of what references now cause what error messages: > > - `#foo(int` `unterminated signature` > - `#foo((int))` `unexpected parenthesis` > - `#foo(int))` `unexpected parenthesis` > - `#foo(int)x` `unexpected parenthesis` > - `F - `F>` `unexpected input` > > I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8264181: Add test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4068/files - new: https://git.openjdk.java.net/jdk/pull/4068/files/a122027e..733e42f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4068&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4068&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4068/head:pull/4068 PR: https://git.openjdk.java.net/jdk/pull/4068 From hannesw at openjdk.java.net Wed May 19 16:07:40 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 19 May 2021 16:07:40 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link [v2] In-Reply-To: References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: <2RipvnELjX30txxGR0h2gZTxEerxHhOBH5bRf_g5_rY=.e324f18a-88a1-40a8-92f7-a99b36395d7d@github.com> On Wed, 19 May 2021 13:29:57 GMT, Pavel Rappo wrote: > ``` > #foo(int > #foo(int)x > F ``` Missing closing parenthesis is tested in `UnterminatedSignature`. I've added `UnterminatedSignature1` for the missing right angle bracket case. Text after closing parens is handled in `RefBadParens1` (it doesn't matter which character follows the closing parenthesis; I changed the test reference to look more like the one above). ------------- PR: https://git.openjdk.java.net/jdk/pull/4068 From prappo at openjdk.java.net Wed May 19 16:25:38 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 16:25:38 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:41:47 GMT, Jonathan Gibbons wrote: > 1. Reporter says nothing about streams. javadoc is inconsistent with javac and when run with two streams, it sends warnings and errors to one stream and notes to the other. javac now sends all diagnostics to the error stream, leaving stdout for command-line help etc. This PR is part 1 of 2; having made both streams explicitly available here, part 2 will align javadoc with javac. Also, DocletEnvironment seemed a more appropriate place to expose the streams. I can see that Reporter does not mention streams. But should it mention them given that Reporter is a higher-level abstraction? If a particular mapping between diagnostic kinds and standard streams is desired can it be achieved by configuring Reporter out of band? What would be the best code locations to look at to get familiar with how javac works with standard streams, diagnostic output, and the like? Don't get me wrong, by asking these questions I'm trying to better understand the intent and the design. ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From prappo at openjdk.java.net Wed May 19 16:37:43 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 16:37:43 GMT Subject: RFR: JDK-8264181: javadoc tool Incorrect error message about malformed link [v3] In-Reply-To: References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: On Wed, 19 May 2021 16:03:19 GMT, Hannes Walln?fer wrote: >> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). >> >> I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". >> >> A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). >> >> Here's a list of what references now cause what error messages: >> >> - `#foo(int` `unterminated signature` >> - `#foo((int))` `unexpected parenthesis` >> - `#foo(int))` `unexpected parenthesis` >> - `#foo(int)x` `unexpected parenthesis` >> - `F> - `F>` `unexpected input` >> >> I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8264181: Add test Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4068 From igraves at openjdk.java.net Wed May 19 16:57:04 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 19 May 2021 16:57:04 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: > 8267329: Modernize Javadoc code to use instanceof with pattern matching Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Name shortening. Copyright updates. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4105/files - new: https://git.openjdk.java.net/jdk/pull/4105/files/d4634500..f52300f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=01-02 Stats: 75 lines in 21 files changed: 0 ins; 1 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/4105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4105/head:pull/4105 PR: https://git.openjdk.java.net/jdk/pull/4105 From jjg at openjdk.java.net Wed May 19 17:03:41 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 17:03:41 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: <9uCbuyW44Zkar9tC-uBCY59YhqQ1vJHTfSqzWAAOFJ4=.845a7691-89cf-4706-91ca-ff02e87d4884@github.com> References: <9uCbuyW44Zkar9tC-uBCY59YhqQ1vJHTfSqzWAAOFJ4=.845a7691-89cf-4706-91ca-ff02e87d4884@github.com> Message-ID: On Wed, 19 May 2021 12:31:20 GMT, liach wrote: >> Something is wrong, but I cannot quite put my finger on it. I think this PR merely highlights a pre-existing issue that should be investigated separately. >> >> I'm surprised by the concept of validity for the **generated** content. I'm also surprised by the fact that a part of the content can be silently omitted depending on whether or not that part is valid. This suggests that javadoc uses instances of HtmlTree as its data model which it shouldn't do. > > This special path for `ContentBuilder` was added in [JDK-8026370](https://bugs.openjdk.java.net/browse/JDK-8026370), commit 99e02c21cdb25bd113dd751f63f0c1fd27f07b57, which, surprisingly, is like the opposite of this missing empty tag issue; the `isValid` was not touched since its addition from long ago in [JDK-6851834](https://bugs.openjdk.java.net/browse/JDK-6851834). ContentBuilder itself was introduced in [JDK-8011642](https://bugs.openjdk.java.net/browse/JDK-8011642) or commit f961eafe351c24536e539819e9efb14272701195. > > It is not quite clear to me the original intentions of `isValid` from over one decade ago. One of the clue may be that when `ContentBuilder` was added, jonathan maybe did not have `isValid` handling in mind? And we are now in a somewhat weird shape. My general recollection is that this dates all the way back to the introduction of `HtmlTree`. Prior to that, HTML was generated directly with `PrintWriter.print` calls (!) and that code gave rise to some notable errors; specifically, empty lists. A list was started, beginning with `
            ` or `
            `, items were added, and the list was closed. Except that sometimes no items were added. Which was generally tolerated by browsers, but not by checkers like `HTML Tidy` when we started using that. Roll the clock forward to the introduction of `HtmlTree`. For the most part, this was done at that time by a mostly direct translation of `print` calls into creating and adding `HtmlTree` nodes. The "empty list" problem was solved by checking _ex post facto_ that nodes were valid before adding them into an enclosing container. The conversion was a big enough job in itself that it was not reasonable to restructure the code at that time to decide whether we should even be creating the list in the first place. It would be better to check the collection of items to be added up front, and not attempt to create an invalid HTML list with no contents in the first place. I've not (yet) followed this thread in detail, but IMO the `isValid` mechanism may be a wart of Technical Debt that it is time to remove. If nothing else, the general improvements to the API over the past few years should mean that we should always and only create valid nodes in the first place, and that we should never create or need to check for invalid nodes. That being said, such a change may be a Big Deal and should probably be handled separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From jjg at openjdk.java.net Wed May 19 17:07:41 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 17:07:41 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: References: <9uCbuyW44Zkar9tC-uBCY59YhqQ1vJHTfSqzWAAOFJ4=.845a7691-89cf-4706-91ca-ff02e87d4884@github.com> Message-ID: <0qfPT9oY6iesqGbfS7M3HUR2Pqu5R7MofkvYeTWdbsk=.ab52cbd3-2c70-4b11-913d-5220c36fdde4@github.com> On Wed, 19 May 2021 17:01:08 GMT, Jonathan Gibbons wrote: >> This special path for `ContentBuilder` was added in [JDK-8026370](https://bugs.openjdk.java.net/browse/JDK-8026370), commit 99e02c21cdb25bd113dd751f63f0c1fd27f07b57, which, surprisingly, is like the opposite of this missing empty tag issue; the `isValid` was not touched since its addition from long ago in [JDK-6851834](https://bugs.openjdk.java.net/browse/JDK-6851834). ContentBuilder itself was introduced in [JDK-8011642](https://bugs.openjdk.java.net/browse/JDK-8011642) or commit f961eafe351c24536e539819e9efb14272701195. >> >> It is not quite clear to me the original intentions of `isValid` from over one decade ago. One of the clue may be that when `ContentBuilder` was added, jonathan maybe did not have `isValid` handling in mind? And we are now in a somewhat weird shape. > > My general recollection is that this dates all the way back to the introduction of `HtmlTree`. Prior to that, HTML was generated directly with `PrintWriter.print` calls (!) and that code gave rise to some notable errors; specifically, empty lists. A list was started, beginning with `
              ` or `
              `, items were added, and the list was closed. Except that sometimes no items were added. Which was generally tolerated by browsers, but not by checkers like `HTML Tidy` when we started using that. > > Roll the clock forward to the introduction of `HtmlTree`. For the most part, this was done at that time by a mostly direct translation of `print` calls into creating and adding `HtmlTree` nodes. The "empty list" problem was solved by checking _ex post facto_ that nodes were valid before adding them into an enclosing container. > > The conversion was a big enough job in itself that it was not reasonable to restructure the code at that time to decide whether we should even be creating the list in the first place. It would be better to check the collection of items to be added up front, and not attempt to create an invalid HTML list with no contents in the first place. > > I've not (yet) followed this thread in detail, but IMO the `isValid` mechanism may be a wart of Technical Debt that it is time to remove. If nothing else, the general improvements to the API over the past few years should mean that we should always and only create valid nodes in the first place, and that we should never create or need to check for invalid nodes. That being said, such a change may be a Big Deal and should probably be handled separately. Exercise for the reader: it may be an interesting exercise to temporarily instrument javadoc to see if we still create any invalid nodes in either `make docs` or in any test. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Wed May 19 17:14:38 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 19 May 2021 17:14:38 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v4] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 10:43:29 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Specify further what isValid expects and how it is used Since the problems around `isValid` is somehow deeper and beyond the scope of 8267219, I will mark this ready for integrate. The discussion on `isValid` deserves its dedicated issue. Feel free to point out other problems before anyone sponsors. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Wed May 19 17:14:38 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 19 May 2021 17:14:38 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v3] In-Reply-To: <0qfPT9oY6iesqGbfS7M3HUR2Pqu5R7MofkvYeTWdbsk=.ab52cbd3-2c70-4b11-913d-5220c36fdde4@github.com> References: <9uCbuyW44Zkar9tC-uBCY59YhqQ1vJHTfSqzWAAOFJ4=.845a7691-89cf-4706-91ca-ff02e87d4884@github.com> <0qfPT9oY6iesqGbfS7M3HUR2Pqu5R7MofkvYeTWdbsk=.ab52cbd3-2c70-4b11-913d-5220c36fdde4@github.com> Message-ID: On Wed, 19 May 2021 17:04:12 GMT, Jonathan Gibbons wrote: >> My general recollection is that this dates all the way back to the introduction of `HtmlTree`. Prior to that, HTML was generated directly with `PrintWriter.print` calls (!) and that code gave rise to some notable errors; specifically, empty lists. A list was started, beginning with `
                ` or `
                `, items were added, and the list was closed. Except that sometimes no items were added. Which was generally tolerated by browsers, but not by checkers like `HTML Tidy` when we started using that. >> >> Roll the clock forward to the introduction of `HtmlTree`. For the most part, this was done at that time by a mostly direct translation of `print` calls into creating and adding `HtmlTree` nodes. The "empty list" problem was solved by checking _ex post facto_ that nodes were valid before adding them into an enclosing container. >> >> The conversion was a big enough job in itself that it was not reasonable to restructure the code at that time to decide whether we should even be creating the list in the first place. It would be better to check the collection of items to be added up front, and not attempt to create an invalid HTML list with no contents in the first place. >> >> I've not (yet) followed this thread in detail, but IMO the `isValid` mechanism may be a wart of Technical Debt that it is time to remove. If nothing else, the general improvements to the API over the past few years should mean that we should always and only create valid nodes in the first place, and that we should never create or need to check for invalid nodes. That being said, such a change may be a Big Deal and should probably be handled separately. > > Exercise for the reader: it may be an interesting exercise to temporarily instrument javadoc to see if we still create any invalid nodes in either `make docs` or in any test. Thanks jonathan! Since I have documented the behavior of `isValid` and all the tests pass, I would assume my changes as of now is ready for this issue. For the further practice, I guess `isValid()` calls will be replaced by `!isEmpty()` then? But this revamp is out of the scope of this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From hannesw at openjdk.java.net Wed May 19 17:20:41 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 19 May 2021 17:20:41 GMT Subject: Integrated: JDK-8264181: javadoc tool Incorrect error message about malformed link In-Reply-To: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> References: <-eGwNFF68bUqkp168fGOBj8vHrXpruk0ACCtM4s5hbo=.cf39e3f3-52d1-499b-95c6-d60bc0771faf@github.com> Message-ID: On Mon, 17 May 2021 16:54:07 GMT, Hannes Walln?fer wrote: > The primary problem was that key `compiler.err.dc.ref.bad.parens` had the wrong message "')' missing in reference". That error message is not used when the right parenthesis is missing, but when it occurs before the end of the signature. The missing parenthesis case is caught earlier by the parens balancing code in `DocCommentParser#reference` and uses message `compiler.err.dc.unterminated.signature` ("unterminated signature"). > > I changed the message for `compiler.err.dc.ref.bad.parens` to "unexpected parenthesis". > > A secondary problem was that `DocCommentParser#reference` also threw "unterminated signature" when there were too many closing angle brackets or parentheses. These cases are now passed through in`DocCommentParser#reference` so that `ReferenceParser#parse` can throw a more appropriate error ("unexpected parenthesis" or "unexpected input"). > > Here's a list of what references now cause what error messages: > > - `#foo(int` `unterminated signature` > - `#foo((int))` `unexpected parenthesis` > - `#foo(int))` `unexpected parenthesis` > - `#foo(int)x` `unexpected parenthesis` > - `F - `F>` `unexpected input` > > I added two new tests for the cases with too many closing brackets/parens that used to fail with "unterminated signature". This pull request has now been integrated. Changeset: 66ab6d86 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/66ab6d86d1f4d636aef697bc4c4443b901d2cb6b Stats: 99 lines in 5 files changed: 97 ins; 0 del; 2 mod 8264181: javadoc tool Incorrect error message about malformed link Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4068 From prappo at openjdk.java.net Wed May 19 17:35:42 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 19 May 2021 17:35:42 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:57:04 GMT, Ian Graves wrote: >> 8267329: Modernize Javadoc code to use instanceof with pattern matching > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Name shortening. Copyright updates. Although I like it, let's wait for my teammates to catch up on this PR. For their convenience, here are some links to a similar effort elsewhere: - https://git.openjdk.java.net/jdk/pull/4088 - https://git.openjdk.java.net/jdk/pull/2913 - https://git.openjdk.java.net/jdk/pull/2879 ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4105 From igraves at openjdk.java.net Wed May 19 17:39:41 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 19 May 2021 17:39:41 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:57:04 GMT, Ian Graves wrote: >> 8267329: Modernize Javadoc code to use instanceof with pattern matching > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Name shortening. Copyright updates. No problem. All good suggestions. We can wait until there are more eyes on before proceeding. ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From jjg at openjdk.java.net Wed May 19 17:47:47 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 17:47:47 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:57:04 GMT, Ian Graves wrote: >> 8267329: Modernize Javadoc code to use instanceof with pattern matching > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Name shortening. Copyright updates. Thanks ... I think ... with a side of grumble. It's bad enough people using IDE driven refactoring; it's even worse when there appears to be a manual component of trying to match (often unsuccessfully) the existing style, such as it is. These module-wide refactorings can and will cause merge conflicts with other ongoing work in progress. In my opinion, this sort of change is better done when the code is being modified for other more legitimate reasons. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 415: > 413: c.add(con); > 414: } > 415: I guess at some point this becomes "pattern switch" or whatever the feature is called ... but not yet src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1127: > 1125: // inherits it automatically. > 1126: if (this instanceof ClassWriterImpl cwrtr) { > 1127: containing = cwrtr.getTypeElement(); suggest the name `writer` not `cwrtr` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2132: > 2130: List stylesheets = new ArrayList<>(); > 2131: DocPath basePath = null; > 2132: if (element instanceof PackageElement pkgElem) { Suggest `pkg` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkOutputImpl.java line 54: > 52: @Override > 53: public void append(Object o) { > 54: output.append(o.toString()); There may be a change in behavior here, for "invalid" arguments, which will now use `.toString()` instead of throwing CCE. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java line 178: > 176: } > 177: for (Element elem : mdl.getEnclosedElements()) { > 178: if (elem instanceof PackageElement pkgElem && configuration.docEnv.isIncluded(elem) Use `pkg` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 323: > 321: } > 322: if (utils.isVariableElement(holder) && ((VariableElement)holder).getConstantValue() != null && > 323: htmlWriter instanceof ClassWriterImpl clsHtml) { Use `writer` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java line 55: > 53: Objects.requireNonNull(content); > 54: ensureMutableContents(); > 55: if (content instanceof ContentBuilder conBldr) { use `b` or `cb` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java line 72: > 70: } else { > 71: contents.add(tb = new TextBuilder()); > 72: } Restructure this contents.add((c instanceof TextBuilder tb) ? tb : new TextBuilder()); or something similar src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 177: > 175: @Override > 176: public HtmlTree add(Content content) { > 177: if (content instanceof ContentBuilder conBldr) { Use `cb` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java line 319: > 317: } > 318: List propertyTags = utils.getBlockTags(property, > 319: t -> (t instanceof UnknownBlockTagTree ukbt) Use `tree` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java line 334: > 332: > 333: List bTags = utils.getBlockTags(property, > 334: t -> (t instanceof UnknownBlockTagTree ukbt) Use `tree` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 399: > 397: private Item findElementItem(Element element) { > 398: Item item = null; > 399: if (element instanceof ModuleElement modElem) { Use `mdle` or `me` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 402: > 400: item = moduleItems.get(utils.getModuleName(modElem)); > 401: } > 402: else if (element instanceof PackageElement pkgElem) { Use `pkg` or `pe` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2335: > 2333: if (val == null) > 2334: return null; > 2335: else if (val instanceof String str) Use `s` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2637: > 2635: return bt.accepts(t); > 2636: } else if (t instanceof UnknownBlockTagTree ukbt) { > 2637: return ukbt.getTagName().equals(taglet.getName()); Use `tree` `ukbt` is not even an acronym, unless you spell it Un Known Blocktag Tree! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 594: > 592: > 593: void warnIfEmpty(TagStackItem tsi, DocTree endTree) { > 594: if (tsi.tag != null && tsi.tree instanceof StartElementTree sElemTree) { Use `tree` src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 69: > 67: public static Messager instance0(Context context) { > 68: Log instance = context.get(logKey); > 69: if (!(instance instanceof Messager msgr)) Use `m` src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java line 143: > 141: > 142: Log log = context.get(Log.logKey); > 143: if (log instanceof Messager mLog){ Use `m` ------------- Changes requested by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4105 From igraves at openjdk.java.net Wed May 19 18:26:15 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 19 May 2021 18:26:15 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v4] In-Reply-To: References: Message-ID: > 8267329: Modernize Javadoc code to use instanceof with pattern matching Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Name refactoring ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4105/files - new: https://git.openjdk.java.net/jdk/pull/4105/files/f52300f1..da06b918 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=02-03 Stats: 18 lines in 6 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4105/head:pull/4105 PR: https://git.openjdk.java.net/jdk/pull/4105 From jjg at openjdk.java.net Wed May 19 18:33:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 18:33:04 GMT Subject: Integrated: JDK-8263684: Avoid wrapping into BufferedWriter twice In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:33:52 GMT, Jonathan Gibbons wrote: > Please review a trivial fix to avoid creating an unnecessary `BufferedWriter`. > > `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test. This pull request has now been integrated. Changeset: 74f30ad3 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/74f30ad38baecc0f7e9b64124fa9a6b801c280a3 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8263684: Avoid wrapping into BufferedWriter twice Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4080 From jjg at openjdk.java.net Wed May 19 18:33:03 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 18:33:03 GMT Subject: RFR: JDK-8263684: Avoid wrapping into BufferedWriter twice [v3] In-Reply-To: References: Message-ID: <69SVfMUMQjnx3vGqSX-M6rtbKtdmwyjdgeJqkfpyPq4=.382fa65a-e8a8-4673-bb49-cb124fb8e154@github.com> > Please review a trivial fix to avoid creating an unnecessary `BufferedWriter`. > > `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4080/files - new: https://git.openjdk.java.net/jdk/pull/4080/files/11be026f..6936e808 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4080&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4080&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4080.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4080/head:pull/4080 PR: https://git.openjdk.java.net/jdk/pull/4080 From jjg at openjdk.java.net Wed May 19 18:36:43 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 18:36:43 GMT Subject: RFR: JDK-8266856 Make element void In-Reply-To: References: Message-ID: <9fEIR6QDcFeoz-DTKjOho0muVQuJSz4b0OHEKzjCB3Q=.c8e8d120-5f7b-4072-a09a-25e804732947@github.com> On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons wrote: > Please review a simple fix to treat `wbr` as a void element. Since you've written the test, I'll include it, but it does seem like "overkill" for void elements and "inadequate" for other aspects. ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Wed May 19 18:58:17 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 18:58:17 GMT Subject: RFR: JDK-8266856 Make element void [v2] In-Reply-To: References: Message-ID: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> > Please review a simple fix to treat `wbr` as a void element. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: add test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4098/files - new: https://git.openjdk.java.net/jdk/pull/4098/files/e933ce21..32c1c7ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4098&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4098&range=00-01 Stats: 72 lines in 1 file changed: 72 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4098.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4098/head:pull/4098 PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Wed May 19 19:04:44 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 19:04:44 GMT Subject: RFR: JDK-8266856 Make element void [v2] In-Reply-To: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> References: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> Message-ID: On Wed, 19 May 2021 18:58:17 GMT, Jonathan Gibbons wrote: >> Please review a simple fix to treat `wbr` as a void element. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > add test Added test. Further out, we should try and come up with a javadoc-internal HTML package that contains the intersection of (the union of the requirements of doclint and the HTML doclet) and the HTML specification, as defined by WhatWG ... meaning, there are some common aspects that can be shared, and that there are some aspects that are specific to doclint and to the HmlDoclet. ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From igraves at openjdk.java.net Wed May 19 19:13:07 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 19 May 2021 19:13:07 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v5] In-Reply-To: References: Message-ID: > 8267329: Modernize Javadoc code to use instanceof with pattern matching Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Additiona name refactoring ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4105/files - new: https://git.openjdk.java.net/jdk/pull/4105/files/da06b918..b18fdc56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=03-04 Stats: 15 lines in 5 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/4105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4105/head:pull/4105 PR: https://git.openjdk.java.net/jdk/pull/4105 From igraves at openjdk.java.net Wed May 19 19:22:40 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 19 May 2021 19:22:40 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 17:24:44 GMT, Jonathan Gibbons wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Name shortening. Copyright updates. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkOutputImpl.java line 54: > >> 52: @Override >> 53: public void append(Object o) { >> 54: output.append(o.toString()); > > There may be a change in behavior here, for "invalid" arguments, which will now use `.toString()` instead of throwing CCE. My first reaction is in agreement, but upon further inspection it seems that this class is not used by anything in the module. Interestingly its documentation header warns not to rely on its behavior to remain the same. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java line 72: > >> 70: } else { >> 71: contents.add(tb = new TextBuilder()); >> 72: } > > Restructure this > > contents.add((c instanceof TextBuilder tb) ? tb : new TextBuilder()); > > or something similar Unclear if there's a more succinct way to refactor this like so. If `c` is not an instance of `TextBuilder` then we need to initialize a new `TextBuilder` and add it to `contents`. This is not the case if `c` is already of the desired instance. ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From vromero at openjdk.java.net Wed May 19 19:34:44 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 May 2021 19:34:44 GMT Subject: RFR: JDK-8266856 Make element void [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:28:07 GMT, Jonathan Gibbons wrote: >> test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java line 154: >> >>> 152: * >>> 153: *

                Test current time is at night

                >>> 154: *

                Testtext

                >> >> this is a positive test shouldnt we have negative tests too? > > I guess I felt this was close to a `noreg-trivial` change to an element that is rarely used, at least in doc comments. The only reason there's a test at all is because it is a holdover from the HTML5 conversion. got it, sounds good ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From vromero at openjdk.java.net Wed May 19 19:34:44 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 May 2021 19:34:44 GMT Subject: RFR: JDK-8266856 Make element void [v2] In-Reply-To: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> References: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> Message-ID: On Wed, 19 May 2021 18:58:17 GMT, Jonathan Gibbons wrote: >> Please review a simple fix to treat `wbr` as a void element. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > add test Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Wed May 19 20:22:36 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 20:22:36 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:22:24 GMT, Pavel Rappo wrote: >> What would be the best code locations to look at to get familiar with how javac works with standard streams, diagnostic output, and the like? Look at `Log.java`, and the introduction of `WriterKind.STDOUT, STDERR`, and the use thereof. Before there was `WriterKind.STDOUT, STDERR`, javac had the same trouble that remains in javadoc ... 1. how to map diagnostics to streams? 2. how to handle command-line help and other "expected" output like from `-Xprint` ? In javac then, and still in javadoc today, it was hampered by the use of public single-stream constructors in the `Main` class. javac actually had it "worse", in that at one point it completely flipped from using `System.out` (only) to using `System.err` (only). (Sort of like the Earth's magnetic poles flipping!) There is still code in `jtreg` to handle that flip, although the flip occurred in versions of JDK that are long unsupported. Part of the realization of the solution came in the JDK 9 timeframe, when someone (I won't name names) came up with the simple rule that "expected" output (like command-line help) should go to `stdout`/`System.out` so that it can be piped into other tools like `grep` etc. All "other"/"unexpected" output should go to `stderr`/`System.err`. That's when we expanded the set of `WriterKind` in `Log` from 3 to 5, and providing access to both kinds of output stream. Note, this does *not* mean 5 streams; it just means a mapping from 5 reasons to the one of the available streams. *Before:* `ERROR, WARN, NOTE` *After:* `ERROR, WARN, NOTE, STDOUT, STDERR` So, depending on why you wanted a stream, you could get the right one. At one point, IIRC, javadoc allowed you to specify 3 streams (!!) for error, warning, notes, but generally, we settled on 1 or 2 streams, representing `System.out` and `System.err` and aligned per the tool's choice for the diagnostic kinds. `javac` went "all-in" for "all diagnostics to `STDERR` and command-line help, etc to `STDOUT`. javadoc was going through its own turmoil at the time (new doclet + HTML5) and so we left javadoc alone, supported by some deprecated constructors in `Log`, to give javadoc what it needs. So, that's generally the history of javac and javadoc streams. I'm looking to eventually align `javadoc` with `javac`: all diagnostics go to `STDERR` and direct access to `STDOUT`(in particular) when that is appropriate. That will be a separate commit/PR, with a tiny incompatibility that most folk will not notice. It will mean that diagnostics NOTEs written from a doclet when javadoc is run from the command line will then appear on `STDERR` instead of `STDOUT` as now. For the standard doclet, we will update it so that all those tracing messages (like `Generating .... file.html`) will be written directly to `STDOUT` and not written with `Reporter.printNote`, so the mainstream use of the standard doclet will not be affected. But, all that change will be in a follow-up PR. For now I'm not changing anything in any incompatible way. This PR is just about exposing the necessary underlying streams. And, I still believe the `DocletEnvironment` is the right place to make the streams available; not the `Reporter` interface. Note, I use terms like `System.out` and `System.err` but think of them as "conceptual terms, and not always the exact same-named streams. Sometimes, alternative streams for the same conceptual purpose can be passed in to constructors etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From mullan at openjdk.java.net Wed May 19 20:33:43 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 19 May 2021 20:33:43 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote: >> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). >> >> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). >> >> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: >> >> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. >> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. >> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. >> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. >> >> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. >> >> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. >> >> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. >> >> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). >> >> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). >> >> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: >> >> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) >> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) >> ``` >> >> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > adjust order of VM options The changes to the security tests look good. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From vromero at openjdk.java.net Wed May 19 20:37:02 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 May 2021 20:37:02 GMT Subject: RFR: 8265684: implement Sealed Classes as a standard feature in Java, javadoc changes [v9] In-Reply-To: References: Message-ID: > Please review the javadoc related changes to make sealed classes a final feature in Java. The patch is mostly removing preview features related code that is not necessary anymore in javadoc. > > TIA Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - manual merge with master - Merge branch 'master' into JDK-8265684 - fixing indentation: review comment - Merge branch 'master' into JDK-8265684 - addressing indentation issues - Merge branch 'master' into JDK-8265684 - additional commit addressing review comments - addressing review comments - Merge branch 'master' into JDK-8265684 - 8265684: implement Sealed Classes as a standard feature in Java, javadoc changes ------------- Changes: https://git.openjdk.java.net/jdk/pull/3613/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3613&range=08 Stats: 179 lines in 17 files changed: 3 ins; 117 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/3613.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3613/head:pull/3613 PR: https://git.openjdk.java.net/jdk/pull/3613 From jjg at openjdk.java.net Wed May 19 21:04:47 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 21:04:47 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v2] In-Reply-To: References: Message-ID: <268wn8jMdjUU8d2rj8jJCQc-IRMsyh1OIsG30bwGTws=.8ead678a-bd10-47a6-a294-7ee8054da324@github.com> On Tue, 18 May 2021 13:44:47 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> minor cleanup > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java line 264: > >> 262: "jdk.javadoc.internal.doclets.formats.html"); >> 263: pkgs.forEach(p -> thisModule.addOpens(p, tagletLoaderUnnamedModule)); >> 264: } > > What's that and the corresponding WorkArounds.accessInternalAPI about? It's Module System Magic. :-) Don't look too hard at the man behind the curtains. The general problem is allowing external code to access module internals if they really want it and ask nicely. For external code that is provided on the class path, there are command-line options like `--add-exports` and `--add-opens`. These options allow a user to override access to module-internal classes for classes in the application class loader, which (colloquially) is the unnamed module for classes on the classpath. The problem is that those command-line options do not grant access from module-internal classes to classes in "other" unnamed modules ... yes, there are many unnamed modules: essentially one per class loader. So, it is up to the creator of any additional class loader to decide whether to grant privileges to the classes in that class loader. For javac, there are (regrettably) annotation processors and plugins that want to access javac internals, and those classes are (you guessed) loaded into a new class loader based on the `-processorpath` option. And so the decision was made to provide an undocumented option to allow such code the same access that they had before the module system was introduced. That javac option is `-XDaccessInternalAPI`. Note that `-XD` is a semi-magic option that effectively allows any `name=value` to be set in the internal options map, thus bypassing the normal mechanism for documentated options. And, side-note, `javadoc` provides the same `-XD` option for the same reasons. If you search the `javac` code for the string `"accessInternalAPI"` you will find two usages, one for plugins and one for anno-processors, and both result in a low-level utility method being called, `ModuleHelper.addExports`, which gives various access rights to any classes in that class loader. Side-story: In JDK 9, `ModuleHelper` was much more complicated in its implementation, because it had to work entirely through core-reflection, because of the "bootstrap compiler" issue. Nowadays, it's much simpler. Back to this PR. You've probably managed to guess most of the story at this point. There's functionality missing from taglets, but I want to write a test taglet that gets at the missing information. So, I've copied the javac backdoor mechanism, and opened up access to some of the internal javadoc packages, provided that a suitable command-line option is given. Further out, we should provide some of the API that is currently missing, so that the test code no longer needs access to doclet internals. As for `WorkArounds`, that class is the only one we allow in the standard doclet to access "tool stuff" via backdoors. In this case, `WorkArounds` needs to access the compiler options, to see if `XDaccessInternalAPI` has been set. Note that both the javac and javadoc mechanism are in line with JPMS policy that you have to ask for the enhanced access by using command-line options. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 474: > >> 472: */ >> 473: private DiagnosticPosition getDiagnosticPosition(DocTreePath path) { >> 474: ToolEnvironment toolEnv = getToolEnv(); > > toolEnv is unused. Thanks, I'll double check and delete if unused. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java line 147: > >> 145: enter = JavadocEnter.instance(context); >> 146: names = Names.instance(context); >> 147: externalizableSym = syms.enterClass(syms.java_base, names.fromString("java.io.Externalizable")); > > What was externalizableSym about and why have you deleted it? TL;DR: the value was unused. It's gratuitous cleanup ;-) The value was the `Symbol` (javac subtype of `Element`) for the class `java.io.Externalizable`. I presume at some point it was required for handling serializable/externalizable classes, by checking if it was a supertype of a class being documented. > test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java line 422: > >> 420: "--javafx", >> 421: "--disable-javafx-strict-checks", >> 422: "--no-platform-links", > > It just happens so that yesterday I [asked](https://github.com/openjdk/jdk/pull/4051#pullrequestreview-660862882) Hannes about proliferation of `--no-platform-links` in tests and now we have 3 more of those in this PR alone. I was getting more messages reporting that the classes could not be found. It was throwing off warning counts in golden output. My unproven suspicion is that we may not have been accurately counting warnings before this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4074 From jjg at openjdk.java.net Wed May 19 21:14:30 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 21:14:30 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 14:09:51 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> minor cleanup > > test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java line 377: > >> 375: >> 376: // make sure the doclet indeed emits the warning >> 377: checkOutput(Output.OUT, true, "C.java:31: warning: invalid usage of tag <"); > > This is interesting: while the line coordinate of an error has changed in this test, those of [TestSearch.java L676-L679](https://github.com/openjdk/jdk/pull/4074/files#diff-79c641910bccd3bfabdf3912fd24f4858edcd17bdd325555930fd85fba580593L676-L679) from this same PR have not. Mind you, I haven't investigated it yet. It's a different error message, coming from a different place in the code, presumably with different contextual info. In the other case, it was correct both before and after. In this case, it was wrong before and now correct. So that's good. Tip: to find where errors come from, use (I think) `-XD-doe`. As I wrote earlier in a different PR, `-XD` is the general mechanism to set any option. `-doe` is a hidden javac option, short for "dump on error", and triggers a track trace when any diagnostic is reported. It's handled down in Log. Look for uses of `Log.dumpOnError`, especially roundabout line 771. ------------- PR: https://git.openjdk.java.net/jdk/pull/4074 From jjg at openjdk.java.net Wed May 19 22:01:34 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 22:01:34 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v2] In-Reply-To: References: Message-ID: <-L7VddWMc3L3ZQgcoSj917AxJu4gHppuRPLcBzz7AsM=.1324be2d-7f10-4f67-a369-3c88c77a2582@github.com> On Wed, 19 May 2021 10:47:46 GMT, Pavel Rappo wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Typos > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 71: > >> 69: if (!(instance instanceof Messager messenger)) >> 70: throw new InternalError("no messager instance!"); >> 71: return messenger; > > Every project has quirks. Out of many quirks of JavaDoc, we love this one the most. Perhaps you misread that type's name: it's Messager [sic!]. Please rename the variable either to `messager` or to a shorter one. @pavelrappo let's consider changing this name sometime (not now) ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From jjg at openjdk.java.net Wed May 19 22:09:41 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 22:09:41 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 19:19:24 GMT, Ian Graves wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkOutputImpl.java line 54: >> >>> 52: @Override >>> 53: public void append(Object o) { >>> 54: output.append(o.toString()); >> >> There may be a change in behavior here, for "invalid" arguments, which will now use `.toString()` instead of throwing CCE. > > My first reaction is in agreement, but upon further inspection it seems that this class is not used by anything in the module. Interestingly its documentation header warns not to rely on its behavior to remain the same. The documentation header is a standard langtools warnings to all those people that rely on access to javac and javadoc internals. Class not used ... wow, correct. I'll file an RFE to investigate and remove it. >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java line 72: >> >>> 70: } else { >>> 71: contents.add(tb = new TextBuilder()); >>> 72: } >> >> Restructure this >> >> contents.add((c instanceof TextBuilder tb) ? tb : new TextBuilder()); >> >> or something similar > > Unclear if there's a more succinct way to refactor this like so. If `c` is not an instance of `TextBuilder` then we need to initialize a new `TextBuilder` and add it to `contents`. This is not the case if `c` is already of the desired instance. Then just a shorter name than `txtBldr` please. Lvng t vwls s nt - jvdc cnvntn. ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From jjg at openjdk.java.net Wed May 19 22:20:34 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 22:20:34 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v5] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 19:13:07 GMT, Ian Graves wrote: >> 8267329: Modernize Javadoc code to use instanceof with pattern matching > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Additiona name refactoring OK, a couple of suggestions, but it would be stylistically consistent to leave some names inconsistent! :-) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2136: > 2134: basePath = docPaths.forPackage(pkg); > 2135: } else if (element instanceof ModuleElement modElem) { > 2136: basePath = DocPaths.forModule(modElem); Missed this last time; maybe "mdle" would be more in line with usage elsewhere ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4105 From jjg at openjdk.java.net Wed May 19 22:20:35 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 22:20:35 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 22:06:18 GMT, Jonathan Gibbons wrote: >> Unclear if there's a more succinct way to refactor this like so. If `c` is not an instance of `TextBuilder` then we need to initialize a new `TextBuilder` and add it to `contents`. This is not the case if `c` is already of the desired instance. > > Then just a shorter name than `txtBldr` please. Lvng t vwls s nt - jvdc cnvntn. I guess we have competing demands for short names! ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From jjg at openjdk.java.net Wed May 19 23:45:51 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 19 May 2021 23:45:51 GMT Subject: RFR: JDK-8267434: Remove LinkOutput[Impl] Message-ID: Please review a trivial patch to remote an unused internal interface and its implementation. I've looked as far back as JDK 8, and the code was unused even back then. ------------- Commit messages: - JDK-8267434: Remove LinkOutput[Impl] Changes: https://git.openjdk.java.net/jdk/pull/4121/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4121&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267434 Stats: 120 lines in 2 files changed: 0 ins; 120 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4121.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4121/head:pull/4121 PR: https://git.openjdk.java.net/jdk/pull/4121 From igraves at openjdk.java.net Thu May 20 02:05:58 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 20 May 2021 02:05:58 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v6] In-Reply-To: References: Message-ID: > 8267329: Modernize Javadoc code to use instanceof with pattern matching Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Additional name cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4105/files - new: https://git.openjdk.java.net/jdk/pull/4105/files/b18fdc56..92fdc87a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=04-05 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4105/head:pull/4105 PR: https://git.openjdk.java.net/jdk/pull/4105 From vromero at openjdk.java.net Thu May 20 09:25:38 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 20 May 2021 09:25:38 GMT Subject: Integrated: 8265684: implement Sealed Classes as a standard feature in Java, javadoc changes In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 02:21:14 GMT, Vicente Romero wrote: > Please review the javadoc related changes to make sealed classes a final feature in Java. The patch is mostly removing preview features related code that is not necessary anymore in javadoc. > > TIA This pull request has now been integrated. Changeset: 7dcb9fda Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/7dcb9fda89ee17a5eadc83999de21e4542f37133 Stats: 179 lines in 17 files changed: 3 ins; 117 del; 59 mod 8265684: implement Sealed Classes as a standard feature in Java, javadoc changes Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/3613 From prappo at openjdk.java.net Thu May 20 12:34:32 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 12:34:32 GMT Subject: RFR: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent [v4] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 10:43:29 GMT, liach wrote: >> This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. >> >> This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. >> >> All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Specify further what isValid expects and how it is used FYI, this issue manifests itself in JDK 16 API Documentation: https://docs.oracle.com/en/java/javase/16/docs/api/java.desktop/javax/swing/JInternalFrame.html ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From github.com+7806504+liach at openjdk.java.net Thu May 20 12:48:43 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Thu, 20 May 2021 12:48:43 GMT Subject: Integrated: JDK-8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent In-Reply-To: References: Message-ID: On Mon, 17 May 2021 16:51:54 GMT, liach wrote: > This change fixes when a method body has only inline tags that produce no output, the method summary will get eaten. > > This change allows `{@inheritDoc}` from empty parents to go through the code path used by `-nocomment` and properly generate tables. > > All `jtreg:test/langtools/jdk/javadoc/doclet` tests pass. This pull request has now been integrated. Changeset: 459abd56 Author: liach Committer: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/459abd561accc9f10456a9d63f7fa19c7f8e020e Stats: 111 lines in 4 files changed: 108 ins; 0 del; 3 mod 8267219: Javadoc method summary breaks when {@inheritDoc} from an empty parent Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/4066 From prappo at openjdk.java.net Thu May 20 13:07:32 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 13:07:32 GMT Subject: RFR: JDK-8267434: Remove LinkOutput[Impl] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 23:36:07 GMT, Jonathan Gibbons wrote: > Please review a trivial patch to remote an unused internal interface and its implementation. > > I've looked as far back as JDK 8, and the code was unused even back then. This might be familiar: https://bugs.openjdk.java.net/browse/JDK-8011642 ------------- PR: https://git.openjdk.java.net/jdk/pull/4121 From prappo at openjdk.java.net Thu May 20 13:22:32 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 13:22:32 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 22:04:14 GMT, Jonathan Gibbons wrote: >> My first reaction is in agreement, but upon further inspection it seems that this class is not used by anything in the module. Interestingly its documentation header warns not to rely on its behavior to remain the same. > > The documentation header is a standard langtools warnings to all those people that rely on access to javac and javadoc internals. > > Class not used ... wow, correct. I'll file an RFE to investigate and remove it. > There may be a change in behavior here, for "invalid" arguments, which will now use `.toString()` instead of throwing CCE. Jon is right about the behavior change. That was a sloppy suggestion on my part. Sorry, Ian; you should revert that to your original version. Jon has created an RFR to remove LinkOutputImpl and LinkOutput: https://git.openjdk.java.net/jdk/pull/4121 ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From prappo at openjdk.java.net Thu May 20 13:28:30 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 13:28:30 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 13:20:01 GMT, Pavel Rappo wrote: >> The documentation header is a standard langtools warnings to all those people that rely on access to javac and javadoc internals. >> >> Class not used ... wow, correct. I'll file an RFE to investigate and remove it. > >> There may be a change in behavior here, for "invalid" arguments, which will now use `.toString()` instead of throwing CCE. > > Jon is right about the behavior change. That was a sloppy suggestion on my part. Sorry, Ian; you should revert that to your original version. Jon has created an RFR to remove LinkOutputImpl and LinkOutput: https://git.openjdk.java.net/jdk/pull/4121 Correction. Instead of reverting to your original version, you should change it to this: @Override public void append(Object o) { output.append(o instanceof String s ? s : ((LinkOutputImpl) o).toString()); } ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From jjg at openjdk.java.net Thu May 20 13:44:45 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 20 May 2021 13:44:45 GMT Subject: RFR: JDK-8267434: Remove LinkOutput[Impl] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 13:04:58 GMT, Pavel Rappo wrote: > This might be familiar: https://bugs.openjdk.java.net/browse/JDK-8011642 Yes, see the full archaeology in the comments for this issue, https://bugs.openjdk.java.net/browse/JDK-8267434 ------------- PR: https://git.openjdk.java.net/jdk/pull/4121 From prappo at openjdk.java.net Thu May 20 14:11:31 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 14:11:31 GMT Subject: RFR: JDK-8267434: Remove LinkOutput[Impl] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 23:36:07 GMT, Jonathan Gibbons wrote: > Please review a trivial patch to remote an unused internal interface and its implementation. > > I've looked as far back as JDK 8, and the code was unused even back then. Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4121 From jjg at openjdk.java.net Thu May 20 14:26:01 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 20 May 2021 14:26:01 GMT Subject: Integrated: JDK-8267434: Remove LinkOutput[Impl] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 23:36:07 GMT, Jonathan Gibbons wrote: > Please review a trivial patch to remote an unused internal interface and its implementation. > > I've looked as far back as JDK 8, and the code was unused even back then. This pull request has now been integrated. Changeset: 878d1b3f Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/878d1b3f600d4a51b082f0c3276df6de49a9bc4f Stats: 120 lines in 2 files changed: 0 ins; 120 del; 0 mod 8267434: Remove LinkOutput[Impl] Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4121 From hannesw at openjdk.java.net Thu May 20 14:39:52 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 20 May 2021 14:39:52 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance Message-ID: This is a simple cleanup to replace the sentinel `HtmlTree.EMPTY` text constant with an instance that achieves the same by overriding `isValid()`. I think this is the nicer solution, and it allows us to remove the special case identity check in `HtmlTree.add(Content)`. ------------- Commit messages: - JDK-8267394: Do not rely on object identity for empty valid Content instance Changes: https://git.openjdk.java.net/jdk/pull/4130/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4130&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267394 Stats: 37 lines in 8 files changed: 19 ins; 9 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4130/head:pull/4130 PR: https://git.openjdk.java.net/jdk/pull/4130 From hannesw at openjdk.java.net Thu May 20 14:45:44 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 20 May 2021 14:45:44 GMT Subject: RFR: JDK-8267481: Make sure table row has correct number of cells Message-ID: This is a trivial change to throw a NPE or IllegalArgumentException if the number of cells passed to `addRow` does not match the number of column styles. (The non-nullness of `columnStyles` is already implied by other Table methods such as `toContent()`.) ------------- Commit messages: - JDK-8267481: Make sure table row has correct number of cells Changes: https://git.openjdk.java.net/jdk/pull/4131/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4131&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267481 Stats: 6 lines in 1 file changed: 3 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4131.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4131/head:pull/4131 PR: https://git.openjdk.java.net/jdk/pull/4131 From jjg at openjdk.java.net Thu May 20 14:51:42 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 20 May 2021 14:51:42 GMT Subject: RFR: JDK-8267481: Make sure table row has correct number of cells In-Reply-To: References: Message-ID: On Thu, 20 May 2021 14:38:08 GMT, Hannes Walln?fer wrote: > This is a trivial change to throw a NPE or IllegalArgumentException if the number of cells passed to `addRow` does not match the number of column styles. (The non-nullness of `columnStyles` is already implied by other Table methods such as `toContent()`.) Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4131 From prappo at openjdk.java.net Thu May 20 15:04:29 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 15:04:29 GMT Subject: RFR: JDK-8266856 Make element void [v2] In-Reply-To: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> References: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> Message-ID: On Wed, 19 May 2021 18:58:17 GMT, Jonathan Gibbons wrote: >> Please review a simple fix to treat `wbr` as a void element. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > add test test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java line 57: > 55: } catch (IllegalArgumentException e) { > 56: } > 57: } Why do you do the check twice? ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Thu May 20 15:08:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 20 May 2021 15:08:29 GMT Subject: RFR: JDK-8266856 Make element void [v2] In-Reply-To: References: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> Message-ID: <91YYyU3KL45SCVf9XiBt9-B3DrW29IQfTk3D5pJqSbw=.252e19aa-7f72-4c63-9eea-76b443b3923b@github.com> On Thu, 20 May 2021 15:05:05 GMT, Jonathan Gibbons wrote: >> test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java line 57: >> >>> 55: } catch (IllegalArgumentException e) { >>> 56: } >>> 57: } >> >> Why do you do the check twice? > > OK, I guess I don't need to ... I was thinking to do the checks "both ways", but I guess the intersection is the same both ways. I'll replace the second check with a comment on the first ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Thu May 20 15:08:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 20 May 2021 15:08:29 GMT Subject: RFR: JDK-8266856 Make element void [v2] In-Reply-To: References: <1sdWNJ1kyLav1IbthR886xQFvJgViQ5URo8dW6J2MWg=.bd878e7d-60fc-4ed7-995b-68f7329dfbca@github.com> Message-ID: On Thu, 20 May 2021 15:01:11 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> add test > > test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java line 57: > >> 55: } catch (IllegalArgumentException e) { >> 56: } >> 57: } > > Why do you do the check twice? OK, I guess I don't need to ... I was thinking to do the checks "both ways", but I guess the intersection is the same both ways. ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From hannesw at openjdk.java.net Thu May 20 15:14:35 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 20 May 2021 15:14:35 GMT Subject: Integrated: JDK-8267481: Make sure table row has correct number of cells In-Reply-To: References: Message-ID: <4BWGVvBEkHPwJwqKSW0xnxJ8OP3r46f62WbIgEyMd9E=.a41e31b3-ecec-4ee1-a664-b35d83ad301f@github.com> On Thu, 20 May 2021 14:38:08 GMT, Hannes Walln?fer wrote: > This is a trivial change to throw a NPE or IllegalArgumentException if the number of cells passed to `addRow` does not match the number of column styles. (The non-nullness of `columnStyles` is already implied by other Table methods such as `toContent()`.) This pull request has now been integrated. Changeset: b7b6acd9 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/b7b6acd9b1cafb791827e151712836c4e7140db5 Stats: 6 lines in 1 file changed: 3 ins; 2 del; 1 mod 8267481: Make sure table row has correct number of cells Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4131 From jjg at openjdk.java.net Thu May 20 15:23:40 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 20 May 2021 15:23:40 GMT Subject: RFR: JDK-8266856 Make element void [v3] In-Reply-To: References: Message-ID: > Please review a simple fix to treat `wbr` as a void element. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: update test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4098/files - new: https://git.openjdk.java.net/jdk/pull/4098/files/32c1c7ed..4e13a451 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4098&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4098&range=01-02 Stats: 11 lines in 1 file changed: 2 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4098.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4098/head:pull/4098 PR: https://git.openjdk.java.net/jdk/pull/4098 From prappo at openjdk.java.net Thu May 20 15:23:40 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 15:23:40 GMT Subject: RFR: JDK-8266856 Make element void [v3] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 15:19:43 GMT, Jonathan Gibbons wrote: >> Please review a simple fix to treat `wbr` as a void element. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > update test Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From github.com+7806504+liach at openjdk.java.net Thu May 20 15:25:30 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Thu, 20 May 2021 15:25:30 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: On Thu, 20 May 2021 14:31:33 GMT, Hannes Walln?fer wrote: > This is a simple cleanup to replace the sentinel `HtmlTree.EMPTY` text constant with an instance that achieves the same by overriding `isValid()`. I think this is the nicer solution, and it allows us to remove the special case identity check in `HtmlTree.add(Content)`. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 174: > 172: ((ContentBuilder) content).contents.forEach(this::add); > 173: } > 174: else if (content.isValid()) { Should the content builder have a similar validity check to ensure if it's not empty, its contents are always valid? otherwise it's quite hard to define if the content builder is valid or not as it can be considered either and always need special case in client code. In comparison, the html tree's contents are always valid no matter if the outer tags are valid or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From prappo at openjdk.java.net Thu May 20 16:42:30 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 16:42:30 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: <7r6SvgcWZnYbPV7pRYpT9Zh6iof6JvCN-VqOVahGWbo=.79bec52d-abbf-4dad-a975-c5771c499ecf@github.com> On Tue, 18 May 2021 00:38:40 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to expose the 1 or 2 streams available within javadoc for writing expected or diagnostic output. > > The change at this time is just to _expose_ the streams; followup work may change how we _use_ them. > > There are two points of note: > > * `JavadocTester` is extended to provided access to the javadoc entry point used by the launcher. This is simpler than exec-ing the tool to invoke the entry point, and allows us to use the existing code to capture and analyze the output. > * The initialization of the default streams in `Messager` is deferred, to allow `Messager` to use the values of `System.out` and `System.err` at the time that javadoc is started, instead of when the class was loaded. This is part of the problems described separately in JDK-8267203, but which needs to be addressed here as part of this work. src/jdk.javadoc/share/classes/jdk/javadoc/doclet/DocletEnvironment.java line 156: > 154: * The implementation provided by the `javadoc` tool to > 155: * {@link Doclet#init(Locale, Reporter) initialize doclets} > 156: * always returns a non-{@code null} value. Did you mean `{@link Doclet#run(DocletEnvironment) run doclets}` instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From prappo at openjdk.java.net Thu May 20 17:19:30 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 20 May 2021 17:19:30 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: On Tue, 18 May 2021 00:38:40 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to expose the 1 or 2 streams available within javadoc for writing expected or diagnostic output. > > The change at this time is just to _expose_ the streams; followup work may change how we _use_ them. > > There are two points of note: > > * `JavadocTester` is extended to provided access to the javadoc entry point used by the launcher. This is simpler than exec-ing the tool to invoke the entry point, and allows us to use the existing code to capture and analyze the output. > * The initialization of the default streams in `Messager` is deferred, to allow `Messager` to use the values of `System.out` and `System.err` at the time that javadoc is started, instead of when the class was loaded. This is part of the problems described separately in JDK-8267203, but which needs to be addressed here as part of this work. Update copyright years. src/jdk.javadoc/share/classes/jdk/javadoc/doclet/DocletEnvironment.java line 154: > 152: * @implSpec > 153: * This implementation returns {@code null}. > 154: * The implementation provided by the `javadoc` tool to Use `{@code javadoc}` or just javadoc instead of `javadoc` (back ticks). src/jdk.javadoc/share/classes/jdk/javadoc/doclet/DocletEnvironment.java line 176: > 174: * The implementation provided by the `javadoc` tool to > 175: * {@link Doclet#init(Locale, Reporter) initialize doclets} > 176: * always returns a non-{@code null} value. Same as two preceding comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From jjg at openjdk.java.net Thu May 20 17:46:32 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 20 May 2021 17:46:32 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: <_Ly-NdYRjCwyZQdFZ-1p8e4-lYdD9r_SE96VwwKlreU=.92102b6d-cd82-4966-b755-465228f0eb1d@github.com> On Thu, 20 May 2021 16:51:59 GMT, Pavel Rappo wrote: >> Please review a relatively simple update to expose the 1 or 2 streams available within javadoc for writing expected or diagnostic output. >> >> The change at this time is just to _expose_ the streams; followup work may change how we _use_ them. >> >> There are two points of note: >> >> * `JavadocTester` is extended to provided access to the javadoc entry point used by the launcher. This is simpler than exec-ing the tool to invoke the entry point, and allows us to use the existing code to capture and analyze the output. >> * The initialization of the default streams in `Messager` is deferred, to allow `Messager` to use the values of `System.out` and `System.err` at the time that javadoc is started, instead of when the class was loaded. This is part of the problems described separately in JDK-8267203, but which needs to be addressed here as part of this work. > > src/jdk.javadoc/share/classes/jdk/javadoc/doclet/DocletEnvironment.java line 154: > >> 152: * @implSpec >> 153: * This implementation returns {@code null}. >> 154: * The implementation provided by the `javadoc` tool to > > Use `{@code javadoc}` or just javadoc instead of `javadoc` (back ticks). oops ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From jjg at openjdk.java.net Thu May 20 17:50:49 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 20 May 2021 17:50:49 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: <7r6SvgcWZnYbPV7pRYpT9Zh6iof6JvCN-VqOVahGWbo=.79bec52d-abbf-4dad-a975-c5771c499ecf@github.com> References: <7r6SvgcWZnYbPV7pRYpT9Zh6iof6JvCN-VqOVahGWbo=.79bec52d-abbf-4dad-a975-c5771c499ecf@github.com> Message-ID: <5zllYdFnSbrIomBC2gLQPvPBUQV_P-yJ-sQac1_BgqI=.bea884b1-33a4-44a2-9a3a-4c77b29d1ebd@github.com> On Thu, 20 May 2021 16:39:39 GMT, Pavel Rappo wrote: >> Please review a relatively simple update to expose the 1 or 2 streams available within javadoc for writing expected or diagnostic output. >> >> The change at this time is just to _expose_ the streams; followup work may change how we _use_ them. >> >> There are two points of note: >> >> * `JavadocTester` is extended to provided access to the javadoc entry point used by the launcher. This is simpler than exec-ing the tool to invoke the entry point, and allows us to use the existing code to capture and analyze the output. >> * The initialization of the default streams in `Messager` is deferred, to allow `Messager` to use the values of `System.out` and `System.err` at the time that javadoc is started, instead of when the class was loaded. This is part of the problems described separately in JDK-8267203, but which needs to be addressed here as part of this work. > > src/jdk.javadoc/share/classes/jdk/javadoc/doclet/DocletEnvironment.java line 156: > >> 154: * The implementation provided by the `javadoc` tool to >> 155: * {@link Doclet#init(Locale, Reporter) initialize doclets} >> 156: * always returns a non-{@code null} value. > > Did you mean `{@link Doclet#run(DocletEnvironment) run doclets}` instead? Hmm, I guess I did. Good catch. > src/jdk.javadoc/share/classes/jdk/javadoc/doclet/DocletEnvironment.java line 176: > >> 174: * The implementation provided by the `javadoc` tool to >> 175: * {@link Doclet#init(Locale, Reporter) initialize doclets} >> 176: * always returns a non-{@code null} value. > > Same as two preceding comments. Same as preceding response! ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From igraves at openjdk.java.net Thu May 20 17:53:57 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 20 May 2021 17:53:57 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v7] In-Reply-To: References: Message-ID: <2R0D4cWsJJkSxyRXwUyAEVpagAfCE-c1M23vmcCPj74=.c60dd3bd-1a11-4f04-b714-3ec53dd19c35@github.com> > 8267329: Modernize Javadoc code to use instanceof with pattern matching Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Re-inserting class cast with some revised pattern usage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4105/files - new: https://git.openjdk.java.net/jdk/pull/4105/files/92fdc87a..2a1d7bf7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4105/head:pull/4105 PR: https://git.openjdk.java.net/jdk/pull/4105 From iris at openjdk.java.net Thu May 20 19:02:43 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 20 May 2021 19:02:43 GMT Subject: RFR: JDK-8266856 Make element void [v3] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 15:23:40 GMT, Jonathan Gibbons wrote: >> Please review a simple fix to treat `wbr` as a void element. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > update test Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From jjg at openjdk.java.net Fri May 21 00:36:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 21 May 2021 00:36:14 GMT Subject: Integrated: JDK-8266856 Make element void In-Reply-To: References: Message-ID: <-TRi7ylzBJJFMiL2eFBQf5SLGPChhpVVcXnO3nHQbUY=.c0208e39-c6e9-437a-8c77-5e4513b02dd4@github.com> On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons wrote: > Please review a simple fix to treat `wbr` as a void element. This pull request has now been integrated. Changeset: e094f3f8 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/e094f3f856f5f17d4be65b9f83ff493aa0280deb Stats: 69 lines in 3 files changed: 66 ins; 0 del; 3 mod 8266856: Make element void Reviewed-by: prappo, iris, vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/4098 From hannesw at openjdk.java.net Fri May 21 08:56:53 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 21 May 2021 08:56:53 GMT Subject: RFR: JDK-8266748: Move modifiers code to Signatures.java Message-ID: This change consolidates the code to generate type signature modifiers into `Signatures.TypeSignature`. Although this mostly consists of moving the code from `ClassWriterImpl` and `Utils` to `Signatures`, I also avoided the need to split the modifiers string when processing preview modifiers by returning a `List` instead of a `String` in what used to be `Utils.modifiersToString` and is now `TypeSignature.getModifiers`. ------------- Commit messages: - JDK-8266748: Make getModifiers() non-static - JDK-8266748: Move modifiers code to Signatures.java Changes: https://git.openjdk.java.net/jdk/pull/4142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4142&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266748 Stats: 261 lines in 5 files changed: 118 ins; 123 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/4142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4142/head:pull/4142 PR: https://git.openjdk.java.net/jdk/pull/4142 From prr at openjdk.java.net Fri May 21 18:31:01 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 21 May 2021 18:31:01 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com> On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote: >> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). >> >> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). >> >> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: >> >> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. >> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. >> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. >> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. >> >> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. >> >> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. >> >> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. >> >> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). >> >> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). >> >> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: >> >> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) >> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) >> ``` >> >> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > adjust order of VM options The client changes are fine except for the one misplaced (c) test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3: > 1: /* > 2: * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Probably the (c) update was meant to be on the .sh file that is actually modified. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From prappo at openjdk.java.net Fri May 21 18:41:01 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 21 May 2021 18:41:01 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 20:40:18 GMT, Jonathan Gibbons wrote: >> Please review a change to overhaul the javadoc support for diagnostics to better leverage the support available in javac. This includes the ability for all javadoc diagnostics to show a "source line and caret" to indicate the position of a reported issue. As a side-effect, it normalizes the formatting of javadoc messages, to be consistent with javac messages. >> >> The primary changes are in the javadoc `Messager` class, and are primarily focussed "downward" on the internal use of the javac `Log.report` method, which is the nexus for reporting methods. There is additional cleanup that could be done in `Messager` in the API it provides to clients, but (for the most part) that is not done in this work. >> >> Additional changes are done to facilitate writing a test for this work, and reflect the current shortcomings of the existing `Doclet` API. Most notably: >> * changes in `Utils` to allow a user-defined taglet to override a built-in taglet >> * changes in `TagletManager` and `Workarounds` to allow a user-defined taglet to access internal API, to workaround API that would be useful to provide on `StandardDoclet` >> >> There are a few minor specific cleanup changes in code style and/or improved comments. >> >> There is one primary new test, `TestDiagsLineCaret.java` which exercises different kinds of diagnostics at different positions in a file, to verify that the source line and a caret are produced as appropriate. >> >> There are additional test changes triggered by the slight change in the format of error messages. Most notably, prefixes like `error -` and `warning -` become `error:` and `warning:`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup I will continue reviewing this change. Meanwhile, please update copyright years and address other nits below. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java line 543: > 541: * Returns whether or not to permit dynamically loaded components to access > 542: * part of the javadoc internal API. The flag is the same (hidden) compiler > 543: * option that allows javac plugins and annotation processors to javac internal Do you use "allow x to y" here in the sense of "letting x into y"? If so, consider using "allow x into y" instead of "allow x to y". Otherwise it might sound like there's a verb missing: allow to (access? enter?) javac internal API. My non-native English speaker's two cents. src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 67: > 65: * of diagnostic messages and to avoid code duplication. > 66: * > 67: * The class is a subtype of javac's Log, and is primarily a transducer between Would "adapter" be more suitable than "transducer"? src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 92: > 90: *
              • {@code Diagnostic.Kind} -- maps to {@code DiagnosticType} and {@code Set} > 91: *
              • {@code Element} -- maps to {@code DiagnosticSource and {@code DiagnosticPosition} > 92: *
              • {@code DocTreePath} -- maps to {@code DiagnosticSource and {@code DiagnosticPosition} Close `@code` tags. src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 96: > 94: * > 95: * The javac layer deals primarily in pre-localized (key, args) pairs, > 96: * while the javadoc layer, especially the {@code Reporter} interface, deals in localized strings. If it is not a typo, consider changing "deal in" to something simpler. src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 125: > 123: private ToolEnvironment toolEnv; > 124: > 125: /** The utility class to access the positions of items in doc comments., */ Remove that trailing comma. src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 332: > 330: > 331: /** > 332: * Print a "notice" message. Add "s" to "print" for consistency with doc comment of other methods in this class. src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 448: > 446: * such as "Generating class ...". Therefore, for now, we detect and report those > 447: * messages directly. (A better solution would be to expose access to the output > 448: * and error streams via {@code DocletEnvironment}. Sentence: either remove "(" or add ")". test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/MyTaglet.java line 127: > 125: @Override > 126: public Void visitEntity(EntityTree node, Diagnostic.Kind k) { > 127: if (node.getName().contentEquals("#x1f955")) { Is this... a carrot (??)? test/langtools/jdk/javadoc/doclet/testMissingComment/TestMissingComment.java line 115: > 113: javadoc("-d", base.resolve("api").toString(), > 114: "-Xdoclint:missing", > 115: "--no-platform-links", More of those... sigh. test/langtools/jdk/javadoc/tool/MaxWarns.java line 78: > 76: StringWriter sw = new StringWriter(); > 77: PrintWriter pw = new PrintWriter(sw); > 78: String[] args = { "-Xdoclint:none", "--no-platform-links", "-d", "api", f.getPath() }; Argh... ------------- Changes requested by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4074 From weijun at openjdk.java.net Fri May 21 19:50:15 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 19:50:15 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com> Message-ID: On Fri, 21 May 2021 18:26:48 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust order of VM options > > test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3: > >> 1: /* >> 2: * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > Probably the (c) update was meant to be on the .sh file that is actually modified. Oops, I'll back it out. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Fri May 21 20:01:15 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 20:01:15 GMT Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v3] In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: feedback from Phil reverted: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4071/files - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From jjg at openjdk.java.net Sat May 22 16:26:17 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 22 May 2021 16:26:17 GMT Subject: RFR: JDK-8267574: Dead code in HtmlStyle/HtmlDocletWriter Message-ID: Please review a simple `noreg-cleanup` change to remove some dead code. ------------- Commit messages: - JDK-8267574: Dead code in HtmlStyle/HtmlDocletWriter Changes: https://git.openjdk.java.net/jdk/pull/4154/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4154&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267574 Stats: 11 lines in 3 files changed: 0 ins; 9 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4154.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4154/head:pull/4154 PR: https://git.openjdk.java.net/jdk/pull/4154 From jjg at openjdk.java.net Sat May 22 21:05:13 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 22 May 2021 21:05:13 GMT Subject: RFR: JDK-8267575: Add new documentation group in HtmlStyle Message-ID: <1k2XJRf0Ip5LzD4qi77iIXOTIIF9_YP8w1u9cDo4Az4=.bdafec4e-0f9a-4cc8-b72c-1af0fac9c1a9@github.com> Please review a relatively simple primarily-doc update for HtmlStyle. The change is mostly grouping and commenting items. Some existing comments were incorrect and have been updated. ------------- Commit messages: - JDK-8267575: Add new documentation group in HtmlStyle Changes: https://git.openjdk.java.net/jdk/pull/4155/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4155&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267575 Stats: 89 lines in 1 file changed: 75 ins; 12 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4155/head:pull/4155 PR: https://git.openjdk.java.net/jdk/pull/4155 From weijun at openjdk.java.net Mon May 24 14:05:08 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 14:05:08 GMT Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v4] In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang 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 20 additional commits since the last revision: - Merge branch 'master' into 8267184 - feedback from Phil reverted: - adjust order of VM options - test for awt - test for hotspot-gc - test for compiler - test for net - test for core-libs - test for beans - test for xml - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4071/files - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02-03 Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From igraves at openjdk.java.net Mon May 24 14:51:52 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 24 May 2021 14:51:52 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v8] In-Reply-To: References: Message-ID: > 8267329: Modernize Javadoc code to use instanceof with pattern matching Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge master - Re-inserting class cast with some revised pattern usage - Additional name cleanup - Additiona name refactoring - Name refactoring - Name shortening. Copyright updates. - Typos - Updating javadoc to use instanceof patterns ------------- Changes: https://git.openjdk.java.net/jdk/pull/4105/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4105&range=07 Stats: 99 lines in 24 files changed: 0 ins; 11 del; 88 mod Patch: https://git.openjdk.java.net/jdk/pull/4105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4105/head:pull/4105 PR: https://git.openjdk.java.net/jdk/pull/4105 From prappo at openjdk.java.net Mon May 24 15:31:04 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 May 2021 15:31:04 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 17:20:02 GMT, Jonathan Gibbons wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Name shortening. Copyright updates. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 415: > >> 413: c.add(con); >> 414: } >> 415: > > I guess at some point this becomes "pattern switch" or whatever the feature is called ... but not yet The feature you are talking about is called "Pattern Matching for switch". The feature is described as a preview feature by JEP 406, which is currently proposed to target JDK 17. ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From prappo at openjdk.java.net Mon May 24 16:56:17 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 May 2021 16:56:17 GMT Subject: RFR: 8267329: Modernize Javadoc code to use instanceof with pattern matching [v8] In-Reply-To: References: Message-ID: <5mIBgJS2bn7DumVAgmzTxtixHGNh9R6zSljaZx3X_lw=.b4b0321a-2a10-491c-bfdd-68ddce9df619@github.com> On Mon, 24 May 2021 14:51:52 GMT, Ian Graves wrote: >> 8267329: Modernize Javadoc code to use instanceof with pattern matching > > Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge master > - Re-inserting class cast with some revised pattern usage > - Additional name cleanup > - Additiona name refactoring > - Name refactoring > - Name shortening. Copyright updates. > - Typos > - Updating javadoc to use instanceof patterns Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From weijun at openjdk.java.net Mon May 24 17:02:13 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 17:02:13 GMT Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com> On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. This pull request has now been integrated. Changeset: 640a2afd Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7 Stats: 1028 lines in 852 files changed: 252 ins; 9 del; 767 mod 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager Co-authored-by: Lance Andersen Co-authored-by: Weijun Wang Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From jjg at openjdk.java.net Mon May 24 19:05:12 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 24 May 2021 19:05:12 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 17:39:43 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> minor cleanup > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java line 543: > >> 541: * Returns whether or not to permit dynamically loaded components to access >> 542: * part of the javadoc internal API. The flag is the same (hidden) compiler >> 543: * option that allows javac plugins and annotation processors to javac internal > > Do you use "allow x to y" here in the sense of "letting x into y"? If so, consider using "allow x into y" instead of "allow x to y". Otherwise it might sound like there's a verb missing: allow to (access? enter?) javac internal API. My non-native English speaker's two cents. Yes, there was a missing verb. Fixed. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 67: > >> 65: * of diagnostic messages and to avoid code duplication. >> 66: * >> 67: * The class is a subtype of javac's Log, and is primarily a transducer between > > Would "adapter" be more suitable than "transducer"? Both are valid, but agreed that "adapter" is a more common term. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 92: > >> 90: *
              • {@code Diagnostic.Kind} -- maps to {@code DiagnosticType} and {@code Set} >> 91: *
              • {@code Element} -- maps to {@code DiagnosticSource and {@code DiagnosticPosition} >> 92: *
              • {@code DocTreePath} -- maps to {@code DiagnosticSource and {@code DiagnosticPosition} > > Close `@code` tags. oops > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 96: > >> 94: * >> 95: * The javac layer deals primarily in pre-localized (key, args) pairs, >> 96: * while the javadoc layer, especially the {@code Reporter} interface, deals in localized strings. > > If it is not a typo, consider changing "deal in" to something simpler. I'll try. Maybe something based on "operates on" or "uses" or something. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 125: > >> 123: private ToolEnvironment toolEnv; >> 124: >> 125: /** The utility class to access the positions of items in doc comments., */ > > Remove that trailing comma. oops > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 332: > >> 330: >> 331: /** >> 332: * Print a "notice" message. > > Add "s" to "print" for consistency with doc comment of other methods in this class. Definitely. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 448: > >> 446: * such as "Generating class ...". Therefore, for now, we detect and report those >> 447: * messages directly. (A better solution would be to expose access to the output >> 448: * and error streams via {@code DocletEnvironment}. > > Sentence: either remove "(" or add ")". Add ")" and change DocletEnvironment to Reporter for now, and to delete the ~sentence~ paragraph when we add streams to Reporter. > test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/MyTaglet.java line 127: > >> 125: @Override >> 126: public Void visitEntity(EntityTree node, Diagnostic.Kind k) { >> 127: if (node.getName().contentEquals("#x1f955")) { > > Is this... a carrot (??)? https://www.fileformat.info/info/unicode/char/search.htm :-) > test/langtools/jdk/javadoc/doclet/testMissingComment/TestMissingComment.java line 115: > >> 113: javadoc("-d", base.resolve("api").toString(), >> 114: "-Xdoclint:missing", >> 115: "--no-platform-links", > > More of those... sigh. A different solution would be to disable platform links by default (in JavadocTester) and only enables for specific tests. But that would be a minor paradigm shift of JavadocTester providing default options. ------------- PR: https://git.openjdk.java.net/jdk/pull/4074 From jjg at openjdk.java.net Mon May 24 19:05:13 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 24 May 2021 19:05:13 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 18:40:26 GMT, Jonathan Gibbons wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java line 543: >> >>> 541: * Returns whether or not to permit dynamically loaded components to access >>> 542: * part of the javadoc internal API. The flag is the same (hidden) compiler >>> 543: * option that allows javac plugins and annotation processors to javac internal >> >> Do you use "allow x to y" here in the sense of "letting x into y"? If so, consider using "allow x into y" instead of "allow x to y". Otherwise it might sound like there's a verb missing: allow to (access? enter?) javac internal API. My non-native English speaker's two cents. > > Yes, there was a missing verb. Fixed. (Copyrights: only TagletManager needed updating; done.) >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 92: >> >>> 90: *
              • {@code Diagnostic.Kind} -- maps to {@code DiagnosticType} and {@code Set} >>> 91: *
              • {@code Element} -- maps to {@code DiagnosticSource and {@code DiagnosticPosition} >>> 92: *
              • {@code DocTreePath} -- maps to {@code DiagnosticSource and {@code DiagnosticPosition} >> >> Close `@code` tags. > > oops mildly worrying that "make docs" did not give errors ... but I guess the error was masked by the subsequent `}` of the subsequent `{@code ...}` >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 96: >> >>> 94: * >>> 95: * The javac layer deals primarily in pre-localized (key, args) pairs, >>> 96: * while the javadoc layer, especially the {@code Reporter} interface, deals in localized strings. >> >> If it is not a typo, consider changing "deal in" to something simpler. > > I'll try. Maybe something based on "operates on" or "uses" or something. Rephrased the sentence and added more details as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/4074 From jjg at openjdk.java.net Mon May 24 21:57:33 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 24 May 2021 21:57:33 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v3] In-Reply-To: References: Message-ID: > Please review a change to overhaul the javadoc support for diagnostics to better leverage the support available in javac. This includes the ability for all javadoc diagnostics to show a "source line and caret" to indicate the position of a reported issue. As a side-effect, it normalizes the formatting of javadoc messages, to be consistent with javac messages. > > The primary changes are in the javadoc `Messager` class, and are primarily focussed "downward" on the internal use of the javac `Log.report` method, which is the nexus for reporting methods. There is additional cleanup that could be done in `Messager` in the API it provides to clients, but (for the most part) that is not done in this work. > > Additional changes are done to facilitate writing a test for this work, and reflect the current shortcomings of the existing `Doclet` API. Most notably: > * changes in `Utils` to allow a user-defined taglet to override a built-in taglet > * changes in `TagletManager` and `Workarounds` to allow a user-defined taglet to access internal API, to workaround API that would be useful to provide on `StandardDoclet` > > There are a few minor specific cleanup changes in code style and/or improved comments. > > There is one primary new test, `TestDiagsLineCaret.java` which exercises different kinds of diagnostics at different positions in a file, to verify that the source line and a caret are produced as appropriate. > > There are additional test changes triggered by the slight change in the format of error messages. Most notably, prefixes like `error -` and `warning -` become `error:` and `warning:`. Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision: - fix typos - address review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4074/files - new: https://git.openjdk.java.net/jdk/pull/4074/files/c57d93a3..55e6be3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4074&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4074&range=01-02 Stats: 18 lines in 3 files changed: 3 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/4074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4074/head:pull/4074 PR: https://git.openjdk.java.net/jdk/pull/4074 From prappo at openjdk.java.net Mon May 24 21:57:48 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 May 2021 21:57:48 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v3] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 20:32:57 GMT, Jonathan Gibbons wrote: >> Please review a change to overhaul the javadoc support for diagnostics to better leverage the support available in javac. This includes the ability for all javadoc diagnostics to show a "source line and caret" to indicate the position of a reported issue. As a side-effect, it normalizes the formatting of javadoc messages, to be consistent with javac messages. >> >> The primary changes are in the javadoc `Messager` class, and are primarily focussed "downward" on the internal use of the javac `Log.report` method, which is the nexus for reporting methods. There is additional cleanup that could be done in `Messager` in the API it provides to clients, but (for the most part) that is not done in this work. >> >> Additional changes are done to facilitate writing a test for this work, and reflect the current shortcomings of the existing `Doclet` API. Most notably: >> * changes in `Utils` to allow a user-defined taglet to override a built-in taglet >> * changes in `TagletManager` and `Workarounds` to allow a user-defined taglet to access internal API, to workaround API that would be useful to provide on `StandardDoclet` >> >> There are a few minor specific cleanup changes in code style and/or improved comments. >> >> There is one primary new test, `TestDiagsLineCaret.java` which exercises different kinds of diagnostics at different positions in a file, to verify that the source line and a caret are produced as appropriate. >> >> There are additional test changes triggered by the slight change in the format of error messages. Most notably, prefixes like `error -` and `warning -` become `error:` and `warning:`. > > Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision: > > - fix typos > - address review feedback Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4074 From prappo at openjdk.java.net Mon May 24 21:57:56 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 May 2021 21:57:56 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v2] In-Reply-To: References: Message-ID: <1LW4BDnGFTbpyS0v0_S26TTfd3gC-F0XIUIs3DdW-gQ=.b1c9c2b6-2ac7-42eb-9558-54945a52398c@github.com> On Mon, 24 May 2021 18:49:08 GMT, Jonathan Gibbons wrote: > mildly worrying that "make docs" did not give errors This should be currently detectable by DocLint: since `
              ` is consumed by `@code`, the `ul` element is left unclosed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4074 From igraves at openjdk.java.net Mon May 24 22:08:57 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 24 May 2021 22:08:57 GMT Subject: Integrated: 8267329: Modernize Javadoc code to use instanceof with pattern matching In-Reply-To: References: Message-ID: On Wed, 19 May 2021 03:43:04 GMT, Ian Graves wrote: > 8267329: Modernize Javadoc code to use instanceof with pattern matching This pull request has now been integrated. Changeset: ebc9357d Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/ebc9357d58957702abbd003d21082badc630876d Stats: 99 lines in 24 files changed: 0 ins; 11 del; 88 mod 8267329: Modernize Javadoc code to use instanceof with pattern matching Reviewed-by: prappo, jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4105 From prappo at openjdk.java.net Mon May 24 22:37:37 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 May 2021 22:37:37 GMT Subject: RFR: 8267633: Clarify documentation of (Doc)TreeScanner Message-ID: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com> When a method is said to be called "on an object", this means that the object is a receiver. When a method is said to be called "with an object", this means that the object is a parameter. To scan an instance of (Doc)Tree, the "scan" method is called on the instance of (Doc)TreeScanner with that instance of (Doc)Tree. ------------- Commit messages: - Change @link to @code similarly to DocTreePath - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/4174/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4174&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267633 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4174/head:pull/4174 PR: https://git.openjdk.java.net/jdk/pull/4174 From jjg at openjdk.java.net Mon May 24 22:37:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 24 May 2021 22:37:38 GMT Subject: RFR: 8267633: Clarify documentation of (Doc)TreeScanner In-Reply-To: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com> References: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com> Message-ID: <454lCcsCz6faWNA1kbcIbIq-4akeTm9kd4s7-T6J-7g=.1cda65a2-6582-4fbe-8f9f-b5555c804f53@github.com> On Mon, 24 May 2021 21:05:02 GMT, Pavel Rappo wrote: > When a method is said to be called "on an object", this means that the object is a receiver. When a method is said to be called "with an object", this means that the object is a parameter. > > To scan an instance of (Doc)Tree, the "scan" method is called on the instance of (Doc)TreeScanner with that instance of (Doc)Tree. OK. I'm not entirely comfortable with the phrasing of `call with` but I understand the issue with `call on`. src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java line 44: > 42: * result of calling {@code scan} with that child. The child may be a simple node > 43: * or itself a list of nodes. > 44: *
            • If the node being visited has more than one child, the result will Inconsistent space after `
            • ` (Since this is mostly a cleanup PR) ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4174 From jjg at openjdk.java.net Tue May 25 01:31:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 01:31:38 GMT Subject: RFR: JDK-8267126: javadoc should show "line and caret" for diagnostics. [v4] In-Reply-To: References: Message-ID: > Please review a change to overhaul the javadoc support for diagnostics to better leverage the support available in javac. This includes the ability for all javadoc diagnostics to show a "source line and caret" to indicate the position of a reported issue. As a side-effect, it normalizes the formatting of javadoc messages, to be consistent with javac messages. > > The primary changes are in the javadoc `Messager` class, and are primarily focussed "downward" on the internal use of the javac `Log.report` method, which is the nexus for reporting methods. There is additional cleanup that could be done in `Messager` in the API it provides to clients, but (for the most part) that is not done in this work. > > Additional changes are done to facilitate writing a test for this work, and reflect the current shortcomings of the existing `Doclet` API. Most notably: > * changes in `Utils` to allow a user-defined taglet to override a built-in taglet > * changes in `TagletManager` and `Workarounds` to allow a user-defined taglet to access internal API, to workaround API that would be useful to provide on `StandardDoclet` > > There are a few minor specific cleanup changes in code style and/or improved comments. > > There is one primary new test, `TestDiagsLineCaret.java` which exercises different kinds of diagnostics at different positions in a file, to verify that the source line and a caret are produced as appropriate. > > There are additional test changes triggered by the slight change in the format of error messages. Most notably, prefixes like `error -` and `warning -` become `error:` and `warning:`. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge with upstream/master - fix typos - address review feedback - minor cleanup - JDK-8267126: javadoc should show "line and caret" for diagnostics. ------------- Changes: https://git.openjdk.java.net/jdk/pull/4074/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4074&range=03 Stats: 935 lines in 37 files changed: 629 ins; 103 del; 203 mod Patch: https://git.openjdk.java.net/jdk/pull/4074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4074/head:pull/4074 PR: https://git.openjdk.java.net/jdk/pull/4074 From jjg at openjdk.java.net Tue May 25 01:37:12 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 01:37:12 GMT Subject: Integrated: JDK-8267126: javadoc should show "line and caret" for diagnostics. In-Reply-To: References: Message-ID: On Mon, 17 May 2021 20:04:49 GMT, Jonathan Gibbons wrote: > Please review a change to overhaul the javadoc support for diagnostics to better leverage the support available in javac. This includes the ability for all javadoc diagnostics to show a "source line and caret" to indicate the position of a reported issue. As a side-effect, it normalizes the formatting of javadoc messages, to be consistent with javac messages. > > The primary changes are in the javadoc `Messager` class, and are primarily focussed "downward" on the internal use of the javac `Log.report` method, which is the nexus for reporting methods. There is additional cleanup that could be done in `Messager` in the API it provides to clients, but (for the most part) that is not done in this work. > > Additional changes are done to facilitate writing a test for this work, and reflect the current shortcomings of the existing `Doclet` API. Most notably: > * changes in `Utils` to allow a user-defined taglet to override a built-in taglet > * changes in `TagletManager` and `Workarounds` to allow a user-defined taglet to access internal API, to workaround API that would be useful to provide on `StandardDoclet` > > There are a few minor specific cleanup changes in code style and/or improved comments. > > There is one primary new test, `TestDiagsLineCaret.java` which exercises different kinds of diagnostics at different positions in a file, to verify that the source line and a caret are produced as appropriate. > > There are additional test changes triggered by the slight change in the format of error messages. Most notably, prefixes like `error -` and `warning -` become `error:` and `warning:`. This pull request has now been integrated. Changeset: b4d4884c Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/b4d4884c03b03d3073ef137a899f3612993f5e65 Stats: 935 lines in 37 files changed: 629 ins; 103 del; 203 mod 8267126: javadoc should show "line and caret" for diagnostics. Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4074 From hannesw at openjdk.java.net Tue May 25 08:34:02 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 25 May 2021 08:34:02 GMT Subject: RFR: JDK-8267575: Add new documentation group in HtmlStyle In-Reply-To: <1k2XJRf0Ip5LzD4qi77iIXOTIIF9_YP8w1u9cDo4Az4=.bdafec4e-0f9a-4cc8-b72c-1af0fac9c1a9@github.com> References: <1k2XJRf0Ip5LzD4qi77iIXOTIIF9_YP8w1u9cDo4Az4=.bdafec4e-0f9a-4cc8-b72c-1af0fac9c1a9@github.com> Message-ID: <1TXMUbf_P7k_W0oloGe_Fiyg3bv7NVufPGhk6n4o9EM=.d1955446-dae8-4bf5-9493-f544c8a939f4@github.com> On Sat, 22 May 2021 20:57:39 GMT, Jonathan Gibbons wrote: > Please review a relatively simple primarily-doc update for HtmlStyle. > > The change is mostly grouping and commenting items. > > Some existing comments were incorrect and have been updated. Looks good. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4155 From hannesw at openjdk.java.net Tue May 25 08:40:05 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 25 May 2021 08:40:05 GMT Subject: RFR: JDK-8267574: Dead code in HtmlStyle/HtmlDocletWriter In-Reply-To: References: Message-ID: On Sat, 22 May 2021 16:18:00 GMT, Jonathan Gibbons wrote: > Please review a simple `noreg-cleanup` change to remove some dead code. Looks good, but I found another potential cleanup target close by (see inline comment). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 580: > 578: display:inline-block; > 579: } > 580: div.block div.deprecation-comment, div.block div.block span.emphasized-phrase { A quick search through the code and generated docs suggests that `emphasized-phrase` is unused as well. Should this also be removed? ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4154 From prappo at openjdk.java.net Tue May 25 09:09:25 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 25 May 2021 09:09:25 GMT Subject: RFR: 8267633: Clarify documentation of (Doc)TreeScanner [v2] In-Reply-To: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com> References: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com> Message-ID: > When a method is said to be called "on an object", this means that the object is a receiver. When a method is said to be called "with an object", this means that the object is a parameter. > > To scan an instance of (Doc)Tree, the "scan" method is called on the instance of (Doc)TreeScanner with that instance of (Doc)Tree. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Remove inconsistent whitespace in
            • ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4174/files - new: https://git.openjdk.java.net/jdk/pull/4174/files/9f5ba184..27590231 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4174&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4174&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4174/head:pull/4174 PR: https://git.openjdk.java.net/jdk/pull/4174 From godin at openjdk.java.net Tue May 25 09:32:03 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Tue, 25 May 2021 09:32:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 19:01:01 GMT, Jan Lahoda wrote: >> Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. >> >> In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. > > @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested changes in recent commits (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 ). > > I've also tried to update the implementation for the latest spec changes here: > https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b > > The spec changes are: total patterns are nullable; pattern matching ("new") statement switches must be complete (as switch expressions). > > Any further feedback is welcome! Hi @lahodaj ?? , I tried `javac` built from this PR and for the following `Example.java` class Example { void example(Object o) { switch (o) { case String s && s.length() == 0 -> System.out.println("1st case"); case String s && s.length() == 1 -> // line 6 System.out.println("2nd case"); // line 7 case String s -> // line 8 System.out.println("3rd case"); // line 9 default -> // line 10 System.out.println("default case"); // line 11 } } } execution of javac --enable-preview --release 17 Example.java javap -v -p Example.class produces void example(java.lang.Object); descriptor: (Ljava/lang/Object;)V flags: (0x0000) Code: stack=2, locals=7, args_size=2 0: aload_1 1: dup 2: invokestatic #7 // Method java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object; 5: pop 6: astore_2 7: iconst_0 8: istore_3 9: aload_2 10: iload_3 11: invokedynamic #13, 0 // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I 16: tableswitch { // 0 to 2 0: 44 1: 74 2: 105 default: 122 } 44: aload_2 45: checkcast #17 // class java/lang/String 48: astore 4 50: aload 4 52: invokevirtual #19 // Method java/lang/String.length:()I 55: ifeq 63 58: iconst_1 59: istore_3 60: goto 9 63: getstatic #23 // Field java/lang/System.out:Ljava/io/PrintStream; 66: ldc #29 // String 1st case 68: invokevirtual #31 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 71: goto 133 74: aload_2 75: checkcast #17 // class java/lang/String 78: astore 5 80: aload 5 82: invokevirtual #19 // Method java/lang/String.length:()I 85: iconst_1 86: if_icmpeq 94 89: iconst_2 90: istore_3 91: goto 9 94: getstatic #23 // Field java/lang/System.out:Ljava/io/PrintStream; 97: ldc #37 // String 2nd case 99: invokevirtual #31 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 102: goto 133 105: aload_2 106: checkcast #17 // class java/lang/String 109: astore 6 111: getstatic #23 // Field java/lang/System.out:Ljava/io/PrintStream; 114: ldc #39 // String 3rd case 116: invokevirtual #31 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 119: goto 133 122: getstatic #23 // Field java/lang/System.out:Ljava/io/PrintStream; 125: ldc #41 // String default case 127: invokevirtual #31 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 130: goto 133 133: return LineNumberTable: line 3: 0 line 4: 44 line 5: 63 line 4: 71 line 6: 74 line 7: 94 line 6: 102 line 8: 105 line 9: 111 line 8: 119 line 11: 122 line 8: 130 line 13: 133 I believe `LineNumberTable` entries `line 6: 102`, `line 8: 119` and `line 8: 130` should not be present. Otherwise debugger misleadingly will be showing line `6` after step from line `7`, line `8` after step from line `9` and even more misleadingly line `8` after step from line `11`. This also affects [JaCoCo](https://github.com/jacoco/jacoco) Java Code Coverage tool (I'm one of its developers), which relies on LineNumberTable to provide code coverage highlighting and these entries cause misleading highlighting - partial coverage of line `8` when default case was not executed. Should I create separate ticket about this in https://bugs.openjdk.java.net/ or this comment here is enough? ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at univ-mlv.fr Tue May 25 11:42:52 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 25 May 2021 13:42:52 +0200 (CEST) Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: <2070914630.587750.1621942972319.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Evgeny Mandrikov" > ?: "build-dev" , "compiler-dev" , "core-libs-dev" > , "javadoc-dev" > Envoy?: Mardi 25 Mai 2021 11:32:03 > Objet: Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] > On Mon, 17 May 2021 19:01:01 GMT, Jan Lahoda wrote: > >>> Good work. There's a lot to take in here. I think overall, it holds up well - I >>> like how case labels have been extended to accommodate for patterns. In the >>> front-end, I think there are some questions over the split between Attr and >>> Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis >>> happens in Attr instead of Flow and I left some questions to make sure I >>> understand what's happening. >>> >>> In the backend it's mostly good work - but overall the structure of the code, >>> both in Lower and in TransPattern is getting very difficult to follow, given >>> there are many different kind of switches each with its own little twist >>> attached to it. It would be nice, I think (maybe in a separate cleanup?) if the >>> code paths serving the different switch kinds could be made more separate, so >>> that, when reading the code we can worry only about one possible code shape. >>> That would make the code easier to document as well. >> >> @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested >> changes in recent commits >> (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b >> https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 >> ). >> >> I've also tried to update the implementation for the latest spec changes here: >> https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b >> >> The spec changes are: total patterns are nullable; pattern matching ("new") >> statement switches must be complete (as switch expressions). >> >> Any further feedback is welcome! > > Hi @lahodaj ?? , > > I tried `javac` built from this PR and for the following `Example.java` > > > class Example { > void example(Object o) { > switch (o) { > case String s && s.length() == 0 -> > System.out.println("1st case"); > case String s && s.length() == 1 -> // line 6 > System.out.println("2nd case"); // line 7 > case String s -> // line 8 > System.out.println("3rd case"); // line 9 > default -> // line 10 > System.out.println("default case"); // line 11 > } > } > } > > > execution of > > > javac --enable-preview --release 17 Example.java > javap -v -p Example.class > > > produces > > > void example(java.lang.Object); > descriptor: (Ljava/lang/Object;)V > flags: (0x0000) > Code: > stack=2, locals=7, args_size=2 > 0: aload_1 > 1: dup > 2: invokestatic #7 // Method > java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object; > 5: pop > 6: astore_2 > 7: iconst_0 > 8: istore_3 > 9: aload_2 > 10: iload_3 > 11: invokedynamic #13, 0 // InvokeDynamic > #0:typeSwitch:(Ljava/lang/Object;I)I > 16: tableswitch { // 0 to 2 > 0: 44 > 1: 74 > 2: 105 > default: 122 > } > 44: aload_2 > 45: checkcast #17 // class java/lang/String > 48: astore 4 > 50: aload 4 > 52: invokevirtual #19 // Method java/lang/String.length:()I > 55: ifeq 63 > 58: iconst_1 > 59: istore_3 > 60: goto 9 > 63: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 66: ldc #29 // String 1st case > 68: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 71: goto 133 > 74: aload_2 > 75: checkcast #17 // class java/lang/String > 78: astore 5 > 80: aload 5 > 82: invokevirtual #19 // Method java/lang/String.length:()I > 85: iconst_1 > 86: if_icmpeq 94 > 89: iconst_2 > 90: istore_3 > 91: goto 9 > 94: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 97: ldc #37 // String 2nd case > 99: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 102: goto 133 > 105: aload_2 > 106: checkcast #17 // class java/lang/String > 109: astore 6 > 111: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 114: ldc #39 // String 3rd case > 116: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 119: goto 133 > 122: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 125: ldc #41 // String default case > 127: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 130: goto 133 > 133: return > LineNumberTable: > line 3: 0 > line 4: 44 > line 5: 63 > line 4: 71 > line 6: 74 > line 7: 94 > line 6: 102 > line 8: 105 > line 9: 111 > line 8: 119 > line 11: 122 > line 8: 130 > line 13: 133 > > > I believe `LineNumberTable` entries `line 6: 102`, `line 8: 119` and `line 8: > 130` should not be present. > Otherwise debugger misleadingly will be showing > line `6` after step from line `7`, > line `8` after step from line `9` > and even more misleadingly line `8` after step from line `11`. > > This also affects [JaCoCo](https://github.com/jacoco/jacoco) Java Code Coverage > tool (I'm one of its developers), which relies on LineNumberTable to provide > code coverage highlighting and these entries cause misleading highlighting - > partial coverage of line `8` when default case was not executed. > > Should I create separate ticket about this in https://bugs.openjdk.java.net/ or > this comment here is enough? Also why invokedynamic take a constant int as second argument ? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3863 R?mi From jlahoda at openjdk.java.net Tue May 25 12:22:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 12:22:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 08:00:12 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing various error-related bugs. Thanks Evgeny, I'll take a look. @forax, do you mean why there is "0" in: 11: invokedynamic #13, 0 ? The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at openjdk.java.net Tue May 25 14:16:59 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 25 May 2021 14:16:59 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 12:20:02 GMT, Jan Lahoda wrote: > Thanks Evgeny, I'll take a look. > > @forax, do you mean why there is "0" in: > 11: invokedynamic #13, 0 > ? Not this one, the one on the stack. 7: iconst_0 <---- this zero 8: istore_3 9: aload_2 10: iload_3 11: invokedynamic #13, 0 // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I Why the descriptor is (Ljava/lang/Object;I)I instead of (Ljava/lang/Object;)I, what is the semantics associated to that integer ? > The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. I know that a little to well, i'm one of the guys behind the design of indy :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Tue May 25 14:25:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 14:25:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:13:55 GMT, R?mi Forax wrote: > > Thanks Evgeny, I'll take a look. > > @forax, do you mean why there is "0" in: > > 11: invokedynamic #13, 0 > > ? > > Not this one, the one on the stack. > > 7: iconst_0 <---- this zero > 8: istore_3 > 9: aload_2 > 10: iload_3 > 11: invokedynamic #13, 0 // InvokeDynamic > #0:typeSwitch:(Ljava/lang/Object;I)I > > Why the descriptor is (Ljava/lang/Object;I)I instead of (Ljava/lang/Object;)I, > what is the semantics associated to that integer ? The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: class Example { void example(Object o) { switch (o) { case String s && s.length() == 0 -> System.out.println("1st case"); case String s && s.length() == 1 -> // line 6 System.out.println("2nd case"); // line 7 case String s -> // line 8 System.out.println("3rd case"); // line 9 default -> // line 10 System.out.println("default case"); // line 11 } } } If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. > > > The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. > > I know that a little to well, i'm one of the guys behind the design of indy :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From godin at openjdk.java.net Tue May 25 14:25:02 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Tue, 25 May 2021 14:25:02 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:13:55 GMT, R?mi Forax wrote: > 7: iconst_0 <---- this zero @forax as far as I understood this will be a value of parameter `startIndex` in `java.lang.runtime. SwitchBootstraps.doSwitch` ?? Please correct me @lahodaj if I'm wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From prappo at openjdk.java.net Tue May 25 14:27:04 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 25 May 2021 14:27:04 GMT Subject: Integrated: 8267633: Clarify documentation of (Doc)TreeScanner In-Reply-To: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com> References: <5W53w-d4Cq7N-KoXhjpa80luvcB2bLoPJLmbBrzN7_8=.b5dcf294-9e43-4e4e-a009-7ca509285267@github.com> Message-ID: On Mon, 24 May 2021 21:05:02 GMT, Pavel Rappo wrote: > When a method is said to be called "on an object", this means that the object is a receiver. When a method is said to be called "with an object", this means that the object is a parameter. > > To scan an instance of (Doc)Tree, the "scan" method is called on the instance of (Doc)TreeScanner with that instance of (Doc)Tree. This pull request has now been integrated. Changeset: 5a5b807e Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/5a5b807e8e3b3148eea911ed1b2c9624b6846370 Stats: 12 lines in 3 files changed: 0 ins; 0 del; 12 mod 8267633: Clarify documentation of (Doc)TreeScanner Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4174 From jjg at openjdk.java.net Tue May 25 14:57:58 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 14:57:58 GMT Subject: Integrated: JDK-8267575: Add new documentation group in HtmlStyle In-Reply-To: <1k2XJRf0Ip5LzD4qi77iIXOTIIF9_YP8w1u9cDo4Az4=.bdafec4e-0f9a-4cc8-b72c-1af0fac9c1a9@github.com> References: <1k2XJRf0Ip5LzD4qi77iIXOTIIF9_YP8w1u9cDo4Az4=.bdafec4e-0f9a-4cc8-b72c-1af0fac9c1a9@github.com> Message-ID: On Sat, 22 May 2021 20:57:39 GMT, Jonathan Gibbons wrote: > Please review a relatively simple primarily-doc update for HtmlStyle. > > The change is mostly grouping and commenting items. > > Some existing comments were incorrect and have been updated. This pull request has now been integrated. Changeset: cc687fd4 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/cc687fd43ade6be8760c559f3ffa909c5937727c Stats: 89 lines in 1 file changed: 75 ins; 12 del; 2 mod 8267575: Add new documentation group in HtmlStyle Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/4155 From jjg at openjdk.java.net Tue May 25 15:00:57 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 15:00:57 GMT Subject: RFR: JDK-8267574: Dead code in HtmlStyle/HtmlDocletWriter In-Reply-To: References: Message-ID: On Tue, 25 May 2021 08:36:13 GMT, Hannes Walln?fer wrote: >> Please review a simple `noreg-cleanup` change to remove some dead code. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 580: > >> 578: display:inline-block; >> 579: } >> 580: div.block div.deprecation-comment, div.block div.block span.emphasized-phrase { > > A quick search through the code and generated docs suggests that `emphasized-phrase` is unused as well. Should this also be removed? Let me investigate a test program to compare the class names in the style sheet and the members of HtmlStyle, and then decide whether to merge that here or do a separate commit/PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4154 From forax at openjdk.java.net Tue May 25 16:03:56 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 25 May 2021 16:03:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:22:57 GMT, Jan Lahoda wrote: > The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: > > ``` > class Example { > void example(Object o) { > switch (o) { > case String s && s.length() == 0 -> > System.out.println("1st case"); > case String s && s.length() == 1 -> // line 6 > System.out.println("2nd case"); // line 7 > case String s -> // line 8 > System.out.println("3rd case"); // line 9 > default -> // line 10 > System.out.println("default case"); // line 11 > } > } > } > ``` > > If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. The problem with this design is that calling example("foo") forces the VM will do 6 checkcast String on "foo", and it doesn't work with sub-patterns. Desugaring the guards as static method like with lambdas seems more promising, indy can be called with the pairs [String, MethodHandle(s -> s.length() == 0)], [String, MethodHandle(s -> s.length() == 0)] and [_,_] (with the guards passed as a constant method handles again like lambdas are desugared). It means that the indy needs to capture all local variables that are used in the guards, instead of passing an int. I believe that a translation using constant method handles for guards is far more efficient than using an int and a backward branch but it has a higher cost in term of runtime data structures. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Tue May 25 16:17:59 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 16:17:59 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> On Tue, 25 May 2021 16:00:43 GMT, R?mi Forax wrote: > > The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: > > ``` > > class Example { > > void example(Object o) { > > switch (o) { > > case String s && s.length() == 0 -> > > System.out.println("1st case"); > > case String s && s.length() == 1 -> // line 6 > > System.out.println("2nd case"); // line 7 > > case String s -> // line 8 > > System.out.println("3rd case"); // line 9 > > default -> // line 10 > > System.out.println("default case"); // line 11 > > } > > } > > } > > ``` > > > > > > > > > > > > > > > > > > > > > > > > If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. > > The problem with this design is that calling example("foo") forces the VM will do 6 checkcast String on "foo", and it doesn't work with sub-patterns. Desugaring the guards as static method like with lambdas seems more promising, indy can be called with the pairs [String, MethodHandle(s -> s.length() == 0)], [String, MethodHandle(s -> s.length() == 0)] and [_,_] (with the guards passed as a constant method handles again like lambdas are desugared). > It means that the indy needs to capture all local variables that are used in the guards, instead of passing an int. > > I believe that a translation using constant method handles for guards is far more efficient than using an int and a backward branch but it has a higher cost in term of runtime data structures. I'd like to note this is a preview feature - we can change the desugaring. At the same time, I don't think this does not work with sub-patterns (those can be easily desugared to guards, I think). Regarding efficiency, it may be a balance between classfile overhead (which will be higher if we need to desugar every guard to a separate method), and the possibility to tweak the matching at runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From prappo at openjdk.java.net Tue May 25 21:43:51 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 25 May 2021 21:43:51 GMT Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.** Message-ID: Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference com.sun.tools.javadoc.ClassDocImpl#findField should've looked like this com.sun.tools.javadoc.main.ClassDocImpl#findField Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed: 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85 ------------- Commit messages: - Fix issues found by a repaired test - Address feedback - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/4192/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4192&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267708 Stats: 24 lines in 6 files changed: 1 ins; 13 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4192.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4192/head:pull/4192 PR: https://git.openjdk.java.net/jdk/pull/4192 From jjg at openjdk.java.net Tue May 25 21:44:13 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 21:44:13 GMT Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.** In-Reply-To: References: Message-ID: On Tue, 25 May 2021 17:32:11 GMT, Pavel Rappo wrote: > Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference > > com.sun.tools.javadoc.ClassDocImpl#findField > > should've looked like this > > com.sun.tools.javadoc.main.ClassDocImpl#findField > > Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed: > > 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74 > 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85 The package references in the two tests you found should be updated to use `jdk.javadoc`. That's already present for #2, so just delete the old package in #2, and change the package in #1. src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 627: > 625: } > 626: > 627: /** @see com.sun.tools.javadoc.ClassDocImpl#findField */ Is there an equivalent new-style method that should be used instead? src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 319: > 317: * com.sun.tools.javadoc.Main.execute(String programName, > 318: * PrintWriter errWriter, PrintWriter warnWriter, PrintWriter noticeWriter, > 319: * String defaultDocletClassName, String... args) It is generally bad form to have `@Deprecated` without `@deprecated`. In this case, separate ongoing work to cleanup `Messager` will eventually mean we can remove the method altogether. If you really want to remove the reference to the old code, the `@deprecated` comment should be updated to "Still in use by javadoc's Mesager class." or some such. ------------- Changes requested by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4192 From prappo at openjdk.java.net Tue May 25 21:44:20 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 25 May 2021 21:44:20 GMT Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.** In-Reply-To: References: Message-ID: On Tue, 25 May 2021 17:32:11 GMT, Pavel Rappo wrote: > Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference > > com.sun.tools.javadoc.ClassDocImpl#findField > > should've looked like this > > com.sun.tools.javadoc.main.ClassDocImpl#findField > > Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed: > > 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74 > 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85 1. Removed extinct packages 2. Removed `ignore("jdk/javadoc/internal/tool/Start", "versionRB")` since `Start.versionRB` was removed in JDK-8246078 3. Returned updated deprecation info. When I fixed the location of javadoc, the NoStringToLower test found two issues it could not see before, both of which I then fixed. I also note, that this method in DetectMutableStaticFields should perhaps use `String.startsWith` instead of `String.contains` in which case `packagesToSeekFor` should be also renamed to `packagePrefixesToSeekFor`: boolean shouldAnalyzePackage(String packageName) { for (String aPackage: packagesToSeekFor) { if (packageName.contains(aPackage)) { return true; } } return false; } But if this is to be fixed, it should be done in a separate PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4192 From jjg at openjdk.java.net Tue May 25 21:44:32 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 21:44:32 GMT Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.** In-Reply-To: References: Message-ID: On Tue, 25 May 2021 17:39:13 GMT, Jonathan Gibbons wrote: >> Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference >> >> com.sun.tools.javadoc.ClassDocImpl#findField >> >> should've looked like this >> >> com.sun.tools.javadoc.main.ClassDocImpl#findField >> >> Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed: >> >> 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74 >> 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85 > > src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 627: > >> 625: } >> 626: >> 627: /** @see com.sun.tools.javadoc.ClassDocImpl#findField */ > > Is there an equivalent new-style method that should be used instead? The most likely justification for all these ClassDocImpl references is now in `ReferenceTree`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4192 From prappo at openjdk.java.net Tue May 25 21:44:35 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 25 May 2021 21:44:35 GMT Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.** In-Reply-To: References: Message-ID: <9Z4Vdedsl2rRdjx2qgBVBudc_kQcG6i9urM2Czjxx4I=.c48dde37-6195-4fc1-b43b-fc6eca04c588@github.com> On Tue, 25 May 2021 17:46:59 GMT, Jonathan Gibbons wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 627: >> >>> 625: } >>> 626: >>> 627: /** @see com.sun.tools.javadoc.ClassDocImpl#findField */ >> >> Is there an equivalent new-style method that should be used instead? > > The most likely justification for all these ClassDocImpl references is now in `ReferenceTree`. A doc comment consisting solely of an `@see` tag has unclear semantics. The methods I removed such doc comments from are private and can be used only from their enclosing instance. ------------- PR: https://git.openjdk.java.net/jdk/pull/4192 From jjg at openjdk.java.net Tue May 25 21:54:08 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 21:54:08 GMT Subject: RFR: JDK-8267574: Dead code in HtmlStyle/HtmlDocletWriter [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:57:58 GMT, Jonathan Gibbons wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 580: >> >>> 578: display:inline-block; >>> 579: } >>> 580: div.block div.deprecation-comment, div.block div.block span.emphasized-phrase { >> >> A quick search through the code and generated docs suggests that `emphasized-phrase` is unused as well. Should this also be removed? > > Let me investigate a test program to compare the class names in the style sheet and the members of HtmlStyle, and then decide whether to merge that here or do a separate commit/PR. Test program reveals differences that need to be investigated. See https://bugs.openjdk.java.net/browse/JDK-8267709 For now, I've just removed `emphasized-phrase` ------------- PR: https://git.openjdk.java.net/jdk/pull/4154 From jjg at openjdk.java.net Tue May 25 21:54:12 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 21:54:12 GMT Subject: Integrated: JDK-8267574: Dead code in HtmlStyle/HtmlDocletWriter In-Reply-To: References: Message-ID: On Sat, 22 May 2021 16:18:00 GMT, Jonathan Gibbons wrote: > Please review a simple `noreg-cleanup` change to remove some dead code. This pull request has now been integrated. Changeset: 594d4544 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/594d4544759a240690ed4c0432c8140b852aea5a Stats: 11 lines in 3 files changed: 0 ins; 9 del; 2 mod 8267574: Dead code in HtmlStyle/HtmlDocletWriter Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/4154 From jjg at openjdk.java.net Tue May 25 21:54:02 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 21:54:02 GMT Subject: RFR: JDK-8267574: Dead code in HtmlStyle/HtmlDocletWriter [v2] In-Reply-To: References: Message-ID: > Please review a simple `noreg-cleanup` change to remove some dead code. 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 four additional commits since the last revision: - review feedback: remove emphasized-phrase completely! - review feedback: remove emphasized-phrase - Merge remote-tracking branch 'upstream/master' into HtmlStyle-interfaceName - JDK-8267574: Dead code in HtmlStyle/HtmlDocletWriter ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4154/files - new: https://git.openjdk.java.net/jdk/pull/4154/files/c33a8bd9..ac0124ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4154&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4154&range=00-01 Stats: 4175 lines in 1040 files changed: 1757 ins; 684 del; 1734 mod Patch: https://git.openjdk.java.net/jdk/pull/4154.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4154/head:pull/4154 PR: https://git.openjdk.java.net/jdk/pull/4154 From jjg at openjdk.java.net Tue May 25 22:21:21 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 22:21:21 GMT Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.** In-Reply-To: <9Z4Vdedsl2rRdjx2qgBVBudc_kQcG6i9urM2Czjxx4I=.c48dde37-6195-4fc1-b43b-fc6eca04c588@github.com> References: <9Z4Vdedsl2rRdjx2qgBVBudc_kQcG6i9urM2Czjxx4I=.c48dde37-6195-4fc1-b43b-fc6eca04c588@github.com> Message-ID: On Tue, 25 May 2021 18:49:10 GMT, Pavel Rappo wrote: >> The most likely justification for all these ClassDocImpl references is now in `ReferenceTree`. > > A doc comment consisting solely of an `@see` tag has unclear semantics. The methods I removed such doc comments from are private and can be used only from their enclosing instance. Let me go do some archaeology. While the comments may have been substandard, I would still like to recall their intent. ------------- PR: https://git.openjdk.java.net/jdk/pull/4192 From jjg at openjdk.java.net Tue May 25 22:28:17 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 22:28:17 GMT Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.** In-Reply-To: References: <9Z4Vdedsl2rRdjx2qgBVBudc_kQcG6i9urM2Czjxx4I=.c48dde37-6195-4fc1-b43b-fc6eca04c588@github.com> Message-ID: On Tue, 25 May 2021 22:17:51 GMT, Jonathan Gibbons wrote: >> A doc comment consisting solely of an `@see` tag has unclear semantics. The methods I removed such doc comments from are private and can be used only from their enclosing instance. > > Let me go do some archaeology. While the comments may have been substandard, I would still like to recall their intent. The notable content of the comments on those `ClassDocImpl` methods is that they document (I hesitate to use the "specify" word) the search order, with the additional comment *Note that this is not necessarily what the compiler would do!* ------------- PR: https://git.openjdk.java.net/jdk/pull/4192 From jjg at openjdk.java.net Tue May 25 22:44:16 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 25 May 2021 22:44:16 GMT Subject: RFR: 8267708: Remove references to com.sun.tools.javadoc.** In-Reply-To: References: Message-ID: On Tue, 25 May 2021 17:32:11 GMT, Pavel Rappo wrote: > Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference > > com.sun.tools.javadoc.ClassDocImpl#findField > > should've looked like this > > com.sun.tools.javadoc.main.ClassDocImpl#findField > > Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed: > > 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74 > 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85 See the updated review comments about removing the obsolete doc comments. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4192 From jjg at openjdk.java.net Wed May 26 00:33:28 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 26 May 2021 00:33:28 GMT Subject: RFR: JDK-8267709: Investigate differences between HtmlStyle and stylesheet.css Message-ID: <3gdBegL2aPbnsFFlhd1SjmLx_Y4XNXzN_Quzw3etZxM=.98b29ab9-eac0-4acd-80e1-d421c9e331d7@github.com> Please review a new test to track the differences between `HtmlStyle.java` and `stylesheet.css`. The test passes, because all discrepancies are noted within the test. However, some of the discrepancies may indicate the need for follow-up work, such as adding new items to `HtmlStyle` for documentation purposes, or removing unused code in the main `stylesheet.css` file. There is also a minor/trivial change to fix a copy-paste error in a comment in `HtmlStyle`. ------------- Commit messages: - polish test - update test; explain more discrepancies - typo in HtmlStyle - typo - JDK-8267709: Investigate differences between HtmlStyle and stylesheet.css Changes: https://git.openjdk.java.net/jdk/pull/4195/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4195&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267709 Stats: 222 lines in 2 files changed: 221 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4195/head:pull/4195 PR: https://git.openjdk.java.net/jdk/pull/4195 From prappo at openjdk.java.net Wed May 26 11:30:16 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 26 May 2021 11:30:16 GMT Subject: Integrated: 8267708: Remove references to com.sun.tools.javadoc.** In-Reply-To: References: Message-ID: On Tue, 25 May 2021 17:32:11 GMT, Pavel Rappo wrote: > Although the `com.sun.tools.javadoc.**` packages were removed in JDK-8215584, some references to them remain, mainly in the form of links in doc comments. Some of those links refer to classes that never existed, which I reckon is due to a typo; for example, this reference > > com.sun.tools.javadoc.ClassDocImpl#findField > > should've looked like this > > com.sun.tools.javadoc.main.ClassDocImpl#findField > > Grep showed that some tests also use `com.sun.tools.javadoc` and some other extinct packages. However, it is unclear if those "references" should also be removed: > > 1. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/NoStringToLower.java#L60-L74 > 2. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java#L73-L85 This pull request has now been integrated. Changeset: 4343997a Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/4343997a1a2b38581488932f6a4971ce330bd467 Stats: 24 lines in 6 files changed: 1 ins; 13 del; 10 mod 8267708: Remove references to com.sun.tools.javadoc.** This commit changes BaseOptions.java to fix the NoStringToLower test that failed after jdk.javadoc has been added to the list of package prefixes that NoStringToLower scans. Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4192 From jlahoda at openjdk.java.net Wed May 26 17:52:36 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 26 May 2021 17:52:36 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html 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: - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. - Correcting LineNumberTable for rule switches. - Merging master into JDK-8262891 - Fixing various error-related bugs. - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. - Reflecting recent spec changes. - Reflecting review comments. - Reflecting review comments on SwitchBootstraps. - Trailing whitespaces. - Cleanup, reflecting review comments. - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=04 Stats: 4551 lines in 77 files changed: 4235 ins; 119 del; 197 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Wed May 26 19:42:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 26 May 2021 19:42:12 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > 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: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 In: https://github.com/openjdk/jdk/pull/3863/commits/7d1abc141ecfecaf0798a2bad899705c116154e7 I've updated the code to produce better/more useful LineNumberTable for rule switches. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at openjdk.java.net Wed May 26 20:24:06 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 26 May 2021 20:24:06 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> References: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> Message-ID: On Tue, 25 May 2021 16:14:56 GMT, Jan Lahoda wrote: > I'd like to note this is a preview feature - we can change the desugaring. At the same time, I don't think this does not work with sub-patterns (those can be easily desugared to guards, I think). Yes, but in that case the classcheck du to a sub-pattern matching will be either an instanceof or some other invokedynamic. Having several indy will bloat the code and if we use instanceof, why not using instanceof all along the way. > Regarding efficiency, it may be a balance between classfile overhead (which will be higher if we need to desugar every guard to a separate method), and the possibility to tweak the matching at runtime. I fear more the 2 bytes length bytecode limit of a method than the constant pool length limit mostly because people are already using a bunch of lambdas to simulate pattern matching. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Thu May 27 09:48:13 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 27 May 2021 09:48:13 GMT Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec Message-ID: As noted in: https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316 Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far. The CSR is started for review here: https://bugs.openjdk.java.net/browse/JDK-8267838 ------------- Depends on: https://git.openjdk.java.net/jdk/pull/3863 Commit messages: - 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec Changes: https://git.openjdk.java.net/jdk/pull/4223/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4223&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267832 Stats: 692 lines in 4 files changed: 500 ins; 0 del; 192 mod Patch: https://git.openjdk.java.net/jdk/pull/4223.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4223/head:pull/4223 PR: https://git.openjdk.java.net/jdk/pull/4223 From mcimadamore at openjdk.java.net Thu May 27 10:45:11 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 27 May 2021 10:45:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > 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: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 Compiler changes look good src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1657: > 1655: > 1656: try { > 1657: boolean enumSwitch = (seltype.tsym.flags() & Flags.ENUM) != 0; This is getting convoluted enough that an enum on the AST (e.g. SwitchKind) might be helpful to save some of these classification properties - which I imagine we have to redo at some point later (e.g. in Lower/TransPattern). I'm ok with fixing in a followup issue. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From hannesw at openjdk.java.net Thu May 27 11:02:16 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 27 May 2021 11:02:16 GMT Subject: RFR: JDK-8263468: New page for "recent" new API Message-ID: This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. ------------- Commit messages: - JDK-8263468: make constant static - JDK-8263468: Remove unused DocPaths methods - JDK-8263468: Cleanup - JDK-8263468: Add tests - JDK-8263468: Update to new Table methods - Merge branch 'master' into JDK-8263468 - JDK-8263468: Fix tests - JDK-8263468: Update to latest CSR - JDK-8263468: Tweak help message wording - JDK-8263468: Rename -since to --since, add --since-name option - ... and 4 more: https://git.openjdk.java.net/jdk/compare/9eaa4afc...e81532b2 Changes: https://git.openjdk.java.net/jdk/pull/4209/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263468 Stats: 1921 lines in 38 files changed: 1842 ins; 38 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/4209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4209/head:pull/4209 PR: https://git.openjdk.java.net/jdk/pull/4209 From prappo at openjdk.java.net Thu May 27 11:59:03 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 27 May 2021 11:59:03 GMT Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:41:17 GMT, Jan Lahoda wrote: > As noted in: > https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316 > > Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far. > > The CSR is started for review here: > https://bugs.openjdk.java.net/browse/JDK-8267838 I wish we had a better class-level (Doc)TreeScanner doc comment. That would allow to avoid most of the repetition in method-level comments, the vast majority of which are there only to say that the children are scanned in left to right order. src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 38: > 36: * nodes. > 37: * > 38: * @implSpec 1. Should the error-counting example in the immediately following paragraph belong to this `@implSpec` section? 2. Why is there no similar `@implSpec` section being added to the class-level doc comment of TreeScanner? If such a section is to be added, then should the identifier-counting example in the immediately following paragraph belong to that section? ------------- PR: https://git.openjdk.java.net/jdk/pull/4223 From erikj at openjdk.java.net Thu May 27 12:55:06 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 12:55:06 GMT Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: References: Message-ID: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> On Wed, 26 May 2021 16:02:29 GMT, Hannes Walln?fer wrote: > This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. > > The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. > > One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. > > The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. I uploaded the generated documentation here: > > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html make/Docs.gmk line 336: > 334: > 335: # Add summary pages for new/deprecated APIs in recent releases > 336: $1_OPTIONS += --since 12,13,14,15,16,17 --since-label "New API since JDK 11" How do you expect this to change as the JDK version is bumped? If there is an expected pattern, then maybe we should try to generate the list instead, so we don't need to manually update twice a year. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Thu May 27 13:08:08 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 27 May 2021 13:08:08 GMT Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: On Thu, 27 May 2021 12:52:34 GMT, Erik Joelsson wrote: >> This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. >> >> The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. >> >> One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. >> >> The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. I uploaded the generated documentation here: >> >> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html >> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html > > make/Docs.gmk line 336: > >> 334: >> 335: # Add summary pages for new/deprecated APIs in recent releases >> 336: $1_OPTIONS += --since 12,13,14,15,16,17 --since-label "New API since JDK 11" > > How do you expect this to change as the JDK version is bumped? If there is an expected pattern, then maybe we should try to generate the list instead, so we don't need to manually update twice a year. I don't have a solution for this problem. AFAIK there are a few things that have to be "bumped" manually between releases, and this would be yet another. Obviously not a great solution. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From erikj at openjdk.java.net Thu May 27 13:31:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 13:31:07 GMT Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: On Thu, 27 May 2021 13:05:27 GMT, Hannes Walln?fer wrote: >> make/Docs.gmk line 336: >> >>> 334: >>> 335: # Add summary pages for new/deprecated APIs in recent releases >>> 336: $1_OPTIONS += --since 12,13,14,15,16,17 --since-label "New API since JDK 11" >> >> How do you expect this to change as the JDK version is bumped? If there is an expected pattern, then maybe we should try to generate the list instead, so we don't need to manually update twice a year. > > I don't have a solution for this problem. AFAIK there are a few things that have to be "bumped" manually between releases, and this would be yet another. Obviously not a great solution. Yes, there are a few things, but in the build itself, we are down to a single config file today, so I would really appreciate if this could be figured out. I can provide the implementation for generating this, but I need to understand what the expected pattern is. From what I can see, it looks like $(sequence N, M) where N is the last LTS+1 and M is current JDK version. Then the string has "JDK N" in it. M is already well defined, so the only new input here is N, which we could move to the version numbers config file (make/conf/version-numbers.conf). Something like DEFAULT_VERSION_DOCS_API_SINCE=11. There is some additional boilerplate needed, and the sequence macro of course, but does this sound reasonable to you? ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From erikj at openjdk.java.net Thu May 27 13:36:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 13:36:03 GMT Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: On Thu, 27 May 2021 13:28:33 GMT, Erik Joelsson wrote: >> I don't have a solution for this problem. AFAIK there are a few things that have to be "bumped" manually between releases, and this would be yet another. Obviously not a great solution. > > Yes, there are a few things, but in the build itself, we are down to a single config file today, so I would really appreciate if this could be figured out. I can provide the implementation for generating this, but I need to understand what the expected pattern is. From what I can see, it looks like $(sequence N, M) where N is the last LTS+1 and M is current JDK version. Then the string has "JDK N" in it. M is already well defined, so the only new input here is N, which we could move to the version numbers config file (make/conf/version-numbers.conf). Something like DEFAULT_VERSION_DOCS_API_SINCE=11. There is some additional boilerplate needed, and the sequence macro of course, but does this sound reasonable to you? We actually have a sequence macro already, so generating the list can be done like this: $(call CommaList,$(call sequence 12, 17)) Or if what you have is 11 and 17: $(call CommaList, $(filter-out 11, $(call sequence 11, 17))) ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Thu May 27 14:11:06 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 27 May 2021 14:11:06 GMT Subject: RFR: JDK-8267709: Investigate differences between HtmlStyle and stylesheet.css In-Reply-To: <3gdBegL2aPbnsFFlhd1SjmLx_Y4XNXzN_Quzw3etZxM=.98b29ab9-eac0-4acd-80e1-d421c9e331d7@github.com> References: <3gdBegL2aPbnsFFlhd1SjmLx_Y4XNXzN_Quzw3etZxM=.98b29ab9-eac0-4acd-80e1-d421c9e331d7@github.com> Message-ID: On Tue, 25 May 2021 19:10:44 GMT, Jonathan Gibbons wrote: > Please review a new test to track the differences between `HtmlStyle.java` and `stylesheet.css`. > > The test passes, because all discrepancies are noted within the test. However, some of the discrepancies may indicate the need for follow-up work, such as adding new items to `HtmlStyle` for documentation purposes, or removing unused code in the main `stylesheet.css` file. > > There is also a minor/trivial change to fix a copy-paste error in a comment in `HtmlStyle`. test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java line 153: > 151: "bottom-nav", "clear", "constant-values-container", "deprecated-content", > 152: "footer", "hidden", "override-specify-label", "serialized-class-details", > 153: "tab", "table-sub-heading-color"); Shouldn't these be removed? Are we planning to do that in a separate issue? ------------- PR: https://git.openjdk.java.net/jdk/pull/4195 From hannesw at openjdk.java.net Thu May 27 14:18:06 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 27 May 2021 14:18:06 GMT Subject: RFR: JDK-8267709: Investigate differences between HtmlStyle and stylesheet.css In-Reply-To: <3gdBegL2aPbnsFFlhd1SjmLx_Y4XNXzN_Quzw3etZxM=.98b29ab9-eac0-4acd-80e1-d421c9e331d7@github.com> References: <3gdBegL2aPbnsFFlhd1SjmLx_Y4XNXzN_Quzw3etZxM=.98b29ab9-eac0-4acd-80e1-d421c9e331d7@github.com> Message-ID: On Tue, 25 May 2021 19:10:44 GMT, Jonathan Gibbons wrote: > Please review a new test to track the differences between `HtmlStyle.java` and `stylesheet.css`. > > The test passes, because all discrepancies are noted within the test. However, some of the discrepancies may indicate the need for follow-up work, such as adding new items to `HtmlStyle` for documentation purposes, or removing unused code in the main `stylesheet.css` file. > > There is also a minor/trivial change to fix a copy-paste error in a comment in `HtmlStyle`. The new test looks good, apart from the question whether we should remove unused styles now, later, or not at all. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4195 From jjg at openjdk.java.net Thu May 27 14:42:12 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 27 May 2021 14:42:12 GMT Subject: Withdrawn: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: On Tue, 18 May 2021 00:38:40 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to expose the 1 or 2 streams available within javadoc for writing expected or diagnostic output. > > The change at this time is just to _expose_ the streams; followup work may change how we _use_ them. > > There are two points of note: > > * `JavadocTester` is extended to provided access to the javadoc entry point used by the launcher. This is simpler than exec-ing the tool to invoke the entry point, and allows us to use the existing code to capture and analyze the output. > * The initialization of the default streams in `Messager` is deferred, to allow `Messager` to use the values of `System.out` and `System.err` at the time that javadoc is started, instead of when the class was loaded. This is part of the problems described separately in JDK-8267203, but which needs to be addressed here as part of this work. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From prappo at openjdk.java.net Thu May 27 14:49:09 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 27 May 2021 14:49:09 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in DocletEnvironment In-Reply-To: References: Message-ID: On Tue, 18 May 2021 00:38:40 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to expose the 1 or 2 streams available within javadoc for writing expected or diagnostic output. > > The change at this time is just to _expose_ the streams; followup work may change how we _use_ them. > > There are two points of note: > > * `JavadocTester` is extended to provided access to the javadoc entry point used by the launcher. This is simpler than exec-ing the tool to invoke the entry point, and allows us to use the existing code to capture and analyze the output. > * The initialization of the default streams in `Messager` is deferred, to allow `Messager` to use the values of `System.out` and `System.err` at the time that javadoc is started, instead of when the class was loaded. This is part of the problems described separately in JDK-8267203, but which needs to be addressed here as part of this work. This PR has been superseded by https://github.com/openjdk/jdk/pull/4216. ------------- PR: https://git.openjdk.java.net/jdk/pull/4077 From jjg at openjdk.java.net Thu May 27 14:59:08 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 27 May 2021 14:59:08 GMT Subject: RFR: JDK-8267709: Investigate differences between HtmlStyle and stylesheet.css In-Reply-To: References: <3gdBegL2aPbnsFFlhd1SjmLx_Y4XNXzN_Quzw3etZxM=.98b29ab9-eac0-4acd-80e1-d421c9e331d7@github.com> Message-ID: On Thu, 27 May 2021 14:14:55 GMT, Hannes Walln?fer wrote: > The new test looks good, apart from the question whether we should remove unused styles now, later, or not at all. I was thinking to remove the unused styles in a separate PR. I wasn't sure if this would need extra investigation/verification that these styles are really unused. ------------- PR: https://git.openjdk.java.net/jdk/pull/4195 From jjg at openjdk.java.net Thu May 27 15:04:16 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 27 May 2021 15:04:16 GMT Subject: Integrated: JDK-8267709: Investigate differences between HtmlStyle and stylesheet.css In-Reply-To: <3gdBegL2aPbnsFFlhd1SjmLx_Y4XNXzN_Quzw3etZxM=.98b29ab9-eac0-4acd-80e1-d421c9e331d7@github.com> References: <3gdBegL2aPbnsFFlhd1SjmLx_Y4XNXzN_Quzw3etZxM=.98b29ab9-eac0-4acd-80e1-d421c9e331d7@github.com> Message-ID: On Tue, 25 May 2021 19:10:44 GMT, Jonathan Gibbons wrote: > Please review a new test to track the differences between `HtmlStyle.java` and `stylesheet.css`. > > The test passes, because all discrepancies are noted within the test. However, some of the discrepancies may indicate the need for follow-up work, such as adding new items to `HtmlStyle` for documentation purposes, or removing unused code in the main `stylesheet.css` file. > > There is also a minor/trivial change to fix a copy-paste error in a comment in `HtmlStyle`. This pull request has now been integrated. Changeset: 07542660 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/07542660446e47164e5a402380bdf7cbfd7b37ad Stats: 222 lines in 2 files changed: 221 ins; 0 del; 1 mod 8267709: Investigate differences between HtmlStyle and stylesheet.css Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/4195 From godin at openjdk.java.net Thu May 27 18:06:20 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Thu, 27 May 2021 18:06:20 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > 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: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > I've updated the code to produce better/more useful LineNumberTable for rule switches. @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries ?? ---- However I also noticed that for class Example { void example(String s) { switch (s) { case "a": System.out.println("a"); } } } there is difference in frames before and after this PR javap -v -p Example.class diff is line 3: 0 line 5: 60 line 7: 68 - StackMapTable: number_of_entries = 4 + StackMapTable: number_of_entries = 5 frame_type = 253 /* append */ - offset_delta = 28 + offset_delta = 4 locals = [ class java/lang/String, int ] + frame_type = 23 /* same */ frame_type = 10 /* same */ frame_type = 20 /* same */ frame_type = 249 /* chop */ and java -cp asm-util-9.1.jar:asm-9.1.jar org.objectweb.asm.util.Textifier Example.class diff is + L1 + FRAME APPEND [java/lang/String I] ALOAD 2 INVOKEVIRTUAL java/lang/String.hashCode ()I LOOKUPSWITCH - 97: L1 - default: L2 - L1 - FRAME APPEND [java/lang/String I] + 97: L2 + default: L3 + L2 + FRAME SAME Don't know about importance of this, and whether this was expected, but decided to mention. ------------- Marked as reviewed by godin (Author). PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at openjdk.java.net Thu May 27 18:22:13 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 27 May 2021 18:22:13 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > 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: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > > I've updated the code to produce better/more useful LineNumberTable for rule switches. > > @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries +1 > [...] > Don't know about importance of this, and whether this was expected, but decided to mention. Look likes a mistake for me, you only need a StackFrame in front of the call to invokedynamic if it's the target of a goto and in your example, there is no guard so no backward goto. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From godin at openjdk.java.net Thu May 27 18:31:09 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Thu, 27 May 2021 18:31:09 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 18:19:38 GMT, R?mi Forax wrote: > in your example, there is no guard so no backward goto @forax btw this example is not about switch pattern matching - it is about already existing string switch, where indy not involed ?? void example(java.lang.String); descriptor: (Ljava/lang/String;)V flags: (0x0000) Code: stack=2, locals=4, args_size=2 0: aload_1 1: astore_2 2: iconst_m1 3: istore_3 4: aload_2 5: invokevirtual #7 // Method java/lang/String.hashCode:()I 8: lookupswitch { // 1 97: 28 default: 39 } 28: aload_2 29: ldc #13 // String a 31: invokevirtual #15 // Method java/lang/String.equals:(Ljava/lang/Object;)Z 34: ifeq 39 37: iconst_0 38: istore_3 39: iload_3 40: lookupswitch { // 1 0: 60 default: 68 } 60: getstatic #19 // Field java/lang/System.out:Ljava/io/PrintStream; 63: ldc #13 // String a 65: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 68: return LineNumberTable: line 3: 0 line 5: 60 line 7: 68 StackMapTable: number_of_entries = 5 frame_type = 253 /* append */ offset_delta = 4 locals = [ class java/lang/String, int ] frame_type = 23 /* same */ frame_type = 10 /* same */ frame_type = 20 /* same */ frame_type = 249 /* chop */ offset_delta = 7 ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jjg at openjdk.java.net Thu May 27 21:11:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 27 May 2021 21:11:14 GMT Subject: RFR: JDK-8267176: StandardDoclet should provide access to Reporter and Locale Message-ID: Please review a simple change for StandardDoclet to expose the locale and reporter with which it was initialized. ------------- Commit messages: - fix whitespace - JDK-8267865: StandardDoclet should provide access to Reporter and Locale Changes: https://git.openjdk.java.net/jdk/pull/4233/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4233&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267176 Stats: 38 lines in 3 files changed: 22 ins; 14 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4233.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4233/head:pull/4233 PR: https://git.openjdk.java.net/jdk/pull/4233 From jonathan.gibbons at oracle.com Fri May 28 04:07:48 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 27 May 2021 21:07:48 -0700 Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: <5e0b8a23-0aa6-c875-8dd0-58f50e0039cd@oracle.com> On 5/27/21 6:31 AM, Erik Joelsson wrote: > On Thu, 27 May 2021 13:05:27 GMT, Hannes Walln?fer wrote: > >>> make/Docs.gmk line 336: >>> >>>> 334: >>>> 335: # Add summary pages for new/deprecated APIs in recent releases >>>> 336: $1_OPTIONS += --since 12,13,14,15,16,17 --since-label "New API since JDK 11" >>> How do you expect this to change as the JDK version is bumped? If there is an expected pattern, then maybe we should try to generate the list instead, so we don't need to manually update twice a year. >> I don't have a solution for this problem. AFAIK there are a few things that have to be "bumped" manually between releases, and this would be yet another. Obviously not a great solution. > Yes, there are a few things, but in the build itself, we are down to a single config file today, so I would really appreciate if this could be figured out. I can provide the implementation for generating this, but I need to understand what the expected pattern is. From what I can see, it looks like $(sequence N, M) where N is the last LTS+1 and M is current JDK version. Then the string has "JDK N" in it. M is already well defined, so the only new input here is N, which we could move to the version numbers config file (make/conf/version-numbers.conf). Something like DEFAULT_VERSION_DOCS_API_SINCE=11. There is some additional boilerplate needed, and the sequence macro of course, but does this sound reasonable to you? The ability to reduce the configuration down to a single number, like DEFAULT_VERSION_DOCS_API_SINCE=11, seems like a good solution until we think of anything better. The issue will be how long we stay with 11, and what do we move to after that, and when? -- Jon > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Fri May 28 08:19:33 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 28 May 2021 08:19:33 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: References: Message-ID: > This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. > > The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. > > One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. > > The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. I uploaded the generated documentation here: > > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8263468: automate build integration ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4209/files - new: https://git.openjdk.java.net/jdk/pull/4209/files/e81532b2..2a9dbbbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=00-01 Stats: 10 lines in 4 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4209/head:pull/4209 PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Fri May 28 08:23:12 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 28 May 2021 08:23:12 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: On Thu, 27 May 2021 13:32:36 GMT, Erik Joelsson wrote: >> Yes, there are a few things, but in the build itself, we are down to a single config file today, so I would really appreciate if this could be figured out. I can provide the implementation for generating this, but I need to understand what the expected pattern is. From what I can see, it looks like $(sequence N, M) where N is the last LTS+1 and M is current JDK version. Then the string has "JDK N" in it. M is already well defined, so the only new input here is N, which we could move to the version numbers config file (make/conf/version-numbers.conf). Something like DEFAULT_VERSION_DOCS_API_SINCE=11. There is some additional boilerplate needed, and the sequence macro of course, but does this sound reasonable to you? > > We actually have a sequence macro already, so generating the list can be done like this: > > $(call CommaList,$(call sequence 12, 17)) > > Or if what you have is 11 and 17: > > $(call CommaList, $(filter-out 11, $(call sequence 11, 17))) Thanks for the help and for providing all the pieces, Erik! I just added a new commit and I think I got everything working. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From jlahoda at openjdk.java.net Fri May 28 11:08:43 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:08:43 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 18:28:13 GMT, Evgeny Mandrikov wrote: >>> > I've updated the code to produce better/more useful LineNumberTable for rule switches. >>> >>> @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries +1 >>> >> [...] >>> Don't know about importance of this, and whether this was expected, but decided to mention. >> >> Look likes a mistake for me, you only need a StackFrame in front of the call to invokedynamic if it's the target of a goto and in your example, there is no guard so no backward goto. > >> in your example, there is no guard so no backward goto > > @forax btw this example is not about switch pattern matching - it is about already existing string switch, where indy not involed ?? > > > void example(java.lang.String); > descriptor: (Ljava/lang/String;)V > flags: (0x0000) > Code: > stack=2, locals=4, args_size=2 > 0: aload_1 > 1: astore_2 > 2: iconst_m1 > 3: istore_3 > 4: aload_2 > 5: invokevirtual #7 // Method java/lang/String.hashCode:()I > 8: lookupswitch { // 1 > 97: 28 > default: 39 > } > 28: aload_2 > 29: ldc #13 // String a > 31: invokevirtual #15 // Method java/lang/String.equals:(Ljava/lang/Object;)Z > 34: ifeq 39 > 37: iconst_0 > 38: istore_3 > 39: iload_3 > 40: lookupswitch { // 1 > 0: 60 > default: 68 > } > 60: getstatic #19 // Field java/lang/System.out:Ljava/io/PrintStream; > 63: ldc #13 // String a > 65: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V > 68: return > LineNumberTable: > line 3: 0 > line 5: 60 > line 7: 68 > StackMapTable: number_of_entries = 5 > frame_type = 253 /* append */ > offset_delta = 4 > locals = [ class java/lang/String, int ] > frame_type = 23 /* same */ > frame_type = 10 /* same */ > frame_type = 20 /* same */ > frame_type = 249 /* chop */ > offset_delta = 7 @Godin thanks for noticing the unnecessary point in the StackMap! I've limited the entry to only be present for pattern matching switches, so ordinary switches should now look as before. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri May 28 11:08:42 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:08:42 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v6] In-Reply-To: References: Message-ID: <9siiRgAecypi4U4cS7zXk2MwDk3EsPZwvUtEMaGTJz8=.ed45bb06-c5d8-4efd-a35a-7e8a566858dd@github.com> > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Avoiding unnecessary StackMap point. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/fd748501..a57d306b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=04-05 Stats: 76 lines in 2 files changed: 72 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri May 28 11:36:10 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:36:10 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 10:38:08 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 12 commits: >> >> - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. >> - Correcting LineNumberTable for rule switches. >> - Merging master into JDK-8262891 >> - Fixing various error-related bugs. >> - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. >> - Reflecting recent spec changes. >> - Reflecting review comments. >> - Reflecting review comments on SwitchBootstraps. >> - Trailing whitespaces. >> - Cleanup, reflecting review comments. >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1657: > >> 1655: >> 1656: try { >> 1657: boolean enumSwitch = (seltype.tsym.flags() & Flags.ENUM) != 0; > > This is getting convoluted enough that an enum on the AST (e.g. SwitchKind) might be helpful to save some of these classification properties - which I imagine we have to redo at some point later (e.g. in Lower/TransPattern). I'm ok with fixing in a followup issue. Thanks Maurizio. Yes, some of the logic is partly repeated elsewhere, but I need to investigate how to improve that. I've filled: https://bugs.openjdk.java.net/browse/JDK-8267929 ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From erikj at openjdk.java.net Fri May 28 12:44:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 28 May 2021 12:44:03 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 08:19:33 GMT, Hannes Walln?fer wrote: >> This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. >> >> The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. >> >> One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. >> >> The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. I uploaded the generated documentation here: >> >> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html >> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263468: automate build integration Build changes look great! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Fri May 28 14:30:13 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 28 May 2021 14:30:13 GMT Subject: RFR: JDK-8247608: Javadoc: CSS margin is not applied consistently Message-ID: This simple stylesheet change adds a 10px right side border to the `
              ` element containing the contents of block tags. I'm attaching a screenshot with the fixed spacing, see JBS attachments for reproducer source code and before-screenshots. border ------------- Commit messages: - JDK-8247608: Javadoc: CSS margin is not applied consistently Changes: https://git.openjdk.java.net/jdk/pull/4250/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4250&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247608 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4250/head:pull/4250 PR: https://git.openjdk.java.net/jdk/pull/4250 From jjg at openjdk.java.net Fri May 28 15:42:06 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 28 May 2021 15:42:06 GMT Subject: RFR: JDK-8247608: Javadoc: CSS margin is not applied consistently In-Reply-To: References: Message-ID: On Fri, 28 May 2021 14:23:43 GMT, Hannes Walln?fer wrote: > This simple stylesheet change adds a 10px right side border to the `
              ` element containing the contents of block tags. I'm attaching a screenshot with the fixed spacing, see JBS attachments for reproducer source code and before-screenshots. > > border As a separate issue, I suggest that it might be good increase the margins for
              so that it is slightly indented relative to the surrounding text. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4250 From jjg at openjdk.java.net Fri May 28 15:45:02 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 28 May 2021 15:45:02 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: On Thu, 20 May 2021 14:31:33 GMT, Hannes Walln?fer wrote: > This is a simple cleanup to replace the sentinel `HtmlTree.EMPTY` text constant with an instance that achieves the same by overriding `isValid()`. I think this is the nicer solution, and it allows us to remove the special case identity check in `HtmlTree.add(Content)`. This is questionable and probably wrong. The use of the identity check was specifically to differentiate between a sentinel value (EMPTY) and values which just happen to be empty. This will require detailed examination. ------------- Changes requested by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4130 From jjg at openjdk.java.net Fri May 28 15:54:02 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 28 May 2021 15:54:02 GMT Subject: RFR: JDK-8266748: Move modifiers code to Signatures.java In-Reply-To: References: Message-ID: On Fri, 21 May 2021 08:46:48 GMT, Hannes Walln?fer wrote: > This change consolidates the code to generate type signature modifiers into `Signatures.TypeSignature`. > > Although this mostly consists of moving the code from `ClassWriterImpl` and `Utils` to `Signatures`, I also avoided the need to split the modifiers string when processing preview modifiers by returning a `List` instead of a `String` in what used to be `Utils.modifiersToString` and is now `TypeSignature.getModifiers`. General comments; not a final review. * Moving code out of `Utils` is generally always good but it's a bit of a shame to move it down into `formats.html`. That being said, `Signatures` is a good abstraction to be building. * The medium amount of use of `HtmlDocletWriter` in `Signatures` is a code-smell, although arguably, we're just exposing an existing code-smell. We should (generally) continue our efforts to move code out of `HtmlDocletWriter` into other more-focussed abstractions. ------------- PR: https://git.openjdk.java.net/jdk/pull/4142 From jlahoda at openjdk.java.net Fri May 28 19:07:17 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 19:07:17 GMT Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec [v2] In-Reply-To: References: Message-ID: > As noted in: > https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316 > > Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far. > > The CSR is started for review here: > https://bugs.openjdk.java.net/browse/JDK-8267838 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reordering @implSpec and example as suggested. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4223/files - new: https://git.openjdk.java.net/jdk/pull/4223/files/d27a84a0..5c9f694f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4223&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4223&range=00-01 Stats: 57 lines in 2 files changed: 29 ins; 28 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4223.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4223/head:pull/4223 PR: https://git.openjdk.java.net/jdk/pull/4223 From jlahoda at openjdk.java.net Fri May 28 19:07:18 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 19:07:18 GMT Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 11:26:14 GMT, Pavel Rappo wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Reordering @implSpec and example as suggested. > > src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 38: > >> 36: * nodes. >> 37: * >> 38: * @implSpec > > 1. Should the error-counting example in the immediately following paragraph belong to this `@implSpec` section? > 2. Why is there no similar `@implSpec` section being added to the class-level doc comment of TreeScanner? If such a section is to be added, then should the identifier-counting example in the immediately following paragraph belong to that section? Thanks for the comment, Pavel. I've tried to do the changes in an update: https://github.com/openjdk/jdk/pull/4223/commits/5c9f694fade7380fa1a7ae667cf4acd5be60c244 ------------- PR: https://git.openjdk.java.net/jdk/pull/4223 From darcy at openjdk.java.net Fri May 28 21:17:18 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 28 May 2021 21:17:18 GMT Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 19:07:17 GMT, Jan Lahoda wrote: >> As noted in: >> https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316 >> >> Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far. >> >> The CSR is started for review here: >> https://bugs.openjdk.java.net/browse/JDK-8267838 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reordering @implSpec and example as suggested. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4223 From prappo at openjdk.java.net Fri May 28 21:37:17 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 28 May 2021 21:37:17 GMT Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 19:07:17 GMT, Jan Lahoda wrote: >> As noted in: >> https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316 >> >> Methods in various utility visitor classes in jdk.compiler should use @implSpec to specify the implementation behavior. This patch tries to add the @implSpec tag to methods which already contain a text specifying the implementation, and adds new javadoc to the handful of methods that are missing it so far. >> >> The CSR is started for review here: >> https://bugs.openjdk.java.net/browse/JDK-8267838 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reordering @implSpec and example as suggested. Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4223 From hannesw at openjdk.java.net Mon May 31 06:48:24 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 31 May 2021 06:48:24 GMT Subject: Integrated: JDK-8247608: Javadoc: CSS margin is not applied consistently In-Reply-To: References: Message-ID: On Fri, 28 May 2021 14:23:43 GMT, Hannes Walln?fer wrote: > This simple stylesheet change adds a 10px right side border to the `
              ` element containing the contents of block tags. I'm attaching a screenshot with the fixed spacing, see JBS attachments for reproducer source code and before-screenshots. > > border This pull request has now been integrated. Changeset: 1ab27769 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/1ab277694740ce77ad70d030c437f47359dbd64e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8247608: Javadoc: CSS margin is not applied consistently Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4250 From hannesw at openjdk.java.net Mon May 31 08:50:24 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 31 May 2021 08:50:24 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: On Thu, 20 May 2021 15:22:08 GMT, liach wrote: >> This is a simple cleanup to replace the sentinel `HtmlTree.EMPTY` text constant with an instance that achieves the same by overriding `isValid()`. I think this is the nicer solution, and it allows us to remove the special case identity check in `HtmlTree.add(Content)`. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 174: > >> 172: ((ContentBuilder) content).contents.forEach(this::add); >> 173: } >> 174: else if (content.isValid()) { > > Should the content builder have a similar validity check to ensure if it's not empty, its contents are always valid? otherwise it's quite hard to define if the content builder is valid or not as it can be considered either and always need special case in client code. In comparison, the html tree's contents are always valid no matter if the outer tags are valid or not. I think the current behaviour of `ContentBuilder` to accept all content and check validity on demand is the better solution. At least in theory it's possible that invalid content (e.g. an empty HtmlTree) is added to a ContentBuilder which later becomes valid by adding valid content to it. On the other hand, one could argue that `ContentBuilder` and `HtmlTree` should behave the same, which would speak for checking validity when adding to `ContentBuilder`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From hannesw at openjdk.java.net Mon May 31 08:55:20 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 31 May 2021 08:55:20 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: On Fri, 28 May 2021 15:42:06 GMT, Jonathan Gibbons wrote: > This is questionable and probably wrong. > > The use of the identity check was specifically to differentiate between a sentinel value (EMPTY) and values which just happen to be empty. The purpose of this change is to implement this same behavior with better naming and documentation, and without requiring the identity check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From hannesw at openjdk.java.net Mon May 31 10:14:34 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 31 May 2021 10:14:34 GMT Subject: RFR: JDK-8259806: Clean up terminology on the "All Classes" page Message-ID: This is a simple change to replace the "All Classes" with "All Classes and Interfaces" in the heading of and references to the page of the same name. ------------- Commit messages: - JDK-8259806: Clean up terminology on the "All Classes" page Changes: https://git.openjdk.java.net/jdk/pull/4270/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4270&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259806 Stats: 29 lines in 10 files changed: 5 ins; 3 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/4270.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4270/head:pull/4270 PR: https://git.openjdk.java.net/jdk/pull/4270 From prappo at openjdk.java.net Mon May 31 10:41:27 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 31 May 2021 10:41:27 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: <6ZCgwnFYN4NQjRhlfWika7o3NKOWxmPPIhfJrS6l9BA=.6c7ee19f-ac2b-4e45-b6a4-fd6ba6174f33@github.com> On Thu, 20 May 2021 14:31:33 GMT, Hannes Walln?fer wrote: > This is a simple cleanup to replace the sentinel `HtmlTree.EMPTY` text constant with an instance that achieves the same by overriding `isValid()`. I think this is the nicer solution, and it allows us to remove the special case identity check in `HtmlTree.add(Content)`. I agree with Jon on that this change should be tested thoroughly. I recommend that you compare outputs of JDK API documentation in addition to running usual tier1 tests. That said, I think I understand what you are trying to achieve with this change: it might be useful to have that "special empty" behavior implemented in a more versatile way which allows both structured and OOP treatment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From hannesw at openjdk.java.net Mon May 31 13:14:28 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 31 May 2021 13:14:28 GMT Subject: RFR: JDK-8246351: elements in headings are of incorrect size Message-ID: <0wxLR11QGxI8awCn9NJ_Ds1rs0cLlyPkJs_SD_5pRpI=.bc7ee73b-eaee-4955-b66c-92f7e9e1abdd@github.com> This is a simple fix to not set the font size and related spacings in `` and `` elements when they occur inside a heading. The screenshot below shows the new rendered text in Safari on Mac OS X (there is a `` in the heading and there are several in the flow text). fontsize ------------- Commit messages: - JDK-8246351: elements in headings are of incorrect size Changes: https://git.openjdk.java.net/jdk/pull/4273/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4273&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246351 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4273/head:pull/4273 PR: https://git.openjdk.java.net/jdk/pull/4273 From prappo at openjdk.java.net Mon May 31 13:39:18 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 31 May 2021 13:39:18 GMT Subject: RFR: JDK-8246351: elements in headings are of incorrect size In-Reply-To: <0wxLR11QGxI8awCn9NJ_Ds1rs0cLlyPkJs_SD_5pRpI=.bc7ee73b-eaee-4955-b66c-92f7e9e1abdd@github.com> References: <0wxLR11QGxI8awCn9NJ_Ds1rs0cLlyPkJs_SD_5pRpI=.bc7ee73b-eaee-4955-b66c-92f7e9e1abdd@github.com> Message-ID: On Mon, 31 May 2021 13:04:57 GMT, Hannes Walln?fer wrote: > This is a simple fix to not set the font size and related spacings in `` and `` elements when they occur inside a heading. The screenshot below shows the new rendered text in Safari on Mac OS X (there is a `` in the heading and there are several in the flow text). > > fontsize Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4273 From jlahoda at openjdk.java.net Mon May 31 13:49:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 31 May 2021 13:49:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v7] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: - Fixing tests. - Total pattern dominates the null pattern. - Properly report errors for pattern+default clash. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/a57d306b..a49b6109 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=05-06 Stats: 52 lines in 6 files changed: 45 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From hannesw at openjdk.java.net Mon May 31 14:31:26 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 31 May 2021 14:31:26 GMT Subject: Integrated: JDK-8246351: elements in headings are of incorrect size In-Reply-To: <0wxLR11QGxI8awCn9NJ_Ds1rs0cLlyPkJs_SD_5pRpI=.bc7ee73b-eaee-4955-b66c-92f7e9e1abdd@github.com> References: <0wxLR11QGxI8awCn9NJ_Ds1rs0cLlyPkJs_SD_5pRpI=.bc7ee73b-eaee-4955-b66c-92f7e9e1abdd@github.com> Message-ID: On Mon, 31 May 2021 13:04:57 GMT, Hannes Walln?fer wrote: > This is a simple fix to not set the font size and related spacings in `` and `` elements when they occur inside a heading. The screenshot below shows the new rendered text in Safari on Mac OS X (there is a `` in the heading and there are several in the flow text). > > fontsize This pull request has now been integrated. Changeset: 382e7eca Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/382e7eca48a3e7ec4901aa4c9b4a4ee19f4accc2 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8246351: elements in headings are of incorrect size Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4273