From jjg at openjdk.org Thu Dec 1 00:25:19 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 00:25:19 GMT Subject: RFR: JDK-8297802: display of @spec tags should mimic that of @see tags In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 19:49:32 GMT, Pavel Rappo wrote: >> Please review a simple change to model the list used to display `@spec` tags on the list used to display `@see` tags. >> >> In both cases, the list uses an inline list if the items are short and do not contain commas, or a bulleted list if they are long or contain commas. >> >> The test is updated for the new output. >> >> For now, new CSS styles are introduced for `spec-list` and `spec-list-long`, duplicating `see-list` and `see-list-long`. We might want to merge these into `tag-list` and `tag-list-long`, or some other suitably-named pair. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 387: > >> 385: return Text.EMPTY; >> 386: } >> 387: // Use a different style if any link label is longer than 30 chars or contains commas. > > It's a good opportunity to be DRY; I suggest: > // Use a different style if any link label is long or contains commas. Maybe in the next round of cleanup ... > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 760: > >> 758: links.stream() >> 759: .filter(Predicate.not(Content::isEmpty)) >> 760: .forEach(item -> specList.add(HtmlTree.LI(item))); > > There's a similar not-DRY comment. Perhaps both could be dealt with by extracting the decision on styling into a method? I'd prefer to avoid minor refactoring like this at this stage; there may be more refactoring in this area in the next release. ------------- PR: https://git.openjdk.org/jdk/pull/11426 From jjg at openjdk.org Thu Dec 1 00:30:32 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 00:30:32 GMT Subject: Integrated: JDK-8297802: display of @spec tags should mimic that of @see tags In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 04:22:24 GMT, Jonathan Gibbons wrote: > Please review a simple change to model the list used to display `@spec` tags on the list used to display `@see` tags. > > In both cases, the list uses an inline list if the items are short and do not contain commas, or a bulleted list if they are long or contain commas. > > The test is updated for the new output. > > For now, new CSS styles are introduced for `spec-list` and `spec-list-long`, duplicating `see-list` and `see-list-long`. We might want to merge these into `tag-list` and `tag-list-long`, or some other suitably-named pair. This pull request has now been integrated. Changeset: 3b513a4f Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/3b513a4f5cc9b607f93dcc9d1ba52280a2cf42f0 Stats: 147 lines in 23 files changed: 41 ins; 12 del; 94 mod 8297802: display of @spec tags should mimic that of @see tags Reviewed-by: prappo ------------- PR: https://git.openjdk.org/jdk/pull/11426 From jjg at openjdk.org Thu Dec 1 19:36:16 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:36:16 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. 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 five additional commits since the last revision: - Change ietf.org URLs to use rfc-editor.org - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags - Remove updates from unexported files - Prefix RFC titles with `RFC NNNN:` - JDK-8296547: Add @spec tags to API ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11073/files - new: https://git.openjdk.org/jdk/pull/11073/files/3905ac83..07882ffc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=02-03 Stats: 83309 lines in 1834 files changed: 38491 ins; 27762 del; 17056 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Dec 1 19:40:16 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:40:16 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> Message-ID: On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato wrote: >> 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 five additional commits since the last revision: >> >> - Change ietf.org URLs to use rfc-editor.org >> - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags >> - Remove updates from unexported files >> - Prefix RFC titles with `RFC NNNN:` >> - JDK-8296547: Add @spec tags to API > > src/java.base/share/classes/java/lang/Character.java line 172: > >> 170: * occur. For example, in a future release, synchronization may fail. >> 171: * >> 172: * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0 > > This should probably be removed, as the original link (explaining `U+n` notation) is broken. @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Dec 1 19:57:33 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:57:33 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove updates from unexported files > > src/java.xml/share/classes/javax/xml/XMLConstants.java line 35: > >> 33: * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition) >> 34: * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition) >> 35: * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition > > Hi Jon, > > I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0. > points to the fifth edition while @see second. > > A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read. > > [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html The presentation of lists of `@spec` tags was fixed separately (JDK-8297802), and is incorporated into the latest docs that demo this work. The same algorithm is now used for both `@see` and `@spec` tags ... if the links are short and do not contain commas, they will be displayed as an inline list; otherwise, they will be displayed in a bulleted list. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From naoto at openjdk.org Thu Dec 1 21:23:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 1 Dec 2022 21:23:09 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> Message-ID: On Thu, 1 Dec 2022 19:37:28 GMT, Jonathan Gibbons wrote: >> src/java.base/share/classes/java/lang/Character.java line 172: >> >>> 170: * occur. For example, in a future release, synchronization may fail. >>> 171: * >>> 172: * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0 >> >> This should probably be removed, as the original link (explaining `U+n` notation) is broken. > > @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards. Either way is fine with me. I will fix it up if you choose the latter. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From dfuchs at openjdk.org Fri Dec 2 12:15:23 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 2 Dec 2022 12:15:23 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> Message-ID: <4EIiX-uBShLoH1cl1MdngnvCc1HfVFXT_GJgFl5LoTE=.b07eefdf-8c2d-439e-a3c1-8ecfe323e2fd@github.com> On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > 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 five additional commits since the last revision: > > - Change ietf.org URLs to use rfc-editor.org > - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags > - Remove updates from unexported files > - Prefix RFC titles with `RFC NNNN:` > - JDK-8296547: Add @spec tags to API I have reviewed again the java.net, java.net.http, jdk.httpserver, java.naming, and javax.management changes - and I spotted a few places where the `@spec` duplicates an `@see` (noted below). I believe the duplicated `@see` should be removed now. src/java.base/share/classes/java/net/StandardSocketOptions.java line 62: > 60: * @spec https://www.rfc-editor.org/info/rfc919 RFC 919: Broadcasting Internet Datagrams > 61: * @see RFC 929: > 62: * Broadcasting Internet Datagrams This `@see` line should now be removed since it's referencing the exact same document. src/java.base/share/classes/java/net/StandardSocketOptions.java line 83: > 81: * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers > 82: * @see RFC 1122 > 83: * Requirements for Internet Hosts -- Communication Layers Same remark here: please remove the `@see` src/java.base/share/classes/java/net/StandardSocketOptions.java line 154: > 152: * @spec https://www.rfc-editor.org/info/rfc1323 RFC 1323: TCP Extensions for High Performance > 153: * @see RFC 1323: TCP > 154: * Extensions for High Performance Remove the `@see` src/java.base/share/classes/java/net/StandardSocketOptions.java line 186: > 184: * > 185: * @spec https://www.rfc-editor.org/info/rfc793 RFC 793: Transmission Control Protocol > 186: * @see RFC 793: Transmission Remove the @see src/java.base/share/classes/java/net/StandardSocketOptions.java line 377: > 375: * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers > 376: * @see RFC 1122: > 377: * Requirements for Internet Hosts -- Communication Layers Remove the @see src/java.management/share/classes/javax/management/remote/JMXServiceURL.java line 122: > 120: * @see 121: * href="http://www.ietf.org/rfc/rfc2609.txt">RFC 2609, > 122: * "Service Templates and Service: Schemes" The two `@see` should now be removed ------------- Changes requested by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11073 From ihse at openjdk.org Fri Dec 2 16:46:11 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 16:46:11 GMT Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in properties files for langtools code Message-ID: According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) Doing so has a dual benefit: 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team. ------------- Commit messages: - 8298044: Fix hidden but significant trailing whitespace in properties files for langtools code Changes: https://git.openjdk.org/jdk/pull/11487/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11487&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298044 Stats: 18 lines in 10 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/11487.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11487/head:pull/11487 PR: https://git.openjdk.org/jdk/pull/11487 From ihse at openjdk.org Fri Dec 2 16:46:11 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 16:46:11 GMT Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in properties files for langtools code In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team. **A note to reviewers:** This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences. In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed. I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR. But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you. ------------- PR: https://git.openjdk.org/jdk/pull/11487 From ihse at openjdk.org Fri Dec 2 17:12:37 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 17:12:37 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs: [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit. [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Fri Dec 2 17:12:39 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 17:12:39 GMT Subject: Withdrawn: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Fri Dec 2 17:15:19 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:15:19 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com> On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie wrote: > and instead I have split up this work in five different bugs would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource? ------------- PR: https://git.openjdk.org/jdk/pull/10792 From dcubed at openjdk.org Fri Dec 2 22:30:07 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 2 Dec 2022 22:30:07 GMT Subject: RFR: 8295424: adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 22:55:40 GMT, Daniel D. Daugherty wrote: > Misc stress testing related fixes: > > [JDK-8295424](https://bugs.openjdk.org/browse/JDK-8295424) adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest > [JDK-8297367](https://bugs.openjdk.org/browse/JDK-8297367) disable TestRedirectLinks.java in slowdebug mode > [JDK-8297369](https://bugs.openjdk.org/browse/JDK-8297369) disable Fuzz.java in slowdebug mode My jdk-20+26 stress run #1 includes these patches (as have stress runs for several earlier jdk-20 promotions) and there's no signs of issues with these patches on either linux-x64 or macosx-aarch64 stress testing. ------------- PR: https://git.openjdk.org/jdk/pull/11278 From ihse at openjdk.org Fri Dec 2 23:06:08 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 23:06:08 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com> References: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com> Message-ID: On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev wrote: >> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs: >> >> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit. >> >> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team. > >> and instead I have split up this work in five different bugs > > would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource? @andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From jjg at openjdk.org Sat Dec 3 01:33:05 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Sat, 3 Dec 2022 01:33:05 GMT Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in properties files for langtools code In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team. All the files are localized versions of the underlying English files. There are no changes in any of the underlying English files. That suggests we should just let these localized versions "catch up" with the normal localization process, unless there is reason to believe that will not happen. ------------- PR: https://git.openjdk.org/jdk/pull/11487 From duke at openjdk.org Mon Dec 5 07:25:59 2022 From: duke at openjdk.org (Justin Lu) Date: Mon, 5 Dec 2022 07:25:59 GMT Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in properties files for langtools code In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties line 142: > 140: doclet.Implementing_Classes=\u65E2\u77E5\u306E\u5B9F\u88C5\u30AF\u30E9\u30B9\u306E\u30EA\u30B9\u30C8: > 141: doclet.Functional_Interface=\u6A5F\u80FD\u30A4\u30F3\u30BF\u30D5\u30A7\u30FC\u30B9 > 142: doclet.Functional_Interface_Message=\u3053\u308C\u306F\u6A5F\u80FD\u30A4\u30F3\u30BF\u30D5\u30A7\u30FC\u30B9\u306A\u306E\u3067\u3001\u30E9\u30E0\u30C0\u5F0F\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u53C2\u7167\u306E\u5272\u5F53\u3066\u30BF\u30FC\u30B2\u30C3\u30C8\u3068\u3057\u3066\u4F7F\u7528\u3067\u304D\u307E\u3059\u3002\u0020 standard.properties (en, de, zh) does not have a trailing white space for doclet.Functional_Interface_Message. For consistency, there should not be a space here. ------------- PR: https://git.openjdk.org/jdk/pull/11487 From duke at openjdk.org Mon Dec 5 07:40:01 2022 From: duke at openjdk.org (Justin Lu) Date: Mon, 5 Dec 2022 07:40:01 GMT Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in properties files for langtools code In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team. src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 170: > 168: jshell.console.no.javadoc = > 169: jshell.console.do.nothing = Nichts machen > 170: jshell.console.choice = Auswahl:\u0020 This is correct. However, the original l10n.properties did not get the change as intended. l10n.properties had it implemented as `jshell.console.choice = Choice: ` The trailing white space was enclosed with a trailing `` (probably to signify the white space is intentional) and thus hidden from the script. It should be changed to `jshell.console.choice = Choice:\u0020` for consistency ------------- PR: https://git.openjdk.org/jdk/pull/11487 From hannesw at openjdk.org Mon Dec 5 16:27:18 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 5 Dec 2022 16:27:18 GMT Subject: Integrated: JDK-8296619: Upgrade jQuery to 3.6.1 In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 17:19:22 GMT, Hannes Walln?fer wrote: > Please review a change to upgrade the jQuery JS library used by javadoc from 3.6.0 to 3.6.1. The files (uncompressed and compressed) were obtained from https://jquery.com/download/. > > I tested the generated API documentation in the browsers and ran the test suite including the manual TestSearchScript test. This pull request has now been integrated. Changeset: 6a7a0db5 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/6a7a0db587446160e77c9ac225669e5a0c9bc638 Stats: 143 lines in 7 files changed: 41 ins; 13 del; 89 mod 8296619: Upgrade jQuery to 3.6.1 Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk/pull/11138 From sspitsyn at openjdk.org Tue Dec 6 23:04:06 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 6 Dec 2022 23:04:06 GMT Subject: RFR: 8295424: adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest In-Reply-To: References: <6tiK8h3MQgoNTHVnRtLGFJmH2HycabKnQvpE3PL413Q=.298830ac-77b9-4916-a568-10aba857b348@github.com> Message-ID: On Tue, 29 Nov 2022 22:30:10 GMT, Daniel D. Daugherty wrote: >> Sorry, I was not clear. >> The Fuzz.java has this order: >> >> +import jdk.test.lib.Platform; >> +import jtreg.SkippedException; >> >> I thought, you ordered imports by names. Then it is better to keep this order unified. >> It is really minor though. > > Sorry I'm still confused. As far as I can see, I've added the imports the > same way in both Fuzz.java and TestRedirectLinks.java. > > And the imports are in sort order: > 'jdk' comes before 'jtreg' and 'Platform' comes before 'SkippedException'. Sorry, copied fragment from a wrong file. This file has imports out of order: test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java + * @build jtreg.SkippedException + * @build jdk.test.lib.Platform ------------- PR: https://git.openjdk.org/jdk/pull/11278 From dcubed at openjdk.org Tue Dec 6 23:04:07 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 6 Dec 2022 23:04:07 GMT Subject: Integrated: 8295424: adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 22:55:40 GMT, Daniel D. Daugherty wrote: > Misc stress testing related fixes: > > [JDK-8295424](https://bugs.openjdk.org/browse/JDK-8295424) adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest > [JDK-8297367](https://bugs.openjdk.org/browse/JDK-8297367) disable TestRedirectLinks.java in slowdebug mode > [JDK-8297369](https://bugs.openjdk.org/browse/JDK-8297369) disable Fuzz.java in slowdebug mode This pull request has now been integrated. Changeset: 6e547052 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/6e5470525d5236901c219146f363d4860e6b8008 Stats: 17 lines in 3 files changed: 16 ins; 0 del; 1 mod 8295424: adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest 8297367: disable TestRedirectLinks.java in slowdebug mode 8297369: disable Fuzz.java in slowdebug mode Reviewed-by: sspitsyn, jjg, cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/11278 From pminborg at openjdk.org Thu Dec 8 09:29:26 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Dec 2022 09:29:26 GMT Subject: RFR: 8298050: Add links to graph output for javadoc Message-ID: This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. ------------- Commit messages: - Remove unused import - Add relative hyperlinks to nodes Changes: https://git.openjdk.org/jdk/pull/11580/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11580&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298050 Stats: 20 lines in 1 file changed: 19 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11580.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11580/head:pull/11580 PR: https://git.openjdk.org/jdk/pull/11580 From duke at openjdk.org Thu Dec 8 10:24:19 2022 From: duke at openjdk.org (Anthony Vanelverdinghe) Date: Thu, 8 Dec 2022 10:24:19 GMT Subject: Integrated: 8287397 : Print top-level exception when snippet fails to read file In-Reply-To: References: Message-ID: On Sun, 22 May 2022 06:28:39 GMT, Anthony Vanelverdinghe wrote: > When using a snippet as follows (on Windows): `{@snippet file=baz\Baz.java }`, javadoc prints the error: > > src\foo\foo\Foo.java:14: error: Error reading file: baz\Baz.java > {@snippet file=baz\Baz.java } > ^ > (null) > > > which is unhelpful. So rather than printing the exception's cause (which is `null` in the example above), it seems better to print the top-level exception itself. > > PS: I'll need help from someone to create a JBS issue & sponsor this PR This pull request has now been integrated. Changeset: 297bf6a5 Author: Anthony Vanelverdinghe Committer: Julian Waters URL: https://git.openjdk.org/jdk/commit/297bf6a5965c4f01ca2091976b5e6ca675ab5395 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8287397: Print top-level exception when snippet fails to read file Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk/pull/8826 From jjg at openjdk.org Thu Dec 8 16:16:00 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Dec 2022 16:16:00 GMT Subject: RFR: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 09:19:54 GMT, Per Minborg wrote: > This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 209: > 207: .filter(c -> '.' == c) > 208: .mapToObj(c -> "../") > 209: .collect(joining()); What about nested classes? ------------- PR: https://git.openjdk.org/jdk/pull/11580 From prappo at openjdk.org Thu Dec 8 16:27:00 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 8 Dec 2022 16:27:00 GMT Subject: RFR: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 09:19:54 GMT, Per Minborg wrote: > This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. Given that this feature is welcome, I would suggest changing the priority of the respective JBS issue to P3, withdrawing this PR and creating a new PR that targets openjdk/jdk20 after it has been created (which should be within hours from now). make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 207: > 205: private static String relativeLink(TypeElement rootNode, TypeElement node) { > 206: var backNavigator = rootNode.getQualifiedName().toString().chars() > 207: .filter(c -> '.' == c) "Yoda conditions" are usually frowned upon. Can `c` be `null`? ------------- PR: https://git.openjdk.org/jdk/pull/11580 From jjg at openjdk.org Thu Dec 8 16:27:01 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Dec 2022 16:27:01 GMT Subject: RFR: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:18:02 GMT, Pavel Rappo wrote: >> This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. > > make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 207: > >> 205: private static String relativeLink(TypeElement rootNode, TypeElement node) { >> 206: var backNavigator = rootNode.getQualifiedName().toString().chars() >> 207: .filter(c -> '.' == c) > > "Yoda conditions" are usually frowned upon. Can `c` be `null`? `c` is a character ------------- PR: https://git.openjdk.org/jdk/pull/11580 From prappo at openjdk.org Thu Dec 8 16:48:34 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 8 Dec 2022 16:48:34 GMT Subject: RFR: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:22:30 GMT, Jonathan Gibbons wrote: >> make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 207: >> >>> 205: private static String relativeLink(TypeElement rootNode, TypeElement node) { >>> 206: var backNavigator = rootNode.getQualifiedName().toString().chars() >>> 207: .filter(c -> '.' == c) >> >> "Yoda conditions" are usually frowned upon. Can `c` be `null`? > > `c` is a character `c` is an `int`, but even that does not matter. I read off `==` but somehow pictured `equals` in my head; so, null-ness does not matter here at all. That said, unnecessary "Yoda conditions" should probably be avoided. ------------- PR: https://git.openjdk.org/jdk/pull/11580 From rmarchenko at azul.com Fri Dec 2 13:49:41 2022 From: rmarchenko at azul.com (Roman Marchenko) Date: Fri, 2 Dec 2022 13:49:41 +0000 Subject: Docs generated by Java8 Javadoc are incompatible with "javadoc -source 8" In-Reply-To: References: <7bed1a7f-8040-4c39-7f55-f8604702ee64@oracle.com> <03a4f213-e12b-99c7-69fe-3617ed5cf05e@oracle.com> Message-ID: I tried to investigate JDK-8297437 issue with Javadoc by myself, and I?ve found that Javadoc8 generates some links to constant-values and serialized-forms incorrectly. I?m not completely sure that this is critical, but I believe that the possible fix for JDK-8297437 will discover this problem, because JDK17 and later have additional test checks for generated anchors, unlike JDK8. Here is the JDK8 patch to discover the problem with Javadoc8: --------------------- diff --git a/langtools/test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java b/langtools/test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java index 9e9a15e9d7..3743800ad8 100644 --- a/langtools/test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java +++ b/langtools/test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java @@ -222,6 +222,13 @@ public class TestAnchorNames extends JavadocTester { {BUG_ID + FS + "constant-values.html", "" }, + {BUG_ID + FS + "constant-values.html", + "" + }, + {BUG_ID + FS + "pkg1" + FS + "RegClass.html", + "" + // "" // this is the current (wrong) link + }, //Test serialized form page @@ -229,6 +236,13 @@ public class TestAnchorNames extends JavadocTester { {BUG_ID + FS + "serialized-form.html", "" }, + {BUG_ID + FS + "serialized-form.html", + "" + }, + {BUG_ID + FS + "pkg1" + FS + "RegClass._NestedClas$.html", + "" + // "" // this is the current (wrong) link + }, //Test member name index page diff --git a/langtools/test/com/sun/javadoc/testAnchorNames/pkg1/RegClass.java b/langtools/test/com/sun/javadoc/testAnchorNames/pkg1/RegClass.java index 60aae773eb..74fb477978 100644 --- a/langtools/test/com/sun/javadoc/testAnchorNames/pkg1/RegClass.java +++ b/langtools/test/com/sun/javadoc/testAnchorNames/pkg1/RegClass.java @@ -172,7 +172,7 @@ public class RegClass implements Serializable { /** * A nested class. */ - public class _NestedClas$ {} + public class _NestedClas$ implements Serializable {} /** * Nested class D. --------------------- Best regards, Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmarchenko at azul.com Fri Dec 9 12:48:16 2022 From: rmarchenko at azul.com (Roman Marchenko) Date: Fri, 9 Dec 2022 12:48:16 +0000 Subject: Docs generated by Java8 Javadoc are incompatible with "javadoc -source 8" In-Reply-To: References: <7bed1a7f-8040-4c39-7f55-f8604702ee64@oracle.com> <03a4f213-e12b-99c7-69fe-3617ed5cf05e@oracle.com> Message-ID: Hi Jon, May I propose a fix for JDK-8297437? I prepared the changes in my JDK fork, so here is the branch comparison: https://github.com/openjdk/jdk/compare/master...wkia:jdk:fix-8297437 If it?s appropriate I?d create a pull request. Thanks. - Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Dec 9 16:51:09 2022 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Dec 2022 08:51:09 -0800 Subject: [External] : RE: Docs generated by Java8 Javadoc are incompatible with "javadoc -source 8" In-Reply-To: References: <7bed1a7f-8040-4c39-7f55-f8604702ee64@oracle.com> <03a4f213-e12b-99c7-69fe-3617ed5cf05e@oracle.com> Message-ID: <9ac9cd49-19ad-505d-855d-dccf6b306919@oracle.com> Roman, You are welcome to file a PR, subject to OCA rules, etc, but that being said, your comparison does not seem like a valid fix for JDK-8297437. Once again, I emphasise to you that the `--source` option is not a valid way to determine the output format, as you do in these lines of getValidHtmlName. { SourceVersion srcVer = configuration.docEnv.getSourceVersion(); if (SourceVersion.RELEASE_8 != srcVer && SourceVersion.RELEASE_9 != srcVer) { return name; } } If nothing else, the code above makes far too simple a choice: the correct choice will depend on the library being linked to.?? When running javadoc on some "recent" code, some of the libraries being linked to may have been generated by JDK8-era javadoc (with HTML4-style ids) and others may have been generated by more recent versions of javadoc (with HTML5-style ids). -- Jon On 12/9/22 4:48 AM, Roman Marchenko wrote: > > Hi Jon, > > May I propose a fix for JDK-8297437? > > I prepared the changes in my JDK fork, so here is the branch comparison: > > https://github.com/openjdk/jdk/compare/master...wkia:jdk:fix-8297437 > > > If it?s appropriate I?d create a pull request. > > Thanks. > > - Roman > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg at openjdk.org Fri Dec 9 19:42:04 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 9 Dec 2022 19:42:04 GMT Subject: RFR: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:21:30 GMT, Pavel Rappo wrote: >> This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. > > Given that this feature is welcome, I would suggest changing the priority of the respective JBS issue to P3, withdrawing this PR and creating a new PR that targets openjdk/jdk20 after it has been created (which should be within hours from now). Agreed with @pavelrappo that this would be better in JDK 20. ------------- PR: https://git.openjdk.org/jdk/pull/11580 From darcy at openjdk.org Fri Dec 9 19:54:49 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 9 Dec 2022 19:54:49 GMT Subject: RFR: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:21:30 GMT, Pavel Rappo wrote: >> This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. > > Given that this feature is welcome, I would suggest changing the priority of the respective JBS issue to P3, withdrawing this PR and creating a new PR that targets openjdk/jdk20 after it has been created (which should be within hours from now). > Agreed with @pavelrappo that this would be better in JDK 20. I concur it would be preferable in 20 :-) ------------- PR: https://git.openjdk.org/jdk/pull/11580 From hannes.wallnoefer at oracle.com Mon Dec 12 15:35:19 2022 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 12 Dec 2022 15:35:19 +0000 Subject: [External] : RE: Docs generated by Java8 Javadoc are incompatible with "javadoc -source 8" In-Reply-To: <9ac9cd49-19ad-505d-855d-dccf6b306919@oracle.com> References: <7bed1a7f-8040-4c39-7f55-f8604702ee64@oracle.com> <03a4f213-e12b-99c7-69fe-3617ed5cf05e@oracle.com> <9ac9cd49-19ad-505d-855d-dccf6b306919@oracle.com> Message-ID: Hi Roman, In case you want to refine your fix, I think Jon?s comment on the JBS issue provides a good approach for detecting which format to use: https://bugs.openjdk.org/browse/JDK-8297437 Package/element lists are read in class `jdk.javadoc.internal.doclets.toolkit.util.Extern`, so I guess this is where you would want to implement this. Hannes > On 9 Dec 2022, at 17:51, Jonathan Gibbons wrote: > > Roman, > > You are welcome to file a PR, subject to OCA rules, etc, but that being said, your comparison does not seem like a valid fix for JDK-8297437. > > Once again, I emphasise to you that the `--source` option is not a valid way to determine the output format, as you do in these lines of getValidHtmlName. > > { > > > SourceVersion srcVer = configuration.docEnv.getSourceVersion(); > > > if (SourceVersion.RELEASE_8 != srcVer && SourceVersion.RELEASE_9 != srcVer) { > > > return name; > > > } > > > } > > If nothing else, the code above makes far too simple a choice: the correct choice will depend on the library being linked to. When running javadoc on some "recent" code, some of the libraries being linked to may have been generated by JDK8-era javadoc (with HTML4-style ids) and others may have been generated by more recent versions of javadoc (with HTML5-style ids). > > -- Jon > > > > On 12/9/22 4:48 AM, Roman Marchenko wrote: >> Hi Jon, >> >> May I propose a fix for JDK-8297437? >> I prepared the changes in my JDK fork, so here is the branch comparison: >> https://github.com/openjdk/jdk/compare/master...wkia:jdk:fix-8297437 >> If it?s appropriate I?d create a pull request. >> >> Thanks. >> >> - Roman From pminborg at openjdk.org Tue Dec 13 13:17:00 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 Dec 2022 13:17:00 GMT Subject: RFR: 8298050: Add links to graph output for javadoc [v2] In-Reply-To: References: Message-ID: > This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove Yoda notation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11580/files - new: https://git.openjdk.org/jdk/pull/11580/files/6c7d21c8..df9b58c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11580&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11580&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11580.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11580/head:pull/11580 PR: https://git.openjdk.org/jdk/pull/11580 From pminborg at openjdk.org Tue Dec 13 13:17:00 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 Dec 2022 13:17:00 GMT Subject: RFR: 8298050: Add links to graph output for javadoc [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:12:29 GMT, Jonathan Gibbons wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove Yoda notation > > make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 209: > >> 207: .filter(c -> '.' == c) >> 208: .mapToObj(c -> "../") >> 209: .collect(joining()); > > What about nested classes? > > You might want to derive `backNavigator` and `forwardNavigator` from the _package_ of the `TypeElement`. Look at `Elements.getPackageOf(Element)`. I think nested classes are ok (e.g. `a.b.c.Main$Foo` would work). ------------- PR: https://git.openjdk.org/jdk/pull/11580 From pminborg at openjdk.org Tue Dec 13 14:31:56 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 Dec 2022 14:31:56 GMT Subject: RFR: 8298050: Add links to graph output for javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 13:17:00 GMT, Per Minborg wrote: >> This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove Yoda notation Replaced by https://github.com/openjdk/jdk20/pull/23 ------------- PR: https://git.openjdk.org/jdk/pull/11580 From pminborg at openjdk.org Tue Dec 13 14:31:56 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 Dec 2022 14:31:56 GMT Subject: Withdrawn: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 09:19:54 GMT, Per Minborg wrote: > This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11580 From pminborg at openjdk.org Tue Dec 13 14:34:43 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 Dec 2022 14:34:43 GMT Subject: [jdk20] RFR: 8298050: Add links to graph output for javadoc Message-ID: This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. ------------- Commit messages: - Add links to graph output for javadoc Changes: https://git.openjdk.org/jdk20/pull/23/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=23&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298050 Stats: 21 lines in 1 file changed: 19 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk20/pull/23.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/23/head:pull/23 PR: https://git.openjdk.org/jdk20/pull/23 From darcy at openjdk.org Tue Dec 13 17:26:00 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 Dec 2022 17:26:00 GMT Subject: [jdk20] RFR: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 14:27:37 GMT, Per Minborg wrote: > This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/23 From jjg at openjdk.org Tue Dec 13 22:34:08 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 13 Dec 2022 22:34:08 GMT Subject: [jdk20] RFR: JDK-8298700: Typo in DocTree comment Message-ID: Please review a trivial fix to a long-standing copy-paste typo. ------------- Commit messages: - JDK-8298700: Typo in DocTree comment Changes: https://git.openjdk.org/jdk20/pull/28/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=28&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298700 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk20/pull/28.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/28/head:pull/28 PR: https://git.openjdk.org/jdk20/pull/28 From darcy at openjdk.org Tue Dec 13 22:46:13 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 Dec 2022 22:46:13 GMT Subject: [jdk20] RFR: JDK-8298700: Typo in DocTree comment In-Reply-To: References: Message-ID: <4vjbP72kPppCt8a7a_Q6BkDw3W3mPmCeT2Wx33DRkOw=.651a847a-bf69-43c0-857a-8cb1f72b3e10@github.com> On Tue, 13 Dec 2022 22:27:05 GMT, Jonathan Gibbons wrote: > Please review a trivial fix to a long-standing copy-paste typo. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/28 From jjg at openjdk.org Tue Dec 13 23:24:55 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 13 Dec 2022 23:24:55 GMT Subject: [jdk20] Integrated: JDK-8298700: Typo in DocTree comment In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 22:27:05 GMT, Jonathan Gibbons wrote: > Please review a trivial fix to a long-standing copy-paste typo. This pull request has now been integrated. Changeset: 61ab16f7 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk20/commit/61ab16f79a735a98b3c095daf1b541f4fc5413c0 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8298700: Typo in DocTree comment Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk20/pull/28 From pminborg at openjdk.org Wed Dec 14 07:30:13 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 14 Dec 2022 07:30:13 GMT Subject: [jdk20] RFR: 8298050: Add links to graph output for javadoc [v2] In-Reply-To: References: Message-ID: > This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Use package for navigation ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/23/files - new: https://git.openjdk.org/jdk20/pull/23/files/6521807f..b4e0ce0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=23&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=23&range=00-01 Stats: 17 lines in 1 file changed: 4 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk20/pull/23.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/23/head:pull/23 PR: https://git.openjdk.org/jdk20/pull/23 From jwilhelm at openjdk.org Wed Dec 14 17:11:21 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 14 Dec 2022 17:11:21 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax - 8298649: JFR: RemoteRecordingStream support for checkpoint event sizes beyond u4 - 8298296: gc/TestFullGCCount.java fails with "System.gc collections miscounted." - 8294902: Undefined Behavior in C2 regalloc with null references - 8298425: System.console().readLine() hangs in jshell - 8298520: C2: assert(found_opaque == res) failed: wrong pattern - 8298527: Cygwin's uname -m returns different string than before - 8298700: Typo in DocTree comment - 8297305: Clarify that javax.lang.model.util.Elements.overrides is irreflexive - ... and 1 more: https://git.openjdk.org/jdk/compare/c05dbac3...873a7e3a The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=11678&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11678&range=00.1 Changes: https://git.openjdk.org/jdk/pull/11678/files Stats: 216 lines in 17 files changed: 132 ins; 41 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/11678.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11678/head:pull/11678 PR: https://git.openjdk.org/jdk/pull/11678 From jwilhelm at openjdk.org Wed Dec 14 21:51:13 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 14 Dec 2022 21:51:13 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 16:59:54 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: a130c8a6 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/a130c8a6688fcdda92e0f6295ec06f1591382328 Stats: 216 lines in 17 files changed: 132 ins; 41 del; 43 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/11678 From dnguyen at openjdk.org Wed Dec 14 23:47:55 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 14 Dec 2022 23:47:55 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 Message-ID: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Open l10n drop All tests passed ------------- Commit messages: - open l10n drop Changes: https://git.openjdk.org/jdk20/pull/35/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298133 Stats: 1177 lines in 110 files changed: 783 ins; 207 del; 187 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From achung at openjdk.org Thu Dec 15 00:07:04 2022 From: achung at openjdk.org (Alisen Chung) Date: Thu, 15 Dec 2022 00:07:04 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed looks good ------------- Marked as reviewed by achung (Committer). PR: https://git.openjdk.org/jdk20/pull/35 From duke at openjdk.org Thu Dec 15 01:01:05 2022 From: duke at openjdk.org (Justin Lu) Date: Thu, 15 Dec 2022 01:01:05 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: > 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 > 187: > 188: main.plugin.category=\u7C7B\u522B As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From duke at openjdk.org Thu Dec 15 01:07:14 2022 From: duke at openjdk.org (Justin Lu) Date: Thu, 15 Dec 2022 01:07:14 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26: > 24: # > 25: > 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now? ------------- PR: https://git.openjdk.org/jdk20/pull/35 From duke at openjdk.org Thu Dec 15 01:16:13 2022 From: duke at openjdk.org (Justin Lu) Date: Thu, 15 Dec 2022 01:16:13 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 00:58:06 GMT, Justin Lu wrote: >> Open l10n drop >> All tests passed > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: > >> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 >> 187: >> 188: main.plugin.category=\u7C7B\u522B > > As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes. Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 02:26:12 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 02:26:12 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 01:04:12 GMT, Justin Lu wrote: >> Open l10n drop >> All tests passed > > src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26: > >> 24: # >> 25: >> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten > > `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now? I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19. I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated. And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 02:45:48 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 02:45:48 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Removed trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/39511b7a..54d2ec5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 12:06:10 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 12:06:10 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 01:13:32 GMT, Justin Lu wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: >> >>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 >>> 187: >>> 188: main.plugin.category=\u7C7B\u522B >> >> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes. > > Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop In our discussion, Kate mentioned that some languages are double byte, so this extra space may be correct but she hasn't looked in detail yet. I looked through all of the changes and these two instances of trailing whitespaces were the only two. I removed the extra spaces to reduce the changes as it seems useless due to the previous version not having the whitespace. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From pminborg at openjdk.org Thu Dec 15 15:49:10 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 15 Dec 2022 15:49:10 GMT Subject: [jdk20] Integrated: 8298050: Add links to graph output for javadoc In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 14:27:37 GMT, Per Minborg wrote: > This PR proposes adding hyperlinks to the sealed graphic layout making navigation much simpler via the image. This pull request has now been integrated. Changeset: 2c424992 Author: Per Minborg Committer: Joe Darcy URL: https://git.openjdk.org/jdk20/commit/2c42499266377a32aa0ff96a0241d76d7517cf2e Stats: 32 lines in 1 file changed: 23 ins; 3 del; 6 mod 8298050: Add links to graph output for javadoc Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk20/pull/23 From dnguyen at openjdk.org Thu Dec 15 18:54:09 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 18:54:09 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 02:23:34 GMT, Damon Nguyen wrote: >> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26: >> >>> 24: # >>> 25: >>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten >> >> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now? > > I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19. > > I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated. > > And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated. I conversed with Kate and the problem seems to come from the extraction process. We went through the source files that were sent for translation as a zip, and some changes would be missing. We confirmed that everything in this zip was translated, so the issue was in the extraction to create the source files to send for translation. For example, the plugin.properties missing text didn't show in the source.zip but showed on my forked repo used in the extraction. I re-ran the extraction script but still did not see the new text in the generated zip. Kate thinks a similar issue occurred in the previous drop and this jmod.properties change wasn't captured in the extraction process. So now it is captured in this drop and translated here. It could be syncing or branch issues, but while working with Kate, I learned to better see what files are pulled from the extraction script. So for future drops, I can better check to make sure changes I expect to be translated will appear. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From naoto at openjdk.org Thu Dec 15 18:58:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Dec 2022 18:58:09 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 02:45:48 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Removed trailing whitespace Changes requested by naoto (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 217: > 215: javac.msg.usage.nonstandard.footer=Diese zus\u00E4tzlichen Optionen k\u00F6nnen jederzeit ohne vorherige Ank\u00FCndigung ge\u00E4ndert werden. > 216: > 217: javac.msg.bug=Im Compiler ({0}) ist eine Ausnahme aufgetreten. Erstellen Sie auf der Java-Seite zum Melden von Bugs (http://bugreport.java.com) einen Bugbericht, nachdem Sie die Bugdatenbank (http://bugs.java.com) auf Duplikate gepr\u00FCft haben. Geben Sie in Ihrem Bericht Ihr Programm, die folgende Diagnose und die Parameter an, die Sie dem Java-Compiler \u00FCbergeben haben. Vielen Dank. How come `https` turned into `http`? I see these happening all over the places other than this location as well. src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134: > 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung > 133: artifact.not.found=nicht gefunden > 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 20:43:42 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 20:43:42 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Fix https and changed URL back ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/54d2ec5f..09140a05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01-02 Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 20:55:08 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 20:55:08 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 18:52:45 GMT, Naoto Sato wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed trailing whitespace > > src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134: > >> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung >> 133: artifact.not.found=nicht gefunden >> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales. This and the https->http differences seem to also be a part of the extraction issue. The resource generation files show "http" and "java.net", but I see differently on my local repo that I used for the extraction. I will run a new extraction job on a fresh repo/branch to see if this issue is reproducible and narrow down the source of the extraction issue. As discussed with Naoto, these are small edits, and they have been addressed in the latest PR. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From naoto at openjdk.org Thu Dec 15 21:16:07 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Dec 2022 21:16:07 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Fix https and changed URL back Thanks for the update, Damon. Looks good for this drop. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 23:01:35 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 23:01:35 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert double quote as well ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/09140a05..57c42206 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From naoto at openjdk.org Thu Dec 15 23:12:06 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Dec 2022 23:12:06 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert double quote as well Marked as reviewed by naoto (Reviewer). src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26: > 24: # > 25: > 26: main.usage=Verwendung: jdeprscan [Optionen] '{dir|jar|class}' ...\n\nOptionen:\n --class-path PATH\n --for-removal\n --full-version\n -? -h --help\n -l --list\n --release {0}\n -v --verbose\n --version Good catch! ------------- PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Thu Dec 15 23:17:12 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Dec 2022 23:17:12 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Fix https and changed URL back src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82: > 80: > 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0}) > 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""? src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties line 82: > 80: > 81: error.foreign-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306B.jpackage.xml\u30D5\u30A1\u30A4\u30EB\u304C\u3042\u308A\u307E\u305B\u3093 > 82: error.invalid-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306F\u5225\u306Ejpackage\u30D0\u30FC\u30B8\u30E7\u30F3\u307E\u305F\u306F\u4E0D\u6B63\u306A.jpackage.xml\u3067\u751F\u6210\u3055\u308C\u307E\u3057\u305F Same as "de" translation. src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties line 82: > 80: > 81: error.foreign-app-image=\u9519\u8BEF\uFF1Aapp-image \u76EE\u5F55 ({0}) \u4E2D\u7F3A\u5C11 .jpackage.xml \u6587\u4EF6 > 82: error.invalid-app-image=\u9519\u8BEF\uFF1A\u53E6\u4E00\u4E2A jpackage \u7248\u672C\u6216\u683C\u5F0F\u9519\u8BEF\u7684 .jpackage.xml \u751F\u6210\u4E86 app-image \u76EE\u5F55 ({0}) Same as "de" translation. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2: > 1: > 2: Why "de-de" was changed to "de"? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2: > 1: > 2: Why "ja-jp" to "ja"? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 37: > 35: resource.post-app-image-script=Auszuf\u00FChrendes Skript nach dem Auff\u00FCllen des Anwendungsimages > 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm > 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl Why this was changed? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37: > 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 > 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 > 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl Why this was changed? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 37: > 35: resource.post-app-image-script=\u8981\u5728\u586B\u5145\u5E94\u7528\u7A0B\u5E8F\u6620\u50CF\u4E4B\u540E\u8FD0\u884C\u7684\u811A\u672C > 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C > 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl Same as above. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Thu Dec 15 23:17:15 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Dec 2022 23:17:15 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert double quote as well src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 15: > 13: ???????????????????? > 14: [ProductName]?????? > 15: Open with [ProductName] Why it was removed in all translations, except English? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51: > 49: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen > 50: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden > 51: error.icon-swap=Failed to update icon for {0} Why this was removed? ------------- PR: https://git.openjdk.org/jdk20/pull/35 From weijun at openjdk.org Thu Dec 15 23:34:10 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 15 Dec 2022 23:34:10 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert double quote as well src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75: > 73: "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey > 74: {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, > 75: {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 00:20:09 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 00:20:09 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 22:57:31 GMT, Alexander Matveev wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix https and changed URL back > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82: > >> 80: >> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0}) >> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt > > error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""? I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted? > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2: > >> 1: >> 2: > > Why "de-de" was changed to "de"? Also not sure why this was changed in the translation. I'm reverting all instances of these language codes. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 00:28:14 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 00:28:14 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:13:22 GMT, Alexander Matveev wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix https and changed URL back > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37: > >> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl > > Why this was changed? Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Fri Dec 16 00:55:07 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Dec 2022 00:55:07 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 00:15:51 GMT, Damon Nguyen wrote: >> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82: >> >>> 80: >>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0}) >>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt >> >> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""? > > I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted? Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Fri Dec 16 00:59:08 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Dec 2022 00:59:08 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 00:24:26 GMT, Damon Nguyen wrote: >> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37: >> >>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl >> >> Why this was changed? > > Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file. Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 01:05:08 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 01:05:08 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 00:51:55 GMT, Alexander Matveev wrote: >> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted? > > Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old. I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then. >> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file. > > Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code. This drop had some issues with the extraction which will be resolved. Some of the changes are correct while some seem to be old. It seems these jpackage files were are older? I can revert these changes for jpackage then. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From joehw at openjdk.org Fri Dec 16 01:25:18 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 16 Dec 2022 01:25:18 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert double quote as well The changes in the java.xml area look good to me. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:38:54 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:38:54 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert old translation. Fix lang codes ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/57c42206..29880af9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03-04 Stats: 18 lines in 9 files changed: 6 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:38:56 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:38:56 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: <_Dir5hjsOpTXHLKfV6SM_6kUJfNcHSkgHjrRAHbGUfw=.db9fe398-4a22-4aab-90ef-72d67f5c708e@github.com> On Fri, 16 Dec 2022 01:02:03 GMT, Damon Nguyen wrote: >> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old. > > I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then. The translated text here has been reverted to its original English. The same has been done for its locales. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:38:58 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:38:58 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 00:17:15 GMT, Damon Nguyen wrote: >> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2: >> >>> 1: >>> 2: >> >> Why "de-de" was changed to "de"? > > Also not sure why this was changed in the translation. I'm reverting all instances of these language codes. This has been reverted as it was a regression for all locales of MsiInstallerStrings.wxl ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:39:01 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:39:01 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:12:58 GMT, Alexander Matveev wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed trailing whitespace > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51: > >> 49: error.msi-product-version-build-out-of-range=Build-Teil der Version muss im Bereich [0, 65535] liegen >> 50: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen >> 51: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden > > Why this was removed? This line was added back to all locales as it was a regression from the translation process. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:45:07 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:45:07 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:30:52 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert double quote as well > > src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75: > >> 73: "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey >> 74: {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, >> 75: {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, > > The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file. I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK? ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:58:08 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:58:08 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes @dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From cjplummer at openjdk.org Fri Dec 16 04:12:17 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Dec 2022 04:12:17 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes `src/jdk.jdi/share/classes/com/sun/tools` changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Fri Dec 16 05:17:11 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Dec 2022 05:17:11 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes jpackage changes looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35 From dfuchs at openjdk.org Fri Dec 16 09:22:29 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 16 Dec 2022 09:22:29 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34: > 32: # Translators please note do not translate the options themselves > 33: java.launcher.opt.footer = \ -cp \n -classpath \n --class-path \n Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n -p \n --module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist.\n --upgrade-module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n Module im Laufzeitimage ersetzen\n --add-modules [,...]\n Root-Module, die zus\u00E4tzlich zum anf\u00E4n glichen Modul aufgel\u00F6st werden sollen.\n kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n ALL-MODULE-PATH.\n --enable-native-access [,...]\n Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n kann auch ALL-UNNAMED lauten.\n --list-modules\n Listet beobachtbare Module auf und beendet den Vorgang\n -d \n --describe-module \n Beschreibt ein Modul und beendet den Vorgang\n --dry-run Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n --validate-modules\n Validiert alle Module und beendet den Vorgang\n Die Option "--vali date-modules" kann n\u00FCtzlich sein, um\n Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n -D=\n Legt eine Systemeigenschaft fest\n -verbose:[class|module|gc|jni]\n Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n -version Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n --version Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n -showversion Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n --show-version\n Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n --show-module-resolution\n Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n -? -h -help\n Gibt diese Hilfemeldung an den Fehlerstream aus\n --help Gibt diese Hilfemeldung an den Outputstream aus\n -X Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n --help-extra Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n -ea[:...|:]\n -enableassertions[:...|:]\n Aktiviert Assertions mit angegebener Granularit\u00E4t\n -da[:...|:]\n -disableassertions[:...|:]\n Deaktiviert Assertions mit angegebener Granularit\u00E4t\n -esa | -enablesystemassertions\n Aktiviert System-Assertions\n -dsa | -disablesystemassertions\n Deaktiviert System-Assertions\n -agentlib:[=]\n L\u00E4dt die native Agent Library . Beispiel: -agentlib:jdwp\n siehe auch -agentlib:jdwp=help\n -agentpath:[=]\n L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n -javaagent:[=]\n \ > 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n -splash:\n Zeigt den Startbildschirm mit einem angegebenen Bild an\n Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n Das am besten geeignete angegebene skalierte Bild wird\n automatisch ausgew\u00E4hlt.\n Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n @argument files\n Eine oder mehrere Argumentdateien mit Optionen\n -disable- at files\n Verhindert die weitere Erweiterung von Argumentdateien\n --enable-preview\n L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f \u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --= oder\n-- verwenden.\n This change seems wrong, unless I'm mistaken the option name is `--disable- at files`, not `-disable- at files` ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dfuchs at openjdk.org Fri Dec 16 09:48:59 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 16 Dec 2022 09:48:59 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com> On Fri, 16 Dec 2022 09:20:07 GMT, Daniel Fuchs wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert old translation. Fix lang codes > > src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34: > >> 32: # Translators please note do not translate the options themselves >> 33: java.launcher.opt.footer = \ -cp \n -classpath \n --class-path \n Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n -p \n --module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist.\n --upgrade-module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n Module im Laufzeitimage ersetzen\n --add-modules [,...]\n Root-Module, die zus\u00E4tzlich zum anf\u00E4 nglichen Modul aufgel\u00F6st werden sollen.\n kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n ALL-MODULE-PATH.\n --enable-native-access [,...]\n Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n kann auch ALL-UNNAMED lauten.\n --list-modules\n Listet beobachtbare Module auf und beendet den Vorgang\n -d \n --describe-module \n Beschreibt ein Modul und beendet den Vorgang\n --dry-run Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n --validate-modules\n Validiert alle Module und beendet den Vorgang\n Die Option "--val idate-modules" kann n\u00FCtzlich sein, um\n Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n -D=\n Legt eine Systemeigenschaft fest\n -verbose:[class|module|gc|jni]\n Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n -version Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n --version Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n -showversion Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n --show-version\n Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n --show-module-resolution\n Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n -? -h -help\n Gibt diese Hilfemeldung an den Fehlerstream aus\n --help Gibt diese Hilfemeldung an den Outputstream aus\n -X Gibt Hilf e zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n --help-extra Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n -ea[:...|:]\n -enableassertions[:...|:]\n Aktiviert Assertions mit angegebener Granularit\u00E4t\n -da[:...|:]\n -disableassertions[:...|:]\n Deaktiviert Assertions mit angegebener Granularit\u00E4t\n -esa | -enablesystemassertions\n Aktiviert System-Assertions\n -dsa | -disablesystemassertions\n Deaktiviert System-Assertions\n -agentlib:[=]\n L\u00E4dt die native Agent Library . Beispiel: -agentlib:jdwp\n siehe auch -agentlib:jdwp=help\n -agentpath:[=]\n L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n -javaagent:[=]\ n \ >> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n -splash:\n Zeigt den Startbildschirm mit einem angegebenen Bild an\n Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n Das am besten geeignete angegebene skalierte Bild wird\n automatisch ausgew\u00E4hlt.\n Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n @argument files\n Eine oder mehrere Argumentdateien mit Optionen\n -disable- at files\n Verhindert die weitere Erweiterung von Argumentdateien\n --enable-preview\n L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --= oder\n-- verwenden.\n > > This change seems wrong, unless I'm mistaken the option name is still `--disable- at files`, not `-disable- at files` I'm unfortunately not familiar with any of these resources files, and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation. Find-in-files revealed that the source is still using --disable- at files. See: https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131 https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377 https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121 ------------- PR: https://git.openjdk.org/jdk20/pull/35 From alanb at openjdk.org Fri Dec 16 10:13:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Dec 2022 10:13:04 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:55:29 GMT, Damon Nguyen wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert old translation. Fix lang codes > > @dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team. @DamonGuy There seems to be several glitches in this refresh. It's also surprising that the translations appear to be done on several out of date files. On the positive front, it's good to see this update has caught the attention of Naoto, Weijun, and others. Once the identified issues have been fixed then it would be good to try to get a review from someone that is native in each of the languages. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From jwilhelm at openjdk.org Fri Dec 16 13:33:14 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Fri, 16 Dec 2022 13:33:14 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge - 8298797: Specification of some restricted methods is incorrect - 8287699: jdk/jfr/api/consumer/TestRecordingFileWrite.java fails with exception: java.lang.Exception: Found event that should not be there. - 8297979: ZGC: Ensure consistent MemoryUsage from MemoryMXBean.getHeapMemoryUsage() - 8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working - 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx - 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected - 8298050: Add links to graph output for javadoc - 8298376: ZGC: thaws stackChunk with stale oops - 8298727: Trees.getPath may crash for unnamed package - ... and 1 more: https://git.openjdk.org/jdk/compare/ac2fcf3f...f069db65 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=11710&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11710&range=00.1 Changes: https://git.openjdk.org/jdk/pull/11710/files Stats: 250 lines in 15 files changed: 180 ins; 52 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/11710.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11710/head:pull/11710 PR: https://git.openjdk.org/jdk/pull/11710 From naoto at openjdk.org Fri Dec 16 13:46:02 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Dec 2022 13:46:02 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes There is another translation drop scheduled in January, so our plan is to figure out why the source extraction in this drop mistakenly used old files till then, then address it in the January l10n drop. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From weijun at openjdk.org Fri Dec 16 15:05:55 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Dec 2022 15:05:55 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com> On Fri, 16 Dec 2022 03:41:09 GMT, Damon Nguyen wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75: >> >>> 73: "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey >>> 74: {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, >>> 75: {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, >> >> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file. > > I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK? Yes, you can replace all "??????" (that is not after ""???") to "?????????". There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From jwilhelm at openjdk.org Fri Dec 16 15:52:00 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Fri, 16 Dec 2022 15:52:00 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 13:25:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: 3696711e Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/3696711efa566fb776d6923da86e17b0e1e22964 Stats: 250 lines in 15 files changed: 180 ins; 52 del; 18 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/11710 From dnguyen at openjdk.org Fri Dec 16 16:53:59 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 16:53:59 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes Right, Naoto's comment is correct. This time, the source extraction used some older files. To resolve this for this drop, I went through the files and reverted any changes that would be deemed as regressions or outdated files. Any other updates missed in this drop will be handled in the close upcoming drop in January. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:02:42 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:02:42 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v6] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Fix missing dash ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/29880af9..62a19a83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04-05 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:02:44 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:02:44 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com> Message-ID: On Fri, 16 Dec 2022 09:46:14 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34: >> >>> 32: # Translators please note do not translate the options themselves >>> 33: java.launcher.opt.footer = \ -cp \n -classpath \n --class-path \n Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n -p \n --module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist.\n --upgrade-module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n Module im Laufzeitimage ersetzen\n --add-modules [,...]\n Root-Module, die zus\u00E4tzlich zum anf\u00E 4nglichen Modul aufgel\u00F6st werden sollen.\n kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n ALL-MODULE-PATH.\n --enable-native-access [,...]\n Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n kann auch ALL-UNNAMED lauten.\n --list-modules\n Listet beobachtbare Module auf und beendet den Vorgang\n -d \n --describe-module \n Beschreibt ein Modul und beendet den Vorgang\n --dry-run Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n --validate-modules\n Validiert alle Module und beendet den Vorgang\n Die Option "--va lidate-modules" kann n\u00FCtzlich sein, um\n Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n -D=\n Legt eine Systemeigenschaft fest\n -verbose:[class|module|gc|jni]\n Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n -version Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n --version Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n -showversion Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n --show-version\n Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n --show-module-resolution\n Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n -? -h -help\n Gibt diese Hilfemeldung an den Fehlerstream aus\n --help Gibt diese Hilfemeldung an den Outputstream aus\n -X Gibt Hil fe zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n --help-extra Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n -ea[:...|:]\n -enableassertions[:...|:]\n Aktiviert Assertions mit angegebener Granularit\u00E4t\n -da[:...|:]\n -disableassertions[:...|:]\n Deaktiviert Assertions mit angegebener Granularit\u00E4t\n -esa | -enablesystemassertions\n Aktiviert System-Assertions\n -dsa | -disablesystemassertions\n Deaktiviert System-Assertions\n -agentlib:[=]\n L\u00E4dt die native Agent Library . Beispiel: -agentlib:jdwp\n siehe auch -agentlib:jdwp=help\n -agentpath:[=]\n L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n -javaagent:[=] \n \ >>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n -splash:\n Zeigt den Startbildschirm mit einem angegebenen Bild an\n Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n Das am besten geeignete angegebene skalierte Bild wird\n automatisch ausgew\u00E4hlt.\n Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n @argument files\n Eine oder mehrere Argumentdateien mit Optionen\n -disable- at files\n Verhindert die weitere Erweiterung von Argumentdateien\n --enable-preview\n L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --= oder\n-- verwenden.\n >> >> This change seems wrong, unless I'm mistaken the option name is still `--disable- at files`, not `-disable- at files` > > I'm unfortunately not familiar with any of these resources files, and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation. > Find-in-files revealed that the source is still using --disable- at files. See: > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131 > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377 > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121 Thanks for taking a look. I fixed this removed dash from the translation in the latest PR. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From prr at openjdk.org Fri Dec 16 17:28:56 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 16 Dec 2022 17:28:56 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v6] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 17:02:42 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Fix missing dash src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430: > 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A > 429: > 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145, \u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6 I was asked to review SwingSet2 changes but this isn't code. But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:42:17 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:42:17 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v7] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert swingset. Consistency in CN ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/62a19a83..fe18e4ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05-06 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:45:05 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:45:05 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com> Message-ID: On Fri, 16 Dec 2022 15:02:42 GMT, Weijun Wang wrote: >> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK? > > Yes, you can replace all "??????" (that is not after ""???") to "?????????". > > There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. Could you re-review the current changes for this drop? ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:51:19 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:51:19 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v8] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Swingset newline ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/fe18e4ea..f058a1de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06-07 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:51:20 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:51:20 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 17:26:18 GMT, Phil Race wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert old translation. Fix lang codes > > src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430: > >> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A >> 429: >> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145\uFF0C\u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6 > > I was asked to review SwingSet2 changes but this isn't code. > But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble. Thanks. I removed the changes to swingset's translation to avoid causing any issues. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From weijun at openjdk.org Fri Dec 16 18:02:55 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Dec 2022 18:02:55 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com> Message-ID: On Fri, 16 Dec 2022 17:41:42 GMT, Damon Nguyen wrote: >> Yes, you can replace all "??????" (that is not after ""???") to "?????????". >> >> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. > > Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. > > Could you re-review the current changes for this drop? The updated file looks fine to me. Thanks. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 21:18:58 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 21:18:58 GMT Subject: [jdk20] Integrated: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: <3RA_5D04t20xCtp1jJI-KMZt7Ev8f7bJv2zlanOnE-E=.d82daa27-fd0d-4eca-88cd-61ace8ba0d4a@github.com> On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed This pull request has now been integrated. Changeset: c997b5bf Author: Damon Nguyen Committer: Naoto Sato URL: https://git.openjdk.org/jdk20/commit/c997b5bffd0ebbd6d68332572639c8cea05ccdb1 Stats: 1128 lines in 99 files changed: 783 ins; 198 del; 147 mod 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 Reviewed-by: achung, naoto, joehw, cjplummer, almatvee ------------- PR: https://git.openjdk.org/jdk20/pull/35 From jjg at openjdk.org Mon Dec 19 21:03:47 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 19 Dec 2022 21:03:47 GMT Subject: RFR: JDK-8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 Message-ID: Please review a fix for the golden-file for a test, required after quotes in resources were fixed in JDK-8298943. ------------- Commit messages: - JDK-8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 Changes: https://git.openjdk.org/jdk/pull/11732/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11732&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299045 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11732.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11732/head:pull/11732 PR: https://git.openjdk.org/jdk/pull/11732 From vromero at openjdk.org Mon Dec 19 21:08:50 2022 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 Dec 2022 21:08:50 GMT Subject: RFR: JDK-8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 In-Reply-To: References: Message-ID: On Mon, 19 Dec 2022 20:56:14 GMT, Jonathan Gibbons wrote: > Please review a fix for the golden-file for a test, required after quotes in resources were fixed in JDK-8298943. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/11732 From jjg at openjdk.org Mon Dec 19 21:11:54 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 19 Dec 2022 21:11:54 GMT Subject: Integrated: JDK-8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 In-Reply-To: References: Message-ID: On Mon, 19 Dec 2022 20:56:14 GMT, Jonathan Gibbons wrote: > Please review a fix for the golden-file for a test, required after quotes in resources were fixed in JDK-8298943. This pull request has now been integrated. Changeset: 5d330f52 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/5d330f5285b535b37dde5cd4e42374d92fafb550 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/11732 From duke at openjdk.org Mon Dec 19 21:14:54 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 19 Dec 2022 21:14:54 GMT Subject: RFR: JDK-8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 In-Reply-To: References: Message-ID: <6m0JtLRxs79NtQPKhWQiO3hCFnTLI5T6luFEtkINi4w=.c3075cda-6256-410c-ae68-0c085a809c8a@github.com> On Mon, 19 Dec 2022 20:56:14 GMT, Jonathan Gibbons wrote: > Please review a fix for the golden-file for a test, required after quotes in resources were fixed in JDK-8298943. Oops - my fault. Thanks for fixing. ------------- PR: https://git.openjdk.org/jdk/pull/11732 From jwilhelm at openjdk.org Tue Dec 20 11:13:46 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 20 Dec 2022 11:13:46 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8298784: JFR: Test chunk integrity - 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false" - 4958969: ObjectOutputStream example leads to non-working code - 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus - 8277074: Qualified exported types show up in JavaDoc - 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 - 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display - ... and 6 more: https://git.openjdk.org/jdk/compare/36de61c4...d70f5831 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.1 Changes: https://git.openjdk.org/jdk/pull/11739/files Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod Patch: https://git.openjdk.org/jdk/pull/11739.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739 PR: https://git.openjdk.org/jdk/pull/11739 From jwilhelm at openjdk.org Tue Dec 20 11:47:31 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 20 Dec 2022 11:47:31 GMT Subject: RFR: Merge jdk20 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 20 -> JDK 21 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption Reviewed-by: valeriep, ascarpino - 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException Reviewed-by: serb - 8298974: Add ftcolor.c to imported freetype sources Reviewed-by: serb - 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac Reviewed-by: serb, honkar - 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 Reviewed-by: vromero - 8298943: Missing escapes for single quote marks in compiler.properties Reviewed-by: jjg - 8298701: Cleanup SA entries in ProblemList-zgc.txt. Reviewed-by: sspitsyn, amenkov - 8298470: Short cut java.lang.Object super class loading Reviewed-by: dholmes, iklam - 8299022: Linux ppc64le and s390x build issues after JDK-8160404 Reviewed-by: mdoerr, lucy - ... and 97 more: https://git.openjdk.org/jdk/compare/3dd2cfab...d70f5831 ------------- Changes: https://git.openjdk.org/jdk/pull/11739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=01 Stats: 13539 lines in 425 files changed: 8409 ins; 3097 del; 2033 mod Patch: https://git.openjdk.org/jdk/pull/11739.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739 PR: https://git.openjdk.org/jdk/pull/11739 From jwilhelm at openjdk.org Tue Dec 20 11:47:33 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 20 Dec 2022 11:47:33 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 10:57:44 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: c5a4a7a6 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0 Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/11739 From jjg at openjdk.org Tue Dec 20 23:20:43 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 20 Dec 2022 23:20:43 GMT Subject: RFR: JDK-8286311: remove boilerplate from use of runTests Message-ID: Please review a test-only cleanup for JDK 21. There are two mostly-automated (IDE) changes here: 1. Remove redundant boiler-plate arguments from calls to `JavadocTester.runTests()`. The use of a function to derive and provide a method-specific directory because unnecessary with JDK- 2. Use `var` for the declaration of the `tester` variable found in the `main` method of most javadoc tests. The changes were mostly done with IDEA _Replace in Files..._, with some manual fixup for some outlying cases found while checking the code. ------------- Commit messages: - JDK-8286311: remove boilerplate from use of runTests Changes: https://git.openjdk.org/jdk/pull/11746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11746&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286311 Stats: 345 lines in 269 files changed: 0 ins; 0 del; 345 mod Patch: https://git.openjdk.org/jdk/pull/11746.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11746/head:pull/11746 PR: https://git.openjdk.org/jdk/pull/11746 From hannesw at openjdk.org Wed Dec 21 10:47:50 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 21 Dec 2022 10:47:50 GMT Subject: RFR: JDK-8286311: remove boilerplate from use of runTests In-Reply-To: References: Message-ID: <6Uu0ksDvHzTCkpobm6Yh-MoMXroupHXWtLY6X-XmlrA=.bf1db62c-7bc0-42ce-91d4-9b284c6d6f5b@github.com> On Tue, 20 Dec 2022 23:13:25 GMT, Jonathan Gibbons wrote: > Please review a test-only cleanup for JDK 21. > > There are two mostly-automated (IDE) changes here: > > 1. Remove redundant boiler-plate arguments from calls to `JavadocTester.runTests()`. The use of a function to derive and provide a method-specific directory because unnecessary with JDK- > 2. Use `var` for the declaration of the `tester` variable found in the `main` method of most javadoc tests. > > The changes were mostly done with IDEA _Replace in Files..._, with some manual fixup for some outlying cases found while checking the code. Should the copyright header dates also be updated on all tests, or are these changes to small to require that? ------------- PR: https://git.openjdk.org/jdk/pull/11746 From jjg at openjdk.org Wed Dec 21 15:38:49 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 21 Dec 2022 15:38:49 GMT Subject: RFR: JDK-8286311: remove boilerplate from use of runTests In-Reply-To: <6Uu0ksDvHzTCkpobm6Yh-MoMXroupHXWtLY6X-XmlrA=.bf1db62c-7bc0-42ce-91d4-9b284c6d6f5b@github.com> References: <6Uu0ksDvHzTCkpobm6Yh-MoMXroupHXWtLY6X-XmlrA=.bf1db62c-7bc0-42ce-91d4-9b284c6d6f5b@github.com> Message-ID: On Wed, 21 Dec 2022 10:44:47 GMT, Hannes Walln?fer wrote: > Should the copyright header dates also be updated on all tests, or are these changes to small to require that? The changes are pretty small. I'll post an update if you think that is important. ------------- PR: https://git.openjdk.org/jdk/pull/11746 From jjg at openjdk.org Wed Dec 21 16:47:42 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 21 Dec 2022 16:47:42 GMT Subject: RFR: JDK-8286311: remove boilerplate from use of runTests [v2] In-Reply-To: References: Message-ID: > Please review a test-only cleanup for JDK 21. > > There are two mostly-automated (IDE) changes here: > > 1. Remove redundant boiler-plate arguments from calls to `JavadocTester.runTests()`. The use of a function to derive and provide a method-specific directory because unnecessary with JDK- > 2. Use `var` for the declaration of the `tester` variable found in the `main` method of most javadoc tests. > > The changes were mostly done with IDEA _Replace in Files..._, with some manual fixup for some outlying cases found while checking the code. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: update copyrights ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11746/files - new: https://git.openjdk.org/jdk/pull/11746/files/877d4470..59d9946f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11746&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11746&range=00-01 Stats: 214 lines in 214 files changed: 0 ins; 0 del; 214 mod Patch: https://git.openjdk.org/jdk/pull/11746.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11746/head:pull/11746 PR: https://git.openjdk.org/jdk/pull/11746 From jjg at openjdk.org Wed Dec 21 16:51:53 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 21 Dec 2022 16:51:53 GMT Subject: RFR: JDK-8286311: remove boilerplate from use of runTests [v2] In-Reply-To: References: Message-ID: <70ixUISbyTOSvAsYg_2nSD_5nxiSuX9dkzsYMbXrLtk=.2b7289cd-2d4f-4d70-922e-d26a15db2b98@github.com> On Wed, 21 Dec 2022 16:47:42 GMT, Jonathan Gibbons wrote: >> Please review a test-only cleanup for JDK 21. >> >> There are two mostly-automated (IDE) changes here: >> >> 1. Remove redundant boiler-plate arguments from calls to `JavadocTester.runTests()`. The use of a function to derive and provide a method-specific directory because unnecessary with JDK- >> 2. Use `var` for the declaration of the `tester` variable found in the `main` method of most javadoc tests. >> >> The changes were mostly done with IDEA _Replace in Files..._, with some manual fixup for some outlying cases found while checking the code. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > update copyrights I've updated the copyrights, using a script to do so. I eyeballed the latest diffs and they look OK. That being said, one file stood out as having an incorrectly indented legal header block. It was TestReporterStreams.java. I'll fix that separately, to avoid overloading this PR even more. ------------- PR: https://git.openjdk.org/jdk/pull/11746 From jjg at openjdk.org Wed Dec 21 17:13:43 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 21 Dec 2022 17:13:43 GMT Subject: RFR: JDK-8299224: TestReporterStreams.java has bad indentation for legal header Message-ID: Please review a trivial fix to update the indentation of the legal header in a test file. ------------- Commit messages: - JDK-8299224: TestReporterStreams.java has bad indentation for legal header Changes: https://git.openjdk.org/jdk/pull/11757/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11757&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299224 Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/11757.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11757/head:pull/11757 PR: https://git.openjdk.org/jdk/pull/11757 From hannesw at openjdk.org Thu Dec 22 11:06:50 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 22 Dec 2022 11:06:50 GMT Subject: RFR: JDK-8286311: remove boilerplate from use of runTests [v2] In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 16:47:42 GMT, Jonathan Gibbons wrote: >> Please review a test-only cleanup for JDK 21. >> >> There are two mostly-automated (IDE) changes here: >> >> 1. Remove redundant boiler-plate arguments from calls to `JavadocTester.runTests()`. The use of a function to derive and provide a method-specific directory because unnecessary with JDK- >> 2. Use `var` for the declaration of the `tester` variable found in the `main` method of most javadoc tests. >> >> The changes were mostly done with IDEA _Replace in Files..._, with some manual fixup for some outlying cases found while checking the code. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > update copyrights I wouldn't have insisted on updating the header dates. The fact that you did so in an automated way makes me feel better about the fact that I made you do so. Looks good! ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.org/jdk/pull/11746 From jjg at openjdk.org Thu Dec 22 21:23:58 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 22 Dec 2022 21:23:58 GMT Subject: Integrated: JDK-8286311: remove boilerplate from use of runTests In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 23:13:25 GMT, Jonathan Gibbons wrote: > Please review a test-only cleanup for JDK 21. > > There are two mostly-automated (IDE) changes here: > > 1. Remove redundant boiler-plate arguments from calls to `JavadocTester.runTests()`. The use of a function to derive and provide a method-specific directory because unnecessary with JDK- > 2. Use `var` for the declaration of the `tester` variable found in the `main` method of most javadoc tests. > > The changes were mostly done with IDEA _Replace in Files..._, with some manual fixup for some outlying cases found while checking the code. This pull request has now been integrated. Changeset: 2294f225 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/2294f225c074516abd2fecf5c64e2e1a2453bc6f Stats: 559 lines in 269 files changed: 0 ins; 0 del; 559 mod 8286311: remove boilerplate from use of runTests Reviewed-by: hannesw ------------- PR: https://git.openjdk.org/jdk/pull/11746 From mernst at openjdk.org Tue Dec 27 14:26:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Dec 2022 14:26:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v3] In-Reply-To: References: Message-ID: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge ../jdk-openjdk into typos-typos - Reinstate typos in Apache code that is copied into the JDK - Merge ../jdk-openjdk into typos-typos - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos ------------- Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02 Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Tue Dec 27 14:26:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Dec 2022 14:26:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai wrote: >> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. > >> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. > > I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs. Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes. I have pulled master and resolved merge conflicts. Only 11 typo fixes remain. Could someone shepherd those into the codebase? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jnimeh at openjdk.org Wed Dec 28 16:06:40 2022 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 28 Dec 2022 16:06:40 GMT Subject: [jdk20] RFR: 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics Message-ID: This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements. This is similar to what has already been done for AES and GHASH diagnostic flags. - JBS: https://bugs.openjdk.org/browse/JDK-8298592 - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 ) ------------- Commit messages: - 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics Changes: https://git.openjdk.org/jdk20/pull/78/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=78&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298592 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk20/pull/78.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/78/head:pull/78 PR: https://git.openjdk.org/jdk20/pull/78 From jnimeh at openjdk.org Thu Dec 29 15:47:37 2022 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 29 Dec 2022 15:47:37 GMT Subject: [jdk20] RFR: 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics [v2] In-Reply-To: References: Message-ID: > This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements. This is similar to what has already been done for AES and GHASH diagnostic flags. > > - JBS: https://bugs.openjdk.org/browse/JDK-8298592 > - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 ) Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Add highlighting for intrinsic diag switch title ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/78/files - new: https://git.openjdk.org/jdk20/pull/78/files/83b7df59..4b0c4cd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=78&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=78&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk20/pull/78.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/78/head:pull/78 PR: https://git.openjdk.org/jdk20/pull/78 From weijun at openjdk.org Thu Dec 29 20:47:02 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 29 Dec 2022 20:47:02 GMT Subject: [jdk20] RFR: 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics [v2] In-Reply-To: References: Message-ID: On Thu, 29 Dec 2022 15:47:37 GMT, Jamil Nimeh wrote: >> This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements. This is similar to what has already been done for AES and GHASH diagnostic flags. >> >> - JBS: https://bugs.openjdk.org/browse/JDK-8298592 >> - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 ) > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Add highlighting for intrinsic diag switch title Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/78 From jnimeh at openjdk.org Thu Dec 29 22:38:01 2022 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 29 Dec 2022 22:38:01 GMT Subject: [jdk20] Integrated: 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics In-Reply-To: References: Message-ID: <7u_1vMLUmsiYoCiAvJC1D6ayHzfLN-vsyXIgU5bhJrU=.c5a803a9-ad97-4616-8c16-801121d4e732@github.com> On Wed, 28 Dec 2022 15:54:49 GMT, Jamil Nimeh wrote: > This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements. This is similar to what has already been done for AES and GHASH diagnostic flags. > > - JBS: https://bugs.openjdk.org/browse/JDK-8298592 > - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 ) This pull request has now been integrated. Changeset: 37f8b059 Author: Jamil Nimeh URL: https://git.openjdk.org/jdk20/commit/37f8b059c1c9245e7f3af90d6ed47c862fee54a3 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk20/pull/78 From rmarchenko at azul.com Tue Dec 27 10:28:41 2022 From: rmarchenko at azul.com (Roman Marchenko) Date: Tue, 27 Dec 2022 10:28:41 +0000 Subject: Docs generated by Java8 Javadoc are incompatible with "javadoc -source 8" In-Reply-To: References: <7bed1a7f-8040-4c39-7f55-f8604702ee64@oracle.com> <03a4f213-e12b-99c7-69fe-3617ed5cf05e@oracle.com> <9ac9cd49-19ad-505d-855d-dccf6b306919@oracle.com> Message-ID: Hi Jon and Hannes, Thank you for reviewing my proposal. As far as I understand, it's suggested to use element/package-list file presence rather than using "-source" option to determine a type of anchors. This is needed because there are docs generated by some "recent" code, so, in case of a fix, we would like to keep backward compatibility and satisfy all the cases. I tried some experiments with javadoc and 3rd party libs, and I've found Dagger library. Its docs are located here https://dagger.dev/api/2.0/. Dagger docs contain "package-list" file. Additionally, headers of html files contain "HTML 4" marks. However, all its anchors are "new" style, e.g. https://dagger.dev/api/2.0/dagger/Lazy.html#get(). I have no idea how it could happen. Is this case a kind of a bug or was it generated by some "legal" version of javadoc we need to support? Perhaps it could be analyzed through all the pages to find a link to any class method to determine a type of anchors, but, I guess, this approach is too complicated. Also there is another minor question. We've got the scenario with URL redirection when URL is not found by a server. For example, URL "https://docs.oracle.com/javase/8/docs/api/element-list" currently will be redirected to "https://docs.oracle.com/en/java/javase/19/" since element-list cannot be found. I suppose it can be processed by detecting that redirection occurred and re-reading the link to find "package-list". Roman -----Original Message----- From: Hannes Wallnoefer Sent: Monday, December 12, 2022 5:35 PM To: Roman Marchenko Cc: javadoc-dev at openjdk.org; Jonathan Gibbons Subject: Re: [External] : RE: Docs generated by Java8 Javadoc are incompatible with "javadoc -source 8" Hi Roman, In case you want to refine your fix, I think Jon?s comment on the JBS issue provides a good approach for detecting which format to use: https://bugs.openjdk.org/browse/JDK-8297437 Package/element lists are read in class `jdk.javadoc.internal.doclets.toolkit.util.Extern`, so I guess this is where you would want to implement this. Hannes > On 9 Dec 2022, at 17:51, Jonathan Gibbons wrote: > > Roman, > > You are welcome to file a PR, subject to OCA rules, etc, but that being said, your comparison does not seem like a valid fix for JDK-8297437. > > Once again, I emphasise to you that the `--source` option is not a valid way to determine the output format, as you do in these lines of getValidHtmlName. > > { > > > SourceVersion srcVer = configuration.docEnv.getSourceVersion(); > > > if (SourceVersion.RELEASE_8 != srcVer && SourceVersion.RELEASE_9 != srcVer) { > > > return name; > > > } > > > } > > If nothing else, the code above makes far too simple a choice: the correct choice will depend on the library being linked to. When running javadoc on some "recent" code, some of the libraries being linked to may have been generated by JDK8-era javadoc (with HTML4-style ids) and others may have been generated by more recent versions of javadoc (with HTML5-style ids). > > -- Jon