RFR: JDK-8283668: Update IllegalFormatException to use sealed classes
Joe Darcy
darcy at openjdk.java.net
Fri Mar 25 23:33:48 UTC 2022
On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:
> Working down the list of candidates to be sealed, this time IllegalFormatException.
>
> Please also review the companion CSR: https://bugs.openjdk.java.net/browse/JDK-8283669
> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_
>
> On 25/03/2022 09:37, Bernd Eckenfels wrote:
>
> > I wonder should the CSR not describe what?s the advantage of this change is and what the compatibility problems are and why they don?t apply here? Especially given the fact that the specific sub exceptions are not sealed I wonder if the risk of breaking existing code is worth it? (But I do see the beauty of such a construct for new code!)
>
> IllegalFormatException does not have any accessible constructors so can't extended by classes outside of the java.util packages. So I think the only compatibility risk is doing something off label with deserialization to create sub-classes.
>
> -Alan
Right; the general user "interface" in question is "this class cannot be extended outside of the JDK." Altering the way that property is implemented, no accessible constructor or being declared sealed, etc. is considered a compatible change.
-Joe
-------------
PR: https://git.openjdk.java.net/jdk/pull/7950
More information about the core-libs-dev
mailing list