JDK 16 RFR of JDK-8071961: Add javac lint warning when a default constructor is created

[Joe Darcy]

On 7/30/2020 11:17 AM, Alex Buckley wrote:
> On 7/30/2020 10:15 AM, Joe Darcy wrote:
>> On 7/30/2020 12:51 AM, Alex Buckley wrote:
>>> On 7/29/2020 9:32 PM, Joe Darcy wrote:
>>>> Perhaps a bit better as
>>>>
>>>>      Since it does not declare any explicit constructors, class {0} 
>>>> in exported package {1} of module {2} exposes a default constructor
>>>
>>> I get your point about warning for the absence of something, in 
>>> which case the lint warning should be `missing-explicit-ctor` and 
>>> the message should be:
>>>
>>>   class {0} in exported package {1} of module {2} is missing an 
>>> explicit constructor; clients rely on the default constructor
>>>
>>> However, what if a class explicitly declares a ctor with the same 
>>> shape as the default ctor? JLS 13.1 teaches that a class file 
>>> doesn't distinguish an explicitly declared ctor with the right shape 
>>> versus the implicitly declared ctor. ("the following constructs are 
>>> declared implicitly in source code, but are not marked as mandated 
>>> because only formal parameters can be so marked in a class file: - 
>>> Default constructors of classes ...")
>>>
>> Operationally, the warning is only issued if the compiler generates 
>> the default constructor when compiling the source file.
>
> Of course! Everything is easy with the right framing. Knowing when the 
> message occurs allows us to characterize the plight of clients more 
> clearly:
>
> class {0} in exported package {1} of module {2} is missing an explicit 
> constructor; clients *will rely* on the default constructor
>
> Or does it? Suppose a class is declared with an explicit ctor, 
> compiled, distributed, other classes instantiate it via the explicit 
> ctor, everything is good. Then, someone accidentally deletes the 
> explicit ctor. Happily, -Xlint:all is here to save the day -- but its 
> "missing an explicit constructor" message seems to suggest that 
> clients will automatically be migrated to rely on the (newly emitted) 
> default ctor. Oops, wrong! The message should therefore confess that 
> "clients must rely on the default constructor" -- whose tone rightly 
> suggests there is something iffy about relying on it.
>
Like most javac lint warnings, this one being proposed to be triggered 
by inclusion of a default constructor is localized in nature. From my 
perspective, the situation being noted  is a not a separate 
(re)compilation hazard or even indirectly an issue for the clients. 
(From earlier in the thread, since the MANDATED information is not 
persisted into the class file, the compiler cannot reliably warn callers 
of a default constructor such a constructor is being called, if that is 
a concern.) Rather, the message is to the author/maintainer of class Foo 
being compiled -- "BTW, since you left one out, clients of your class 
Foo will see a constructor not present in your source code. Make sure 
your are okay with that and all it implies."

-Joe