Late change to JEP 433
Brian Goetz
brian.goetz at oracle.com
Mon Nov 14 23:05:44 UTC 2022
At the time, Kevin made an excellent argument that "developers have
learned that ICCE means 'your class path is borked, dude, recompile'",
and a novel enum value was indicative of a borked class path. This was
compelling in context, and we went this way.
As we've moved on, we realize there is a bigger picture here, so I
support this change.
On 11/14/2022 2:14 PM, Kevin Bourrillion wrote:
> Makes complete sense to me. A switch that was acceptably exhaustive
> when it was compiled can still get an unhandleable value at runtime
> for I think a small handful of different reasons, and with your change
> they would all throw the same thing, correct? I don't fully remember
> the points I made about ICCError, but surely this overrides them!
>
>
> On Mon, Nov 14, 2022 at 4:38 AM Gavin Bierman
> <gavin.bierman at oracle.com> wrote:
>
> Dear Experts,
>
> As we put the final polish on features for JDK20, we noticed that
> we have an opportunity to make a very small breaking change (as
> part of the preview feature) to simplify our lives. I’m writing to
> see what you think.
>
> tldr: A switch expression over an enum class should throw
> MatchException rather than IncompatibleClassChangeError if no
> switch label applies at runtime.
>
> Details:
>
> When we introduced switch expressions, we opted for a design where
> the switch body had to be exhaustive. When switching over an enum
> type, a switch body with case labels supporting all the enum
> constants for the enum type is considered exhaustive, meaning a
> default clause is not needed.
>
> However, there is a possibility that the enum class is changed
> after compilation of the switch expression, and a new enum
> constant added. Then when executing the switchexpression, no label
> would apply.
>
> The question we faced in JDK14 was what to do at this point. We
> decided on IncompatibleClassChangeError as that was a pre-existing
> exception that was generally understood by developers as a signal
> that things have got out of sync and re-compilation is needed.
>
> Back to the present day, with the support of pattern switches, we
> can now write switches over a sealed type. When switching over a
> sealed type, a switch body with case labels with type patterns
> matching all the permitted subclasses is considered exhaustive,
> meaning a default clause is not needed.
>
> If the sealed hierarchy has been changed after compilation of the
> switch, it is possible that when executing the switch that no
> label would apply. In this case we have settled on throwing a
> MatchException.
>
> Throughout our design process, we have noticed the connection
> between enum classes/enum constants and sealed class/permitted
> subclasses – they are essentially the same thing up the term/type
> hierarchy. Moreover, in a future release, we plan to support case
> labels with a mix of sealed class type patterns and enum constants.
>
> But we now have an inconsistency - one throws
> IncompatibleClassChangeException in a bad situation and the other
> MatchException which will make this future development almost
> impossible. We need these cases to throw the same exception:
> MatchException. So we propose to make the small breaking case to
> the language that switch expressions over enum classes throw
> MatchException should no switch label apply in the switch body.
>
> People who deliberately change their enum classes by adding new
> constants, and do not recompile their switches over this enum
> class, and rely on this throwing ICCE will notice this breaking
> change. We think this is a vanishingly small set of developers.
> The vast majority of developers, on the other hand, will thank us
> for this unification, especially if it enables other new features
> down the road.
>
> What do you think?
>
> Thanks,
> Gavin
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20221114/7d868c75/attachment.htm>
More information about the amber-spec-experts
mailing list