A library for implementing equals and hashCode

Liam Miller-Cushon cushon at google.com
Tue Apr 23 22:41:09 UTC 2019

Hi Remi,

On Tue, Apr 23, 2019 at 2:54 PM Remi Forax <forax at univ-mlv.fr> wrote:

> Here is my implementation
> https://github.com/forax/exotic/blob/master/src/main/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupport.java

Thanks for the pointer! I'll add a note to the prior art section.

> I disagree that it has to be included in the JDK, because as you said
> there is no typesafe way to represent a field at compile time so any APIs
> will be either typesafe but slow or less typesafe and faster*.
> * It doesn't seems logical that if an API is less typesafe, it can be
> faster at runtime. It's because if you have an API based on strings you
> have less type info at compile time but more type info at runtime thanks to
> the reflection. By contrast, an API based on lambdas will be more typesafe
> but because you can not do reflection on lambdas, so you have less type
> info at runtime.

To maybe clarify the mention of performance in the 'non-goals' section,
it's more that it's a long term goal than it is a non-goal. Ultimately we
want the performance to be competitive with hand-written implementations,
perhaps through some combination of intensification, field references, and
lambda cracking.

For the initial discussion I wanted to consider what the best (e.g. most
readable and ergonomic) library version of the feature would look like.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190423/cec891b4/attachment.html>

More information about the amber-spec-experts mailing list