<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>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Viktor Klang" <viktor.klang@oracle.com>, "amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Sent: </b>Tuesday, January 20, 2026 2:23:13 AM<br><b>Subject: </b>Re: Data Oriented Programming, Beyond Records<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;"><blockquote cite="mid:1884486700.20372636.1768848050872.JavaMail.zimbra@univ-eiffel.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
        <div>
          <div><br>
          </div>
          <div>The modifier "component" is too close to the "property"
            modifier I wanted to include years ago, it's just to sugary
            for its own good.</div>
        </div>
      </div>
    </blockquote>
    <br>
    You know the rule; mention syntax and you forfeit the right to more
    substantial comments....</blockquote><div><br></div><div>I'm talking about the semantics, especially the fact that equals/hashCode and toString() are derived from.</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;"><br>
    <br>
    <blockquote cite="mid:1884486700.20372636.1768848050872.JavaMail.zimbra@univ-eiffel.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
        <div>
          <div>I have used HashSet as an example to say that I would
            prefer equals/hashCode/toString not to be generated so my
            students can launch the debugger to understand why it does
            not work as intended.</div>
        </div>
      </div>
    </blockquote>
    <br>
    "Generation" is not the right level for this discussion, though. 
    This feature is not a Lombok macro generator; it is a semantic
    feature.  Can you restate this in terms of what you think such as
    class should _mean_?  </blockquote><div><br data-mce-bogus="1"></div><div>As far as i understand, the carrier class syntax </div><div>  class Point(int x, int y) { ... }</div><div>means that</div><div>- if it's not a concrete class, the implementation should provide an implementation for the canonical constructor and accessors,</div><div>- if it's an interface or an abstract class, the accessors are generated as abstract methods. </div><div><br data-mce-bogus="1"></div><div>Then declaring a field as "component" generates the canonical constructor, the corresponding accessor and toString/equals/hashCode.</div><div><br data-mce-bogus="1"></div><div>I see those two features as separated, and i am not convince that the latter is worth it.</div><div>For me, all the juice come from the carrier class semantics.</div><div><br data-mce-bogus="1"></div><div>As i said earlier, I think that providing an implementation for toString/equals/hashCode is not a good idea.</div><div>Given that the class can be mutable, generating equals and hashCode hide important details that are necessary for debugging and I also think it does not makes no sense for an enum (you did not answer that question ?).</div><div><br data-mce-bogus="1"></div><div>regards,</div><div>RĂ©mi</div><div><br data-mce-bogus="1"></div></div></div></body></html>