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

[Alexey Ivanov]

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