<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    Hi Stephen,<br>

    <br>

    Yes, we didn't take the time to refactor ZoneOffset to be a value

    class and yes, the cache was the bump in the road on that.<br>

    <br>

    We'll take another look at it.<br>

    <br>

    Regards, Roger<br>

    <br>

    <div class="moz-cite-prefix">On 9/30/25 5:10 PM, Brian Goetz wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:48550302-9fae-42d8-a78e-cb8e9eb2ddd7@oracle.com">

      <font size="4" face="monospace">Dan can fill in the details on

        this specific case, but by way of background, for JEP 401 we're

        not trying to migrate _every_ candidate value class in the JDK

        -- just a good set of the most common ones.  So any list we came

        up with is surely going to be just an approximation, not the

        last word.  </font><br>

      <br>

      <div class="moz-cite-prefix">On 9/30/2025 5:04 PM, Stephen

        Colebourne wrote:<br>

      </div>

      <blockquote type="cite" cite="mid:CACzrW9AUztzOMy=BbFh6pCmwUpHBqSy8WCaarnbae-r4uqZEag@mail.gmail.com">

        <pre wrap="" class="moz-quote-pre">I notice from the updated JEP <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/401" moz-do-not-send="true">https://openjdk.org/jeps/401</a> that

ZoneOffset is not intended to become a value class. I assume this is

because of the id and rules cache variables?

It seems to me that ZoneOffset is very much applicable to be a value,

as it's state is fundamentally an int. Performance tests would be

needed, but it might be possible to create the id and rules on the fly

rather than caching them.

thanks

Stephen

</pre>

      </blockquote>

      <br>

    </blockquote>

    <br>

  </body>

</html>