Inline Record

[Srikanth]

On 09/05/20 6:28 am, Srikanth wrote:
>
> 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.

That is the case, but what you report below may be an instance of the 
problem acknowledged here in https://github.com/openjdk/valhalla/pull/32 
under "There are many known issues that have been deliberately deferred 
to a later iteration:"

|Need to verify that attributes from V are not carried over 
inadvertently to V$ref.class |

I'll follow up -- 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
>>
>>
>>
>