On 17/08/2020 22:10, Alexey Ivanov wrote:
Hi Prasanta, Sergey,
On 17/08/2020 21:19, Sergey Bylokhov wrote:
Hi, Prasanta.
There is a small typo, see dots: "Constructs for subclasses to call.."
Shall it be "Constructs a {@code BasicLookAndFeel} for subclasses to
call."?
This way it is consistent with other added constructors and specifies
the object.
I see there's a discussion on jdk-dev about the proposed text:
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-August/004613.html
There's a precedent of using such a description:
"Constructor for subclasses to call."
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-August/004614.html
https://cr.openjdk.java.net/~darcy/8250244.0/src/java.base/share/classes/java/net/SocketAddress.java.frames.html
And it's fine.
Yet "Constructs for subclasses to call.." seems incorrect,
ungrammatical, as if something missing and that something is the object
for the verb "to construct".
Should it be replaced with: "Constructor for subclasses to call."?
Regards,
Alexey
Other than that looks fine.
On 15.08.2020 05:30, Prasanta Sadhukhan wrote:
Hi All,
Please review a fix for issue where it was seen that several classes
rely on default constructors as part of their public API.
It's to be noted that "A no-arg public constructor is generated by
the compiler for a class if it does not declare an explicit
constructor. While convenient, this is inappropriate for many kinds
of formal classes, both because the constructor will have no javadoc
and because the constructor may be unintended."
For the JDK, classes intended to be used outside of the JDK, public
classes in exported packages, should not rely on default constructors.
Proposed fix is to create protected constructors to the public
abstract classes for javax.swing.plaf.basic module (as one part of
overalll java.desktop change)
Bug: https://bugs.openjdk.java.net/browse/JDK-8250852
webrev: http://cr.openjdk.java.net/~psadhukhan/8250852/webrev.0/
CSR: https://bugs.openjdk.java.net/browse/JDK-8251855
Regards
Prasanta
