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
--
Best regards, Sergey.
