A library for implementing equals and hashCode

Remi Forax forax at univ-mlv.fr
Tue Apr 23 21:54:19 UTC 2019


Hi Liam, 
interesting proposal, 

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

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*. 

Rémi 

* 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. 

> De: "Liam Miller-Cushon" <cushon at google.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Lundi 22 Avril 2019 20:29:51
> Objet: A library for implementing equals and hashCode

> Please consider this proposal for a library to help implement equals and
> hashCode.

> The doc includes a discussion of the motivation for adding such an API to the
> JDK, a map of the design space, and some thoughts on the subset of that space
> which might be most interesting:

> [ http://cr.openjdk.java.net/~cushon/amber/equivalence.html |
> http://cr.openjdk.java.net/~cushon/amber/equivalence.html ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190423/bb385685/attachment.html>


More information about the amber-spec-experts mailing list