JDK 16 RFR of JDK-8250244: Address reliance on default constructors in java.net

[Alan Bateman]

On 24/07/2020 18:42, Joe Darcy wrote:

>>
> At least from a few minutes thinking, I don't see a meaningful 
> compatibility issue in replacing
>
> 1) a public constructor in an abstract class
>
> with
>
> 2) a protected constructor in an abstract class
>
> It is source compatible, subclasses would have access to the 
> constructor in either case, and should also be binary compatible as 
> linkage shouldn't be impacted (because subclasses would still have 
> access to the constructor).
>
> That said, for this exercise I'd prefer to replace the implicit 
> default constructors with equivalent explicit ones, but would be open 
> to future refinements to make the constructors protected.
>
I don't mind if we do it in one or two steps. My only concern is that 
the javadoc will make the public constructor stand out a bit more and 
newbies might think can use the public constructor. "protected" is 
understood by few so a good deterrent.

-Alan