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

[Philip Race]

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
>>>>
>>>
>>>
>>
>