Looks good.
Regards,
Alexey
On 18/08/2020 05:00, Prasanta Sadhukhan wrote:
Yes, it was a typo. Thanks Sergey for spotting it. Please find
modified version
http://cr.openjdk.java.net/~psadhukhan/8250852/webrev.1/
Regards
Prasanta
On 18-Aug-20 4:23 AM, Sergey Bylokhov wrote:
I guess it is just a typo, previously correct wording was used:
https://hg.openjdk.java.net/jdk/client/rev/db216b85f50b
On 17.08.2020 14:58, Philip Race wrote:
My preference is that the abstract classes all use the same verbiage
Joe used
for such cases in the java.base module. i.e just "Constructor for
subclasses to call. "
It may not be the optimal text but it is certainly better than
"Constructs for subclasses to call".
-phil.11
On 8/17/20, 2:47 PM, Alexey Ivanov wrote:
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
