On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg wrote:
> Non-instantiable utility classes should be declared `final` and have a
> private constructors.
>
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item
> 22).
>
There are numerous examples in the JDK where we h
On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg wrote:
> Non-instantiable utility classes should be declared `final` and have a
> private constructors.
>
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item
> 22).
In some future, one could mistakenly instantiate the
On Wed, 29 Mar 2023 16:09:18 GMT, Raffaello Giulietti
wrote:
>
> Would it make sense to throw an `AssertionError` in the constructor? Just in
> case...
It hardly seems worth the bytecode; the constructor could only be invoked by
breaking in using reflection and the result would be an inst
On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg wrote:
> Non-instantiable utility classes should be declared `final` and have a
> private constructors.
>
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item
> 22).
The CSR implies that java.util.Arrays has a non-priva
On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg wrote:
> Non-instantiable utility classes should be declared `final` and have a
> private constructors.
>
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item
> 22).
Would it make sense to throw an `AssertionError` in t
On Wed, 29 Mar 2023 09:03:58 GMT, Alan Bateman wrote:
> > I thought the change would trigger a change in the public API as the
> > modifiers are changed for the class. This would likely be picked up by
> > compatibility checks and so, a CSR would be needed?
>
> It's not a compatibility issue b
On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg wrote:
> Non-instantiable utility classes should be declared `final` and have a
> private constructors.
>
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item
> 22).
Marked as reviewed by bpb (Reviewer).
-
On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg wrote:
> Non-instantiable utility classes should be declared `final` and have a
> private constructors.
>
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item
> 22).
Marked as reviewed by rriggs (Reviewer).
---
On Wed, 29 Mar 2023 08:59:50 GMT, Per Minborg wrote:
> I thought the change would trigger a change in the public API as the
> modifiers are changed for the class. This would likely be picked up by
> compatibility checks and so, a CSR would be needed?
It's not a compatibility issue but a CSR is
On Wed, 29 Mar 2023 08:24:38 GMT, Alan Bateman wrote:
> Look fine, it can't be subclassed anyway so there is no compatibility impact.
I thought the change would trigger a change in the public API as the modifiers
are changed for the class. This would likely be picked up by compatibility
checks
On Wed, 29 Mar 2023 08:13:06 GMT, Per Minborg wrote:
> Non-instantiable utility classes should be declared `final` and have a
> private constructors.
>
> See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item
> 22).
Look fine, it can't be subclassed anyway so there is
Non-instantiable utility classes should be declared `final` and have a private
constructors.
See Effective Java, Third Edition, Joshua Bloch (for example, Item 19 or Item
22).
-
Commit messages:
- Make java.util.Arrays final
Changes: https://git.openjdk.org/jdk/pull/13221/files
12 matches
Mail list logo
