On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy <da...@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.bate...@oracle.com) on > [core-libs-dev](mailto:core-libs-...@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
