Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5]
On Fri, 29 Apr 2022 08:45:42 GMT, Pavel Rappo wrote: > Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. I've created a PR; feel free to review it at your convenience. - PR: https://git.openjdk.java.net/jdk/pull/8410
Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5]
On Thu, 28 Apr 2022 19:06:04 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48:
>>
>>> 46: * The {@link #refersTo(Object) refersTo} method can be used to test
>>> 47: * whether some object is the referent of a phantom reference.
>>> 48: * @param the type of the referent
>>
>> Shouldn't there be a space after `@param` ?
>
> Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files.
> Shouldn't there be a space after `@param` ?
> Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files.
I built the API documentation after this PR has been integrated and the result
was okay. I saw this output in every such case:
Type Parameters:
T - the type of the referent
javadoc is quite robust. However, for some IDEs such missing whitespace seems
significant. Not only do they highlight the `@param` tag, but the type
parameter information is missing from the rendered output.
Although it's not critical, we should fix it; I have filed JDK-8285890.
-
PR: https://git.openjdk.java.net/jdk/pull/8410
Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please > review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated > out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the > doclint checks (JDK-8285496). > > I'll update copyright years before pushing. I note that many years ago you filed JDK-6327933, which I'm currently looking at. If implemented, many of the issues from this PR will be addressed automatically, including those in `java.util.concurrent`. - PR: https://git.openjdk.java.net/jdk/pull/8410
Integrated: 8281057: Fix doc references to overriding in JLS
On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a > number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I > believe that the real target should be "8.4.8. Inheritance, Overriding, and > Hiding" and its subsections. This pull request has now been integrated. Changeset: 1f926609 Author:Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/1f926609372c9b80dde831a014310a3729768c92 Stats: 18 lines in 5 files changed: 0 ins; 0 del; 18 mod 8281057: Fix doc references to overriding in JLS Reviewed-by: darcy, iris, dholmes, cjplummer - PR: https://git.openjdk.java.net/jdk/pull/7311
Re: RFR: 8281057: Fix doc references to overriding in JLS
On Wed, 2 Feb 2022 14:37:39 GMT, Maurizio Cimadamore wrote: >> My guess is that "transitivity" here refers to the subclass relationship >> being the transitive closure of the direct subclass relationship. Could it >> also be that the "quirk" paragraph starting at >> com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore? > > First, this class contains many references to 8.4.6.x - which should really > be 8.4.8.x - not just this one. > > I'm not 100% sure about the "without transitivity" comment, but if I had to > guess I'd say that it refers to the fact that the checks described in 8.4.8.3 > are missing from this routine. More specifically, this section: > > > It is a compile-time error if a class or interface C has a member method m1 > and there exists a method m2 declared in C or a superclass or superinterface > of C, A, such that all of the following are true: > * m1 and m2 have the same name. > * m2 is accessible (§6.6) from C. > * The signature of m1 is not a subsignature (§8.4.2) of the signature of m2 > as a member of the supertype of C that names A. > * The declared signature of m1 or some method m1 overrides (directly or > indirectly) has the same erasure as the declared signature of m2 or some > method m2 overrides (directly or indirectly). <-- > > As you can see, the last bullet introduces some sort of global requirement > across the inheritance chain; this constraint was necessary after Java 5, as > generics require the introduction of bridge methods, and it is possible, in > some extreme cases, for a subclass to override (accidentally) a bridge > method. The JLS doesn't say the word "bridge method" anywhere, but this is > what this check morally does. > > Now, in an early version of the Java compiler (5 and 6, IIRC), we used to > check for clashes with bridge methods at code generation time. So, the checks > in the compiler frontend, such as Symbol::overrides did not really have to > concerb with that expensive side of the override check. > > But, as the implementation matured, it became clearer that (a) the > code-generation clash check was not enough to detect all problematic cases > and (b) detecting clashes at code generation time was *too late*, especially > for clients of the compiler API which might only run the "analyze" step. For > these reasons, staring from Java 7, the frontend also has a more expensive > check which supports 8.4.8.3 in full (Check::checkOverrideClashes). > > Of course, not being the author of that comment, this is only my best guess > as to what that could mean :-) FWIW, I found a related bug: https://bugs.openjdk.java.net/browse/JDK-4362349. It might be responsible for that "(without transitivity)" caveat. - PR: https://git.openjdk.java.net/jdk/pull/7311
Re: RFR: 8281057: Fix doc references to overriding in JLS
On Wed, 2 Feb 2022 12:06:39 GMT, David Holmes wrote:
>> While looking into guts of javadoc comment inheritance, I noticed that a
>> number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
>>
>> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I
>> believe that the real target should be "8.4.8. Inheritance, Overriding, and
>> Hiding" and its subsections.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1793:
>
>> 1791: }
>> 1792:
>> 1793: // Error if static method overrides instance method (JLS
>> 8.4.8.2).
>
> "overrides" should be "hides"
Although you seem to be correct, the error messages and the code around operate
using the term "override":
// Error if static method overrides instance method (JLS 8.4.8.2).
if ((m.flags() & STATIC) != 0 &&
(other.flags() & STATIC) == 0) {
log.error(TreeInfo.diagnosticPositionFor(m, tree),
Errors.OverrideStatic(cannotOverride(m, other)));
m.flags_field |= BAD_OVERRIDE;
return;
}
// Error if instance method overrides static or final
// method (JLS 8.4.8.1).
if ((other.flags() & FINAL) != 0 ||
(m.flags() & STATIC) == 0 &&
(other.flags() & STATIC) != 0) {
log.error(TreeInfo.diagnosticPositionFor(m, tree),
Errors.OverrideMeth(cannotOverride(m, other),
asFlagSet(other.flags() & (FINAL |
STATIC;
m.flags_field |= BAD_OVERRIDE;
return;
}
/**
* compiler.err.override.static=\
*{0}\n\
*overriding method is static
*/
public static Error OverrideStatic(Fragment arg0) {
return new Error("compiler", "override.static", arg0);
}
Compiler folk, what do you think?
-
PR: https://git.openjdk.java.net/jdk/pull/7311
Re: RFR: 8281057: Fix doc references to overriding in JLS
On Wed, 2 Feb 2022 12:04:29 GMT, David Holmes wrote: >> While looking into guts of javadoc comment inheritance, I noticed that a >> number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. >> >> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I >> believe that the real target should be "8.4.8. Inheritance, Overriding, and >> Hiding" and its subsections. > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 670: > >> 668: * modifier is ignored for this test. >> 669: * >> 670: * See JLS 8.4.8.1 (without transitivity) and 8.4.8.4 > > Any idea what the "(without transitivity)" is referring to here and elsewhere? My guess is that "transitivity" here refers to the subclass relationship being the transitive closure of the direct subclass relationship. Could it also be that the "quirk" paragraph starting at com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore? - PR: https://git.openjdk.java.net/jdk/pull/7311
Re: RFR: 8281057: Fix doc references to overriding in JLS
On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a > number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I > believe that the real target should be "8.4.8. Inheritance, Overriding, and > Hiding" and its subsections. I would appreciate it if serviceability and hotspot could review this PR too. - PR: https://git.openjdk.java.net/jdk/pull/7311
RFR: 8281057: Fix doc references to overriding in JLS
While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/7311/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7311&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281057 Stats: 18 lines in 5 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7311.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7311/head:pull/7311 PR: https://git.openjdk.java.net/jdk/pull/7311
Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags. - PR: https://git.openjdk.java.net/jdk/pull/7189
Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build
On Mon, 24 Jan 2022 11:00:37 GMT, Daniel Fuchs wrote:
> LGTM. I hope in the future IDEs will pick that rule up and offer some help
> when writing `{@link }` `@see`...
They will do it quicker, if you create new or support existing bugs in their
bug trackers.
-
PR: https://git.openjdk.java.net/jdk/pull/7189
Integrated: 8279918: Fix various doc typos
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, > please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant > formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. This pull request has now been integrated. Changeset: f1805309 Author:Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/f1805309352a22119ae2edf8bfbb596f00936224 Stats: 88 lines in 35 files changed: 0 ins; 0 del; 88 mod 8279918: Fix various doc typos Reviewed-by: kevinw, lancea, mullan, sspitsyn, naoto, jlahoda, azvegint, egahlin, jjg - PR: https://git.openjdk.java.net/jdk/pull/7063
Re: RFR: 8279918: Fix various doc typos [v2]
> - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, > please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant > formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Additional typos - Changes: - all: https://git.openjdk.java.net/jdk/pull/7063/files - new: https://git.openjdk.java.net/jdk/pull/7063/files/fe81eeca..b256a13f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7063/head:pull/7063 PR: https://git.openjdk.java.net/jdk/pull/7063
Re: RFR: 8279918: Fix various doc typos
On Thu, 13 Jan 2022 11:38:13 GMT, Lance Andersen wrote: > Yes an "or" is probably worthwhile to add. I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql: * java/sql/Statement.java:59 * java/sql/Statement.java:85 * java/sql/Statement.java:346 * java/sql/Statement.java:524 * java/sql/Statement.java:745 * java/sql/Statement.java:814 * java/sql/Statement.java:860 * java/sql/Statement.java:913 * java/sql/Statement.java:962 * java/sql/Statement.java:1225 * java/sql/Statement.java:1269 * java/sql/Statement.java:1314 - PR: https://git.openjdk.java.net/jdk/pull/7063
Re: RFR: 8279918: Fix various doc typos
On Thu, 13 Jan 2022 11:42:48 GMT, Lance Andersen wrote: > The above is a bit confusing as it reads(same in ImageInputStream.java). I > think that that can be looked at later. Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up. - PR: https://git.openjdk.java.net/jdk/pull/7063
Re: RFR: 8279918: Fix various doc typos
On Thu, 13 Jan 2022 11:18:42 GMT, Kevin Walls wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead,
>> please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant
>> formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/Statement.java line 784:
>
>> 782: * statement returns a {@code ResultSet} object, the second argument
>> 783: * supplied to this method is not an
>> 784: * {@code int} array whose elements are valid column indexes, the
>> method is called on a
>
> Should it be "or the method is called on...", i.e. add the "or", otherwise
> it's a list of problems but we don't know if they are all required, or are
> alternatives. It probably does not mean that all these have to be true to
> throw the exception, but it doesn't say that. We are nitpicking of course.
You are right in that this `@throws` description reads a bit weird in its
current form. That said, I wouldn't touch it in this PR for two reasons.
Firstly, this wording seems to be consistent with other locations in that file.
Secondly, this is a spec territory.
-
PR: https://git.openjdk.java.net/jdk/pull/7063
Re: RFR: 8279918: Fix various doc typos
On Thu, 13 Jan 2022 11:00:55 GMT, Kevin Walls wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead,
>> please say so; I will drop those typos from the patch.
>> - As I understand it, in ImageInputStream and DataInput is an irrelevant
>> formatting artefact and thus can be removed.
>> - ' is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
>
>> 56: * A JDBC driver implementation should use
>> 57: * the constructor {@code BatchUpdateException(String reason, String
>> SQLState,
>> 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of
>
> While we are here, is it more normal to say "long[] updateCounts", not
> separating the [] from the type.
> Similarly at line 81, 118, 151, 247, 277, 318, 354.
I thought about it too, but then noticed how the position of `[]` mimics that
of the respective method signatures in code.
-
PR: https://git.openjdk.java.net/jdk/pull/7063
Re: RFR: 8279918: Fix various doc typos
On Thu, 13 Jan 2022 10:46:11 GMT, Kevin Walls wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, >> please say so; I will drop those typos from the patch. >> - As I understand it, in ImageInputStream and DataInput is an irrelevant >> formatting artefact and thus can be removed. >> - ' is an apostrophe, which does not require to be encoded. > > src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73: > >> 71: * will be transparent to the BreakIterator. A sequence of >> characters will break the >> 72: * same way it would if any ignore characters it contains are taken >> out. Break >> 73: * positions never occur before ignore characters. > > "before ignored characters" I believe it's the name of a concept, so I will leave it as is: > There is one special substitution. If the description defines a substitution > called "", the expression must be a [] expression, and the expression > defines a set of characters (the "ignore characters") that will be > transparent to the BreakIterator. - PR: https://git.openjdk.java.net/jdk/pull/7063
RFR: 8279918: Fix various doc typos
- Most of the typos are of a trivial kind: missing whitespace. - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. - ' is an apostrophe, which does not require to be encoded. - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/7063/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279918 Stats: 85 lines in 34 files changed: 0 ins; 0 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/7063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7063/head:pull/7063 PR: https://git.openjdk.java.net/jdk/pull/7063
Re: RFR: 8272992: Replace usages of Collections.sort with List.sort call in jdk.* modules [v4]
On Sat, 25 Sep 2021 11:23:18 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance >> method directly. >> Affected modules: jdk.javadoc, jdk.jcmd, jdk.jconsole > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8272992: Replace usages of Collections.sort with List.sort call in jdk.* > modules > extracted jdk.hotspot.agent changes into separate PR. Rollback them here. I've submitted an extended test job with the 5f75485 commit; if that job shows no issues, I'll sponsor this PR. - PR: https://git.openjdk.java.net/jdk/pull/5230
Re: RFR: 8272992: Replace usages of Collections.sort with List.sort call in jdk.* modules [v4]
On Sat, 25 Sep 2021 11:23:18 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance >> method directly. >> Affected modules: jdk.javadoc, jdk.jcmd, jdk.jconsole > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8272992: Replace usages of Collections.sort with List.sort call in jdk.* > modules > extracted jdk.hotspot.agent changes into separate PR. Rollback them here. Changes to the jdk.javadoc module look good; I can sponsor this PR. - Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5230
Integrated: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap
On Wed, 5 May 2021 15:59:43 GMT, Pavel Rappo wrote: > This fixes two javadoc tag references and several typos. References are fixed > by removing whitespace before the opening `(`. That whitespace caused the > opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern > APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be > changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new > IllegalArgumentException(msg).initCause(e);` could be changed to `throw new > IllegalArgumentException(msg, e);` This pull request has now been integrated. Changeset: 4727187f Author:Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/4727187f86d18d34bd79cf93a74ff4a6515c662e Stats: 12 lines in 1 file changed: 0 ins; 1 del; 11 mod 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap Reviewed-by: dfuchs, sspitsyn - PR: https://git.openjdk.java.net/jdk/pull/3885
Re: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v3]
On Wed, 12 May 2021 00:43:59 GMT, Serguei Spitsyn wrote: > Just one nit is to add a dot at the end of this comment: > 280 // time. It's OK for now as logic in Agent.java forbids multiple agents I added two full stops: one for each unterminated sentence in that inline comment. - PR: https://git.openjdk.java.net/jdk/pull/3885
Re: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v4]
> This fixes two javadoc tag references and several typos. References are fixed > by removing whitespace before the opening `(`. That whitespace caused the > opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern > APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be > changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new > IllegalArgumentException(msg).initCause(e);` could be changed to `throw new > IllegalArgumentException(msg, e);` Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Added missing full stops - Changes: - all: https://git.openjdk.java.net/jdk/pull/3885/files - new: https://git.openjdk.java.net/jdk/pull/3885/files/c8d2c04f..7a834b3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3885/head:pull/3885 PR: https://git.openjdk.java.net/jdk/pull/3885
Re: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v2]
On Wed, 5 May 2021 19:22:11 GMT, Daniel Fuchs wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed more typos
>
> src/jdk.management.agent/share/classes/sun/management/jmxremote/ConnectorBootstrap.java
> line 308:
>
>> 306: public static synchronized JMXConnectorServer initialize() {
>> 307:
>> 308: // Load new management properties
>
> Debatable. I guess what was meant here is:
>
> // Loads a new management Properties instance
>
> Or maybe a better comment text would be:
>
> Load and snapshot management properties
>
> Otherwise LGTM.
I've reverted that particular line.
-
PR: https://git.openjdk.java.net/jdk/pull/3885
Re: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v3]
> This fixes two javadoc tag references and several typos. References are fixed > by removing whitespace before the opening `(`. That whitespace caused the > opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern > APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be > changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new > IllegalArgumentException(msg).initCause(e);` could be changed to `throw new > IllegalArgumentException(msg, e);` Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Reverted a previously fixed typo - Changes: - all: https://git.openjdk.java.net/jdk/pull/3885/files - new: https://git.openjdk.java.net/jdk/pull/3885/files/6eea552e..c8d2c04f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3885/head:pull/3885 PR: https://git.openjdk.java.net/jdk/pull/3885
Re: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v2]
On Wed, 5 May 2021 18:39:14 GMT, Pavel Rappo wrote: >> This fixes two javadoc tag references and several typos. References are >> fixed by removing whitespace before the opening `(`. That whitespace caused >> the opening `(` and the rest of the reference to be parsed as a link label. >> >> Since we are here, I think this class could also benefit from using modern >> APIs. This should be done in a separate PR though. For example: >> >> 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be >> changed to `Boolean.parseBoolean( )` >> 2. `throw (IllegalArgumentException) new >> IllegalArgumentException(msg).initCause(e);` could be changed to `throw new >> IllegalArgumentException(msg, e);` > > Pavel Rappo has updated the pull request incrementally with one additional > commit since the last revision: > > Fixed more typos Daniel, would you kindly review the most recent commit, which fixes three more typos? - PR: https://git.openjdk.java.net/jdk/pull/3885
Re: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v2]
> This fixes two javadoc tag references and several typos. References are fixed > by removing whitespace before the opening `(`. That whitespace caused the > opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern > APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be > changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new > IllegalArgumentException(msg).initCause(e);` could be changed to `throw new > IllegalArgumentException(msg, e);` Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Fixed more typos - Changes: - all: https://git.openjdk.java.net/jdk/pull/3885/files - new: https://git.openjdk.java.net/jdk/pull/3885/files/b8113178..6eea552e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3885/head:pull/3885 PR: https://git.openjdk.java.net/jdk/pull/3885
RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap
This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/3885/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266567 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3885/head:pull/3885 PR: https://git.openjdk.java.net/jdk/pull/3885
Re: *Address.hashCode ignore the upper 32 bits of a long value
A better place for this email might be the serviceability-dev mailing list (CC'ed). > On 4 Apr 2021, at 09:31, kariyam wrote: > > Hi, > > I found that sun.jvm.hotspot.debugger.*.*Address.hashCode ignore the upper 32 > bits of a long value. > > e.g. > https://github.com/openjdk/jdk/blob/3789983e89c9de252ef546a1b98a732a7d066650/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java#L56 > > I don't think the upper 32 bits of a long value should be ignored. > IMHO, the Long.hashCode static method is suitable for such cases. > > If it's worth making this change, could anyone submit this issue to JBS? > > I'm ready to submit a pull request, but I don't have an Author role. > > Please let me know if there is a better place to do so. > > Thanks
Re: RFR: [small, docs] JDK-8240971 Fix CSS styles in some doc comments
This is really nice. Incidentally, it also makes
https://bugs.openjdk.java.net/browse/JDK-8234395
less relevant.
-Pavel
> On 12 Mar 2020, at 20:50, Jonathan Gibbons
> wrote:
>
> Please review a simple fix regarding the non-standard use of some CSS in some
> doc comments.
>
> From the JBS Description:
>
> Recently, for the display of javadoc block tags, javadoc changed from using
> an inconsistent set of CSS class names on the generated 'dt' elements to
> using a single new name ("notes") on the enclosing 'dl' element.
>
> There are a few (4) places in the main JDK code where the old-style names
> were used explicitly in doc comments, in order to emulate the appearance of a
> list of block tags. These use-sites should be fixed up. They are in the
> following files:
>
> open/src/java.base/share/classes/module-info.java
> open/src/java.se/share/classes/module-info.java
> open/src/java.management.rmi/share/classes/module-info.java
> open/src/jdk.jconsole/share/classes/module-info.java
>
> In addition, these four files used the style attribute to force the font to
> be used. The font is now set in the standard CSS for "notes", and so the
> local use of a "style" attribute is no longer necessary.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8240971
> Webrev: http://cr.openjdk.java.net/~jjg/8240971/webrev.00/index.html
> API: http://cr.openjdk.java.net/~jjg/8240971/api.00/index.html
>
