<Swing Dev> RFR 8250852: Address reliance on default constructors in the javax.swing.plaf.basic APIs

[Sergey Bylokhov]

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.