Re: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote: >> This issue is responsible for updating the translations of all the >> localize(able) resources in the JDK. Primarily, the changes between JDK 22 >> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. >> >> The translation tool adjusted some definitions, which causes some changes in >> localized files where the source file had no changes. This causes some words >> being reverted from localized languages to English, and some had its >> definitions changed. >> >> Alternatively, the diffs are viewable here and was generated using Jonathan >> Gibbons' diff tool for l10n: >> https://cr.openjdk.org/~dnguyen/output2/ > > Damon Nguyen has updated the pull request incrementally with one additional > commit since the last revision: > > Remove double quotes I was asked to have a look at this PR elsewhere. I cannot verify correctness of translation, but I can review this PR generally for `jdk.javadoc`. >From what I can see, the changes are only to the property files, which is >expected from the PR title. The keys from English files 1-1 match the keys >from non-English files: there are no missing or extra keys. >From that point of view, the changes to `jdk.javadoc` look good. - Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2110098592
Withdrawn: 8330205: Initial troff manpage generation for JDK 24
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/19119
Re: RFR: 8330205: Initial troff manpage generation for JDK 24
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. Withdrawing this, as a different approach is required. - PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-282078
Re: RFR: 8330205: Initial troff manpage generation for JDK 24
On Thu, 9 May 2024 08:18:41 GMT, David Holmes wrote: >> Please review this mechanical change to man pages. This PR should be >> integrated after https://github.com/openjdk/jdk/pull/18787. > > src/java.base/share/man/java.1 line 3856: > >> 3854: .SH REMOVED JAVA OPTIONS >> 3855: .PP >> 3856: These \f[V]java\f[R] options have been removed in JDK 24 and using them > > This is incorrect. You can't just change 23 to 24 here as the actual set of > flags listed below will be will be different. David, my understanding is that you agree that this is okay (per our out-of-band, follow-up discussion). - PR Review Comment: https://git.openjdk.org/jdk/pull/19119#discussion_r1598432769
Re: RFR: 8330205: Initial troff manpage generation for JDK 24
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. Thanks for reviewing it Joe, I'm now delegating integration of this PR to @JesperIRL, you, or anyone who will be integrating https://github.com/openjdk/jdk/pull/18787. - PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2099395990
Re: RFR: 8330205: Initial troff manpage generation for JDK 24
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. This PR is standalone as opposed to dependent because the https://github.com/openjdk/jdk/pull/18787 dependency currently has a merge conflict, which complicates the required workflow. This comment serves as a reminder to merge master into this PR once https://github.com/openjdk/jdk/pull/18787 has been integrated. If we don't do that, Skara will likely create a backport issue: > (⚠️ The fixVersion in this issue is [24] but the fixVersion in .jcheck/conf > is 23, a new backport will be created when this pr is integrated.) - PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2098246931
RFR: 8330205: Initial troff manpage generation for JDK 24
Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/19119/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19119=00 Issue: https://bugs.openjdk.org/browse/JDK-8330205 Stats: 30 lines in 28 files changed: 0 ins; 0 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/19119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19119/head:pull/19119 PR: https://git.openjdk.org/jdk/pull/19119
Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when it is
> time to consider whether to generate the diagnostic or not.
>
> 2. Updates to the `javac` front end to record "dangling docs comments" found
> near the beginning of a declaration, and to report them using an instance of
> `DeferredLintHandler`. This allows the warnings to be enabled or disabled
> using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The
> procedure for handling dangling doc comments is described in this comment in
> `JavacParser`.
>
> * Dangling documentation comments are handled as follows.
> * 1. {@code Scanner} adds all doc comments to a queue of
> * recent doc comments. The queue is flushed whenever
> * it is known that the recent doc comments should be
> * ignored and should not cause any warnings.
> * 2. The primary documentation comment is the one obtained
> * from the first token of any declaration.
> * (using {@code token.getDocComment()}.
> * 3. At the end of the "signature" of the declaration
> * (that is, before any initialization or body for the
> * declaration) any other "recent" comments are saved
> * in a map using the primary comment as a key,
> * using this method, {@code saveDanglingComments}.
> * 4. When the tree node for the declaration is finally
> * available, and the primary comment, if any,
> * is "attached", (in {@link #attach}) any related
> * dangling comments are also attached to the tree node
> * by registering them using the {@link #deferredLintHandler}.
> * 5. (Later) Warnings may be genereated for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` to
> create box or other standout comments.
src/jdk.javadoc/share/man/javadoc.1 line 111:
> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more
> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R].
> 111: Within a source file, you may use suppress any warnings generated by
Typo?
Suggestion:
Within a source file, you may suppress any warnings generated by
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542131487
Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when it is
> time to consider whether to generate the diagnostic or not.
>
> 2. Updates to the `javac` front end to record "dangling docs comments" found
> near the beginning of a declaration, and to report them using an instance of
> `DeferredLintHandler`. This allows the warnings to be enabled or disabled
> using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The
> procedure for handling dangling doc comments is described in this comment in
> `JavacParser`.
>
> * Dangling documentation comments are handled as follows.
> * 1. {@code Scanner} adds all doc comments to a queue of
> * recent doc comments. The queue is flushed whenever
> * it is known that the recent doc comments should be
> * ignored and should not cause any warnings.
> * 2. The primary documentation comment is the one obtained
> * from the first token of any declaration.
> * (using {@code token.getDocComment()}.
> * 3. At the end of the "signature" of the declaration
> * (that is, before any initialization or body for the
> * declaration) any other "recent" comments are saved
> * in a map using the primary comment as a key,
> * using this method, {@code saveDanglingComments}.
> * 4. When the tree node for the declaration is finally
> * available, and the primary comment, if any,
> * is "attached", (in {@link #attach}) any related
> * dangling comments are also attached to the tree node
> * by registering them using the {@link #deferredLintHandler}.
> * 5. (Later) Warnings may be genereated for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` to
> create box or other standout comments.
Javadoc changes look trivially good. I only note that the javadoc man page diff
contains some unrelated changes.
-
PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024116236
Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when it is
> time to consider whether to generate the diagnostic or not.
>
> 2. Updates to the `javac` front end to record "dangling docs comments" found
> near the beginning of a declaration, and to report them using an instance of
> `DeferredLintHandler`. This allows the warnings to be enabled or disabled
> using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The
> procedure for handling dangling doc comments is described in this comment in
> `JavacParser`.
>
> * Dangling documentation comments are handled as follows.
> * 1. {@code Scanner} adds all doc comments to a queue of
> * recent doc comments. The queue is flushed whenever
> * it is known that the recent doc comments should be
> * ignored and should not cause any warnings.
> * 2. The primary documentation comment is the one obtained
> * from the first token of any declaration.
> * (using {@code token.getDocComment()}.
> * 3. At the end of the "signature" of the declaration
> * (that is, before any initialization or body for the
> * declaration) any other "recent" comments are saved
> * in a map using the primary comment as a key,
> * using this method, {@code saveDanglingComments}.
> * 4. When the tree node for the declaration is finally
> * available, and the primary comment, if any,
> * is "attached", (in {@link #attach}) any related
> * dangling comments are also attached to the tree node
> * by registering them using the {@link #deferredLintHandler}.
> * 5. (Later) Warnings may be genereated for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` to
> create box or other standout comments.
Would this be the first lint -- not doclint -- warning related to comments, let
alone doc comments?
-
PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024106466
Re: RFR: 8325109: Sort method modifiers in canonical order
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few > do not involve `static` but instead puts `final` or `abstract` in the correct > place. > > I have deliberately stayed away from `default` in this PR, since they should > probably get a more thorough treatment, see > https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Changes to jdk.javadoc look fine. - Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857871131
Re: RFR: 8322065: Initial nroff manpage generation for JDK 23
On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & > jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK > 23 backport) > - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) > > > In addition this includes the updates for > > - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags > in JDK 23 > > Thanks > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > * [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline. - PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855467435
Integrated: 8314738: Remove all occurrences of and support for @revised
On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo wrote: > Please review this simple PR. This pull request has now been integrated. Changeset: f39fc0aa Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/f39fc0aa2de19332fa51af605ece0660891d8c7a Stats: 124 lines in 28 files changed: 0 ins; 116 del; 8 mod 8314738: Remove all occurrences of and support for @revised Reviewed-by: mr - PR: https://git.openjdk.org/jdk/pull/15382
Re: RFR: 8314738: Remove all occurrences of and support for @revised
On Tue, 22 Aug 2023 12:23:18 GMT, Mark Reinhold wrote: > I wouldn’t update the copyright year as you have in some of these files. I was taught to do it every time when I change a file. Would you like me to revert those changes to copyright years in this case? - PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688086627
RFR: 8314738: Remove all occurrences of and support for @revised
Please review this simple PR. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/15382/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15382=00 Issue: https://bugs.openjdk.org/browse/JDK-8314738 Stats: 124 lines in 28 files changed: 0 ins; 116 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15382/head:pull/15382 PR: https://git.openjdk.org/jdk/pull/15382
Re: RFR: 8304919: Implementation of Virtual Threads [v2]
On Tue, 28 Mar 2023 23:47:02 GMT, Leonid Mesnik wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>> commits since the last revision:
>>
>> - ThreadSleepEvent refactoring
>> - Merge
>> - Merge
>> - Initial sync from fibers branch
>
> src/java.base/share/classes/java/lang/System.java line 2566:
>
>> 2564:
>> 2565: public V executeOnCarrierThread(Callable task)
>> throws Exception {
>> 2566: if (Thread.currentThread() instanceof VirtualThread
>> vthread) {
>
> Any specific reason to don't use Thread.currentThread().isVirtual()?
To use the pattern variable to call `executeOnCarrierThread` on it?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151270089
Integrated: 8303480: Miscellaneous fixes to mostly invisible doc comments
On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by > unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation > (i.e. the observable effect on the generated HTML pages) can be summarized as > follows: > > > diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html > build/macosx-aarch64/images/docs-after/api/serialized-form.html > --- build/macosx-aarch64/images/docs-before/api/serialized-form.html > 2023-03-02 11:47:44 > +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html > 2023-03-02 11:48:45 > @@ -17084,7 +17084,7 @@ > throws href="java.base/java/io/IOException.html" title="class in > java.io">IOException, > ClassNotFoundException > readObject is called to restore the > state of the > - (@code BasicPermission} from a stream. > + BasicPermission from a stream. > > Parameters: > s - the ObjectInputStream from which data > is read > > Notes > - > > * I'm not an expert in any of the affected areas, except for jdk.javadoc, and > I was merely after misused tags. Because of that, I would appreciate reviews > from experts in other areas. > * I discovered many more issues than I included in this PR. The excluded > issues seem to occur in infrequently updated third-party code (e.g. > javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as > required. This pull request has now been integrated. Changeset: 45a616a8 Author:Pavel Rappo URL: https://git.openjdk.org/jdk/commit/45a616a891e4a4b0e77b1f2fa040522f4a99d172 Stats: 75 lines in 39 files changed: 0 ins; 0 del; 75 mod 8303480: Miscellaneous fixes to mostly invisible doc comments Reviewed-by: mullan, prr, cjplummer, aivanov, jjg, lancea, rriggs, ihse - PR: https://git.openjdk.org/jdk/pull/12826
Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2]
> Please review this superficial documentation cleanup that was triggered by > unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation > (i.e. the observable effect on the generated HTML pages) can be summarized as > follows: > > > diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html > build/macosx-aarch64/images/docs-after/api/serialized-form.html > --- build/macosx-aarch64/images/docs-before/api/serialized-form.html > 2023-03-02 11:47:44 > +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html > 2023-03-02 11:48:45 > @@ -17084,7 +17084,7 @@ > throws href="java.base/java/io/IOException.html" title="class in > java.io">IOException, > ClassNotFoundException > readObject is called to restore the > state of the > - (@code BasicPermission} from a stream. > + BasicPermission from a stream. > > Parameters: > s - the ObjectInputStream from which data > is read > > Notes > - > > * I'm not an expert in any of the affected areas, except for jdk.javadoc, and > I was merely after misused tags. Because of that, I would appreciate reviews > from experts in other areas. > * I discovered many more issues than I included in this PR. The excluded > issues seem to occur in infrequently updated third-party code (e.g. > javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as > required. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8303480 - Initial commit - Changes: - all: https://git.openjdk.org/jdk/pull/12826/files - new: https://git.openjdk.org/jdk/pull/12826/files/d2f4a553..87166408 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=12826=01 - incr: https://webrevs.openjdk.org/?repo=jdk=12826=00-01 Stats: 13433 lines in 415 files changed: 9003 ins; 2610 del; 1820 mod Patch: https://git.openjdk.org/jdk/pull/12826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826 PR: https://git.openjdk.org/jdk/pull/12826
Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
On Fri, 3 Mar 2023 08:15:49 GMT, Alexey Ivanov wrote:
>> Please review this superficial documentation cleanup that was triggered by
>> unrelated analysis of doc comments in JDK API.
>>
>> The only effect that this multi-area PR has on the JDK API Documentation
>> (i.e. the observable effect on the generated HTML pages) can be summarized
>> as follows:
>>
>>
>> diff -ur
>> build/macosx-aarch64/images/docs-before/api/serialized-form.html
>> build/macosx-aarch64/images/docs-after/api/serialized-form.html
>> --- build/macosx-aarch64/images/docs-before/api/serialized-form.html
>> 2023-03-02 11:47:44
>> +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html
>> 2023-03-02 11:48:45
>> @@ -17084,7 +17084,7 @@
>> throws > href="java.base/java/io/IOException.html" title="class in
>> java.io">IOException,
>> ClassNotFoundException
>> readObject is called to restore the
>> state of the
>> - (@code BasicPermission} from a stream.
>> + BasicPermission from a stream.
>>
>> Parameters:
>> s - the ObjectInputStream from which data
>> is read
>>
>> Notes
>> -
>>
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc,
>> and I was merely after misused tags. Because of that, I would appreciate
>> reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded
>> issues seem to occur in infrequently updated third-party code (e.g.
>> javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as
>> required.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:
>
>> 2864: * Merge multiple abstract methods. The preferred method is a
>> method that is a subsignature
>> 2865: * of all the other signatures and whose return type is more
>> specific {@link MostSpecificReturnCheck}.
>> 2866: * The resulting preferred method has a thrown clause that is the
>> intersection of the merged
>
> Is it “…has a {@code throws} clause…”?
Thanks! I'll add this to a separate PR.
-
PR: https://git.openjdk.org/jdk/pull/12826
Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
On Thu, 2 Mar 2023 16:23:17 GMT, Alexey Ivanov wrote:
>> Please review this superficial documentation cleanup that was triggered by
>> unrelated analysis of doc comments in JDK API.
>>
>> The only effect that this multi-area PR has on the JDK API Documentation
>> (i.e. the observable effect on the generated HTML pages) can be summarized
>> as follows:
>>
>>
>> diff -ur
>> build/macosx-aarch64/images/docs-before/api/serialized-form.html
>> build/macosx-aarch64/images/docs-after/api/serialized-form.html
>> --- build/macosx-aarch64/images/docs-before/api/serialized-form.html
>> 2023-03-02 11:47:44
>> +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html
>> 2023-03-02 11:48:45
>> @@ -17084,7 +17084,7 @@
>> throws > href="java.base/java/io/IOException.html" title="class in
>> java.io">IOException,
>> ClassNotFoundException
>> readObject is called to restore the
>> state of the
>> - (@code BasicPermission} from a stream.
>> + BasicPermission from a stream.
>>
>> Parameters:
>> s - the ObjectInputStream from which data
>> is read
>>
>> Notes
>> -
>>
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc,
>> and I was merely after misused tags. Because of that, I would appreciate
>> reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded
>> issues seem to occur in infrequently updated third-party code (e.g.
>> javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as
>> required.
>
> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line
> 257:
>
>> 255:
>> 256: /**
>> 257: * @return true iff the BSM method type exactly matches
>
> I assume “iff” should “if”?
Here and elsewhere in this file "iff" might mean [if and only
if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense.
(FWIW, there are a few hundred occurrences of the word "iff" in src.)
@cl4es (Claes Redestad), as the author of those lines would you like to chime
in?
Since Claes might read this, I note that when I changed unsupported `{@see}` to
`{@link}` thoughtout this file, my IDE could not resolve one of the links:
`java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`
While there's a similarly-name method with slightly different parameters, I
refrained from using it:
`java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.
-
PR: https://git.openjdk.org/jdk/pull/12826
RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html --- build/macosx-aarch64/images/docs-before/api/serialized-form.html 2023-03-02 11:47:44 +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html 2023-03-02 11:48:45 @@ -17084,7 +17084,7 @@ throws IOException, ClassNotFoundException readObject is called to restore the state of the - (@code BasicPermission} from a stream. + BasicPermission from a stream. Parameters: s - the ObjectInputStream from which data is read Notes - * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas. * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary. * I will update copyright years after (and if) the fix had been approved, as required. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/12826/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12826=00 Issue: https://bugs.openjdk.org/browse/JDK-8303480 Stats: 75 lines in 39 files changed: 0 ins; 0 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/12826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826 PR: https://git.openjdk.org/jdk/pull/12826
Re: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
On Wed, 25 Jan 2023 18:00:33 GMT, Weijun Wang wrote: >> The translation tool didn't seem to translate this. Either because it >> couldn't or because it somehow missed it. I'm not sure which, but I'm open >> to replacing this with a translation suggestion you have. Or I can leave it >> as is. > > I'm not sure either. You can ask a javadoc expert whether this is a proper > noun or just plain English. I noticed it's also not translated in the > Japanese version but the German version has translated it. It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows: doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \ that are not declared by a method; document such exception types directly JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type. @jonathan-gibbons thoughts? - PR: https://git.openjdk.org/jdk20/pull/116
Integrated: 8296953: Fix a typo in exception documentation
On Mon, 14 Nov 2022 19:04:49 GMT, Pavel Rappo wrote: > Please review this trivial documentation change that fixes a typo > accidentally found while comparing javadoc output for an unrelated change in > jdk.javadoc. This pull request has now been integrated. Changeset: 97ab2c3e Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/97ab2c3ea61daa32ab51506fefa42d486121e089 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8296953: Fix a typo in exception documentation Reviewed-by: cjplummer, dfuchs - PR: https://git.openjdk.org/jdk/pull/11140
RFR: 8296953: Fix a typo in exception documentation
Please review this trivial documentation change that fixes a typo accidentally found while comparing javadoc output for an unrelated change in jdk.javadoc. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/11140/files Webrev: https://webrevs.openjdk.org/?repo=jdk=11140=00 Issue: https://bugs.openjdk.org/browse/JDK-8296953 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11140.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11140/head:pull/11140 PR: https://git.openjdk.org/jdk/pull/11140
