From jlahoda at openjdk.java.net Tue Jun 1 07:50:49 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 1 Jun 2021 07:50:49 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v8] 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 enum switch with patterns with guards. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/a49b6109..80b1392b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=06-07 Stats: 82 lines in 3 files changed: 80 ins; 0 del; 2 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 Tue Jun 1 10:04:18 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 1 Jun 2021 10:04:18 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: <1Q5IufMVbIbySuJCsNGTPDVJDCfcMdvuLqfsqYsugPM=.b79df9f2-8618-425f-b4bc-c9f7a7a310aa@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 compared output for JDK API docs before and after this patch, they are bit-for-bit identical. This is what I would have expected, since `HtmlTree.add(Content)` is pretty much the only relevant place where `Content.isValid()` is invoked (apart from some peripheral writers, and as of JDK-8267219, `ContentBuilder.isValid()`). > 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 jjg at openjdk.java.net Tue Jun 1 15:52:18 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 1 Jun 2021 15:52:18 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: <08U2dcSEQsBkB5y3gDnRFhxsLXK537lXjYuj6x4VRNk=.352823cb-0f2f-4684-b103-0b9fdc5cc3d1@github.com> On Mon, 31 May 2021 08:47:45 GMT, Hannes Walln?fer wrote: >> 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`. Can we take the bigger step and make it unnecessary to have/use `isValid`? We should never knowingly create nodes that will be invalid by whatever metric we choose to define validity. If there's a risk of creating nodes that will end up being invalid, we should do the work ahead of time to not create the nodes in the first place. Bottom line, the original reasons for `isValid` were, at best, flawed. Is this the time to fix that? ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From prappo at openjdk.java.net Tue Jun 1 16:06:19 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 1 Jun 2021 16:06:19 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: <08U2dcSEQsBkB5y3gDnRFhxsLXK537lXjYuj6x4VRNk=.352823cb-0f2f-4684-b103-0b9fdc5cc3d1@github.com> References: <08U2dcSEQsBkB5y3gDnRFhxsLXK537lXjYuj6x4VRNk=.352823cb-0f2f-4684-b103-0b9fdc5cc3d1@github.com> Message-ID: <5bu7ikPMyUPauLO4umr8DxNttAVtn5dJV2bKmUhD2T4=.7e5edbd2-0928-4b06-ae1d-e19a80a05475@github.com> On Tue, 1 Jun 2021 15:49:22 GMT, Jonathan Gibbons wrote: > Can we take the bigger step and make it unnecessary to have/use `isValid`? Yes. > the original reasons for `isValid` were, at best, flawed. Is this the time to fix that? When you say "time", do you mean "this PR" or "physical time"? If you meant the latter, then I find it hard to imagine a simple and correct fix that would also fit in the JDK 17 timeframe. ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From hannesw at openjdk.java.net Tue Jun 1 16:30:34 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 1 Jun 2021 16:30:34 GMT Subject: RFR: JDK-8149138: [javadoc] Fix SerialFormBuilder eliminate String bashing Message-ID: Removal of ugly old code in `SerializedFormBuilder.java`. Luckily there already is a clean overloaded method in the associated writer that we can use, so this is mostly a removal of code that is no longer used. I also enhanced the test to cover more cases such as primitive arrays and linked references. ------------- Commit messages: - JDK-8149138: [javadoc] Fix SerialFormBuilder eliminate String bashing Changes: https://git.openjdk.java.net/jdk/pull/4284/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4284&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8149138 Stats: 95 lines in 5 files changed: 38 ins; 46 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4284/head:pull/4284 PR: https://git.openjdk.java.net/jdk/pull/4284 From hannesw at openjdk.java.net Tue Jun 1 16:41:26 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 1 Jun 2021 16:41:26 GMT Subject: RFR: JDK-8267176: StandardDoclet should provide access to Reporter and Locale In-Reply-To: References: Message-ID: On Thu, 27 May 2021 20:57:04 GMT, Jonathan Gibbons wrote: > Please review a simple change for StandardDoclet to expose the locale and reporter with which it was initialized. Looks good. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4233 From mcimadamore at openjdk.java.net Tue Jun 1 20:19:19 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 1 Jun 2021 20:19:19 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v8] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 07:50:49 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 enum switch with patterns with guards. New changes looks good. I suggest to also add tests for strings in switch with guards and numeric with guards, to make sure every kind of switch works well. As discussed offline, we can probably simplify code generation logic for enum switches by leaning on the ConstantBootstraps BSM which allows to create enum constants given a class name and a constant name. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From vromero at openjdk.java.net Wed Jun 2 04:33:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 2 Jun 2021 04:33:33 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. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4037 From hannesw at openjdk.java.net Wed Jun 2 14:13:30 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 2 Jun 2021 14:13:30 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: <5bu7ikPMyUPauLO4umr8DxNttAVtn5dJV2bKmUhD2T4=.7e5edbd2-0928-4b06-ae1d-e19a80a05475@github.com> References: <08U2dcSEQsBkB5y3gDnRFhxsLXK537lXjYuj6x4VRNk=.352823cb-0f2f-4684-b103-0b9fdc5cc3d1@github.com> <5bu7ikPMyUPauLO4umr8DxNttAVtn5dJV2bKmUhD2T4=.7e5edbd2-0928-4b06-ae1d-e19a80a05475@github.com> Message-ID: On Tue, 1 Jun 2021 16:03:49 GMT, Pavel Rappo wrote: >> Can we take the bigger step and make it unnecessary to have/use `isValid`? We should never knowingly create nodes that will be invalid by whatever metric we choose to define validity. If there's a risk of creating nodes that will end up being invalid, we should do the work ahead of time to not create the nodes in the first place. >> >> Bottom line, the original reasons for `isValid` were, at best, flawed. Is this the time to fix that? > >> Can we take the bigger step and make it unnecessary to have/use `isValid`? > > Yes. > >> the original reasons for `isValid` were, at best, flawed. Is this the time to fix that? > > When you say "time", do you mean "this PR" or "physical time"? If you meant the latter, then I find it hard to imagine a simple and correct fix that would also fit in the JDK 17 timeframe. I agree that our current `isValid` implementation does not feel right. But there are many (dozens?) of places in the code that potentially generate empty elements. If we want to avoid these, shifting the responsability to the content producer will blow up the code a lot. I'm trying out different things to see if I can come up with a better solution. ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From jonathan.gibbons at oracle.com Wed Jun 2 14:32:31 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 2 Jun 2021 07:32:31 -0700 Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: <08U2dcSEQsBkB5y3gDnRFhxsLXK537lXjYuj6x4VRNk=.352823cb-0f2f-4684-b103-0b9fdc5cc3d1@github.com> <5bu7ikPMyUPauLO4umr8DxNttAVtn5dJV2bKmUhD2T4=.7e5edbd2-0928-4b06-ae1d-e19a80a05475@github.com> Message-ID: <954a9862-d315-6bea-045f-7d300ab732d1@oracle.com> On 6/2/21 7:13 AM, Hannes Walln?fer wrote: > On Tue, 1 Jun 2021 16:03:49 GMT, Pavel Rappo wrote: > >>> Can we take the bigger step and make it unnecessary to have/use `isValid`? We should never knowingly create nodes that will be invalid by whatever metric we choose to define validity. If there's a risk of creating nodes that will end up being invalid, we should do the work ahead of time to not create the nodes in the first place. >>> >>> Bottom line, the original reasons for `isValid` were, at best, flawed. Is this the time to fix that? >>> Can we take the bigger step and make it unnecessary to have/use `isValid`? >> Yes. >> >>> the original reasons for `isValid` were, at best, flawed. Is this the time to fix that? >> When you say "time", do you mean "this PR" or "physical time"? If you meant the latter, then I find it hard to imagine a simple and correct fix that would also fit in the JDK 17 timeframe. > I agree that our current `isValid` implementation does not feel right. > > But there are many (dozens?) of places in the code that potentially generate empty elements. If we want to avoid these, shifting the responsability to the content producer will blow up the code a lot. I'm trying out different things to see if I can come up with a better solution. Do we have any sense of how often the "isValid" check prevents an empty node to be added to the tree? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4130 From jjg at openjdk.java.net Wed Jun 2 16:59:31 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 16:59:31 GMT Subject: Integrated: JDK-8267176: StandardDoclet should provide access to Reporter and Locale In-Reply-To: References: Message-ID: On Thu, 27 May 2021 20:57:04 GMT, Jonathan Gibbons wrote: > Please review a simple change for StandardDoclet to expose the locale and reporter with which it was initialized. This pull request has now been integrated. Changeset: e1462e79 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/e1462e79df7c22f3e09fa453c7887b6f51ef3dbb Stats: 38 lines in 3 files changed: 22 ins; 14 del; 2 mod 8267176: StandardDoclet should provide access to Reporter and Locale Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/4233 From prappo at openjdk.java.net Wed Jun 2 17:09:43 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 2 Jun 2021 17:09:43 GMT Subject: RFR: JDK-8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 18:01:19 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. > > 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 Update the copyright years and you're good to go. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java line 153: > 151: > 152: /** Create a StandardDocFile for a given location and relative path. */ > 153: StandardDocFile(Location location, DocPath path) { Why did you remove these two `private` modifiers? ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3954 From jjg at openjdk.java.net Wed Jun 2 21:23:01 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 21:23:01 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter Message-ID: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. ------------- Commit messages: - Fix typos - Fix typos - Fix typos - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter - Address review feedback - Address review feedback - extend Messages to provide convenient access to the new Reporter.report method - add new test; update stream handling - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter - ... and 4 more: https://git.openjdk.java.net/jdk/compare/1ae934e0...521ffe99 Changes: https://git.openjdk.java.net/jdk/pull/4216/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4216&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267204 Stats: 541 lines in 10 files changed: 427 ins; 35 del; 79 mod Patch: https://git.openjdk.java.net/jdk/pull/4216.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4216/head:pull/4216 PR: https://git.openjdk.java.net/jdk/pull/4216 From prappo at openjdk.java.net Wed Jun 2 21:23:03 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 2 Jun 2021 21:23:03 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter In-Reply-To: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: On Thu, 27 May 2021 03:20:34 GMT, Jonathan Gibbons wrote: > Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. > > The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. Thank you so much for doing this, Jon. Although this PR is good by itself, it will be particularly useful for snippets (JEP 413). While I'm still reviewing this PR, you could have a look at the comments I have made so far. As far as I understand https://github.com/openjdk/jdk/pull/4077 will be closed as superseded by this PR? src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 39: > 37: * Interface for reporting diagnostics and other messages. > 38: * > 39: *

Diagnostics consist of a diagnostic {@link Diagnostic.Kind kind} and a message, Consider moving "diagnostic" into the `@link` label: `{@link Diagnostic.Kind diagnostic kind}`. src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 69: > 67: * > 68: * @param kind the kind of diagnostic > 69: * @param message message to print Prepend "message to print" with "the". Alternatively, consider using "the message to be printed", which seems typical in this file. src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 98: > 96: * @param file the file > 97: * @param start the beginning of the enclosing range > 98: * @param pos the position Unless there's a reason not to, I would prefer to have an inequality clearly showing how these 3 indexes relate to each other. For example, is it the case that `{@code start <= pos <= end}`? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java line 104: > 102: * @param start the start of a range of characters to be associated with the end > 103: * @param pos the position to be associated with the end > 104: * @param end the end of a range of characters to be associated with the end "Associated with end"? I believe it should either be "error" or "message", not "end". src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java line 106: > 104: * @param end the end of a range of characters to be associated with the end > 105: * @param key the name of a resource containing the message to be printed > 106: * @param args optional arguments to be replaced in the message. Remove the trailing period. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java line 157: > 155: * @param start the start of a range of characters to be associated with the end > 156: * @param pos the position to be associated with the end > 157: * @param end the end of a range of characters to be associated with the end Same here: "associated with the end"? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java line 159: > 157: * @param end the end of a range of characters to be associated with the end > 158: * @param key the name of a resource containing the message to be printed > 159: * @param args optional arguments to be replaced in the message. Same here: remove the trailing period. src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 180: > 178: */ > 179: public Messager(Context context, String programName) { > 180: // use the current values of System.out, System,err, in case they have been redirected Replace "," with ".": System.err src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 435: > 433: > 434: /** > 435: * Prints the error and warning counts, if any, to. the diagnostic writer Move period from after "to" to the end of the sentence. test/langtools/jdk/javadoc/doclet/testReporterStreams/TestReporterStreams.java line 1: > 1: /* Indent. ------------- PR: https://git.openjdk.java.net/jdk/pull/4216 From jjg at openjdk.java.net Wed Jun 2 21:23:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 21:23:04 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter In-Reply-To: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: On Thu, 27 May 2021 03:20:34 GMT, Jonathan Gibbons wrote: > Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. > > The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. > As far as I understand #4077 will be closed as superseded by this PR? Yes, I've closed the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4216 From jjg at openjdk.java.net Wed Jun 2 21:23:05 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 21:23:05 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter In-Reply-To: References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: On Thu, 27 May 2021 10:15:43 GMT, Pavel Rappo wrote: >> Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. >> >> The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. > > src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 98: > >> 96: * @param file the file >> 97: * @param start the beginning of the enclosing range >> 98: * @param pos the position > > Unless there's a reason not to, I would prefer to have an inequality clearly showing how these 3 indexes relate to each other. For example, is it the case that `{@code start <= pos <= end}`? Will do. I had this in an earlier draft. I backed out because I also wanted to bound `start` and `end` but it is not common in API to indicate indices must be non-negative, and it is an IO operation (and potential exception) to verify the upper bound is valid. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java line 435: > >> 433: >> 434: /** >> 435: * Prints the error and warning counts, if any, to. the diagnostic writer > > Move period from after "to" to the end of the sentence. Wow, how did that typo come about? :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4216 From github.com+7806504+liach at openjdk.java.net Wed Jun 2 21:23:05 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 2 Jun 2021 21:23:05 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter In-Reply-To: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: On Thu, 27 May 2021 03:20:34 GMT, Jonathan Gibbons wrote: > Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. > > The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 100: > 98: * @param pos the position > 99: * @param end the end of the enclosing range > 100: * @param message the message to be printed Needs a `@since 17` as this is an addition ------------- PR: https://git.openjdk.java.net/jdk/pull/4216 From prappo at openjdk.java.net Wed Jun 2 21:23:06 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 2 Jun 2021 21:23:06 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter In-Reply-To: References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: On Thu, 27 May 2021 04:44:14 GMT, liach wrote: >> Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. >> >> The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. > > src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 100: > >> 98: * @param pos the position >> 99: * @param end the end of the enclosing range >> 100: * @param message the message to be printed > > Needs a `@since 17` as this is an addition I agree: there needs to be `@since 17`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4216 From jjg at openjdk.java.net Wed Jun 2 22:49:43 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 22:49:43 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: e9f3e325 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/e9f3e325c274f19b0f6eceea2367708e3be689e9 Stats: 267 lines in 10 files changed: 261 ins; 0 del; 6 mod 8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/3954 From hannes.wallnoefer at oracle.com Thu Jun 3 05:37:42 2021 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 3 Jun 2021 05:37:42 +0000 Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: <954a9862-d315-6bea-045f-7d300ab732d1@oracle.com> References: <08U2dcSEQsBkB5y3gDnRFhxsLXK537lXjYuj6x4VRNk=.352823cb-0f2f-4684-b103-0b9fdc5cc3d1@github.com> <5bu7ikPMyUPauLO4umr8DxNttAVtn5dJV2bKmUhD2T4=.7e5edbd2-0928-4b06-ae1d-e19a80a05475@github.com> <954a9862-d315-6bea-045f-7d300ab732d1@oracle.com> Message-ID: There are 24 failing tests if the `isValid()` check is omitted in HtmlTree.add(Content). I started going after ?invalid? HtmlTree instances using stack traces to locate their origin, but gave up after 3 or 4 due to the reasons given earlier: there?s quite a few of them, and even if we find them all there?s no way to prevent them from popping up in the future. My conclusion would be to close this PR/issue as ?won?t fix? and start working on finding a better solution. IMO that solution would still be implemented in Content/HtmlTree, but should have a name that better reflects its purpose, and would possibly be implemented using different means at a different level. Hannes > Am 02.06.2021 um 16:32 schrieb Jonathan Gibbons : > > > On 6/2/21 7:13 AM, Hannes Walln?fer wrote: >> >> I agree that our current `isValid` implementation does not feel right. >> >> But there are many (dozens?) of places in the code that potentially generate empty elements. If we want to avoid these, shifting the responsability to the content producer will blow up the code a lot. I'm trying out different things to see if I can come up with a better solution. > > Do we have any sense of how often the "isValid" check prevents an empty node to be added to the tree? > > > >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/4130 From jlahoda at openjdk.java.net Thu Jun 3 07:39:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Jun 2021 07:39:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v9] 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: Enhancing tests as suggested. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/80b1392b..79e3621b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=07-08 Stats: 44 lines in 1 file changed: 44 ins; 0 del; 0 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 Thu Jun 3 09:05:08 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Jun 2021 09:05:08 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v10] 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 19 commits: - Merging master into JDK-8262891 - Enhancing tests as suggested. - Fixing enum switch with patterns with guards. - Fixing tests. - Total pattern dominates the null pattern. - Properly report errors for pattern+default clash. - Avoiding unnecessary StackMap point. - 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 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/bdeaeb47...fa50b5fb ------------- Changes: https://git.openjdk.java.net/jdk/pull/3863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=09 Stats: 4828 lines in 79 files changed: 4509 ins; 118 del; 201 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 jjg at openjdk.java.net Thu Jun 3 14:31:40 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 3 Jun 2021 14:31:40 GMT Subject: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: <4U9mE0FMweMkjIwL4DGjbfMpgai6ZK9skPwcCCSMJdA=.99c7990b-fde5-49e5-96d4-483d8fde711f@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)`. Agreed to leave this for now. I think we can incrementally go after sites that are creating invalid nodes. I don't see why it is so bad to use a sentinel value to mark "temporarily empty" nodes, but I do think it's an error than the name of the sentinel suggests it can be used for other purposes -- i.e. as a general purpose "empty" node. ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From jjg at openjdk.java.net Thu Jun 3 17:02:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 3 Jun 2021 17:02:38 GMT Subject: RFR: JDK-8149138: [javadoc] Fix SerialFormBuilder eliminate String bashing In-Reply-To: References: Message-ID: <8Li1Xo0ONTeNn2F08-6RssxHAb5sp_7nk6cYmfI17w0=.feb0d23a-0aee-40c1-927b-2fc76c089a81@github.com> On Tue, 1 Jun 2021 16:21:56 GMT, Hannes Walln?fer wrote: > Removal of ugly old code in `SerializedFormBuilder.java`. Luckily there already is a clean overloaded method in the associated writer that we can use, so this is mostly a removal of code that is no longer used. > > I also enhanced the test to cover more cases such as primitive arrays and linked references. Marked as reviewed by jjg (Reviewer). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java line 123: > 121: } else { > 122: Content fieldContent = writer.getLink(new HtmlLinkInfo( > 123: configuration, HtmlLinkInfo.Kind.SERIAL_MEMBER, fieldType)); Just curious, is SERIAL_MEMBER still required? ------------- PR: https://git.openjdk.java.net/jdk/pull/4284 From jjg at openjdk.java.net Thu Jun 3 17:12:37 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 3 Jun 2021 17:12:37 GMT Subject: RFR: JDK-8259806: Clean up terminology on the "All Classes" page In-Reply-To: References: Message-ID: On Mon, 31 May 2021 10:06:14 GMT, Hannes Walln?fer wrote: > 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. Maybe I'm fighting a losing battle on this one, but the current policy is to generate the correct new terminology for recent releases and the older terminology for older releases, to try and stay consist within the release. The mapping is handled semi-automatically in `HtmlDoclet.getResourceKeyMapper`, line 130. As a general rule, if you're changing terminology, you should at least be updating the mapping as well. ------------- Changes requested by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4270 From jjg at openjdk.java.net Thu Jun 3 17:25:44 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 3 Jun 2021 17:25:44 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`. Minor changes suggestion, to access items from the configuration where possible. As a followup, it would be good to look at the remaining uses of `HtmlDocletWriter` in `Signatures`. There is at least a theme of "methods to create links", and if those methods are just used in the `Signatures` class, they would be candidates to move into that class as well. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 134: > 132: HtmlTree nameSpan = new HtmlTree(TagName.SPAN).setStyle(HtmlStyle.elementName); > 133: Content className = Text.of(utils.getSimpleName(typeElement)); > 134: if (writer.options.linkSource()) { better to use configuration.getOptions() src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 210: > 208: } > 209: if (linkablePermits.size() < permits.size()) { > 210: Content c = Text.of(writer.resources.getText("doclet.not.exhaustive")); Better to use `configuration.getDocResources()` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 249: > 247: content.add(HtmlTree.SUP(writer.links.createLink( > 248: writer.htmlIds.forPreviewSection(typeElement), > 249: writer.contents.previewMark))); use the configuration for these two values ------------- Changes requested by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4142 From jlahoda at openjdk.java.net Fri Jun 4 09:01:27 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 09:01:27 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v11] 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 two additional commits since the last revision: - Tweaking SwitchBootstraps javadoc, as suggested. - Improving javadoc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/fa50b5fb..216b87c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=09-10 Stats: 66 lines in 2 files changed: 40 ins; 9 del; 17 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 Fri Jun 4 09:38:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 09:38:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v11] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:01:27 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 two additional commits since the last revision: > > - Tweaking SwitchBootstraps javadoc, as suggested. > - Improving javadoc. Re-approving to keep the bots happy ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 09:46:31 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 09:46:31 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] 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 typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/216b87c2..8d4c02b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=10-11 Stats: 1 line in 1 file changed: 0 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 psandoz at openjdk.java.net Fri Jun 4 15:54:00 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 4 Jun 2021 15:54:00 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:46:31 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 typo. A really nice feature, and a significant amount of work in javac. I mostly focused on the bootstrap and API aspects, and left some minor comments (most of which you can choose to apply or not as you see fit). I suspect the bootstrap might evolve as we get feedback and switch is enhanced with further forms of matching. But, at the moment it looks good. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 87: > 85: * returns {@literal -1}. > 86: *

> 87: * the {@code target} is not {@code null}, then the method of the call site Suggestion: * If the {@code target} is not {@code null}, then the method of the call site src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 92: > 90: *

    > 91: *
  • the element is of type {@code Class} and the target value > 92: * is a subtype of this {@code Class}; or
  • Suggestion: *
  • the element is of type {@code Class} that is assignable * from the target's class; or
  • src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 162: > 160: return i; > 161: } else { > 162: if (label instanceof Integer constant) { Minor suggestion: use `else if` rather than nest src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 166: > 164: return i; > 165: } > 166: if (target instanceof Character input && constant.intValue() == input.charValue()) { Use `else if` src/jdk.compiler/share/classes/com/sun/source/tree/CaseLabelTree.java line 31: > 29: > 30: /**A marker interface for {@code Tree}s that may be used as {@link CaseTree} labels. > 31: * Suggestion: /** * A marker interface for {@code Tree}s that may be used as {@link CaseTree} labels. * src/jdk.compiler/share/classes/com/sun/source/tree/DefaultCaseLabelTree.java line 30: > 28: > 29: /** A case label that marks {@code default} in {@code case null, default}. > 30: * @since 17 Suggestion: /** * A case label that marks {@code default} in {@code case null, default}. * * @since 17 test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 55: > 53: catch (NoSuchMethodException | IllegalAccessException e) { > 54: throw new RuntimeException(e); > 55: } Suggestion: catch (ReflectiveOperationException e) { throw new AssertionError(e, "Should not happen"); } test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 73: > 71: } > 72: > 73: public void testTypes() throws Throwable { As a follow up issue consider adding tests for `null` values test/langtools/tools/javac/patterns/DisambiguateParenthesizedPattern.java line 72: > 70: SwitchTree st = (SwitchTree) method.getBody().getStatements().get(0); > 71: CaseLabelTree label = st.getCases().get(0).getLabels().get(0); > 72: ExpressionType actualType = switch (label) { Should the test be careful of using a pattern match switch? ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From mchung at openjdk.java.net Fri Jun 4 16:53:03 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Jun 2021 16:53:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:46:31 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 typo. I reviewed the `java.base` change namely, SwitchBootstraps.java. Looks good. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 47: > 45: * of the {@code switch}, implicitly numbered sequentially from {@code [0..N)}. > 46: * > 47: *

    The bootstrap call site accepts a single parameter of the type of the It takes 2 parameters (not single parameter). Perhaps you can take out this paragraph since it's specified in the `typeSwitch` method. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 110: > 108: * @return a {@code CallSite} returning the first matching element as described above > 109: * > 110: * @throws NullPointerException if any argument is null Suggestion: * @throws NullPointerException if any argument is {@code null} same formatting nit for other occurrenace of "null" ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From vromero at openjdk.java.net Fri Jun 4 18:27:01 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 4 Jun 2021 18:27:01 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:46:31 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 typo. test/langtools/tools/javac/patterns/SealedTypeChanges.java line 58: > 56: void statement(SealedTypeChangesIntf obj) { > 57: switch (obj) { > 58: case A a -> System.err.println(1); what about having tests with a case that matches the sealed class? test/langtools/tools/javac/patterns/SealedTypeChanges.java line 71: > 69: } > 70: > 71: sealed interface SealedTypeChangesIntf permits SealedTypeChanges.A {} just for completeness shouldn't we have a test with sealed, non-abstract classes? ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 20:20:27 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 20:20:27 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: <3V_zMXiJp7WrQ3RTA9T5XdwDYsHCPluTNVva7q5BLWA=.69ff5e7e-b2b8-4588-aa09-eedf19b1ba9b@github.com> On Fri, 4 Jun 2021 09:46:31 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 typo. Thanks a lot for all the feedback. I've tried to do the requested changes in the recent commits. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 20:20:26 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 20:20:26 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v13] 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 two additional commits since the last revision: - Applying review feedback. - Tweaking javadoc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/8d4c02b4..e3c29759 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=11-12 Stats: 125 lines in 8 files changed: 91 ins; 10 del; 24 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 Jun 4 20:20:29 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 20:20:29 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 18:23:28 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing typo. > > test/langtools/tools/javac/patterns/SealedTypeChanges.java line 71: > >> 69: } >> 70: >> 71: sealed interface SealedTypeChangesIntf permits SealedTypeChanges.A {} > > just for completeness shouldn't we have a test with sealed, non-abstract classes? Note that for sealed non-abstract classes, the permits is not checked (as an instance of the non-abstract class may be created and passed to the switch, the switch needs to contain a case that will cover the class anyway). I've added tests that check the behavior for abstract class, and non-abstract classes (error is produced in the latter case). ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 20:20:28 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 20:20:28 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 15:46:32 GMT, Paul Sandoz wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing typo. > > test/langtools/tools/javac/patterns/DisambiguateParenthesizedPattern.java line 72: > >> 70: SwitchTree st = (SwitchTree) method.getBody().getStatements().get(0); >> 71: CaseLabelTree label = st.getCases().get(0).getLabels().get(0); >> 72: ExpressionType actualType = switch (label) { > > Should the test be careful of using a pattern match switch? I don't think using the new feature in the tests is problematic (esp. javac tests related to the feature). It helps to ensure the feature really works on real code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From prappo at openjdk.java.net Fri Jun 4 20:38:00 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 4 Jun 2021 20:38:00 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter In-Reply-To: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: On Thu, 27 May 2021 03:20:34 GMT, Jonathan Gibbons wrote: > Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. > > The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. Update the copyright years and you're good to go. src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 42: > 40: * and may additionally be associated with an {@link Element element}, > 41: * a {@link DocTreePath tree node} in a documentation comment, > 42: * or at an arbitrary position in a given {@link FileObject file}. "at" looks misplaced here. src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 108: > 106: void print(Diagnostic.Kind kind, FileObject file, int start, int pos, int end, String message); > 107: > 108: Delete one line. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java line 141: > 139: * > 140: * @param e an element identifying the declaration whose position should > 141: * be included with the message I see what you've changed: one of these words needed to go. Either "should" or "to". You chose "to". Unless you did it for semantical reasons, I note that this file uses "to be" in the vast majority of similar cases. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4216 From jjg at openjdk.java.net Fri Jun 4 20:47:17 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 4 Jun 2021 20:47:17 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter [v2] In-Reply-To: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: > Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. > > The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Update copyright years - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter - Fix typos - Fix typos - Fix typos - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter - Address review feedback - Address review feedback - extend Messages to provide convenient access to the new Reporter.report method - ... and 7 more: https://git.openjdk.java.net/jdk/compare/20b63127...78e811b1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4216/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4216&range=01 Stats: 545 lines in 10 files changed: 427 ins; 35 del; 83 mod Patch: https://git.openjdk.java.net/jdk/pull/4216.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4216/head:pull/4216 PR: https://git.openjdk.java.net/jdk/pull/4216 From jjg at openjdk.java.net Fri Jun 4 22:26:08 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 4 Jun 2021 22:26:08 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter [v2] In-Reply-To: References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: <8XjkvUyuI9GWXL1RCY25sOz86y9sg3zWnMJdJRYZFbs=.c8bc4166-3b9e-4e3f-a196-e8c0bec444b9@github.com> On Fri, 4 Jun 2021 20:12:59 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Update copyright years >> - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter >> - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter >> - Fix typos >> - Fix typos >> - Fix typos >> - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter >> - Address review feedback >> - Address review feedback >> - extend Messages to provide convenient access to the new Reporter.report method >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/20b63127...78e811b1 > > src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 42: > >> 40: * and may additionally be associated with an {@link Element element}, >> 41: * a {@link DocTreePath tree node} in a documentation comment, >> 42: * or at an arbitrary position in a given {@link FileObject file}. > > "at" looks misplaced here. When I wrote it, it looked right; now, I agree with you. ------------- PR: https://git.openjdk.java.net/jdk/pull/4216 From jjg at openjdk.java.net Fri Jun 4 22:41:59 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 4 Jun 2021 22:41:59 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter [v2] In-Reply-To: References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: On Fri, 4 Jun 2021 20:30:30 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Update copyright years >> - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter >> - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter >> - Fix typos >> - Fix typos >> - Fix typos >> - Merge remote-tracking branch 'upstream/master' into jdk-8267204-reporter >> - Address review feedback >> - Address review feedback >> - extend Messages to provide convenient access to the new Reporter.report method >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/20b63127...78e811b1 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java line 141: > >> 139: * >> 140: * @param e an element identifying the declaration whose position should >> 141: * be included with the message > > I see what you've changed: one of these words needed to go. Either "should" or "to". You chose "to". Unless you did it for semantical reasons, I note that this file uses "to be" in the vast majority of similar cases. The wording is correct, but I agree it the overall phrasing is inconsistent in form with similar phrases elsewhere, because in this context it uses "the declaration whose position ..." It's an internal API, so I don't want to get too hung up on it. I'll change the form to be more like the others. ------------- PR: https://git.openjdk.java.net/jdk/pull/4216 From jjg at openjdk.java.net Fri Jun 4 22:47:28 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 4 Jun 2021 22:47:28 GMT Subject: RFR: JDK-8267204: Expose access to underlying streams in Reporter [v3] In-Reply-To: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: <3ITlVdhW6t4rYc78SoxLhP_pEaCi7f9pXIWjTe-AHQQ=.236778bf-7f82-427b-a8c7-c8b6f34d4d6b@github.com> > Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. > > The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: use printRawLines instead of println for correct newline handline on Windows address review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4216/files - new: https://git.openjdk.java.net/jdk/pull/4216/files/78e811b1..1b70b66d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4216&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4216&range=01-02 Stats: 7 lines in 3 files changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4216.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4216/head:pull/4216 PR: https://git.openjdk.java.net/jdk/pull/4216 From jjg at openjdk.java.net Sat Jun 5 00:09:08 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 5 Jun 2021 00:09:08 GMT Subject: Integrated: JDK-8267204: Expose access to underlying streams in Reporter In-Reply-To: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> References: <_vZPAVJLRFvbbNmu38xhX6dNOTZrhg5133Hhb_lU0zA=.cbee05a1-58dd-44aa-8e97-1e87b7551512@github.com> Message-ID: On Thu, 27 May 2021 03:20:34 GMT, Jonathan Gibbons wrote: > Please review an update to `jdk.javadoc/jdk.javadoc.doclets.Reporter` to add 3 new methods and to improve the descriptions of other parts of the interface. > > The new methods provide access to the underlying streams (informally, for standard output and diagnostic output), and a new `report` method to report diagnostics at an arbitrary position in a file being read by a doclet, or a taglet within a doclet. This pull request has now been integrated. Changeset: 6ff978ac Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/6ff978ac16e631ebded7964d89ac42fd0452b1d3 Stats: 544 lines in 10 files changed: 426 ins; 36 del; 82 mod 8267204: Expose access to underlying streams in Reporter Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4216 From hannesw at openjdk.java.net Sat Jun 5 06:57:55 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Sat, 5 Jun 2021 06:57:55 GMT Subject: RFR: JDK-8259806: Clean up terminology on the "All Classes" page In-Reply-To: References: Message-ID: <2m1kxNdowQ3fMBpDh9tXlHdMzr4eIpk3Vzsxn-BxcJk=.8284b7d1-d8fa-4a96-b91b-fe0a6945575b@github.com> On Thu, 3 Jun 2021 17:09:21 GMT, Jonathan Gibbons wrote: > Maybe I'm fighting a losing battle on this one, but the current policy is to generate the correct new terminology for recent releases and the older terminology for older releases, to try and stay consist within the release. > > The mapping is handled semi-automatically in `HtmlDoclet.getResourceKeyMapper`, line 130. As a general rule, if you're changing terminology, you should at least be updating the mapping as well. Is "Classes and Interfaces" part of the "new terminology"? I thought "classes and interfaces" would be the correct term for anything living in a .class file, regardless of release. ------------- PR: https://git.openjdk.java.net/jdk/pull/4270 From hannesw at openjdk.java.net Sat Jun 5 06:59:02 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Sat, 5 Jun 2021 06:59:02 GMT Subject: Withdrawn: JDK-8267394: Do not rely on object identity for empty valid Content instance In-Reply-To: References: Message-ID: <0-qAoNIMwPjUI9LOGQrnMi9eMnGObl0xunWtjHPA7iM=.3c8c6b4a-bfaa-405b-a1b6-1175198e2274@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)`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4130 From godin at openjdk.java.net Sat Jun 5 08:13:01 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Sat, 5 Jun 2021 08:13:01 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: <3V_zMXiJp7WrQ3RTA9T5XdwDYsHCPluTNVva7q5BLWA=.69ff5e7e-b2b8-4588-aa09-eedf19b1ba9b@github.com> References: <3V_zMXiJp7WrQ3RTA9T5XdwDYsHCPluTNVva7q5BLWA=.69ff5e7e-b2b8-4588-aa09-eedf19b1ba9b@github.com> Message-ID: On Fri, 4 Jun 2021 20:17:43 GMT, Jan Lahoda wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing typo. > > Thanks a lot for all the feedback. I've tried to do the requested changes in the recent commits. @lahodaj I also noticed that https://bugs.openjdk.java.net/browse/JDK-8213076 as well as https://openjdk.java.net/jeps/406 state > The implementation will likely make use of dynamic constants (JEP 309). and wondering if this should be changed on > The implementation will likely make use of invokedynamic. or maybe even removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at openjdk.java.net Sat Jun 5 09:46:06 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 5 Jun 2021 09:46:06 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v13] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 20:20:26 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 two additional commits since the last revision: > > - Applying review feedback. > - Tweaking javadoc. Dynamic constants are needed when de-structuring classes that are not record at top-level, to make the type that will carry the bindings, from invokedynamic to where they are accessed, opaque. So dynamic constants are not needed yet ! ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jonathan.gibbons at oracle.com Sat Jun 5 19:16:21 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 5 Jun 2021 12:16:21 -0700 Subject: RFR: JDK-8259806: Clean up terminology on the "All Classes" page In-Reply-To: <2m1kxNdowQ3fMBpDh9tXlHdMzr4eIpk3Vzsxn-BxcJk=.8284b7d1-d8fa-4a96-b91b-fe0a6945575b@github.com> References: <2m1kxNdowQ3fMBpDh9tXlHdMzr4eIpk3Vzsxn-BxcJk=.8284b7d1-d8fa-4a96-b91b-fe0a6945575b@github.com> Message-ID: <9343c5f5-ae84-57c8-8463-b410341ea681@oracle.com> Up until recently, we used Types (now Classes and Interfaces) Annotation Type (now Annotation Interface) Enum (now Enum Class) Record (now Record Class) The general decision has been to use the older terms consistent with the usage throughout the documentation for the older releases. I guess you have a corner case here, where you are fixing "Classes" (IIRC) and I guess it is "weird" to be retroactively changing it to deprecated terminology like "Types" even if it would be more consistent, especially when the new term is more accurate even for older releases. -- Jon On 6/4/21 11:57 PM, Hannes Walln?fer wrote: > On Thu, 3 Jun 2021 17:09:21 GMT, Jonathan Gibbons wrote: > >> Maybe I'm fighting a losing battle on this one, but the current policy is to generate the correct new terminology for recent releases and the older terminology for older releases, to try and stay consist within the release. >> >> The mapping is handled semi-automatically in `HtmlDoclet.getResourceKeyMapper`, line 130. As a general rule, if you're changing terminology, you should at least be updating the mapping as well. > Is "Classes and Interfaces" part of the "new terminology"? I thought "classes and interfaces" would be the correct term for anything living in a .class file, regardless of release. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4270 From darcy at openjdk.java.net Sun Jun 6 22:12:12 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 6 Jun 2021 22:12:12 GMT Subject: RFR: 8268299: jvms tag produces incorrect URL Message-ID: The @jls and @jvms taglet share most of their functionality. A JLS URL looks like https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1 and a JVMS URL looks like https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2 The current taglet incorrectly uses "jls" in from the chapter for both JLS and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs. ------------- Commit messages: - 8268299: jvms tag produces incorrect URL Changes: https://git.openjdk.java.net/jdk/pull/4381/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4381&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268299 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4381.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4381/head:pull/4381 PR: https://git.openjdk.java.net/jdk/pull/4381 From iris at openjdk.java.net Mon Jun 7 03:14:04 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 7 Jun 2021 03:14:04 GMT Subject: RFR: 8268299: jvms tag produces incorrect URL In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy wrote: > The @jls and @jvms taglet share most of their functionality. A JLS URL looks like > > https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1 > > and a JVMS URL looks like > > https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2 > > The current taglet incorrectly uses "jls" in from the chapter for both JLS and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4381 From jlahoda at openjdk.java.net Mon Jun 7 07:05:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Jun 2021 07:05:12 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: 908aca29 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/908aca29ca60f5f251df8c6a31b2543929be12fc Stats: 4940 lines in 79 files changed: 4621 ins; 118 del; 201 mod 8262891: Compiler implementation for Pattern Matching for switch (Preview) Co-authored-by: Brian Goetz Co-authored-by: Mandy Chung Co-authored-by: Jan Lahoda Reviewed-by: mcimadamore, forax, godin, psandoz, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Mon Jun 7 07:06:01 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Mon, 7 Jun 2021 07:06:01 GMT Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec [v2] In-Reply-To: References: Message-ID: <1aqRzyA9lx9CS3fb8CQNhVApWEPvb_U_S9az9zvH6ic=.de35353f-19f2-42e5-93eb-e2542ae3143b@github.com> 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. The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JDK-8262891 git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/4223 From jlahoda at openjdk.java.net Mon Jun 7 07:53:25 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Jun 2021 07:53:25 GMT Subject: RFR: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec [v3] 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 with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merging master into JDK-8267833 - Reordering @implSpec and example as suggested. - 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec - 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. - ... and 5 more: https://git.openjdk.java.net/jdk/compare/908aca29...7cea033a ------------- Changes: https://git.openjdk.java.net/jdk/pull/4223/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4223&range=02 Stats: 749 lines in 4 files changed: 529 ins; 28 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 hannesw at openjdk.java.net Mon Jun 7 08:44:12 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 08:44:12 GMT Subject: RFR: JDK-8149138: [javadoc] Fix SerialFormBuilder eliminate String bashing In-Reply-To: <8Li1Xo0ONTeNn2F08-6RssxHAb5sp_7nk6cYmfI17w0=.feb0d23a-0aee-40c1-927b-2fc76c089a81@github.com> References: <8Li1Xo0ONTeNn2F08-6RssxHAb5sp_7nk6cYmfI17w0=.feb0d23a-0aee-40c1-927b-2fc76c089a81@github.com> Message-ID: <0K287m8RxPrcBdt1TKBOWtYku_3uEeDCOqnWnFinKI4=.eb6c8349-d05b-423a-8273-89f7a8a3cf3e@github.com> On Thu, 3 Jun 2021 16:59:22 GMT, Jonathan Gibbons wrote: >> Removal of ugly old code in `SerializedFormBuilder.java`. Luckily there already is a clean overloaded method in the associated writer that we can use, so this is mostly a removal of code that is no longer used. >> >> I also enhanced the test to cover more cases such as primitive arrays and linked references. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java line 123: > >> 121: } else { >> 122: Content fieldContent = writer.getLink(new HtmlLinkInfo( >> 123: configuration, HtmlLinkInfo.Kind.SERIAL_MEMBER, fieldType)); > > Just curious, is SERIAL_MEMBER still required? `SERIAL_MEMBER` is still used in the remaining `addMemberHeader` method below. On a deeper level it doesn't seem to be required, as there isn't any link formatting rule associated with it, i.e. it uses the default link format. But this is probably true for several of the 35 `HtmlLinkInfo.Kind` constants we currently have. If we wanted to reduce the number of `HtmlLinkInfo.Kind` enum constants we should file a separate JBS issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/4284 From hannesw at openjdk.java.net Mon Jun 7 08:47:06 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 08:47:06 GMT Subject: Integrated: JDK-8149138: [javadoc] Fix SerialFormBuilder eliminate String bashing In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 16:21:56 GMT, Hannes Walln?fer wrote: > Removal of ugly old code in `SerializedFormBuilder.java`. Luckily there already is a clean overloaded method in the associated writer that we can use, so this is mostly a removal of code that is no longer used. > > I also enhanced the test to cover more cases such as primitive arrays and linked references. This pull request has now been integrated. Changeset: 6d1f3ac7 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/6d1f3ac74914db662d2a39a5b69d8b8143d2f3ef Stats: 95 lines in 5 files changed: 38 ins; 46 del; 11 mod 8149138: [javadoc] Fix SerialFormBuilder eliminate String bashing Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4284 From dholmes at openjdk.java.net Mon Jun 7 10:26:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Jun 2021 10:26:23 GMT Subject: Integrated: 8268318: Missing comma in copyright header Message-ID: Please review this trivial fix to a copyright line. Thanks, David ------------- Commit messages: - 8268318: Missing comma in copyright header Changes: https://git.openjdk.java.net/jdk/pull/4385/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4385&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268318 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4385.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4385/head:pull/4385 PR: https://git.openjdk.java.net/jdk/pull/4385 From stefank at openjdk.java.net Mon Jun 7 10:26:23 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 7 Jun 2021 10:26:23 GMT Subject: Integrated: 8268318: Missing comma in copyright header In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 10:15:06 GMT, David Holmes wrote: > Please review this trivial fix to a copyright line. > > Thanks, > David Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4385 From dholmes at openjdk.java.net Mon Jun 7 10:26:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Jun 2021 10:26:24 GMT Subject: Integrated: 8268318: Missing comma in copyright header In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 10:15:06 GMT, David Holmes wrote: > Please review this trivial fix to a copyright line. > > Thanks, > David This pull request has now been integrated. Changeset: 8130be56 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/8130be561b76906be660e6d779839eb197bd7486 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8268318: Missing comma in copyright header Reviewed-by: stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/4385 From jlahoda at openjdk.java.net Mon Jun 7 11:16:04 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Jun 2021 11:16:04 GMT Subject: Integrated: 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec In-Reply-To: References: Message-ID: <3Mx1yUhBHAtNjh7rsp3M-BVxd4epgoJy0h-KsStj2qY=.945b2708-8102-4abf-ae4d-d9333d60469f@github.com> 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 This pull request has now been integrated. Changeset: e4d04540 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/e4d045402fa1992a1d91586bd4f67362d07f543c Stats: 749 lines in 4 files changed: 529 ins; 28 del; 192 mod 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec Reviewed-by: prappo, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/4223 From erikj at openjdk.java.net Mon Jun 7 12:39:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 12:39:58 GMT Subject: RFR: 8268299: jvms tag produces incorrect URL In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy wrote: > The @jls and @jvms taglet share most of their functionality. A JLS URL looks like > > https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1 > > and a JVMS URL looks like > > https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2 > > The current taglet incorrectly uses "jls" in from the chapter for both JLS and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4381 From hannesw at openjdk.java.net Mon Jun 7 13:09:24 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 13:09:24 GMT Subject: RFR: JDK-8266748: Move modifiers code to Signatures.java [v2] In-Reply-To: References: 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`. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8266748: Use configuration instead of writer where possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4142/files - new: https://git.openjdk.java.net/jdk/pull/4142/files/9970cd2e..b5c5a95c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4142&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4142&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 hannesw at openjdk.java.net Mon Jun 7 13:30:58 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 13:30:58 GMT Subject: RFR: JDK-8266748: Move modifiers code to Signatures.java [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 17:22:26 GMT, Jonathan Gibbons wrote: > Minor changes suggestion, to access items from the configuration where possible. > > As a followup, it would be good to look at the remaining uses of `HtmlDocletWriter` in `Signatures`. There is at least a theme of "methods to create links", and if those methods are just used in the `Signatures` class, they would be candidates to move into that class as well. I changed the mentioned accesses to use configuration instead of writer. Most of the link methods in `HtmlDocletWriter` are used all over the place. `addSrcLink` is only used in `TypeSignature` and `MemberSignature`, but there's various circumstances that makes a move to Signatures unattractive (it accesses fields in HtmlDocletWriter, to which static nested classes TypeSignature and MemberSignature don't share a common reference). ------------- PR: https://git.openjdk.java.net/jdk/pull/4142 From hannes.wallnoefer at oracle.com Mon Jun 7 13:40:33 2021 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 7 Jun 2021 13:40:33 +0000 Subject: RFR: JDK-8259806: Clean up terminology on the "All Classes" page In-Reply-To: <9343c5f5-ae84-57c8-8463-b410341ea681@oracle.com> References: <2m1kxNdowQ3fMBpDh9tXlHdMzr4eIpk3Vzsxn-BxcJk=.8284b7d1-d8fa-4a96-b91b-fe0a6945575b@github.com> <9343c5f5-ae84-57c8-8463-b410341ea681@oracle.com> Message-ID: Yes, the move is from ?All Classes? to ?All Classes and Interfaces?. This is also the new terminology used in the combined tabbed table in package pages, regardless of release. Hannes > Am 05.06.2021 um 21:16 schrieb Jonathan Gibbons : > > Up until recently, we used > > Types (now Classes and Interfaces) > Annotation Type (now Annotation Interface) > Enum (now Enum Class) > Record (now Record Class) > > The general decision has been to use the older terms consistent with the usage throughout the documentation for the older releases. > > I guess you have a corner case here, where you are fixing "Classes" (IIRC) and I guess it is "weird" to be retroactively changing it to deprecated terminology like "Types" even if it would be more consistent, especially when the new term is more accurate even for older releases. > > -- Jon > > On 6/4/21 11:57 PM, Hannes Walln?fer wrote: >> On Thu, 3 Jun 2021 17:09:21 GMT, Jonathan Gibbons wrote: >> >>> Maybe I'm fighting a losing battle on this one, but the current policy is to generate the correct new terminology for recent releases and the older terminology for older releases, to try and stay consist within the release. >>> >>> The mapping is handled semi-automatically in `HtmlDoclet.getResourceKeyMapper`, line 130. As a general rule, if you're changing terminology, you should at least be updating the mapping as well. >> Is "Classes and Interfaces" part of the "new terminology"? I thought "classes and interfaces" would be the correct term for anything living in a .class file, regardless of release. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/4270 From hannesw at openjdk.java.net Mon Jun 7 15:00:43 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 15:00:43 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v3] In-Reply-To: References: Message-ID: <19hnZTFcwuM3fcXgPQUteMMrYY26at7MoCT7pACByxw=.17bbe534-0419-470a-86c6-122e3dd6e99a@github.com> > 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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into JDK-8263468 - JDK-8263468: automate build integration - 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 # Conflicts: # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css - JDK-8263468: Fix tests - JDK-8263468: Update to latest CSR - ... and 6 more: https://git.openjdk.java.net/jdk/compare/3396b69f...3b13ae32 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4209/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=02 Stats: 1925 lines in 41 files changed: 1846 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 jjg at openjdk.java.net Mon Jun 7 15:54:18 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 7 Jun 2021 15:54:18 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: References: Message-ID: <5mNaqwwKOkAhVU0c3hmCaHrwadS8EBClFNEJ8U8pXIw=.1fb0a715-187f-4d80-9655-a7f8b804ef0b@github.com> 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 Some minor suggestions for your consideration src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 112: > 110: doclet.Deprecated_Tabs_Intro=(The leftmost tab "Deprecated ..." indicates all the \ > 111: deprecated elements, regardless of the releases in which they were deprecated. \ > 112: Each of the righthand tabs "Deprecated in ..." indicates the elements deprecated \ "Each of the righthand" doesn't read well. Would "Each of the other" be better? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 119: > 117: doclet.New_Label=New > 118: doclet.New_Tabs_Intro=(The leftmost tab "New ..." indicates all the new elements, \ > 119: regardless of the releases in which they were added. Each of the righthand \ ditto src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 268: > 266: doclet.help.new.body=\ > 267: The {0} page lists APIs that have been added in recent releases. \ > 268: The content of this page is based on information provided by Javadoc @since tags. Either change to "JavaDoc" or (preferably?) just delete this word, or even the sentence. Is there any interaction with `-nosince`? Should there be? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 337: > 335: */ > 336: public int getSourceVersionNumber() { > 337: return configuration.docEnv.getSourceVersion().ordinal(); As a general comment, I believe Joe does not encourage use of `ordinal` ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From jjg at openjdk.java.net Mon Jun 7 15:54:25 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 7 Jun 2021 15:54:25 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v3] In-Reply-To: <19hnZTFcwuM3fcXgPQUteMMrYY26at7MoCT7pACByxw=.17bbe534-0419-470a-86c6-122e3dd6e99a@github.com> References: <19hnZTFcwuM3fcXgPQUteMMrYY26at7MoCT7pACByxw=.17bbe534-0419-470a-86c6-122e3dd6e99a@github.com> Message-ID: On Mon, 7 Jun 2021 15:00:43 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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into JDK-8263468 > - JDK-8263468: automate build integration > - 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 > > # Conflicts: > # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css > - JDK-8263468: Fix tests > - JDK-8263468: Update to latest CSR > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/3396b69f...3b13ae32 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java line 49: > 47: /** > 48: * Generate File to list all the new API elements with the > 49: * appropriate links. (minor) not standard form of comment, but it's "only" an internal class, so could be fixed up later src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java line 72: > 70: /** > 71: * Get list of all the new elements. > 72: * Then instantiate NewAPIListWriter and generate File. Comment. Looks like it may have been copied from elsewhere, I guess src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java line 726: > 724: */ > 725: deprecatedInReleasePage, > 726: Note to self ... affects new "Output Generated ...." document src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java line 145: > 143: public static final DocPath PACKAGE_USE = DocPath.create("package-use.html"); > 144: > 145: /** The name of the fie for preview elements. */ typo: "fie" src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java line 148: > 146: public static final DocPath PREVIEW_LIST = DocPath.create("preview-list.html"); > 147: > 148: /** The name of the fie for new elements. */ typo "fie" src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 1526: > 1524: } > 1525: > 1526: // Returns the Deprecated annotation element value of the given element, or null. Use `/**...*/` test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/module-info.java line 30: > 28: module mdl { > 29: exports pkg; > 30: } final newline ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From jjg at openjdk.java.net Mon Jun 7 15:54:27 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 7 Jun 2021 15:54:27 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v3] In-Reply-To: References: <19hnZTFcwuM3fcXgPQUteMMrYY26at7MoCT7pACByxw=.17bbe534-0419-470a-86c6-122e3dd6e99a@github.com> Message-ID: On Mon, 7 Jun 2021 15:46:45 GMT, Jonathan Gibbons wrote: >> 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 16 commits: >> >> - Merge branch 'master' into JDK-8263468 >> - JDK-8263468: automate build integration >> - 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 >> >> # Conflicts: >> # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css >> - JDK-8263468: Fix tests >> - JDK-8263468: Update to latest CSR >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/3396b69f...3b13ae32 > > test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/module-info.java line 30: > >> 28: module mdl { >> 29: exports pkg; >> 30: } > > final newline For all these "sample API" source files, they are OK, but another time, consider the use of possibly-custom builders, to generate these files dynamically. and to make for more concise reading. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From jjg at openjdk.java.net Mon Jun 7 17:04:16 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 7 Jun 2021 17:04:16 GMT Subject: RFR: 8268299: jvms tag produces incorrect URL In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy wrote: > The @jls and @jvms taglet share most of their functionality. A JLS URL looks like > > https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1 > > and a JVMS URL looks like > > https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2 > > The current taglet incorrectly uses "jls" in from the chapter for both JLS and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4381 From darcy at openjdk.java.net Mon Jun 7 17:07:23 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Jun 2021 17:07:23 GMT Subject: Integrated: 8268299: jvms tag produces incorrect URL In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy wrote: > The @jls and @jvms taglet share most of their functionality. A JLS URL looks like > > https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1 > > and a JVMS URL looks like > > https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2 > > The current taglet incorrectly uses "jls" in from the chapter for both JLS and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs. This pull request has now been integrated. Changeset: e663ba96 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/e663ba961f25c83758815bbfce97a58d9560c7a2 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8268299: jvms tag produces incorrect URL Reviewed-by: iris, erikj, jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4381 From hannesw at openjdk.java.net Mon Jun 7 19:48:39 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 19:48:39 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v4] 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: review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4209/files - new: https://git.openjdk.java.net/jdk/pull/4209/files/3b13ae32..c9c5f832 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=02-03 Stats: 29 lines in 7 files changed: 6 ins; 2 del; 21 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 Mon Jun 7 19:48:40 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 19:48:40 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: <5mNaqwwKOkAhVU0c3hmCaHrwadS8EBClFNEJ8U8pXIw=.1fb0a715-187f-4d80-9655-a7f8b804ef0b@github.com> References: <5mNaqwwKOkAhVU0c3hmCaHrwadS8EBClFNEJ8U8pXIw=.1fb0a715-187f-4d80-9655-a7f8b804ef0b@github.com> Message-ID: <4QddKtr8UiPGxVUgb-rRfUFZorqTKYd1BJkzyA75rsI=.d8dd5538-5da1-4b3e-bea1-11c577299873@github.com> On Mon, 7 Jun 2021 14:52:57 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263468: automate build integration > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 112: > >> 110: doclet.Deprecated_Tabs_Intro=(The leftmost tab "Deprecated ..." indicates all the \ >> 111: deprecated elements, regardless of the releases in which they were deprecated. \ >> 112: Each of the righthand tabs "Deprecated in ..." indicates the elements deprecated \ > > "Each of the righthand" doesn't read well. Would "Each of the other" be better? Changed to "Each of the other". ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Mon Jun 7 19:57:23 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 19:57:23 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v3] In-Reply-To: References: <19hnZTFcwuM3fcXgPQUteMMrYY26at7MoCT7pACByxw=.17bbe534-0419-470a-86c6-122e3dd6e99a@github.com> Message-ID: On Mon, 7 Jun 2021 15:27:21 GMT, Jonathan Gibbons wrote: >> 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 16 commits: >> >> - Merge branch 'master' into JDK-8263468 >> - JDK-8263468: automate build integration >> - 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 >> >> # Conflicts: >> # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css >> - JDK-8263468: Fix tests >> - JDK-8263468: Update to latest CSR >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/3396b69f...3b13ae32 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java line 49: > >> 47: /** >> 48: * Generate File to list all the new API elements with the >> 49: * appropriate links. > > (minor) not standard form of comment, but it's "only" an internal class, so could be fixed up later This comment and the comment below was copied and adapter from another SummaryListWriter subclass. I took the liberty of rewriting both comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Mon Jun 7 19:57:24 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 7 Jun 2021 19:57:24 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: <5mNaqwwKOkAhVU0c3hmCaHrwadS8EBClFNEJ8U8pXIw=.1fb0a715-187f-4d80-9655-a7f8b804ef0b@github.com> References: <5mNaqwwKOkAhVU0c3hmCaHrwadS8EBClFNEJ8U8pXIw=.1fb0a715-187f-4d80-9655-a7f8b804ef0b@github.com> Message-ID: On Mon, 7 Jun 2021 14:53:55 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263468: automate build integration > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 268: > >> 266: doclet.help.new.body=\ >> 267: The {0} page lists APIs that have been added in recent releases. \ >> 268: The content of this page is based on information provided by Javadoc @since tags. > > Either change to "JavaDoc" or (preferably?) just delete this word, or even the sentence. > > Is there any interaction with `-nosince`? Should there be? I removed the second sentence. There is no interaction with `-nosince`. I one point I thought `-nosince` should disable this feature, but actually both features are just different ways of displaying the information stored in `@since` tags that don't depend on each other. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 337: > >> 335: */ >> 336: public int getSourceVersionNumber() { >> 337: return configuration.docEnv.getSourceVersion().ordinal(); > > As a general comment, I believe Joe does not encourage use of `ordinal` I undid this change as it's not really part of the feature. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From jjg at openjdk.java.net Tue Jun 8 01:09:36 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 01:09:36 GMT Subject: RFR: JDK-8267187: Remove deprecated constructor for Log [v2] In-Reply-To: References: 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. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - JDK-8267187: Remove deprecated constructor for Log - 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=01 Stats: 34 lines in 1 file changed: 0 ins; 34 del; 0 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 jjg at openjdk.java.net Tue Jun 8 01:18:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 01:18:38 GMT Subject: Withdrawn: 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4037 From jjg at openjdk.java.net Tue Jun 8 01:18:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 01:18:38 GMT Subject: RFR: JDK-8267187: Remove deprecated constructor for Log [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 01:09:36 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. > > Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - JDK-8267187: Remove deprecated constructor for Log > - JDK-8267187: Remove deprecated constructor for Log PR seems confused. New PR filed as https://github.com/openjdk/jdk/pull/4404 ------------- PR: https://git.openjdk.java.net/jdk/pull/4037 From jjg at openjdk.java.net Tue Jun 8 01:35:31 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 01:35:31 GMT Subject: RFR: JDK-8268352: Rename javadoc Messager class to JavadocLog Message-ID: Please review a simple cleanup, to rename the javadoc Messager class to the more explicit, less-confusing name of JavadocLog, since it is the javadoc subtype of the javac Log class. The new name is in line with other javadoc subtypes of javac classes. The change only affects the javadoc.tool package; it does not affect any doclet packages, which use the `Reporter` interface, provided by `JavadocLog`. ------------- Commit messages: - JDK-8268352: Rename javadoc Messager class to JavadocLog Changes: https://git.openjdk.java.net/jdk/pull/4405/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4405&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268352 Stats: 122 lines in 8 files changed: 0 ins; 0 del; 122 mod Patch: https://git.openjdk.java.net/jdk/pull/4405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4405/head:pull/4405 PR: https://git.openjdk.java.net/jdk/pull/4405 From prappo at openjdk.java.net Tue Jun 8 10:02:17 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 8 Jun 2021 10:02:17 GMT Subject: RFR: JDK-8268352: Rename javadoc Messager class to JavadocLog In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 01:23:17 GMT, Jonathan Gibbons wrote: > Please review a simple cleanup, to rename the javadoc Messager class to the more explicit, less-confusing name of JavadocLog, since it is the javadoc subtype of the javac Log class. > > The new name is in line with other javadoc subtypes of javac classes. > > The change only affects the javadoc.tool package; it does not affect any doclet packages, which use the `Reporter` interface, provided by `JavadocLog`. 1. Update copyright years 2. Update the comment at test/langtools/jdk/javadoc/tool/CheckResourceKeys.java:229-230 ------------- Changes requested by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4405 From jjg at openjdk.java.net Tue Jun 8 16:23:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 16:23:14 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v4] In-Reply-To: References: Message-ID: <_Io-EG2fMe1hdaJxdskPSEHbX8lKZCOAKxkuiagbdtQ=.924a6839-1228-4f90-857b-c5f1f3eeccd3@github.com> On Mon, 7 Jun 2021 19:48:39 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: review comments One future suggestion. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 113: > 111: deprecated elements, regardless of the releases in which they were deprecated. \ > 112: Each of the other tabs "Deprecated in ..." indicates the elements deprecated \ > 113: in a specific release.) This is OK for now, but a noreg-doc follow-up might be to improve the punctuation in this text, possibly after consulting with docs folk. It's the use of the quoted strings that seems weird, without any commas or parentheses too set them off. On the other hand, I realize we sometimes go for brevity in places like this. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4209 From jjg at openjdk.java.net Tue Jun 8 16:24:17 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 16:24:17 GMT Subject: RFR: JDK-8259806: Clean up terminology on the "All Classes" page In-Reply-To: References: Message-ID: On Mon, 31 May 2021 10:06:14 GMT, Hannes Walln?fer wrote: > 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. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4270 From jjg at openjdk.java.net Tue Jun 8 16:28:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 16:28:14 GMT Subject: RFR: JDK-8266748: Move modifiers code to Signatures.java [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 13:09:24 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`. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266748: Use configuration instead of writer where possible Generally good, and as with many cleanups, it's a great step in the right direction. As I indicated in a previous round of review, I think that further cleanup is possible (later) by moving more code out of `HtmlDocletWriter` into more specific abstractions, possibly including this one. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4142 From jjg at openjdk.java.net Tue Jun 8 17:04:37 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 17:04:37 GMT Subject: RFR: JDK-8268352: Rename javadoc Messager class to JavadocLog [v2] In-Reply-To: References: Message-ID: > Please review a simple cleanup, to rename the javadoc Messager class to the more explicit, less-confusing name of JavadocLog, since it is the javadoc subtype of the javac Log class. > > The new name is in line with other javadoc subtypes of javac classes. > > The change only affects the javadoc.tool package; it does not affect any doclet packages, which use the `Reporter` interface, provided by `JavadocLog`. 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/4405/files - new: https://git.openjdk.java.net/jdk/pull/4405/files/20bb75b2..c7f81586 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4405&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4405&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4405/head:pull/4405 PR: https://git.openjdk.java.net/jdk/pull/4405 From prappo at openjdk.java.net Tue Jun 8 17:20:14 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 8 Jun 2021 17:20:14 GMT Subject: RFR: JDK-8268352: Rename javadoc Messager class to JavadocLog [v2] In-Reply-To: References: Message-ID: <-73mFhnwVHFYRnAxcoO1nXjB3aSbKeJk6uK02q-EuxY=.982cecbc-601f-4ccb-99c7-725bbd5c8e29@github.com> On Tue, 8 Jun 2021 17:04:37 GMT, Jonathan Gibbons wrote: >> Please review a simple cleanup, to rename the javadoc Messager class to the more explicit, less-confusing name of JavadocLog, since it is the javadoc subtype of the javac Log class. >> >> The new name is in line with other javadoc subtypes of javac classes. >> >> The change only affects the javadoc.tool package; it does not affect any doclet packages, which use the `Reporter` interface, provided by `JavadocLog`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > address review feedback Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4405 From jjg at openjdk.java.net Tue Jun 8 17:26:23 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 17:26:23 GMT Subject: Integrated: JDK-8268352: Rename javadoc Messager class to JavadocLog In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 01:23:17 GMT, Jonathan Gibbons wrote: > Please review a simple cleanup, to rename the javadoc Messager class to the more explicit, less-confusing name of JavadocLog, since it is the javadoc subtype of the javac Log class. > > The new name is in line with other javadoc subtypes of javac classes. > > The change only affects the javadoc.tool package; it does not affect any doclet packages, which use the `Reporter` interface, provided by `JavadocLog`. This pull request has now been integrated. Changeset: fafc4d97 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/fafc4d976434c196c16b652c859073c5888b992e Stats: 126 lines in 9 files changed: 0 ins; 0 del; 126 mod 8268352: Rename javadoc Messager class to JavadocLog Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4405 From hannesw at openjdk.java.net Tue Jun 8 18:25:18 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 8 Jun 2021 18:25:18 GMT Subject: Integrated: JDK-8263468: New page for "recent" new API In-Reply-To: References: Message-ID: <__Es1h4_XCxlIzRYBu2dqa3AchquS9to3HdkeXGR1OY=.dcc87eff-6d1c-4a9d-9917-c9d14e3be53e@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 This pull request has now been integrated. Changeset: dc6c96bb Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/dc6c96bbaf1c0af3eacaa2e59646ed7c5bb0767d Stats: 1920 lines in 40 files changed: 1846 ins; 34 del; 40 mod 8263468: New page for "recent" new API Reviewed-by: erikj, jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Tue Jun 8 18:53:15 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 8 Jun 2021 18:53:15 GMT Subject: Integrated: JDK-8259806: Clean up terminology on the "All Classes" page In-Reply-To: References: Message-ID: On Mon, 31 May 2021 10:06:14 GMT, Hannes Walln?fer wrote: > 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. This pull request has now been integrated. Changeset: 4dd0e7e7 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/4dd0e7e78aab23e5c98f3457dd6c14788780becd Stats: 29 lines in 10 files changed: 5 ins; 3 del; 21 mod 8259806: Clean up terminology on the "All Classes" page Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4270 From hannesw at openjdk.java.net Tue Jun 8 19:24:20 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 8 Jun 2021 19:24:20 GMT Subject: Integrated: JDK-8266748: Move modifiers code to Signatures.java In-Reply-To: References: Message-ID: <953j1f0w33gbpcTi1xj_afWA8YGGACQbzGklrIma_eE=.5ecfbdd6-df7a-4bd7-a4ef-7904c597566d@github.com> 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`. This pull request has now been integrated. Changeset: f9b593d6 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/f9b593d668147979a16e743fe138d4e447e8232b Stats: 261 lines in 5 files changed: 118 ins; 123 del; 20 mod 8266748: Move modifiers code to Signatures.java Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4142 From darcy at openjdk.java.net Tue Jun 8 19:44:27 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Jun 2021 19:44:27 GMT Subject: RFR: 8264866: Remove unneeded WorkArounds.isAutomaticModule Message-ID: Simple cleanup as a follow-on to JDK-8264865. Clean langtools test run. ------------- Commit messages: - 8264866: Remove unneeded WorkArounds.isAutomaticModule Changes: https://git.openjdk.java.net/jdk/pull/4417/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4417&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264866 Stats: 13 lines in 2 files changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4417.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4417/head:pull/4417 PR: https://git.openjdk.java.net/jdk/pull/4417 From jjg at openjdk.java.net Tue Jun 8 20:21:13 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Jun 2021 20:21:13 GMT Subject: RFR: 8264866: Remove unneeded WorkArounds.isAutomaticModule In-Reply-To: References: Message-ID: <__vCBit8LXhdMECuW5T6LBaum2HpGVbv7pj2owS8DLU=.634cbbcb-afae-44e3-b52d-14339d76ab02@github.com> On Tue, 8 Jun 2021 19:37:28 GMT, Joe Darcy wrote: > Simple cleanup as a follow-on to JDK-8264865. Clean langtools test run. ?? ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4417 From darcy at openjdk.java.net Tue Jun 8 20:24:17 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Jun 2021 20:24:17 GMT Subject: Integrated: 8264866: Remove unneeded WorkArounds.isAutomaticModule In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 19:37:28 GMT, Joe Darcy wrote: > Simple cleanup as a follow-on to JDK-8264865. Clean langtools test run. This pull request has now been integrated. Changeset: 7a378165 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/7a37816548b913494b9671df9469b159cc62ae73 Stats: 13 lines in 2 files changed: 0 ins; 12 del; 1 mod 8264866: Remove unneeded WorkArounds.isAutomaticModule Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4417 From hannesw at openjdk.java.net Thu Jun 10 11:02:36 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 10 Jun 2021 11:02:36 GMT Subject: RFR: JDK-8262886: javadoc generates broken links with {@inheritDoc} Message-ID: This change fixes a whole slew of shortcomings in the redirection of relative links in doc comments. The basic idea is that relative links are authored to work in their "native primary" environment (e.g. the package summary page for a package or the class page for a class and its members), and have to be rewritten when used in other contexts such as "use" or index pages. A list of omissions that are fixed in this change: - Relative links in class or member comments were not redirected when inherited by other classes - Relative links in package comments were not rewritten when displayed in other package summaries as "related packages" - Fragment links used in foreign contexts were not completed with the file name - Relative links in module comments were not redirected at all While fixing above issues I also made sure link rewriting is kept to a minimum, avoiding it as much as possible for elements that live in the same package. Furthermore, the test for redirected relative links was a bit out of order. The `javadoc` command issued by the test returned `ERROR` because one of the source files contained non-valid HTML (an anchor with a `name` attribute to test whether that attribute would be modified). Because of this, the `checkLinks()` method was never invoked, which is a problem for a test that is supposed to make sure generated links are valid. I changed the test to use the valid `id` attribute instead of `name` and made sure `checkLinks()` is executed again. I also added checks for the newly supported cases. I added a whole new test for modules since retrofitting the existing test to cover modules would not have been practical. ------------- Commit messages: - JDK-8262886: Minor test change - JDK-8262886: Fix whitespace - JDK-8262886: Further improvements - JDK-8262886: javadoc generates broken links with {@inheritDoc} Changes: https://git.openjdk.java.net/jdk/pull/4459/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4459&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262886 Stats: 488 lines in 9 files changed: 393 ins; 49 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/4459.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4459/head:pull/4459 PR: https://git.openjdk.java.net/jdk/pull/4459 From prappo at openjdk.java.net Thu Jun 10 13:04:18 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 10 Jun 2021 13:04:18 GMT Subject: RFR: JDK-8262886: javadoc generates broken links with {@inheritDoc} In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 09:27:40 GMT, Hannes Walln?fer wrote: > This change fixes a whole slew of shortcomings in the redirection of relative links in doc comments. The basic idea is that relative links are authored to work in their "native primary" environment (e.g. the package summary page for a package or the class page for a class and its members), and have to be rewritten when used in other contexts such as "use" or index pages. > > A list of omissions that are fixed in this change: > > - Relative links in class or member comments were not redirected when inherited by other classes > - Relative links in package comments were not rewritten when displayed in other package summaries as "related packages" > - Fragment links used in foreign contexts were not completed with the file name > - Relative links in module comments were not redirected at all > > While fixing above issues I also made sure link rewriting is kept to a minimum, avoiding it as much as possible for elements that live in the same package. > > Furthermore, the test for redirected relative links was a bit out of order. The `javadoc` command issued by the test returned `ERROR` because one of the source files contained non-valid HTML (an anchor with a `name` attribute to test whether that attribute would be modified). Because of this, the `checkLinks()` method was never invoked, which is a problem for a test that is supposed to make sure generated links are valid. I changed the test to use the valid `id` attribute instead of `name` and made sure `checkLinks()` is executed again. > > I also added checks for the newly supported cases. I added a whole new test for modules since retrofitting the existing test to cover modules would not have been practical. If you haven't already, please run `doccheck` on the JDK API documentation to make sure the issues mentioned in the JBS issue are gone. ------------- PR: https://git.openjdk.java.net/jdk/pull/4459 From hannesw at openjdk.java.net Thu Jun 10 13:56:14 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 10 Jun 2021 13:56:14 GMT Subject: RFR: JDK-8262886: javadoc generates broken links with {@inheritDoc} In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 13:01:18 GMT, Pavel Rappo wrote: > If you haven't already, please run `doccheck` on the JDK API documentation to make sure the issues mentioned in the JBS issue are gone. I have checked the mentioned issues. The ones in `MemoryAddress` were actual documentation errors which have been fixed in the meantime. The others are solved by this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4459 From hannesw at openjdk.java.net Thu Jun 10 14:15:34 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 10 Jun 2021 14:15:34 GMT Subject: RFR: JDK-8262886: javadoc generates broken links with {@inheritDoc} [v2] In-Reply-To: References: Message-ID: > This change fixes a whole slew of shortcomings in the redirection of relative links in doc comments. The basic idea is that relative links are authored to work in their "native primary" environment (e.g. the package summary page for a package or the class page for a class and its members), and have to be rewritten when used in other contexts such as "use" or index pages. > > A list of omissions that are fixed in this change: > > - Relative links in class or member comments were not redirected when inherited by other classes > - Relative links in package comments were not rewritten when displayed in other package summaries as "related packages" > - Fragment links used in foreign contexts were not completed with the file name > - Relative links in module comments were not redirected at all > > While fixing above issues I also made sure link rewriting is kept to a minimum, avoiding it as much as possible for elements that live in the same package. > > Furthermore, the test for redirected relative links was a bit out of order. The `javadoc` command issued by the test returned `ERROR` because one of the source files contained non-valid HTML (an anchor with a `name` attribute to test whether that attribute would be modified). Because of this, the `checkLinks()` method was never invoked, which is a problem for a test that is supposed to make sure generated links are valid. I changed the test to use the valid `id` attribute instead of `name` and made sure `checkLinks()` is executed again. > > I also added checks for the newly supported cases. I added a whole new test for modules since retrofitting the existing test to cover modules would not have been practical. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8262886: Fix copyright headers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4459/files - new: https://git.openjdk.java.net/jdk/pull/4459/files/89945cce..0a597560 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4459&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4459&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4459.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4459/head:pull/4459 PR: https://git.openjdk.java.net/jdk/pull/4459 From hannesw at openjdk.java.net Fri Jun 11 07:19:53 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 11 Jun 2021 07:19:53 GMT Subject: RFR: JDK-8262886: javadoc generates broken links with {@inheritDoc} [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 14:15:34 GMT, Hannes Walln?fer wrote: >> This change fixes a whole slew of shortcomings in the redirection of relative links in doc comments. The basic idea is that relative links are authored to work in their "native primary" environment (e.g. the package summary page for a package or the class page for a class and its members), and have to be rewritten when used in other contexts such as "use" or index pages. >> >> A list of omissions that are fixed in this change: >> >> - Relative links in class or member comments were not redirected when inherited by other classes >> - Relative links in package comments were not rewritten when displayed in other package summaries as "related packages" >> - Fragment links used in foreign contexts were not completed with the file name >> - Relative links in module comments were not redirected at all >> >> While fixing above issues I also made sure link rewriting is kept to a minimum, avoiding it as much as possible for elements that live in the same package. >> >> Furthermore, the test for redirected relative links was a bit out of order. The `javadoc` command issued by the test returned `ERROR` because one of the source files contained non-valid HTML (an anchor with a `name` attribute to test whether that attribute would be modified). Because of this, the `checkLinks()` method was never invoked, which is a problem for a test that is supposed to make sure generated links are valid. I changed the test to use the valid `id` attribute instead of `name` and made sure `checkLinks()` is executed again. >> >> I also added checks for the newly supported cases. I added a whole new test for modules since retrofitting the existing test to cover modules would not have been practical. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8262886: Fix copyright headers This PR is succeeded by openjdk/jdk17#17. ------------- PR: https://git.openjdk.java.net/jdk/pull/4459 From hannesw at openjdk.java.net Fri Jun 11 07:19:53 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 11 Jun 2021 07:19:53 GMT Subject: Withdrawn: JDK-8262886: javadoc generates broken links with {@inheritDoc} In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 09:27:40 GMT, Hannes Walln?fer wrote: > This change fixes a whole slew of shortcomings in the redirection of relative links in doc comments. The basic idea is that relative links are authored to work in their "native primary" environment (e.g. the package summary page for a package or the class page for a class and its members), and have to be rewritten when used in other contexts such as "use" or index pages. > > A list of omissions that are fixed in this change: > > - Relative links in class or member comments were not redirected when inherited by other classes > - Relative links in package comments were not rewritten when displayed in other package summaries as "related packages" > - Fragment links used in foreign contexts were not completed with the file name > - Relative links in module comments were not redirected at all > > While fixing above issues I also made sure link rewriting is kept to a minimum, avoiding it as much as possible for elements that live in the same package. > > Furthermore, the test for redirected relative links was a bit out of order. The `javadoc` command issued by the test returned `ERROR` because one of the source files contained non-valid HTML (an anchor with a `name` attribute to test whether that attribute would be modified). Because of this, the `checkLinks()` method was never invoked, which is a problem for a test that is supposed to make sure generated links are valid. I changed the test to use the valid `id` attribute instead of `name` and made sure `checkLinks()` is executed again. > > I also added checks for the newly supported cases. I added a whole new test for modules since retrofitting the existing test to cover modules would not have been practical. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4459 From hannesw at openjdk.java.net Fri Jun 11 07:22:24 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 11 Jun 2021 07:22:24 GMT Subject: [jdk17] RFR: JDK-8262886: javadoc generates broken links with {@inheritDoc} Message-ID: (This jdk17 PR is the continuation of PR openjdk/jdk#4459 in the mainline jdk repo, commits are identical at the point of transition.) This change fixes a whole slew of shortcomings in the redirection of relative links in doc comments. The basic idea is that relative links are authored to work in their "native primary" environment (e.g. the package summary page for a package or the class page for a class and its members), and have to be rewritten when used in other contexts such as "use" or index pages. A list of omissions that are fixed in this change: - Relative links in class or member comments were not redirected when inherited by other classes - Relative links in package comments were not rewritten when displayed in other package summaries as "related packages" - Fragment links used in foreign contexts were not completed with the file name - Relative links in module comments were not redirected at all While fixing above issues I also made sure link rewriting is kept to a minimum, avoiding it as much as possible for elements that live in the same package. Furthermore, the test for redirected relative links was a bit out of order. The `javadoc` command issued by the test returned `ERROR` because one of the source files contained non-valid HTML (an anchor with a `name` attribute to test whether that attribute would be modified). Because of this, the `checkLinks()` method was never invoked, which is a problem for a test that is supposed to make sure generated links are valid. I changed the test to use the valid `id` attribute instead of `name` and made sure `checkLinks()` is executed again. I also added checks for the newly supported cases. I added a whole new test for modules since retrofitting the existing test to cover modules would not have been practical. ------------- Commit messages: - JDK-8262886: Fix copyright headers - JDK-8262886: Minor test change - JDK-8262886: Fix whitespace - JDK-8262886: Further improvements - JDK-8262886: javadoc generates broken links with {@inheritDoc} Changes: https://git.openjdk.java.net/jdk17/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=17&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262886 Stats: 489 lines in 9 files changed: 393 ins; 49 del; 47 mod Patch: https://git.openjdk.java.net/jdk17/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/17/head:pull/17 PR: https://git.openjdk.java.net/jdk17/pull/17 From jfranck at openjdk.java.net Mon Jun 14 13:44:19 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Mon, 14 Jun 2021 13:44:19 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint Message-ID: Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed. This proposed fix checks references at parse time to disallow annotated types instead of crashing later on. Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong. Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18. ------------- Commit messages: - 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint Changes: https://git.openjdk.java.net/jdk/pull/4483/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4483&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266082 Stats: 99 lines in 5 files changed: 98 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4483/head:pull/4483 PR: https://git.openjdk.java.net/jdk/pull/4483 From hannesw at openjdk.java.net Mon Jun 14 13:51:15 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 14 Jun 2021 13:51:15 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 Message-ID: This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. ------------- Commit messages: - JDK-8263321: Regression 8% in javadoc-steady in 17-b11 Changes: https://git.openjdk.java.net/jdk17/pull/42/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=42&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263321 Stats: 21 lines in 7 files changed: 2 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk17/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/42/head:pull/42 PR: https://git.openjdk.java.net/jdk17/pull/42 From hannesw at openjdk.java.net Mon Jun 14 14:22:03 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 14 Jun 2021 14:22:03 GMT Subject: [jdk17] RFR: JDK-8268557: Module page uses unstyled table class Message-ID: This adds CSS rules for the `details-table` class used in the module summary page. The rules are identical to the ones for the `summary-table` class. The screenshot below shows the module summary page with the fixed stylesheet. module-summary-fixed ------------- Commit messages: - JDK-8268557: Module page uses unstyled table class Changes: https://git.openjdk.java.net/jdk17/pull/43/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=43&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268557 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk17/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/43/head:pull/43 PR: https://git.openjdk.java.net/jdk17/pull/43 From vromero at openjdk.java.net Mon Jun 14 17:54:54 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 14 Jun 2021 17:54:54 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 13:43:40 GMT, Hannes Walln?fer wrote: > This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. > > Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. just curious, what was the performance improvement after this change? ------------- PR: https://git.openjdk.java.net/jdk17/pull/42 From hannesw at openjdk.java.net Mon Jun 14 18:58:03 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 14 Jun 2021 18:58:03 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 In-Reply-To: References: Message-ID: <6bEgf0G6OfVhXKK_GIKUxz-W3sMoW0wDBWrh3tk3F9o=.eb95224b-f6c5-47e6-8044-7c9f85f0e9c0@github.com> On Mon, 14 Jun 2021 17:51:59 GMT, Vicente Romero wrote: > just curious, what was the performance improvement after this change? Running the JavadocSteadyCompilerBench benchmark on my laptop (with other apps running) I get close to 5% improvement, which is similar to what I see in the regression. Before/After change results below. Result "execute": 294,600 ?(99.9%) 5,860 ms/op [Average] (min, avg, max) = (284,487, 294,600, 336,963), stdev = 10,416 CI (99.9%): [288,740, 300,460] (assumes normal distribution) Result "execute": 281,528 ?(99.9%) 2,316 ms/op [Average] (min, avg, max) = (275,671, 281,528, 292,972), stdev = 4,117 CI (99.9%): [279,212, 283,844] (assumes normal distribution) ------------- PR: https://git.openjdk.java.net/jdk17/pull/42 From vromero at openjdk.java.net Mon Jun 14 19:50:55 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 14 Jun 2021 19:50:55 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 In-Reply-To: <6bEgf0G6OfVhXKK_GIKUxz-W3sMoW0wDBWrh3tk3F9o=.eb95224b-f6c5-47e6-8044-7c9f85f0e9c0@github.com> References: <6bEgf0G6OfVhXKK_GIKUxz-W3sMoW0wDBWrh3tk3F9o=.eb95224b-f6c5-47e6-8044-7c9f85f0e9c0@github.com> Message-ID: On Mon, 14 Jun 2021 18:54:39 GMT, Hannes Walln?fer wrote: > > just curious, what was the performance improvement after this change? > > Running the JavadocSteadyCompilerBench benchmark on my laptop (with other apps running) I get close to 5% improvement, which is similar to what I see in the regression. Before/After change results below. > > Result "execute": > 294,600 ?(99.9%) 5,860 ms/op [Average] > (min, avg, max) = (284,487, 294,600, 336,963), stdev = 10,416 > CI (99.9%): [288,740, 300,460] (assumes normal distribution) > > Result "execute": > 281,528 ?(99.9%) 2,316 ms/op [Average] > (min, avg, max) = (275,671, 281,528, 292,972), stdev = 4,117 > CI (99.9%): [279,212, 283,844] (assumes normal distribution) thanks ------------- PR: https://git.openjdk.java.net/jdk17/pull/42 From jjg at openjdk.java.net Mon Jun 14 21:56:47 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 14 Jun 2021 21:56:47 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node Message-ID: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. There are some cosmetic cleanups that were made while exploring the current solution. The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. ------------- Commit messages: - JDK-8268420 Changes: https://git.openjdk.java.net/jdk/pull/4489/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268420 Stats: 542 lines in 8 files changed: 528 ins; 5 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4489/head:pull/4489 PR: https://git.openjdk.java.net/jdk/pull/4489 From vromero at openjdk.java.net Tue Jun 15 00:18:44 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 15 Jun 2021 00:18:44 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 13:35:35 GMT, Joel Borggr?n-Franck wrote: > Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed. > > This proposed fix checks references at parse time to disallow annotated types instead of crashing later on. > > Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong. > > Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18. test/langtools/tools/doclint/CrashInAnnotateTest.java line 31: > 29: */ > 30: > 31: /** {@link #equals(@Deprecated Object)} */ I think that the test should include other cases like links to fields and methods in another package etc. with annotations modifying different elements not only method parameters. ------------- PR: https://git.openjdk.java.net/jdk/pull/4483 From jfranck at openjdk.java.net Tue Jun 15 11:38:14 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 15 Jun 2021 11:38:14 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint [v2] In-Reply-To: References: Message-ID: > Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed. > > This proposed fix checks references at parse time to disallow annotated types instead of crashing later on. > > Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong. > > Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18. Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: 8266082: Use nodynamiccopyright and add test cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4483/files - new: https://git.openjdk.java.net/jdk/pull/4483/files/2296e579..8c387d12 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4483&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4483&range=00-01 Stats: 45 lines in 2 files changed: 14 ins; 23 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4483/head:pull/4483 PR: https://git.openjdk.java.net/jdk/pull/4483 From jfranck at openjdk.java.net Tue Jun 15 11:44:37 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 15 Jun 2021 11:44:37 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint [v2] In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 00:15:55 GMT, Vicente Romero wrote: >> Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266082: Use nodynamiccopyright and add test cases > > test/langtools/tools/doclint/CrashInAnnotateTest.java line 31: > >> 29: */ >> 30: >> 31: /** {@link #equals(@Deprecated Object)} */ > > I think that the test should include other cases like links to fields and methods in another package etc. with annotations modifying different elements not only method parameters. Added some more cases, both were previously handled ------------- PR: https://git.openjdk.java.net/jdk/pull/4483 From prappo at openjdk.java.net Tue Jun 15 12:20:40 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 15 Jun 2021 12:20:40 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 In-Reply-To: References: Message-ID: <1kUDYXIxVozVlH0AUNaqY1kkQ6kt983Ob7sCRMyu7Zs=.f1c15c9b-54aa-4c27-985a-a21bbf615879@github.com> On Mon, 14 Jun 2021 13:43:40 GMT, Hannes Walln?fer wrote: > This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. > > Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. Based on these numbers, 8% degradation followed by 5% improvement, this patch reverses approximately half of the initial degradation introduced by JDK-8260223, right? (Had to remind myself how tricky percentages can be.) If so, then where is the other half? Should we be concerned about it? ------------- PR: https://git.openjdk.java.net/jdk17/pull/42 From prappo at openjdk.java.net Tue Jun 15 13:14:41 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 15 Jun 2021 13:14:41 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 13:43:40 GMT, Hannes Walln?fer wrote: > This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. > > Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. I think this is a reasonable change for both JavaDoc and javac. That said, you should wait for someone from the compiler team to review it. Meanwhile, update the copyright year in Entity.java ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/42 From jai.forums2013 at gmail.com Tue Jun 15 04:55:06 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 15 Jun 2021 10:25:06 +0530 Subject: JDK 17 EA build 26 - javadoc tool now writes message to STDERR instead of STDOUT? Message-ID: <15f90207-8c8e-6ffd-afd8-885e1970263c@gmail.com> While testing the Apache Ant project with the latest released JDK 17 EA (build 26)[1], we have run into an unexpected test failure in our project. The test is pretty simple. It launches the javadoc task and passes it a Java source file which has javadoc content which is expected to raise a warning message. Something like: package test; /** ?* This is a test class. ?*/ public class Foo { ??? /** ???? * With a test method. ???? * @param baz wrong parameter name should cause warning. ???? */ ??? public void foo(String bar) {} } The test then expects the javadoc tool/command to print a message of the form "1 warning" to the STDOUT of the launced javadoc process. Of course, other log messages are also logged to that STDOUT by the tool. In JDK version 8, 11 and even 16, this all works as expected and the test passes. However, this latest JDK 17 EA, it fails because it doesn't find this message on the STDOUT of the process. I looked into this in a bit more detail and it looks like the javadoc command/tool is now writing this message to the STDERR of the process. Not just that, it also looks like the tool is now writing a lot other messages to STDERR, which previously were written to STDOUT. To give you can example, if you directly run the javadoc command from JDK 16 and JDK 17 EA build against the above trivial code, you will see that in JDK 16, the following were logged to STDOUT: Loading source file Foo.java... Constructing Javadoc information... Building index for all the packages and classes... Standard Doclet version 16+36-2231 Building tree for all the packages and classes... Generating ./test/Foo.html... Generating ./test/package-summary.html... Generating ./test/package-tree.html... Generating ./overview-tree.html... Building index for all classes... Generating ./allclasses-index.html... Generating ./allpackages-index.html... Generating ./index-all.html... Generating ./index.html... Generating ./help-doc.html... 1 error 1 warning and JDK 16 STDERR only had: Foo.java:9: error: @param name not found ???? * @param baz wrong parameter name should cause warning. ????????????? ^ Foo.java:11: warning: no @param for bar ??? public void foo(String bar) {} Now in JDK 17 EA, the same command generates the following STDOUT: Loading source file Foo.java... Constructing Javadoc information... and this STDERR: Building index for all the packages and classes... Standard Doclet version 17-ea+26-2439 Building tree for all the packages and classes... Generating ./test/Foo.html... Foo.java:9: error: @param name not found ???? * @param baz wrong parameter name should cause warning. ????????????? ^ Foo.java:11: warning: no @param for bar ??? public void foo(String bar) {} ??????????????? ^ Generating ./test/package-summary.html... Generating ./test/package-tree.html... Generating ./overview-tree.html... Building index for all classes... Generating ./allclasses-index.html... Generating ./allpackages-index.html... Generating ./index-all.html... Generating ./index.html... Generating ./help-doc.html... 1 error 1 warning Given the kind of content now being generated in STDERR, it looks more like a bug than an intentional change, but I wanted to check here first before filing a JBS issue. Is this an intentional change? [1] https://jdk.java.net/17/ -Jaikiran From jonathan.gibbons at oracle.com Tue Jun 15 14:41:52 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 15 Jun 2021 07:41:52 -0700 Subject: JDK 17 EA build 26 - javadoc tool now writes message to STDERR instead of STDOUT? In-Reply-To: <15f90207-8c8e-6ffd-afd8-885e1970263c@gmail.com> References: <15f90207-8c8e-6ffd-afd8-885e1970263c@gmail.com> Message-ID: <09ebac8a-3e2d-a14f-fe4f-8ebee3017799@oracle.com> Jaikiran, This was an intentional change, as part of an effort to align javadoc diagnostics and use of streams with javac. The general policy is that STDOUT should be used when the command and options specify to generate output ... such as the command-line help generated by the `--help` option or the version info generated by `--version`.??? STDERR should be used for diagnostics and other incidental "chatty" logging messages like `Generating ...` The purpose is that STDOUT may be used to pipe output to other commands and should not be "polluted" by diagnostics and logging messages. This is generally described here: https://en.wikipedia.org/wiki/Standard_streams -- Jon On 6/14/21 9:55 PM, Jaikiran Pai wrote: > While testing the Apache Ant project with the latest released JDK 17 > EA (build 26)[1], we have run into an unexpected test failure in our > project. The test is pretty simple. It launches the javadoc task and > passes it a Java source file which has javadoc content which is > expected to raise a warning message. Something like: > > package test; > > /** > ?* This is a test class. > ?*/ > public class Foo { > ??? /** > ???? * With a test method. > ???? * @param baz wrong parameter name should cause warning. > ???? */ > ??? public void foo(String bar) {} > > } > > The test then expects the javadoc tool/command to print a message of > the form "1 warning" to the STDOUT of the launced javadoc process. Of > course, other log messages are also logged to that STDOUT by the tool. > > In JDK version 8, 11 and even 16, this all works as expected and the > test passes. However, this latest JDK 17 EA, it fails because it > doesn't find this message on the STDOUT of the process. I looked into > this in a bit more detail and it looks like the javadoc command/tool > is now writing this message to the STDERR of the process. Not just > that, it also looks like the tool is now writing a lot other messages > to STDERR, which previously were written to STDOUT. > > To give you can example, if you directly run the javadoc command from > JDK 16 and JDK 17 EA build against the above trivial code, you will > see that in JDK 16, the following were logged to STDOUT: > > Loading source file Foo.java... > Constructing Javadoc information... > Building index for all the packages and classes... > Standard Doclet version 16+36-2231 > Building tree for all the packages and classes... > Generating ./test/Foo.html... > Generating ./test/package-summary.html... > Generating ./test/package-tree.html... > Generating ./overview-tree.html... > Building index for all classes... > Generating ./allclasses-index.html... > Generating ./allpackages-index.html... > Generating ./index-all.html... > Generating ./index.html... > Generating ./help-doc.html... > 1 error > 1 warning > > and JDK 16 STDERR only had: > > Foo.java:9: error: @param name not found > ???? * @param baz wrong parameter name should cause warning. > ????????????? ^ > Foo.java:11: warning: no @param for bar > ??? public void foo(String bar) {} > > > Now in JDK 17 EA, the same command generates the following STDOUT: > > Loading source file Foo.java... > Constructing Javadoc information... > > and this STDERR: > > Building index for all the packages and classes... > Standard Doclet version 17-ea+26-2439 > Building tree for all the packages and classes... > Generating ./test/Foo.html... > Foo.java:9: error: @param name not found > ???? * @param baz wrong parameter name should cause warning. > ????????????? ^ > Foo.java:11: warning: no @param for bar > ??? public void foo(String bar) {} > ??????????????? ^ > Generating ./test/package-summary.html... > Generating ./test/package-tree.html... > Generating ./overview-tree.html... > Building index for all classes... > Generating ./allclasses-index.html... > Generating ./allpackages-index.html... > Generating ./index-all.html... > Generating ./index.html... > Generating ./help-doc.html... > 1 error > 1 warning > > Given the kind of content now being generated in STDERR, it looks more > like a bug than an intentional change, but I wanted to check here > first before filing a JBS issue. Is this an intentional change? > > [1] https://jdk.java.net/17/ > > -Jaikiran > > From vromero at openjdk.java.net Tue Jun 15 14:43:44 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 15 Jun 2021 14:43:44 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint [v2] In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 11:38:14 GMT, Joel Borggr?n-Franck wrote: >> Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed. >> >> This proposed fix checks references at parse time to disallow annotated types instead of crashing later on. >> >> Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong. >> >> Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18. > > Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: > > 8266082: Use nodynamiccopyright and add test cases test/langtools/tools/doclint/CrashInAnnotateTest.out line 4: > 2: CrashInAnnotateTest.java:14:5: compiler.err.proc.messager: annotations not allowed > 3: CrashInAnnotateTest.java:16:10: compiler.warn.proc.messager: no comment > 4: CrashInAnnotateTest.java:19:5: compiler.err.proc.messager: syntax error in reference I think that this errors are because the annotation is fully qualified ------------- PR: https://git.openjdk.java.net/jdk/pull/4483 From hannesw at openjdk.java.net Tue Jun 15 14:49:42 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Jun 2021 14:49:42 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 13:43:40 GMT, Hannes Walln?fer wrote: > This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. > > Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. I've taken the time to run the benchmarks as well as I can, with no other apps running. I also ran it for the regression and the commit before the regression. As it turns out, the original performance loss is almost exactly the same as the improvement with the proposed fix. As to why my numbers are so different to the ones reported by Eric in JBS I don't know, but I guess there are a lot of variables (hardware, OS, command line options). commit 8cfea7c523fdda1375dc74bfc3a1042d45f2188e (before regression) Result "execute": 276,936 ?(99.9%) 2,292 ms/op [Average] (min, avg, max) = (269,618, 276,936, 286,777), stdev = 4,075 CI (99.9%): [274,644, 279,228] (assumes normal distribution) commit a5c4b9a6b078b12596e3e31f7f67e82f17181fdb (regression) Result "execute": 287,666 ?(99.9%) 2,187 ms/op [Average] (min, avg, max) = (279,349, 287,666, 293,730), stdev = 3,887 CI (99.9%): [285,480, 289,853] (assumes normal distribution) commit fe48ea9d7975188853bc165ce29789753f4758f2 (before proposed fix) Result "execute": 288,385 ?(99.9%) 1,498 ms/op [Average] (min, avg, max) = (284,871, 288,385, 296,769), stdev = 2,663 CI (99.9%): [286,887, 289,883] (assumes normal distribution) commit f6c876e472f82b8ff74e94e4e4d043bfaf145c4c (proposed fix) Result "execute": 276,643 ?(99.9%) 1,558 ms/op [Average] (min, avg, max) = (271,067, 276,643, 282,503), stdev = 2,770 CI (99.9%): [275,085, 278,201] (assumes normal distribution) ------------- PR: https://git.openjdk.java.net/jdk17/pull/42 From vromero at openjdk.java.net Tue Jun 15 14:56:38 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 15 Jun 2021 14:56:38 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 13:43:40 GMT, Hannes Walln?fer wrote: > This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. > > Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/42 From jonathan.gibbons at oracle.com Tue Jun 15 15:05:01 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 15 Jun 2021 08:05:01 -0700 Subject: JDK 17 EA build 26 - javadoc tool now writes message to STDERR instead of STDOUT? In-Reply-To: <09ebac8a-3e2d-a14f-fe4f-8ebee3017799@oracle.com> References: <15f90207-8c8e-6ffd-afd8-885e1970263c@gmail.com> <09ebac8a-3e2d-a14f-fe4f-8ebee3017799@oracle.com> Message-ID: Jaikiran, Someone noted a detail in your message, that some "chatty" logging messages were still being generated to STDOUT. That is a bug that needs to be addressed. -- Jon On 6/15/21 7:41 AM, Jonathan Gibbons wrote: > Jaikiran, > > This was an intentional change, as part of an effort to align javadoc > diagnostics and use of streams with javac. > > The general policy is that STDOUT should be used when the command and > options specify to generate output ... such as the command-line help > generated by the `--help` option or the version info generated by > `--version`.??? STDERR should be used for diagnostics and other > incidental "chatty" logging messages like `Generating ...` > > The purpose is that STDOUT may be used to pipe output to other > commands and should not be "polluted" by diagnostics and logging > messages. This is generally described here: > https://en.wikipedia.org/wiki/Standard_streams > > -- Jon > > On 6/14/21 9:55 PM, Jaikiran Pai wrote: >> While testing the Apache Ant project with the latest released JDK 17 >> EA (build 26)[1], we have run into an unexpected test failure in our >> project. The test is pretty simple. It launches the javadoc task and >> passes it a Java source file which has javadoc content which is >> expected to raise a warning message. Something like: >> >> package test; >> >> /** >> ?* This is a test class. >> ?*/ >> public class Foo { >> ??? /** >> ???? * With a test method. >> ???? * @param baz wrong parameter name should cause warning. >> ???? */ >> ??? public void foo(String bar) {} >> >> } >> >> The test then expects the javadoc tool/command to print a message of >> the form "1 warning" to the STDOUT of the launced javadoc process. Of >> course, other log messages are also logged to that STDOUT by the tool. >> >> In JDK version 8, 11 and even 16, this all works as expected and the >> test passes. However, this latest JDK 17 EA, it fails because it >> doesn't find this message on the STDOUT of the process. I looked into >> this in a bit more detail and it looks like the javadoc command/tool >> is now writing this message to the STDERR of the process. Not just >> that, it also looks like the tool is now writing a lot other messages >> to STDERR, which previously were written to STDOUT. >> >> To give you can example, if you directly run the javadoc command from >> JDK 16 and JDK 17 EA build against the above trivial code, you will >> see that in JDK 16, the following were logged to STDOUT: >> >> Loading source file Foo.java... >> Constructing Javadoc information... >> Building index for all the packages and classes... >> Standard Doclet version 16+36-2231 >> Building tree for all the packages and classes... >> Generating ./test/Foo.html... >> Generating ./test/package-summary.html... >> Generating ./test/package-tree.html... >> Generating ./overview-tree.html... >> Building index for all classes... >> Generating ./allclasses-index.html... >> Generating ./allpackages-index.html... >> Generating ./index-all.html... >> Generating ./index.html... >> Generating ./help-doc.html... >> 1 error >> 1 warning >> >> and JDK 16 STDERR only had: >> >> Foo.java:9: error: @param name not found >> ???? * @param baz wrong parameter name should cause warning. >> ????????????? ^ >> Foo.java:11: warning: no @param for bar >> ??? public void foo(String bar) {} >> >> >> Now in JDK 17 EA, the same command generates the following STDOUT: >> >> Loading source file Foo.java... >> Constructing Javadoc information... >> >> and this STDERR: >> >> Building index for all the packages and classes... >> Standard Doclet version 17-ea+26-2439 >> Building tree for all the packages and classes... >> Generating ./test/Foo.html... >> Foo.java:9: error: @param name not found >> ???? * @param baz wrong parameter name should cause warning. >> ????????????? ^ >> Foo.java:11: warning: no @param for bar >> ??? public void foo(String bar) {} >> ??????????????? ^ >> Generating ./test/package-summary.html... >> Generating ./test/package-tree.html... >> Generating ./overview-tree.html... >> Building index for all classes... >> Generating ./allclasses-index.html... >> Generating ./allpackages-index.html... >> Generating ./index-all.html... >> Generating ./index.html... >> Generating ./help-doc.html... >> 1 error >> 1 warning >> >> Given the kind of content now being generated in STDERR, it looks >> more like a bug than an intentional change, but I wanted to check >> here first before filing a JBS issue. Is this an intentional change? >> >> [1] https://jdk.java.net/17/ >> >> -Jaikiran >> >> From jonathan.gibbons at oracle.com Tue Jun 15 15:16:51 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 15 Jun 2021 08:16:51 -0700 Subject: JDK 17 EA build 26 - javadoc tool now writes message to STDERR instead of STDOUT? In-Reply-To: References: <15f90207-8c8e-6ffd-afd8-885e1970263c@gmail.com> <09ebac8a-3e2d-a14f-fe4f-8ebee3017799@oracle.com> Message-ID: <33693ab4-96a4-a2b9-ceec-d213cc99b9cd@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8268774 -- Jon On 6/15/21 8:05 AM, Jonathan Gibbons wrote: > Jaikiran, > > Someone noted a detail in your message, that some "chatty" logging > messages were still being generated to STDOUT. That is a bug that > needs to be addressed. > > -- Jon > > On 6/15/21 7:41 AM, Jonathan Gibbons wrote: >> Jaikiran, >> >> This was an intentional change, as part of an effort to align javadoc >> diagnostics and use of streams with javac. >> >> The general policy is that STDOUT should be used when the command and >> options specify to generate output ... such as the command-line help >> generated by the `--help` option or the version info generated by >> `--version`.??? STDERR should be used for diagnostics and other >> incidental "chatty" logging messages like `Generating ...` >> >> The purpose is that STDOUT may be used to pipe output to other >> commands and should not be "polluted" by diagnostics and logging >> messages. This is generally described here: >> https://en.wikipedia.org/wiki/Standard_streams >> >> -- Jon >> >> On 6/14/21 9:55 PM, Jaikiran Pai wrote: >>> While testing the Apache Ant project with the latest released JDK 17 >>> EA (build 26)[1], we have run into an unexpected test failure in our >>> project. The test is pretty simple. It launches the javadoc task and >>> passes it a Java source file which has javadoc content which is >>> expected to raise a warning message. Something like: >>> >>> package test; >>> >>> /** >>> ?* This is a test class. >>> ?*/ >>> public class Foo { >>> ??? /** >>> ???? * With a test method. >>> ???? * @param baz wrong parameter name should cause warning. >>> ???? */ >>> ??? public void foo(String bar) {} >>> >>> } >>> >>> The test then expects the javadoc tool/command to print a message of >>> the form "1 warning" to the STDOUT of the launced javadoc process. >>> Of course, other log messages are also logged to that STDOUT by the >>> tool. >>> >>> In JDK version 8, 11 and even 16, this all works as expected and the >>> test passes. However, this latest JDK 17 EA, it fails because it >>> doesn't find this message on the STDOUT of the process. I looked >>> into this in a bit more detail and it looks like the javadoc >>> command/tool is now writing this message to the STDERR of the >>> process. Not just that, it also looks like the tool is now writing a >>> lot other messages to STDERR, which previously were written to STDOUT. >>> >>> To give you can example, if you directly run the javadoc command >>> from JDK 16 and JDK 17 EA build against the above trivial code, you >>> will see that in JDK 16, the following were logged to STDOUT: >>> >>> Loading source file Foo.java... >>> Constructing Javadoc information... >>> Building index for all the packages and classes... >>> Standard Doclet version 16+36-2231 >>> Building tree for all the packages and classes... >>> Generating ./test/Foo.html... >>> Generating ./test/package-summary.html... >>> Generating ./test/package-tree.html... >>> Generating ./overview-tree.html... >>> Building index for all classes... >>> Generating ./allclasses-index.html... >>> Generating ./allpackages-index.html... >>> Generating ./index-all.html... >>> Generating ./index.html... >>> Generating ./help-doc.html... >>> 1 error >>> 1 warning >>> >>> and JDK 16 STDERR only had: >>> >>> Foo.java:9: error: @param name not found >>> ???? * @param baz wrong parameter name should cause warning. >>> ????????????? ^ >>> Foo.java:11: warning: no @param for bar >>> ??? public void foo(String bar) {} >>> >>> >>> Now in JDK 17 EA, the same command generates the following STDOUT: >>> >>> Loading source file Foo.java... >>> Constructing Javadoc information... >>> >>> and this STDERR: >>> >>> Building index for all the packages and classes... >>> Standard Doclet version 17-ea+26-2439 >>> Building tree for all the packages and classes... >>> Generating ./test/Foo.html... >>> Foo.java:9: error: @param name not found >>> ???? * @param baz wrong parameter name should cause warning. >>> ????????????? ^ >>> Foo.java:11: warning: no @param for bar >>> ??? public void foo(String bar) {} >>> ??????????????? ^ >>> Generating ./test/package-summary.html... >>> Generating ./test/package-tree.html... >>> Generating ./overview-tree.html... >>> Building index for all classes... >>> Generating ./allclasses-index.html... >>> Generating ./allpackages-index.html... >>> Generating ./index-all.html... >>> Generating ./index.html... >>> Generating ./help-doc.html... >>> 1 error >>> 1 warning >>> >>> Given the kind of content now being generated in STDERR, it looks >>> more like a bug than an intentional change, but I wanted to check >>> here first before filing a JBS issue. Is this an intentional change? >>> >>> [1] https://jdk.java.net/17/ >>> >>> -Jaikiran >>> >>> From hannesw at openjdk.java.net Tue Jun 15 16:00:03 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Jun 2021 16:00:03 GMT Subject: [jdk17] Integrated: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 13:43:40 GMT, Hannes Walln?fer wrote: > This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. > > Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. This pull request has now been integrated. Changeset: 76cad4b1 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk17/commit/76cad4b1ae76c6cc854f7a901736bf108639f8f2 Stats: 22 lines in 7 files changed: 2 ins; 0 del; 20 mod 8263321: Regression 8% in javadoc-steady in 17-b11 Reviewed-by: prappo, vromero ------------- PR: https://git.openjdk.java.net/jdk17/pull/42 From hannesw at openjdk.java.net Tue Jun 15 16:00:02 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Jun 2021 16:00:02 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 [v2] In-Reply-To: References: Message-ID: > This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. > > Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8268557: Update year in copyright header ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/42/files - new: https://git.openjdk.java.net/jdk17/pull/42/files/f6c876e4..9e051e07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=42&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=42&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/42/head:pull/42 PR: https://git.openjdk.java.net/jdk17/pull/42 From jonathan.gibbons at oracle.com Tue Jun 15 16:16:03 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 15 Jun 2021 09:16:03 -0700 Subject: [External] : Re: JDK 17 EA build 26 - javadoc tool now writes message to STDERR instead of STDOUT? In-Reply-To: References: <15f90207-8c8e-6ffd-afd8-885e1970263c@gmail.com> <09ebac8a-3e2d-a14f-fe4f-8ebee3017799@oracle.com> Message-ID: <82f11955-2a66-72b4-4918-ec3fe2731a4c@oracle.com> Jaikiran, Both javac and javadoc provide various entry points. Some of those entry points take a single stream that is used for all output. You may find those helpful. -- Jon On 6/15/21 9:07 AM, Jaikiran Pai wrote: > Thank you for these details, Jon. I'll bring this up for discussion on > our Ant dev list to decide how we deal with this change to take into > account various JDK versions and difference in their behaviour. > > Thank you also for creating that JBS issue to address the part where > some diagnostic messages are still ending up in STDOUT. > > -Jaikiran > > On 15/06/21 8:11 pm, Jonathan Gibbons wrote: >> Jaikiran, >> >> This was an intentional change, as part of an effort to align javadoc >> diagnostics and use of streams with javac. >> >> The general policy is that STDOUT should be used when the command and >> options specify to generate output ... such as the command-line help >> generated by the `--help` option or the version info generated by >> `--version`.??? STDERR should be used for diagnostics and other >> incidental "chatty" logging messages like `Generating ...` >> >> The purpose is that STDOUT may be used to pipe output to other >> commands and should not be "polluted" by diagnostics and logging >> messages. This is generally described here: >> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Standard_streams__;!!GqivPVa7Brio!IDCS8t1LzsWEUK5PutT48IIehxxhhuuBPoUejOQ5chac2rS8qEJ2pvtvhkz5tFqOjqXtlw$ >> >> -- Jon >> >> On 6/14/21 9:55 PM, Jaikiran Pai wrote: >>> While testing the Apache Ant project with the latest released JDK 17 >>> EA (build 26)[1], we have run into an unexpected test failure in our >>> project. The test is pretty simple. It launches the javadoc task and >>> passes it a Java source file which has javadoc content which is >>> expected to raise a warning message. Something like: >>> >>> package test; >>> >>> /** >>> ?* This is a test class. >>> ?*/ >>> public class Foo { >>> ??? /** >>> ???? * With a test method. >>> ???? * @param baz wrong parameter name should cause warning. >>> ???? */ >>> ??? public void foo(String bar) {} >>> >>> } >>> >>> The test then expects the javadoc tool/command to print a message of >>> the form "1 warning" to the STDOUT of the launced javadoc process. >>> Of course, other log messages are also logged to that STDOUT by the >>> tool. >>> >>> In JDK version 8, 11 and even 16, this all works as expected and the >>> test passes. However, this latest JDK 17 EA, it fails because it >>> doesn't find this message on the STDOUT of the process. I looked >>> into this in a bit more detail and it looks like the javadoc >>> command/tool is now writing this message to the STDERR of the >>> process. Not just that, it also looks like the tool is now writing a >>> lot other messages to STDERR, which previously were written to STDOUT. >>> >>> To give you can example, if you directly run the javadoc command >>> from JDK 16 and JDK 17 EA build against the above trivial code, you >>> will see that in JDK 16, the following were logged to STDOUT: >>> >>> Loading source file Foo.java... >>> Constructing Javadoc information... >>> Building index for all the packages and classes... >>> Standard Doclet version 16+36-2231 >>> Building tree for all the packages and classes... >>> Generating ./test/Foo.html... >>> Generating ./test/package-summary.html... >>> Generating ./test/package-tree.html... >>> Generating ./overview-tree.html... >>> Building index for all classes... >>> Generating ./allclasses-index.html... >>> Generating ./allpackages-index.html... >>> Generating ./index-all.html... >>> Generating ./index.html... >>> Generating ./help-doc.html... >>> 1 error >>> 1 warning >>> >>> and JDK 16 STDERR only had: >>> >>> Foo.java:9: error: @param name not found >>> ???? * @param baz wrong parameter name should cause warning. >>> ????????????? ^ >>> Foo.java:11: warning: no @param for bar >>> ??? public void foo(String bar) {} >>> >>> >>> Now in JDK 17 EA, the same command generates the following STDOUT: >>> >>> Loading source file Foo.java... >>> Constructing Javadoc information... >>> >>> and this STDERR: >>> >>> Building index for all the packages and classes... >>> Standard Doclet version 17-ea+26-2439 >>> Building tree for all the packages and classes... >>> Generating ./test/Foo.html... >>> Foo.java:9: error: @param name not found >>> ???? * @param baz wrong parameter name should cause warning. >>> ????????????? ^ >>> Foo.java:11: warning: no @param for bar >>> ??? public void foo(String bar) {} >>> ??????????????? ^ >>> Generating ./test/package-summary.html... >>> Generating ./test/package-tree.html... >>> Generating ./overview-tree.html... >>> Building index for all classes... >>> Generating ./allclasses-index.html... >>> Generating ./allpackages-index.html... >>> Generating ./index-all.html... >>> Generating ./index.html... >>> Generating ./help-doc.html... >>> 1 error >>> 1 warning >>> >>> Given the kind of content now being generated in STDERR, it looks >>> more like a bug than an intentional change, but I wanted to check >>> here first before filing a JBS issue. Is this an intentional change? >>> >>> [1] >>> https://urldefense.com/v3/__https://jdk.java.net/17/__;!!GqivPVa7Brio!IDCS8t1LzsWEUK5PutT48IIehxxhhuuBPoUejOQ5chac2rS8qEJ2pvtvhkz5tFoPOSiZYg$ >>> >>> -Jaikiran >>> >>> From jjg at openjdk.java.net Tue Jun 15 16:45:46 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 15 Jun 2021 16:45:46 GMT Subject: [jdk17] RFR: JDK-8263321: Regression 8% in javadoc-steady in 17-b11 [v2] In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 16:00:02 GMT, Hannes Walln?fer wrote: >> This change fixes a performance regression caused by passing instances of `com.sun.tools.javac.util.Name` to a `html.markup.Text` object, where their content is accessed using`CharSequence` methods which are implemented very inefficiently. >> >> Since improving `javac.util.Name` will likely require a bit more work (see JDK-8268622), a safe short term solution for JDK 17 is to make sure instances of `Name` are converted to `String` before invoking said `CharSequence` methods. The main fix is to convert to `String` early in `Entity.escapeHtmlChars(CharSequence)` which is invoked by the `Text` constructor. There are a few more `.toString()` invocations added in places where a `Name` is appended to a `StringBuilder`, although these have less performance impact. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8268557: Update year in copyright header This is OK as a short-term fix. I hope we can revert it when the underlying problem in `Name`is fixed. ------------- PR: https://git.openjdk.java.net/jdk17/pull/42 From jwilhelm at openjdk.java.net Tue Jun 15 22:01:09 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:01:09 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge jdk17 - 8268768: idea.sh has been updated in surprising and incompatible ways - 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64 - 8268723: Problem list SA core file tests on OSX when using ZGC - 8268736: Use apiNote in AutoCloseable.close javadoc - 8263321: Regression 8% in javadoc-steady in 17-b11 - 8268125: ZGC: Clone oop array gets wrong acopy stub - 8268663: Crash when guards contain boolean expression - 8268347: C2: nested locks optimization may create unbalanced monitor enter/exit code - 8268643: SVML lib shouldn't be generated when C2 is absent - ... and 7 more: https://git.openjdk.java.net/jdk/compare/0b09129f...e748b877 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4499/files Stats: 1606 lines in 62 files changed: 1180 ins; 181 del; 245 mod Patch: https://git.openjdk.java.net/jdk/pull/4499.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4499/head:pull/4499 PR: https://git.openjdk.java.net/jdk/pull/4499 From jjg at openjdk.java.net Tue Jun 15 22:28:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 15 Jun 2021 22:28:04 GMT Subject: [jdk17] RFR: JDK-8268774: Residual logging output written to STDOUT, not STDERR Message-ID: Please review an interim minimal fix to write logging messages from the javadoc tool to STDERR, not STDOUT. Recent work focussed on the use of the `Reporter` API in doclets, including the standard doclet. This patch aligns the tool code with the same policies as used in the doclet (and indirectly, in javac.) Given we're in RDP1, the fix is intentionally minimal. The direct use of JavadocLog.printRawLines is a definite code-smell, and the `notice` methods in `ToolEnvironment` are seemingly obsolete and could be replaced by more appropriate API in `JavadocLog`. JDK-8268831 is a follow-up issue to address these issues. ------------- Commit messages: - JDK-8268774: Residual logging output written to STDOUT, not STDERR Changes: https://git.openjdk.java.net/jdk17/pull/68/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=68&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268774 Stats: 131 lines in 5 files changed: 123 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk17/pull/68.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/68/head:pull/68 PR: https://git.openjdk.java.net/jdk17/pull/68 From jwilhelm at openjdk.java.net Tue Jun 15 22:49:40 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:49:40 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson 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 25 additional commits since the last revision: - Merge jdk17 - 8268620: InfiniteLoopException test may fail on x86 platforms Reviewed-by: prr, trebari, azvegint - 8268125: ZGC: Clone oop array gets wrong acopy stub Reviewed-by: kvn, vlivanov - 8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name Co-authored-by: Markus GaisBauer Reviewed-by: stuefe, luhenry - 8268626: Remove native pre-jdk9 support for jtreg failure handler Reviewed-by: erikj - 8268699: Shenandoah: Add test for JDK-8268127 Reviewed-by: rkennke - Merge Reviewed-by: dcubed - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" Reviewed-by: prr - 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow Reviewed-by: dcubed, stefank, kbarrett - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException Reviewed-by: darcy, jfranck - ... and 15 more: https://git.openjdk.java.net/jdk/compare/6da37cd0...e748b877 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4499/files - new: https://git.openjdk.java.net/jdk/pull/4499/files/e748b877..e748b877 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4499.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4499/head:pull/4499 PR: https://git.openjdk.java.net/jdk/pull/4499 From jwilhelm at openjdk.java.net Tue Jun 15 22:49:41 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:49:41 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 21:51:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: e0f6f70d Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/e0f6f70d3f9e748d2bc53f371beca487e9343d4a Stats: 1606 lines in 62 files changed: 1180 ins; 181 del; 245 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4499 From jfranck at openjdk.java.net Wed Jun 16 07:13:06 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 16 Jun 2021 07:13:06 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint [v3] In-Reply-To: References: Message-ID: > Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed. > > This proposed fix checks references at parse time to disallow annotated types instead of crashing later on. > > Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong. > > Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18. Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: 8266082: Review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4483/files - new: https://git.openjdk.java.net/jdk/pull/4483/files/8c387d12..b7953cff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4483&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4483&range=01-02 Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4483/head:pull/4483 PR: https://git.openjdk.java.net/jdk/pull/4483 From jfranck at openjdk.java.net Wed Jun 16 07:30:14 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 16 Jun 2021 07:30:14 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint [v2] In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 14:40:51 GMT, Vicente Romero wrote: >> Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: >> >> 8266082: Use nodynamiccopyright and add test cases > > test/langtools/tools/doclint/CrashInAnnotateTest.out line 4: > >> 2: CrashInAnnotateTest.java:14:5: compiler.err.proc.messager: annotations not allowed >> 3: CrashInAnnotateTest.java:16:10: compiler.warn.proc.messager: no comment >> 4: CrashInAnnotateTest.java:19:5: compiler.err.proc.messager: syntax error in reference > > I think that these syntax errors are because the annotation is fully qualified, you should use `@Deprecated` instead of `java.lang. at Deprecated` Yes and no. The parts other than the arguments are parsed in a different way that doesn't allow a space, see DocCommentParser.java:417 . Since there can be no space it is impossible to insert a type annotation in a type. I have updated the test with a few more examples. I'm not looking to unify parsing in this PR, IMO it is enough to 1) not crash and 2) provide a friendly message. ------------- PR: https://git.openjdk.java.net/jdk/pull/4483 From jfranck at openjdk.java.net Wed Jun 16 07:30:09 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 16 Jun 2021 07:30:09 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint [v4] In-Reply-To: References: Message-ID: > Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed. > > This proposed fix checks references at parse time to disallow annotated types instead of crashing later on. > > Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong. > > Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18. Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: 8266082: Test more cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4483/files - new: https://git.openjdk.java.net/jdk/pull/4483/files/b7953cff..06557813 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4483&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4483&range=02-03 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4483/head:pull/4483 PR: https://git.openjdk.java.net/jdk/pull/4483 From prappo at openjdk.java.net Wed Jun 16 12:52:34 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 16 Jun 2021 12:52:34 GMT Subject: [jdk17] RFR: JDK-8268774: Residual logging output written to STDOUT, not STDERR In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 22:18:40 GMT, Jonathan Gibbons wrote: > Please review an interim minimal fix to write logging messages from the javadoc tool to STDERR, not STDOUT. > > Recent work focussed on the use of the `Reporter` API in doclets, including the standard doclet. This patch aligns the tool code with the same policies as used in the doclet (and indirectly, in javac.) > > Given we're in RDP1, the fix is intentionally minimal. The direct use of JavadocLog.printRawLines is a definite code-smell, and the `notice` methods in `ToolEnvironment` are seemingly obsolete and could be replaced by more appropriate API in `JavadocLog`. JDK-8268831 is a follow-up issue to address these issues. Please update the copyright years before integrating. The change looks good; in particular, thanks for filing a follow-up refactoring issue JDK-8268831. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/68 From hannesw at openjdk.java.net Wed Jun 16 12:57:40 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 16 Jun 2021 12:57:40 GMT Subject: [jdk17] RFR: JDK-8268774: Residual logging output written to STDOUT, not STDERR In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 22:18:40 GMT, Jonathan Gibbons wrote: > Please review an interim minimal fix to write logging messages from the javadoc tool to STDERR, not STDOUT. > > Recent work focussed on the use of the `Reporter` API in doclets, including the standard doclet. This patch aligns the tool code with the same policies as used in the doclet (and indirectly, in javac.) > > Given we're in RDP1, the fix is intentionally minimal. The direct use of JavadocLog.printRawLines is a definite code-smell, and the `notice` methods in `ToolEnvironment` are seemingly obsolete and could be replaced by more appropriate API in `JavadocLog`. JDK-8268831 is a follow-up issue to address these issues. Looks good to me. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/68 From prappo at openjdk.java.net Wed Jun 16 13:46:36 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 16 Jun 2021 13:46:36 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node In-Reply-To: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: <0HsfNo1LN3LljOCfd4u4H9qmEXMVtF3NC03jbv6qcS0=.44051c45-065e-4a17-a67a-fca5fe9d267d@github.com> On Mon, 14 Jun 2021 21:45:11 GMT, Jonathan Gibbons wrote: > Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. > > This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. > > The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. > > There are some cosmetic cleanups that were made while exploring the current solution. > > The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. Please synchronize the code snippet from the CSR with that of this PR: the method in this PR is neither `default` nor has an `@implNote`. Also, update the copyright years. ------------- Changes requested by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4489 From vromero at openjdk.java.net Wed Jun 16 15:21:39 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 16 Jun 2021 15:21:39 GMT Subject: RFR: 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint [v4] In-Reply-To: References: Message-ID: <0T342btEWIAXsGn3cnOH0anr4Ihm_PHrlPD0KpS19i0=.f6b6eba6-63d4-4023-ab94-7527ee237d9d@github.com> On Wed, 16 Jun 2021 07:30:09 GMT, Joel Borggr?n-Franck wrote: >> Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed. >> >> This proposed fix checks references at parse time to disallow annotated types instead of crashing later on. >> >> Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong. >> >> Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18. > > Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: > > 8266082: Test more cases looks good, thanks ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4483 From rick.hillegas at gmail.com Wed Jun 16 16:45:37 2021 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Wed, 16 Jun 2021 09:45:37 -0700 Subject: javadoc crash on JDK 11 caused by @SuppressWarnings annotations Message-ID: <366f00ae-5532-68cc-8a67-43dcb990904d@gmail.com> I work on Apache Derby. Derby is one of the applications which receive advance notice of new Open JDK distributions. We then build our application with the new JDK's javac and javadoc tools and we run our full test suite against the new JVM. As a canary in the mineshaft, we noticed the following significant disruption. When I tried to build Derby with the Rampdown Phase One build of open JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation of Security Manager classes and methods, undoubtedly the consequence of JEP 411 (https://openjdk.java.net/jeps/411). In a security-dev at openjdk.java.net email thread titled "blizzard of deprecation warnings related to JEP 411", Alan Bateman recommended that we decorate the warned usages with @SuppressWarnings("removal") annotations, as the Open JDK's own code does. That does silence the warnings. I can then cleanly build the Derby javadoc using 17-ea+26-2439. However, when I run javadoc on the annotated code using OpenJDK Runtime Environment 18.9 (build 11+28), the JDK 11 javadoc tool dies with the following stack trace: ? [javadoc] javadoc: error - An internal exception has occurred. ? [javadoc] ??? (java.lang.OutOfMemoryError: Java heap space) ? [javadoc] Please file a bug against the javadoc tool via the Java bug reporting page ? [javadoc] (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) ? [javadoc] for duplicates. Include error messages and the following diagnostic in your report. Thank you. ? [javadoc] java.lang.OutOfMemoryError: Java heap space ? [javadoc] ??? at java.base/java.util.Arrays.copyOf(Arrays.java:3745) ? [javadoc] ??? at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:888) ? [javadoc] ??? at java.base/java.lang.StringCoding.encode(StringCoding.java:489) ? [javadoc] ??? at java.base/java.lang.String.getBytes(String.java:981) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.AbstractIndexWriter.createSearchIndexFile(AbstractIndexWriter.java:501) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.AbstractIndexWriter.createSearchIndexFiles(AbstractIndexWriter.java:456) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:133) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:85) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:147) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:213) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.run(AbstractDoclet.java:114) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.doclet.StandardDoclet.run(StandardDoclet.java:72) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:582) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:431) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:344) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63) ? [javadoc] ??? at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52) Is this a known problem with a known mitigation or should I file a javadoc bug for this? Thanks, -Rick From pavel.rappo at oracle.com Wed Jun 16 17:16:32 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 16 Jun 2021 17:16:32 +0000 Subject: javadoc crash on JDK 11 caused by @SuppressWarnings annotations In-Reply-To: <366f00ae-5532-68cc-8a67-43dcb990904d@gmail.com> References: <366f00ae-5532-68cc-8a67-43dcb990904d@gmail.com> Message-ID: I haven't heard of this problem. Filing a bug seems the right thing to do. Please provide as much of the relevant information as you can. For example: what options you run javadoc with, what happens if you run javadoc from the same JDK 17 (17-ea+26-2439), how many annotations and where you have added, what the source-lines-of-code count of the project is, etc. -Pavel > On 16 Jun 2021, at 17:45, Rick Hillegas wrote: > > I work on Apache Derby. Derby is one of the applications which receive advance notice of new Open JDK distributions. We then build our application with the new JDK's javac and javadoc tools and we run our full test suite against the new JVM. As a canary in the mineshaft, we noticed the following significant disruption. > > When I tried to build Derby with the Rampdown Phase One build of open JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation of Security Manager classes and methods, undoubtedly the consequence of JEP 411 (https://openjdk.java.net/jeps/411). In a security-dev at openjdk.java.net email thread titled "blizzard of deprecation warnings related to JEP 411", Alan Bateman recommended that we decorate the warned usages with @SuppressWarnings("removal") annotations, as the Open JDK's own code does. That does silence the warnings. I can then cleanly build the Derby javadoc using 17-ea+26-2439. > > However, when I run javadoc on the annotated code using OpenJDK Runtime Environment 18.9 (build 11+28), the JDK 11 javadoc tool dies with the following stack trace: > > [javadoc] javadoc: error - An internal exception has occurred. > [javadoc] (java.lang.OutOfMemoryError: Java heap space) > [javadoc] Please file a bug against the javadoc tool via the Java bug reporting page > [javadoc] (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) > [javadoc] for duplicates. Include error messages and the following diagnostic in your report. Thank you. > [javadoc] java.lang.OutOfMemoryError: Java heap space > [javadoc] at java.base/java.util.Arrays.copyOf(Arrays.java:3745) > [javadoc] at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:888) > [javadoc] at java.base/java.lang.StringCoding.encode(StringCoding.java:489) > [javadoc] at java.base/java.lang.String.getBytes(String.java:981) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.AbstractIndexWriter.createSearchIndexFile(AbstractIndexWriter.java:501) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.AbstractIndexWriter.createSearchIndexFiles(AbstractIndexWriter.java:456) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:133) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:85) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:147) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:213) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.run(AbstractDoclet.java:114) > [javadoc] at jdk.javadoc/jdk.javadoc.doclet.StandardDoclet.run(StandardDoclet.java:72) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:582) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:431) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:344) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63) > [javadoc] at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52) > > Is this a known problem with a known mitigation or should I file a javadoc bug for this? > > Thanks, > -Rick > From jjg at openjdk.java.net Wed Jun 16 17:18:31 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 16 Jun 2021 17:18:31 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node [v2] In-Reply-To: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: > Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. > > This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. > > The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. > > There are some cosmetic cleanups that were made while exploring the current solution. > > The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. 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/4489/files - new: https://git.openjdk.java.net/jdk/pull/4489/files/64131f6d..e3d9721b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=00-01 Stats: 11 lines in 4 files changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4489/head:pull/4489 PR: https://git.openjdk.java.net/jdk/pull/4489 From jjg at openjdk.java.net Wed Jun 16 17:52:22 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 16 Jun 2021 17:52:22 GMT Subject: [jdk17] RFR: JDK-8268774: Residual logging output written to STDOUT, not STDERR [v2] In-Reply-To: References: Message-ID: > Please review an interim minimal fix to write logging messages from the javadoc tool to STDERR, not STDOUT. > > Recent work focussed on the use of the `Reporter` API in doclets, including the standard doclet. This patch aligns the tool code with the same policies as used in the doclet (and indirectly, in javac.) > > Given we're in RDP1, the fix is intentionally minimal. The direct use of JavadocLog.printRawLines is a definite code-smell, and the `notice` methods in `ToolEnvironment` are seemingly obsolete and could be replaced by more appropriate API in `JavadocLog`. JDK-8268831 is a follow-up issue to address these issues. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: update copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/68/files - new: https://git.openjdk.java.net/jdk17/pull/68/files/cb28d35f..b48f3033 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=68&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=68&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/68.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/68/head:pull/68 PR: https://git.openjdk.java.net/jdk17/pull/68 From jjg at openjdk.java.net Wed Jun 16 18:07:23 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 16 Jun 2021 18:07:23 GMT Subject: [jdk17] Integrated: JDK-8268774: Residual logging output written to STDOUT, not STDERR In-Reply-To: References: Message-ID: <4ADvtmrnXsouaamX6QyJ54z52qF6E8cGAb6dAAG-BBU=.601794f0-a6e2-4822-a477-613e2a215510@github.com> On Tue, 15 Jun 2021 22:18:40 GMT, Jonathan Gibbons wrote: > Please review an interim minimal fix to write logging messages from the javadoc tool to STDERR, not STDOUT. > > Recent work focussed on the use of the `Reporter` API in doclets, including the standard doclet. This patch aligns the tool code with the same policies as used in the doclet (and indirectly, in javac.) > > Given we're in RDP1, the fix is intentionally minimal. The direct use of JavadocLog.printRawLines is a definite code-smell, and the `notice` methods in `ToolEnvironment` are seemingly obsolete and could be replaced by more appropriate API in `JavadocLog`. JDK-8268831 is a follow-up issue to address these issues. This pull request has now been integrated. Changeset: 2c7e47e1 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk17/commit/2c7e47e12b8a772bcebcdf0b15d6a4d3f92e2267 Stats: 133 lines in 5 files changed: 123 ins; 0 del; 10 mod 8268774: Residual logging output written to STDOUT, not STDERR Reviewed-by: prappo, hannesw ------------- PR: https://git.openjdk.java.net/jdk17/pull/68 From jjg at openjdk.java.net Wed Jun 16 23:38:00 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 16 Jun 2021 23:38:00 GMT Subject: [jdk17] RFR: JDK-8264843: Javac crashes with NullPointerException when finding unencoded XML in

     tag
    Message-ID: 
    
    Please review a simple fix for an NPE in doclint, in JDK 17.
    
    The NPE is caused by checking if an unknown tag is self-closing. The fix is to move the check into the arm of the preceding `if` statement that ensures that the tags is not null.   Effectively, we do not valid whether unknown tags may be self-closing.
    
    The potential for the NPE has been there a long time. The check that triggers the NPE became more likely when we removed support for HTML4.
    
    -------------
    
    Commit messages:
     - JDK-8264843: Javac crashes with NullPointerException when finding unencoded XML in 
     tag
    
    Changes: https://git.openjdk.java.net/jdk17/pull/86/files
     Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=86&range=00
      Issue: https://bugs.openjdk.java.net/browse/JDK-8264843
      Stats: 32 lines in 3 files changed: 28 ins; 1 del; 3 mod
      Patch: https://git.openjdk.java.net/jdk17/pull/86.diff
      Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/86/head:pull/86
    
    PR: https://git.openjdk.java.net/jdk17/pull/86
    
    From jwilhelm at openjdk.java.net  Thu Jun 17 00:57:15 2021
    From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
    Date: Thu, 17 Jun 2021 00:57:15 GMT
    Subject: RFR: Merge jdk17
    Message-ID: 
    
    Forwardport JDK 17 -> JDK 18
    
    -------------
    
    Commit messages:
     - Merge
     - 8260194: Update the documentation for -Xcheck:jni
     - 8268863: ProblemList serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC
     - 8268909: ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64
     - 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test
     - 8268774: Residual logging output written to STDOUT, not STDERR
     - 8268714: [macos-aarch64] 7 java/net/httpclient/websocket tests failed
     - 8268901: JDK-8268768 missed removing two files
     - 8256934: C2: assert(C->live_nodes() <= C->max_node_limit()) failed: Live Node limit exceeded limit
     - 8268861: Disable Windows-Aarch64 build in GitHub Actions
     - ... and 4 more: https://git.openjdk.java.net/jdk/compare/02c9bf08...c47ba95e
    
    The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.
    
    Changes: https://git.openjdk.java.net/jdk/pull/4514/files
      Stats: 659 lines in 33 files changed: 450 ins; 121 del; 88 mod
      Patch: https://git.openjdk.java.net/jdk/pull/4514.diff
      Fetch: git fetch https://git.openjdk.java.net/jdk pull/4514/head:pull/4514
    
    PR: https://git.openjdk.java.net/jdk/pull/4514
    
    From jwilhelm at openjdk.java.net  Thu Jun 17 01:11:25 2021
    From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
    Date: Thu, 17 Jun 2021 01:11:25 GMT
    Subject: RFR: Merge jdk17 [v2]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Forwardport JDK 17 -> JDK 18
    
    Jesper Wilhelmsson 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 35 additional commits since the last revision:
    
     - Merge
     - 8268852: AsyncLogWriter should not overide is_Named_thread()
       
       Reviewed-by: dholmes, ysuenaga
     - 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test
       
       Reviewed-by: xuelei
     - 8259066: Obsolete -XX:+AlwaysLockClassLoader
       
       Reviewed-by: hseigel
     - 8268778: CDS check_excluded_classes needs DumpTimeTable_lock
       
       Reviewed-by: ccheung, minqi
     - 8267752: KVHashtable doesn't deallocate entries
       
       Reviewed-by: iklam, stuefe
     - 8267870: Remove unnecessary char_converter during class loading
       
       Reviewed-by: dholmes, iklam
     - 8268078: ClassListParser::_interfaces should be freed
       
       Reviewed-by: minqi, iklam, coleenp
     - 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated '
       
       Reviewed-by: cjplummer, zgu, dcubed
     - Merge
     - ... and 25 more: https://git.openjdk.java.net/jdk/compare/fdaabfed...c47ba95e
    
    -------------
    
    Changes:
      - all: https://git.openjdk.java.net/jdk/pull/4514/files
      - new: https://git.openjdk.java.net/jdk/pull/4514/files/c47ba95e..c47ba95e
    
    Webrevs:
     - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4514&range=01
     - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4514&range=00-01
    
      Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
      Patch: https://git.openjdk.java.net/jdk/pull/4514.diff
      Fetch: git fetch https://git.openjdk.java.net/jdk pull/4514/head:pull/4514
    
    PR: https://git.openjdk.java.net/jdk/pull/4514
    
    From jwilhelm at openjdk.java.net  Thu Jun 17 01:11:26 2021
    From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
    Date: Thu, 17 Jun 2021 01:11:26 GMT
    Subject: Integrated: Merge jdk17
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Thu, 17 Jun 2021 00:49:27 GMT, Jesper Wilhelmsson  wrote:
    
    > Forwardport JDK 17 -> JDK 18
    
    This pull request has now been integrated.
    
    Changeset: 3637e50b
    Author:    Jesper Wilhelmsson 
    URL:       https://git.openjdk.java.net/jdk/commit/3637e50b30e92538510c1a8e8893cedc3bd4ccd5
    Stats:     659 lines in 33 files changed: 450 ins; 121 del; 88 mod
    
    Merge
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk/pull/4514
    
    From jjg at openjdk.java.net  Thu Jun 17 01:44:34 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Thu, 17 Jun 2021 01:44:34 GMT
    Subject: [jdk17] RFR: JDK-8249899: jdk/javadoc/tool/InlineTagsWithBraces.java
     uses @ignore w/o bug-id
    Message-ID: 
    
    Also:
    JDK-8249897: jdk/javadoc/tool/LangVers.java uses @ignore w/o bug-id
    JDK-8249898: jdk/javadoc/tool/6176978/T6176978.java uses @ignore w/o bug-id
    
    Please review a trivial PR for 17 to remove some tests which have been `@ignore`d since at least JDK 9.
    The tests were previously written for the old API and doclet, and were at best incompletely updated for the new world.
    The functionality covered by these tests is now better covered in other non-ignored tests, and there seems little benefit to trying to update them for the new world.
    
    * InlineTagsWithBraces.java was about checking nested `{ }` inside inline tags, which is now covered by `doctree` tests for the `DocCommentParser`.
    * LangVers.java was a JDK5-era test, ensuring that the right language level was assumed. This is now covered by delegating the relevant options (`-source`, `--release`, etc) to javac
    * T6176978.java was about testing classloading of doclets. While we do not have any direct replacement tests, we have a variety of tests that load custom doclets, and javadoc uses the JavaFileManager API to get a class loader for the appropriate path.
    
    -------------
    
    Commit messages:
     - JDK-8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
    
    Changes: https://git.openjdk.java.net/jdk17/pull/87/files
     Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=87&range=00
      Issue: https://bugs.openjdk.java.net/browse/JDK-8249899
      Stats: 333 lines in 4 files changed: 0 ins; 333 del; 0 mod
      Patch: https://git.openjdk.java.net/jdk17/pull/87.diff
      Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/87/head:pull/87
    
    PR: https://git.openjdk.java.net/jdk17/pull/87
    
    From hannesw at openjdk.java.net  Thu Jun 17 08:44:10 2021
    From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
    Date: Thu, 17 Jun 2021 08:44:10 GMT
    Subject: [jdk17] RFR: JDK-8249899:
     jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Thu, 17 Jun 2021 01:35:58 GMT, Jonathan Gibbons  wrote:
    
    > Also:
    > JDK-8249897: jdk/javadoc/tool/LangVers.java uses @ignore w/o bug-id
    > JDK-8249898: jdk/javadoc/tool/6176978/T6176978.java uses @ignore w/o bug-id
    > 
    > Please review a trivial PR for 17 to remove some tests which have been `@ignore`d since at least JDK 9.
    > The tests were previously written for the old API and doclet, and were at best incompletely updated for the new world.
    > The functionality covered by these tests is now better covered in other non-ignored tests, and there seems little benefit to trying to update them for the new world.
    > 
    > * InlineTagsWithBraces.java was about checking nested `{ }` inside inline tags, which is now covered by `doctree` tests for the `DocCommentParser`.
    > * LangVers.java was a JDK5-era test, ensuring that the right language level was assumed. This is now covered by delegating the relevant options (`-source`, `--release`, etc) to javac
    > * T6176978.java was about testing classloading of doclets. While we do not have any direct replacement tests, we have a variety of tests that load custom doclets, and javadoc uses the JavaFileManager API to get a class loader for the appropriate path.
    
    Looks good.
    
    -------------
    
    Marked as reviewed by hannesw (Reviewer).
    
    PR: https://git.openjdk.java.net/jdk17/pull/87
    
    From hannesw at openjdk.java.net  Thu Jun 17 09:55:14 2021
    From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
    Date: Thu, 17 Jun 2021 09:55:14 GMT
    Subject: [jdk17] RFR: JDK-8264843: Javac crashes with NullPointerException
     when finding unencoded XML in 
     tag
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Wed, 16 Jun 2021 23:29:38 GMT, Jonathan Gibbons  wrote:
    
    > Please review a simple fix for an NPE in doclint, in JDK 17.
    > 
    > The NPE is caused by checking if an unknown tag is self-closing. The fix is to move the check into the arm of the preceding `if` statement that ensures that the tags is not null.   Effectively, we do not valid whether unknown tags may be self-closing.
    > 
    > The potential for the NPE has been there a long time. The check that triggers the NPE became more likely when we removed support for HTML4.
    
    Looks good!
    
    -------------
    
    Marked as reviewed by hannesw (Reviewer).
    
    PR: https://git.openjdk.java.net/jdk17/pull/86
    
    From jjg at openjdk.java.net  Thu Jun 17 14:12:12 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Thu, 17 Jun 2021 14:12:12 GMT
    Subject: [jdk17] Integrated: JDK-8249899:
     jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Thu, 17 Jun 2021 01:35:58 GMT, Jonathan Gibbons  wrote:
    
    > Also:
    > JDK-8249897: jdk/javadoc/tool/LangVers.java uses @ignore w/o bug-id
    > JDK-8249898: jdk/javadoc/tool/6176978/T6176978.java uses @ignore w/o bug-id
    > 
    > Please review a trivial PR for 17 to remove some tests which have been `@ignore`d since at least JDK 9.
    > The tests were previously written for the old API and doclet, and were at best incompletely updated for the new world.
    > The functionality covered by these tests is now better covered in other non-ignored tests, and there seems little benefit to trying to update them for the new world.
    > 
    > * InlineTagsWithBraces.java was about checking nested `{ }` inside inline tags, which is now covered by `doctree` tests for the `DocCommentParser`.
    > * LangVers.java was a JDK5-era test, ensuring that the right language level was assumed. This is now covered by delegating the relevant options (`-source`, `--release`, etc) to javac
    > * T6176978.java was about testing classloading of doclets. While we do not have any direct replacement tests, we have a variety of tests that load custom doclets, and javadoc uses the JavaFileManager API to get a class loader for the appropriate path.
    
    This pull request has now been integrated.
    
    Changeset: 69d01b6b
    Author:    Jonathan Gibbons 
    URL:       https://git.openjdk.java.net/jdk17/commit/69d01b6bcabda177f5e27f6c7b141be57cd00619
    Stats:     333 lines in 4 files changed: 0 ins; 333 del; 0 mod
    
    8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
    8249897: jdk/javadoc/tool/LangVers.java uses @ignore w/o bug-id
    8249898: jdk/javadoc/tool/6176978/T6176978.java uses @ignore w/o bug-id
    
    Reviewed-by: hannesw
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk17/pull/87
    
    From jjg at openjdk.java.net  Thu Jun 17 16:41:31 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Thu, 17 Jun 2021 16:41:31 GMT
    Subject: [jdk17] Integrated: JDK-8264843: Javac crashes with
     NullPointerException when finding unencoded XML in 
     tag
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Wed, 16 Jun 2021 23:29:38 GMT, Jonathan Gibbons  wrote:
    
    > Please review a simple fix for an NPE in doclint, in JDK 17.
    > 
    > The NPE is caused by checking if an unknown tag is self-closing. The fix is to move the check into the arm of the preceding `if` statement that ensures that the tags is not null.   Effectively, we do not valid whether unknown tags may be self-closing.
    > 
    > The potential for the NPE has been there a long time. The check that triggers the NPE became more likely when we removed support for HTML4.
    
    This pull request has now been integrated.
    
    Changeset: 0011b52e
    Author:    Jonathan Gibbons 
    URL:       https://git.openjdk.java.net/jdk17/commit/0011b52ee81d88b023f771432abc079c64266578
    Stats:     32 lines in 3 files changed: 28 ins; 1 del; 3 mod
    
    8264843: Javac crashes with NullPointerException when finding unencoded XML in 
     tag
    
    Reviewed-by: hannesw
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk17/pull/86
    
    From jjg at openjdk.java.net  Thu Jun 17 17:44:37 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Thu, 17 Jun 2021 17:44:37 GMT
    Subject: [jdk17] RFR: JDK-8268972: Add default impl for recent new
     Reporter.print method
    Message-ID: 
    
    Please review a simple fix to add a default implementation for a recent new method on the Reporter interface. (It was an oversight that the default implementation was not provided in the original work.)
    
    -------------
    
    Commit messages:
     - JDK-8268973: Add default impl for recent new method
    
    Changes: https://git.openjdk.java.net/jdk17/pull/92/files
     Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=92&range=00
      Issue: https://bugs.openjdk.java.net/browse/JDK-8268972
      Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
      Patch: https://git.openjdk.java.net/jdk17/pull/92.diff
      Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/92/head:pull/92
    
    PR: https://git.openjdk.java.net/jdk17/pull/92
    
    From prappo at openjdk.java.net  Thu Jun 17 17:45:29 2021
    From: prappo at openjdk.java.net (Pavel Rappo)
    Date: Thu, 17 Jun 2021 17:45:29 GMT
    Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic
     within a DocTree node [v2]
    In-Reply-To: 
    References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com>
     
    Message-ID: 
    
    On Wed, 16 Jun 2021 17:18:31 GMT, Jonathan Gibbons  wrote:
    
    >> Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string.
    >> 
    >> This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc.
    >> 
    >> The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes.
    >> 
    >> There are some cosmetic cleanups that were made while exploring the current solution.
    >> 
    >> The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream.
    >
    > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   Address review feedback
    
    Re-synchronize with the CSR.
    
    src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 97:
    
    > 95:      * The positions should satisfy the relation {@code start <= pos <= end}.
    > 96:      *
    > 97:      * @implNote
    
    Should be `@implSpec` instead; please make sure the CSR is updated as well since it also uses `@implNote`.
    
    src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 99:
    
    > 97:      * @implNote
    > 98:      * This implementation ignores the {@code (start, pos, end)} values and simply calls
    > 99:      * {@link #print(Diagnostic.Kind, DocTreePath,String) print(kind, path, message)};
    
    Add a single space character after `,` in the reference.
    
    -------------
    
    Changes requested by prappo (Reviewer).
    
    PR: https://git.openjdk.java.net/jdk/pull/4489
    
    From prappo at openjdk.java.net  Thu Jun 17 17:53:28 2021
    From: prappo at openjdk.java.net (Pavel Rappo)
    Date: Thu, 17 Jun 2021 17:53:28 GMT
    Subject: [jdk17] RFR: JDK-8268972: Add default impl for recent new
     Reporter.print method
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Thu, 17 Jun 2021 17:36:51 GMT, Jonathan Gibbons  wrote:
    
    > Please review a simple fix to add a default implementation for a recent new method on the Reporter interface. (It was an oversight that the default implementation was not provided in the original work.)
    
    Synchronize with the respective CSR.
    
    src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 97:
    
    > 95:      * The positions should satisfy the relation {@code start <= pos <= end}.
    > 96:      *
    > 97:      * @implNote
    
    Should be `@implSpec` instead: both here and in the respective CSR.
    
    src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 98:
    
    > 96:      *
    > 97:      * @implNote
    > 98:      * This implementation throws {@code UnsupportedOperationException}.
    
    I'd suggest rephrasing this as follows: "This implementation always throws..." both here and in the respective CSR.
    
    src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 101:
    
    > 99:      * The implementation provided by the {@code javadoc} tool to
    > 100:      * {@link Doclet#init(Locale, Reporter) initialize} a doclet
    > 101:      * overrides this implementation.
    
    Overrides how?
    
    -------------
    
    Changes requested by prappo (Reviewer).
    
    PR: https://git.openjdk.java.net/jdk17/pull/92
    
    From jjg at openjdk.java.net  Thu Jun 17 18:09:27 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Thu, 17 Jun 2021 18:09:27 GMT
    Subject: [jdk17] RFR: JDK-8268972: Add default impl for recent new
     Reporter.print method
    In-Reply-To: 
    References: 
     
    Message-ID: 
    
    On Thu, 17 Jun 2021 17:50:31 GMT, Pavel Rappo  wrote:
    
    >> Please review a simple fix to add a default implementation for a recent new method on the Reporter interface. (It was an oversight that the default implementation was not provided in the original work.)
    >
    > src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 101:
    > 
    >> 99:      * The implementation provided by the {@code javadoc} tool to
    >> 100:      * {@link Doclet#init(Locale, Reporter) initialize} a doclet
    >> 101:      * overrides this implementation.
    > 
    > Overrides how?
    
    ...per the documented spec.   I tried writing `The implementation .... always generates an appropriate diagnostic` but that's not true if an exception is thrown, and writing `The implementation ... does not throw UOE` seems weird.
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk17/pull/92
    
    From jjg at openjdk.java.net  Thu Jun 17 18:40:50 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Thu, 17 Jun 2021 18:40:50 GMT
    Subject: [jdk17] RFR: JDK-8268972: Add default impl for recent new
     Reporter.print method [v2]
    In-Reply-To: 
    References: 
    Message-ID: 
    
    > Please review a simple fix to add a default implementation for a recent new method on the Reporter interface. (It was an oversight that the default implementation was not provided in the original work.)
    
    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/jdk17/pull/92/files
      - new: https://git.openjdk.java.net/jdk17/pull/92/files/b5fe9e24..e9172ca4
    
    Webrevs:
     - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=92&range=01
     - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=92&range=00-01
    
      Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
      Patch: https://git.openjdk.java.net/jdk17/pull/92.diff
      Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/92/head:pull/92
    
    PR: https://git.openjdk.java.net/jdk17/pull/92
    
    From prappo at openjdk.java.net  Thu Jun 17 18:40:51 2021
    From: prappo at openjdk.java.net (Pavel Rappo)
    Date: Thu, 17 Jun 2021 18:40:51 GMT
    Subject: [jdk17] RFR: JDK-8268972: Add default impl for recent new
     Reporter.print method [v2]
    In-Reply-To: 
    References: 
     
     
    Message-ID: 
    
    On Thu, 17 Jun 2021 18:06:35 GMT, Jonathan Gibbons  wrote:
    
    >> src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 101:
    >> 
    >>> 99:      * The implementation provided by the {@code javadoc} tool to
    >>> 100:      * {@link Doclet#init(Locale, Reporter) initialize} a doclet
    >>> 101:      * overrides this implementation.
    >> 
    >> Overrides how?
    >
    > ...per the documented spec.   I tried writing `The implementation .... always generates an appropriate diagnostic` but that's not true if an exception is thrown, and writing `The implementation ... does not throw UOE` seems weird.
    
    The difficulty you have with ironing out this wording wrinkle suggests that the behavior of the `Reporter` provided to `Doclet.init` should be described in `Doclet.init` rather than here. The same goes for other default methods of Reporter.
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk17/pull/92
    
    From jwilhelm at openjdk.java.net  Thu Jun 17 23:34:36 2021
    From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
    Date: Thu, 17 Jun 2021 23:34:36 GMT
    Subject: RFR: Merge jdk17
    Message-ID: 
    
    Forwardport JDK 17 -> JDK 18
    
    -------------
    
    Commit messages:
     - Merge
     - 8268371: C2: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed
     - 8268676: assert(!ik->is_interface() && !ik->has_subklass()) failed: inconsistent klass hierarchy
     - 8268265: MutableSpaceUsedHelper::take_sample() hits assert(left >= right) failed: avoid overflow
     - 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64
     - 8264843: Javac crashes with NullPointerException when finding unencoded XML in 
     tag
     - 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"
     - 8268353: Test libsvml.so is and is not present in jdk image
     - 8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
     - 8268776: Test `ADatagramSocket.java` missing /othervm from @run tag
     - ... and 3 more: https://git.openjdk.java.net/jdk/compare/bb24fa65...a3951c44
    
    The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.
    
    Changes: https://git.openjdk.java.net/jdk/pull/4525/files
      Stats: 845 lines in 26 files changed: 408 ins; 384 del; 53 mod
      Patch: https://git.openjdk.java.net/jdk/pull/4525.diff
      Fetch: git fetch https://git.openjdk.java.net/jdk pull/4525/head:pull/4525
    
    PR: https://git.openjdk.java.net/jdk/pull/4525
    
    From jwilhelm at openjdk.java.net  Fri Jun 18 00:56:32 2021
    From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
    Date: Fri, 18 Jun 2021 00:56:32 GMT
    Subject: Integrated: Merge jdk17
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Thu, 17 Jun 2021 23:26:26 GMT, Jesper Wilhelmsson  wrote:
    
    > Forwardport JDK 17 -> JDK 18
    
    This pull request has now been integrated.
    
    Changeset: a051e735
    Author:    Jesper Wilhelmsson 
    URL:       https://git.openjdk.java.net/jdk/commit/a051e735cda0d5ee5cb6ce0738aa549a7319a28c
    Stats:     845 lines in 26 files changed: 408 ins; 384 del; 53 mod
    
    Merge
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk/pull/4525
    
    From prappo at openjdk.java.net  Fri Jun 18 10:28:26 2021
    From: prappo at openjdk.java.net (Pavel Rappo)
    Date: Fri, 18 Jun 2021 10:28:26 GMT
    Subject: [jdk17] RFR: JDK-8268972: Add default impl for recent new
     Reporter.print method [v2]
    In-Reply-To: 
    References: 
     
    Message-ID: <7EelmUVRLKX_yakUfH7LIcbf4Iq-YsJmvd27PkTtB0s=.e9cf4414-55be-4e79-8a12-c3a4f433367b@github.com>
    
    On Thu, 17 Jun 2021 18:40:50 GMT, Jonathan Gibbons  wrote:
    
    >> Please review a simple fix to add a default implementation for a recent new method on the Reporter interface. (It was an oversight that the default implementation was not provided in the original work.)
    >
    > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
    > 
    >   address review feedback
    
    Marked as reviewed by prappo (Reviewer).
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk17/pull/92
    
    From jfranck at openjdk.java.net  Mon Jun 21 08:43:32 2021
    From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
    Date: Mon, 21 Jun 2021 08:43:32 GMT
    Subject: Integrated: 8266082: AssertionError in Annotate.fromAnnotations with
     -Xdoclint
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 14 Jun 2021 13:35:35 GMT, Joel Borggr?n-Franck  wrote:
    
    > Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed.
    > 
    > This proposed fix checks references at parse time to disallow annotated types instead of crashing later on.
    > 
    > Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong.
    > 
    > Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18.
    
    This pull request has now been integrated.
    
    Changeset: 0b8a0e2b
    Author:    Joel Borggr?n-Franck 
    URL:       https://git.openjdk.java.net/jdk/commit/0b8a0e2b58dbdd5c9553e502212d32c033a5efb5
    Stats:     96 lines in 5 files changed: 95 ins; 0 del; 1 mod
    
    8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint
    
    Reviewed-by: vromero
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk/pull/4483
    
    From jjg at openjdk.java.net  Fri Jun 25 01:10:03 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Fri, 25 Jun 2021 01:10:03 GMT
    Subject: [jdk17] Integrated: JDK-8268972: Add default impl for recent new
     Reporter.print method
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Thu, 17 Jun 2021 17:36:51 GMT, Jonathan Gibbons  wrote:
    
    > Please review a simple fix to add a default implementation for a recent new method on the Reporter interface. (It was an oversight that the default implementation was not provided in the original work.)
    
    This pull request has now been integrated.
    
    Changeset: 44691cc3
    Author:    Jonathan Gibbons 
    URL:       https://git.openjdk.java.net/jdk17/commit/44691cc3b003ee6769249b481fb9bf9c5afa6182
    Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod
    
    8268972: Add default impl for recent new Reporter.print method
    
    Reviewed-by: prappo
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk17/pull/92
    
    From jwilhelm at openjdk.java.net  Sun Jun 27 23:14:43 2021
    From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
    Date: Sun, 27 Jun 2021 23:14:43 GMT
    Subject: RFR: Merge jdk17
    Message-ID: 
    
    Forwardport JDK 17 -> JDK 18
    
    -------------
    
    Commit messages:
     - Merge
     - 8258746: illegal access to global field _jvmci_old_thread_counters by terminated thread causes crash
     - 8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class
     - 8269351: Proxy::newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
     - 8269260: Add AVX512 and other SSE + AVX combinations testing for tests which generate vector instructions
     - 8269302: serviceability/dcmd/framework/InvalidCommandTest.java still fails after JDK-8268433
     - 8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"
     - 8269074: (fs) Files.copy fails to copy from /proc on some linux kernel versions
     - 8256919: BCEL: Utility.encode forget to close
     - 8269335: Unable to load svml library
     - ... and 20 more: https://git.openjdk.java.net/jdk/compare/8bed3534...2d9b73c0
    
    The webrevs contain the adjustments done while merging with regards to each parent branch:
     - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.0
     - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.1
    
    Changes: https://git.openjdk.java.net/jdk/pull/4606/files
      Stats: 1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod
      Patch: https://git.openjdk.java.net/jdk/pull/4606.diff
      Fetch: git fetch https://git.openjdk.java.net/jdk pull/4606/head:pull/4606
    
    PR: https://git.openjdk.java.net/jdk/pull/4606
    
    From jwilhelm at openjdk.java.net  Sun Jun 27 23:55:06 2021
    From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
    Date: Sun, 27 Jun 2021 23:55:06 GMT
    Subject: Integrated: Merge jdk17
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Sun, 27 Jun 2021 23:05:10 GMT, Jesper Wilhelmsson  wrote:
    
    > Forwardport JDK 17 -> JDK 18
    
    This pull request has now been integrated.
    
    Changeset: a29953d8
    Author:    Jesper Wilhelmsson 
    URL:       https://git.openjdk.java.net/jdk/commit/a29953d805ac6360bcfe005bcefa60e112788494
    Stats:     1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod
    
    Merge
    
    -------------
    
    PR: https://git.openjdk.java.net/jdk/pull/4606
    
    From jjg at openjdk.java.net  Wed Jun 30 16:02:01 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Wed, 30 Jun 2021 16:02:01 GMT
    Subject: [jdk17] RFR: JDK-8268557: Module page uses unstyled table class
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Mon, 14 Jun 2021 14:16:00 GMT, Hannes Walln?fer  wrote:
    
    > This adds CSS rules for the `details-table` class used in the module summary page. The rules are identical to the ones for the `summary-table` class. The screenshot below shows the module summary page with the fixed stylesheet.
    > 
    > module-summary-fixed
    
    ??
    
    -------------
    
    Marked as reviewed by jjg (Reviewer).
    
    PR: https://git.openjdk.java.net/jdk17/pull/43
    
    From jjg at openjdk.java.net  Wed Jun 30 16:16:07 2021
    From: jjg at openjdk.java.net (Jonathan Gibbons)
    Date: Wed, 30 Jun 2021 16:16:07 GMT
    Subject: [jdk17] RFR: JDK-8262886: javadoc generates broken links with
     {@inheritDoc}
    In-Reply-To: 
    References: 
    Message-ID: 
    
    On Fri, 11 Jun 2021 07:14:42 GMT, Hannes Walln?fer  wrote:
    
    > (This jdk17 PR is the continuation of PR openjdk/jdk#4459 in the mainline jdk repo, commits are identical at the point of transition.)
    > 
    > This change fixes a whole slew of shortcomings in the redirection of relative links in doc comments. The basic idea is that relative links are authored to work in their "native primary"  environment (e.g. the package summary page for a package or the class page for a class and its members), and have to be rewritten when used in other contexts such as "use" or index pages.
    > 
    > A list of omissions that are fixed in this change:
    > 
    >  - Relative links in class or member comments were not redirected when inherited by other classes
    >  - Relative links in package comments were not rewritten when displayed in other package summaries as "related packages"
    >  - Fragment links used in foreign contexts were not completed with the file name
    >  - Relative links in module comments were not redirected at all
    > 
    > While fixing above issues I also made sure link rewriting is kept to a minimum, avoiding it as much as possible for elements that live in the same package.
    > 
    > Furthermore, the test for redirected relative links was a bit out of order. The `javadoc` command issued by the test returned `ERROR` because one of the source files contained non-valid HTML (an anchor with a `name` attribute to test whether that attribute would be modified). Because of this, the `checkLinks()` method was never invoked, which is a problem for a test that is supposed to make sure generated links are valid. I changed the test to use the valid `id` attribute instead of `name` and made sure `checkLinks()` is executed again.
    > 
    > I also added checks for the newly supported cases. I added a whole new test for modules since retrofitting the existing test to cover modules would not have been practical.
    
    Approved, but (as is often the case) there is potential for additional cleanup downstream.
    
    src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1664:
    
    > 1662:                 currentPageElement = moduleWriter.mdle;
    > 1663:             }
    > 1664:         }
    
    File an RFE?
    
    src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1724:
    
    > 1722:             text = "{@" + (new DocRootTaglet()).getName() + "}/"
    > 1723:                     + redirectPathFromRoot.resolve(text).getPath();
    > 1724:             text = replaceDocRootDir(text);
    
    ah OK, I see you were just moving stuff around ;-)
    
    src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1728:
    
    > 1726:                 text = docPaths.forName(typeElement).getPath() + text;
    > 1727:             }
    > 1728:         }
    
    This is OK, but would it be better to try and create a URI from the text, and then use URI methods to check or manipulate the URI? Maybe an RFE...?
    
    src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1764:
    
    > 1762:             if (redirectPathFromRoot != null) {
    > 1763:                 text = "{@" + (new DocRootTaglet()).getName() + "}/"
    > 1764:                         + redirectPathFromRoot.resolve(text).getPath();
    
    OK, but icky code ...
    * icky to create an object to just get its name
    * icky to create a comment fragment to get the docRoot behavior
    
    I accept this is old code moved around. Maybe file an RFE for cleanup
    
    test/langtools/jdk/javadoc/doclet/testRelativeLinks/TestRelativeLinks.java line 93:
    
    > 91:         checkOutput("index-all.html", true,
    > 92:             """
    > 93:                 
    """); wow! test/langtools/jdk/javadoc/doclet/testRelativeLinks/TestRelativeLinks.java line 193: > 191: public void checkLinks() { > 192: // since the test uses explicit links to non-existent files, > 193: // we create those files to avoid false positive errors from checkLinks :-) ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/17 From jjg at openjdk.java.net Wed Jun 30 16:20:07 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 30 Jun 2021 16:20:07 GMT Subject: [jdk17] RFR: JDK-8262886: javadoc generates broken links with {@inheritDoc} In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 07:14:42 GMT, Hannes Walln?fer wrote: > (This jdk17 PR is the continuation of PR openjdk/jdk#4459 in the mainline jdk repo, commits are identical at the point of transition.) > > This change fixes a whole slew of shortcomings in the redirection of relative links in doc comments. The basic idea is that relative links are authored to work in their "native primary" environment (e.g. the package summary page for a package or the class page for a class and its members), and have to be rewritten when used in other contexts such as "use" or index pages. > > A list of omissions that are fixed in this change: > > - Relative links in class or member comments were not redirected when inherited by other classes > - Relative links in package comments were not rewritten when displayed in other package summaries as "related packages" > - Fragment links used in foreign contexts were not completed with the file name > - Relative links in module comments were not redirected at all > > While fixing above issues I also made sure link rewriting is kept to a minimum, avoiding it as much as possible for elements that live in the same package. > > Furthermore, the test for redirected relative links was a bit out of order. The `javadoc` command issued by the test returned `ERROR` because one of the source files contained non-valid HTML (an anchor with a `name` attribute to test whether that attribute would be modified). Because of this, the `checkLinks()` method was never invoked, which is a problem for a test that is supposed to make sure generated links are valid. I changed the test to use the valid `id` attribute instead of `name` and made sure `checkLinks()` is executed again. > > I also added checks for the newly supported cases. I added a whole new test for modules since retrofitting the existing test to cover modules would not have been practical. (general wishful thinking) It would be nice to move the "relative links" code out of `HtmlDocletWriter` into another class more focussed on link handling. `HtmlDocletWriter` (and its historical supertypes, now eliminated) has always been a bit of a _utils_ or _misc_ dumping ground and it would be good to continue improving the abstractions in this area. ------------- PR: https://git.openjdk.java.net/jdk17/pull/17 From hannesw at openjdk.java.net Wed Jun 30 18:43:06 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 30 Jun 2021 18:43:06 GMT Subject: [jdk17] Integrated: JDK-8268557: Module page uses unstyled table class In-Reply-To: References: Message-ID: <2IYDZF5beMLvItrxYrMjXfaK_9BTcFevmK0PVXYdonU=.65546617-1f85-4318-83fa-d5a049948dd2@github.com> On Mon, 14 Jun 2021 14:16:00 GMT, Hannes Walln?fer wrote: > This adds CSS rules for the `details-table` class used in the module summary page. The rules are identical to the ones for the `summary-table` class. The screenshot below shows the module summary page with the fixed stylesheet. > > module-summary-fixed This pull request has now been integrated. Changeset: 38260122 Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk17/commit/38260122815aed32627472e5d58b516e89ef7bd7 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod 8268557: Module page uses unstyled table class Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk17/pull/43