On Fri, 3 Mar 2023 08:15:49 GMT, Alexey Ivanov <aiva...@openjdk.org> 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. > > 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