FYI, coming soon new javac lint warning for reliance on default constructors by formal API classes

Joe Darcy joe.darcy at
Wed Aug 12 18:57:07 UTC 2020


FYI, a new javac lint warning is out for review for JDK 16, JDK-8071961: 
"Add javac lint warning when a default constructor is created." [1]

As described in JLS section 8.8.9 "Default Constructor" [2], if a class 
does not declare an explicit constructor, an implicit no-arg constructor 
is declared and added by the compiler. While a default constructor can 
be fine for an informal class, the default constructor can be 
troublesome for more formal APIs. The default constructor does not have 
javadoc and can be inappropriate for classes not intended for 
instantiation, such as a class that is only a holder for static items.

With some guidance from the JDK code base, the criteria to determine if 
a class is a formal enough API to merit a warning for reliance on a 
default constructor is currently:

* The class is in a named package and the packaged has an unqualified 
export from its module AND
* The class is public and, if it is a nested class, all of its lexically 
enclosing types are public too.

In particular, a class in a package conditionally exported to only 
certain modules does *not* generate a warning under the current 
criteria. In addition, the class must be non-anonymous, not a record, 
etc. to have a warning generated.

The JDK build of most modules enables all warnings and runs with 
warnings-as-errors. Therefore, before the new lint warning can be 
enabled for the JDK build, the instances of the conditions triggering 
the warning have to be addressed in a module or the module needs the 
warning to be disabled. Through the subtasks of JDK-8250212: "Address 
reliance on default constructors in the JDK (umbrella)", the instances 
in most JDK modules have been fixed already. Work is on-going to address 
the instances in client libraries, see JDK-8250639. Therefore, only a 
few modules will likely have the warning disabled when the new lint 
warnings goes in, depending on the timing of the full fix of JDK-8250639.





More information about the jdk-dev mailing list