Late change to JEP 433

[Brian Goetz]

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>