Data Oriented Programming, Beyond Records

[Olexandr Rotan]

"Given that the class can be mutable, generating equals and hashCode hide
important details that are necessary for debugging"

This may be rather not obvious for an unexpirienced user, and is rather
ridiculous to be known by complete beginners that lost value in hashset for
the the first time, but classfile decompilers (or at least one used by
intellij), is fully capable of decompiling records in a way that
auto-generated implementations are explicitly present, and (or at least I
hope) should be capable of placing breakpoint here directly from line in
decompiled classfile. Of course this is not obvious, and without wrangling
with class loading and bytecode manipulation you wouldn't be able to add
something like logging for debugging purposes, but there are other tools
provided by debuggers such as field watchpoints, method breakpoints and
log-on-break functionality that, I believe, should cover vast majority of
debugging cases

On Tue, Jan 20, 2026, 10:17 <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Brian Goetz" <brian.goetz at oracle.com>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Viktor Klang" <viktor.klang at oracle.com>, "amber-spec-experts" <
> amber-spec-experts at openjdk.java.net>
> *Sent: *Tuesday, January 20, 2026 2:23:13 AM
> *Subject: *Re: Data Oriented Programming, Beyond Records
>
>
> 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.
>
>
> You know the rule; mention syntax and you forfeit the right to more
> substantial comments....
>
>
> I'm talking about the semantics, especially the fact that equals/hashCode
> and toString() are derived from.
>
>
>
> 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.
>
>
> "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_?
>
>
> As far as i understand, the carrier class syntax
>   class Point(int x, int y) { ... }
> means that
> - if it's not a concrete class, the implementation should provide an
> implementation for the canonical constructor and accessors,
> - if it's an interface or an abstract class, the accessors are generated
> as abstract methods.
>
> Then declaring a field as "component" generates the canonical constructor,
> the corresponding accessor and toString/equals/hashCode.
>
> I see those two features as separated, and i am not convince that the
> latter is worth it.
> For me, all the juice come from the carrier class semantics.
>
> As i said earlier, I think that providing an implementation for
> toString/equals/hashCode is not a good idea.
> 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 ?).
>
> regards,
> Rémi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20260120/60c372fb/attachment.htm>