<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net><br><b>Sent: </b>Monday, August 21, 2023 6:39:26 PM<br><b>Subject: </b>Fwd: Superclasses with fields<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4"><font face="monospace">The below was received on the
        valhalla-spec-comments list.  <br><br>
        The topic of further relaxing the restrictions on abstract class
        supertypes of value classes has been discussed by the EG.  While
        it is possible that such restrictions could be further relaxed,
        we are likely facing diminishing returns.  <br><br>
        It is certainly possible to define a way that fields and
        initialization logic from an abstract super is "copied" into the
        value class.  But this would still come with restrictions we
        might not like; we would then either have to give up putting
        fields in the value subclass (to eliminate layout polymorphism),
        or give up flattening of the abstract class type (because there
        is layout polymorphism.)  And, we would likely end up creating a
        new category of abstract class to support the "pushing down" of
        fields and initialization, which is new language complexity. 
        Overall this seems like something that has a relatively weak
        return-on-complexity and there are many opportunities for much
        higher return right now.</font></font></blockquote><div><br></div><div>I will add that in case of an enum, it's not clear that a "value enum" make sense in term of performance.</div><div> The number of instances of an enum is fixed, and because there are all initialized one after the other, there are all in the same memory page so the actual representation is already very cache friendly.</div><div><br data-mce-bogus="1"></div><div>RĂ©mi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
    <div class="moz-forward-container"><br>
      <br>
      -------- Forwarded Message --------
      <table class="moz-email-headers-table" cellspacing="0" cellpadding="0" border="0">
        <tbody>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
            </th>
            <td>Superclasses with fields</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
            <td>Mon, 21 Aug 2023 08:03:58 -0300</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
            <td>Thiago Henrique Hupner <a class="moz-txt-link-rfc2396E" href="mailto:thihup@gmail.com" target="_blank"><thihup@gmail.com></a><br data-mce-bogus="1"></td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:valhalla-spec-comments@openjdk.org" target="_blank">valhalla-spec-comments@openjdk.org</a><br data-mce-bogus="1"></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      
      <div dir="ltr">
        <div>Now that most of the migration issues from classes to value
          classes have been discovered, would it also be possible to
          allow maybe a subset of superclasses that contains some
          fields?<br>
          <br>
        </div>
        <div>Probably having "value enums" would be great, but also it
          would enable to have subclasses of j.u.AbstractList to also
          become value classes.<br>
          <br>
        </div>
        <div>Probably there are more issues to it than I could remember,
          but wouldn't it be possible to check at load time if the
          superclass uses some unsupported features, like synchronized
          methods, and throw an error?<br>
        </div>
      </div>
    </div><br></blockquote></div></div></body></html>