On Tue, 7 May 2024 20:23:11 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
>>> Should this be final? >> >> With only the private constructor, it doesn't matter too much in practice, >> but an explicit `final` would be good documentation if that is the intent. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596377720
