<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">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.<br>
<br>
As we've moved on, we realize there is a bigger picture here, so
I support this change. <br>
</font></font><br>
<div class="moz-cite-prefix">On 11/14/2022 2:14 PM, Kevin
Bourrillion wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAGKkBkuVsULeiVtg40Pg4hykjPEb8ac1konHbwyfM=cvk1bvgg@mail.gmail.com">
<div dir="ltr">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!
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Nov 14, 2022 at 4:38
AM Gavin Bierman <<a href="mailto:gavin.bierman@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">gavin.bierman@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear
Experts,<br>
<br>
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.<br>
<br>
tldr: A switch expression over an enum class should throw
MatchException rather than IncompatibleClassChangeError if no
switch label applies at runtime.<br>
<br>
Details:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
What do you think?<br>
<br>
Thanks, <br>
Gavin</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px
0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin
Bourrillion |</span><span style="border-width:2px
0px
0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java
Librarian |</span><span style="border-width:2px
0px
0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google,
Inc. |</span><span style="border-width:2px 0px
0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">kevinb@google.com</a></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>