RFR: 8305457: Implement java.io.IO [v7]

[Pavel Rappo]

On Fri, 10 May 2024 07:29:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> If the sole constructor of a class is private, not only does it preclude the class from being instantiated, but it also precludes the class from being extended. Mind you, even with the sole private constructor, both instantiation and extension are still possible from inside the class or its nested classes. As long as we don't leak such instances to API clients, they won't seem to be able to observe any difference between "the private constructor" and "the private constructor of a final class".
>> 
>> I think that just having that constructor private but the class "non-final" makes bigger bang for the buck. We can defer the decision to make the class final.
>> 
>> If this helps, here are a few well-known similar classes:
>> 
>>   - java.util.Collections
>>   - java.util.concurrent.Executors
>
> Although true (and also described in Item 4 in "Effective Java" 3rd ed by JB) I think it is better to also signal the intent by marking the class as `final`. See for example Arrays that we updated some time ago.

It feels better to specify what the class is for than to "signal" all the things it is not for. In the first sentence of its documentation comment, `IO` says that it's a "collection of static convenience methods". I'm not sure how a class can signal its intent more clearly than that.

Like that of `Arrays`, `Collections`, `Collectors`, `Comparators`, `Executors`, `Files`, `Objects`, etc., an instance of `IO` or of its subclass is no more useful than an instance of `Object`. Even if `IO` isn't `final` and has a default constructor, it doesn't matter in practice.

Not too far ago, we started generating warnings on default constructors. To avoid those warnings, I had to provide an explicit constructor.

While unnecessary, I'll make `IO` `final`. Maybe it will help an IDE tell the programmer that they are doing something meaningless.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596572570