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

[Alex Buckley]

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.

Alex