Integrated: 8251123: doclint warnings about missing javadoc tags and comments
On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote: > We have a number of missing javadoc tags and comments in the desktop module. > Most of the missing comments are related to the serialized form. > > The fix: > - Adds missing comments to the non-static/non-transient fields(even > private) of the "serializable" classes > - Adds comments to the "serializable" classes even if those classes are > non-public > - Fixes references/adds missing tags to the special methods(like > readObject/writeObject) > - Delete the java.awt.PeerFixer class. > > I need advice about what exact change should be reviewed in the CSR(except > PeerFixer removal) > > Note that in some cases I added the comments to the "implementation details", > so I did not specify it fully. > > The old review request: > https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html This pull request has now been integrated. Changeset: f397b60a Author:Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/f397b60a Stats: 1256 lines in 69 files changed: 809 ins; 165 del; 282 mod 8251123: doclint warnings about missing javadoc tags and comments Reviewed-by: jdv, prr - PR: https://git.openjdk.java.net/jdk/pull/369
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly
On Mon, 5 Oct 2020 22:23:56 GMT, Ian Graves wrote: > The `java.util.Formatter` format specifies support for field widths, argument > indexes, or precision lengths of a field > that relate to the variadic arguments supplied to the formatter. These > numbers are specified by integers, sometimes > negative. For argument index, it's specified in the documentation that the > highest allowed argument is limited by the > largest possible index of an array (ie the largest possible variadic index), > but for the other two it's not defined. > Moreover, what happens when a number field in a string is too large or too > small to be represented by a 32-bit integer > type is not defined. This fix adds documentation to specify what error > behavior occurs during these cases. > Additionally it adds an additional exception type to throw when an invalid > argument index is observed. A CSR will be > required for this PR. Is the new exception type useful? yes, it matches the previous pattern. But it (and none of the IllegalFormatException subclasses) produce a readable message with the offending value. So the developer will not see anything useful. The fine grained exceptions provide little value. - PR: https://git.openjdk.java.net/jdk/pull/516
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly
On Tue, 6 Oct 2020 13:55:55 GMT, Roger Riggs wrote: >> The `java.util.Formatter` format specifies support for field widths, >> argument indexes, or precision lengths of a field >> that relate to the variadic arguments supplied to the formatter. These >> numbers are specified by integers, sometimes >> negative. For argument index, it's specified in the documentation that the >> highest allowed argument is limited by the >> largest possible index of an array (ie the largest possible variadic index), >> but for the other two it's not defined. >> Moreover, what happens when a number field in a string is too large or too >> small to be represented by a 32-bit integer >> type is not defined. This fix adds documentation to specify what error >> behavior occurs during these cases. >> Additionally it adds an additional exception type to throw when an invalid >> argument index is observed. A CSR will be >> required for this PR. > > Is the new exception type useful? yes, it matches the previous pattern. > But it does not (and none of the IllegalFormatException subclasses) produce a > readable message with the offending > value. So the developer will not see anything useful. The fine grained > exceptions provide little value. I've been on the fence about this, personally. The Formatter uses pretty fine-grained exception types for error conditions. I'd be okay discontinuing this practice here, but am not sure what to replace this with. Perhaps we enable `IllegalFormatException` to be, itself, public and instantiable ? - PR: https://git.openjdk.java.net/jdk/pull/516
