On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <[email protected]> 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 <span class="exceptions"><a
> href="java.base/java/io/IOException.html" title="class in
> java.io">IOException</a>,
> <a href="java.base/java/lang/ClassNotFoundException.html" title="class
> in java.lang">ClassNotFoundException</a></span></div>
> <div class="block"><code>readObject</code> is called to restore the
> state of the
> - (@code BasicPermission} from a stream.</div>
> + <code>BasicPermission</code> from a stream.</div>
> <dl class="notes">
> <dt>Parameters:</dt>
> <dd><code>s</code> - the <code>ObjectInputStream</code> from which data
> is read</dd>
>
> 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.
Looks good to me.
I looked through all the changes, paying more attention to the client area.
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”?
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…”?
-------------
Marked as reviewed by aivanov (Reviewer).
PR: https://git.openjdk.org/jdk/pull/12826
