<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>