<div dir="ltr">I think Thiago has a good point: this abstract class with fields scenario may look like what we will encounter when we implement generic specialization: the erased type acts like a superclass and the parameterized types (with value types, especially) act like subclasses. I think such a model is also why JEP 181 was introduced. Why can't these 2 processes share at least some of their logic? How are we going to implement generic specialization otherwise?<div><br></div><div>> <span style="font-family:monospace;font-size:large">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.</span></div><div><br></div><div>Isn't this already in the language model, that if an abstract class is not identity (either implicitly or explicitly, such as by declaring synchronized methods, etc.), then it belongs to such a category? Do we need another category to "push down" the fields for only some of these non-identity classes, once the non-identity requirements are relaxed, to avoid the performance overhead?<br></div><div><br></div><div>Chen Liang</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 22, 2023 at 2:54 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@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">
<div>
<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.<br>
</font></font>
<div><br>
<br>
-------- Forwarded Message --------
<table cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap align="RIGHT">Subject:
</th>
<td>Superclasses with fields</td>
</tr>
<tr>
<th valign="BASELINE" nowrap align="RIGHT">Date: </th>
<td>Mon, 21 Aug 2023 08:03:58 -0300</td>
</tr>
<tr>
<th valign="BASELINE" nowrap align="RIGHT">From: </th>
<td>Thiago Henrique Hupner <a href="mailto:thihup@gmail.com" target="_blank"><thihup@gmail.com></a></td>
</tr>
<tr>
<th valign="BASELINE" nowrap align="RIGHT">To: </th>
<td><a href="mailto:valhalla-spec-comments@openjdk.org" target="_blank">valhalla-spec-comments@openjdk.org</a></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>
</div>
</blockquote></div>