Inline Record

[Srikanth]

Thanks for these reports. I should mention that the combination of 
records + inlines has seen zero testing - has not even been in the 
reckoning for testing as of now. Nevertheless reports are welcome.

Srikanth

On 09/05/20 1:36 am, forax at univ-mlv.fr wrote:
> yes,
> an inline should use Object.equals and Object.hashCode.
>
> There is still an issue with the reference projection vs java.lang.Record.
> An inline record can not insert a ref projection because 
> java.lang.Record as to be the sole super type.
>
> With the current compiler, this code compiles
> inline record RecordPoint(int x, int y) {
>   public boolean equals(Object o) {
>     return this == o;
>   }
>   public int hashCode() {
>     return System.identityHashCode(this);
>   }
>   public String toString() {
>     return "Point";
>   }
> }
>
> but there is a class format error on the ref projection
> java.lang.ClassFormatError: Record attribute in non-final or abstract 
> class file fr/umlv/valuetype/RecordPoint$ref
>
> Rémi
>
> ------------------------------------------------------------------------
>
>     *De: *"Brian Goetz" <brian.goetz at oracle.com>
>     *À: *"John Rose" <john.r.rose at oracle.com>
>     *Cc: *"Remi Forax" <forax at univ-mlv.fr>, "Srikanth"
>     <srikanth.adayapalam at oracle.com>, "amber-dev"
>     <amber-dev at openjdk.java.net>
>     *Envoyé: *Jeudi 7 Mai 2020 15:47:07
>     *Objet: *Re: Inline Record
>
>     The implementation in Object is
>
>         public boolean equals(Object obj) {
>             return (this == obj);
>         }
>
>
>     This _already_ has exactly the default semantics we want for both
>     inlines and identities.  Records layer their implementation atop
>     it, regardless of inline-ness.
>
>
>     On 5/6/2020 7:11 PM, John Rose wrote:
>
>         On May 6, 2020, at 3:42 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>
>
>             Eventually, inline classes will inherit eq/hashCode from
>             Object.
>
>
>         Crazy half-baked idea of the moment:
>
>         Factor the equals/hashCode/toString methods for records into
>         static methods (in ju.Objects) which are configurable
>         appropriately,
>         and have a default configuration.  Use ClassValue for performance.
>
>         Then define equals/hashCode/toString in jl.Object (yes, Object)
>         to call those methods, *when the receiver is a Record and/or
>         an inline*.
>
>         Two ideas here:  1. No per-class indy or BSM at all, but a
>         ClassValue
>         instead.  (We should do this for Record anyway.)  2. Push the
>         specification
>         all the way up to Object.  (2 makes more sense for inlines
>         than for
>         Record, since it’s natural to define equals/hashCode/toString in
>         the class hierarchy, if there’s a place to put it.  There
>         isn’t for inlines.)
>
>         — John
>
>
>