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

[Prasanta Sadhukhan]

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