hg: amber/amber: adding method Class::isRecord

forax at univ-mlv.fr forax at univ-mlv.fr
Thu Jul 12 21:11:17 UTC 2018


> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>, "Vicente Romero"
> <vicente.romero at oracle.com>
> Envoyé: Jeudi 12 Juillet 2018 22:36:50
> Objet: Re: hg: amber/amber: adding method Class::isRecord

> It’s not like the only two options for recording record-ness in the classfile
> are ACC_RECORD and a nominal superclass; we can use attributes too.

yes, like an attributes that reference a ConstantDynamic with the getter method handles as parameters so you can use that attribute to implement reflection too. 

> Similarly, there’s nothing that stops us from making an exception of
> AbstractRecord as a super type of value types, as it has no state (which it
> doesn’t.) Or make AbstractRecord an interface. Or a whole host of options in
> between, such as a Value interface with a sub-interface of ValueRecord.

It can not be an interface because AbstractRecord re-abstract Object public methods (hashCode/equals/toString) something an interface can not do. And you can not fake the re-abstraction with default methods because as you know you can not override an Object public method with a default method. 
You can 'specialize' AbstractRecord in the VM not unlike the VM does with Object, i.e. do not call it's constructor if its a value type, but does AbstractRecord really worth that complexity. 

> So I’ll discard all the “can’ts” and “problems” and restate this as:

:) 

> - We should bear in mind that we want records of both value- and object-nature,
> and ensure that there is a strategy to translate them and reflect over them.

> Which I would agree with.

Rémi 

>> On Jul 12, 2018, at 4:29 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>> wrote:

>> Thinking a little bit more about record and the abstract class AbstractRecord,
>> the problem with the presence of AbstractRecord is that it means can not have
>> 'value record', a record which are value class because a value class can not
>> inherits from an abstract class.

>> Rémi

>>> De: "Vicente Romero" < [ mailto:vicente.romero at oracle.com |
>>> vicente.romero at oracle.com ] >
>>> À: "Brian Goetz" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ] >,
>>> "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "amber-dev" < [ mailto:amber-dev at openjdk.java.net |
>>> amber-dev at openjdk.java.net ] >
>>> Envoyé: Mercredi 11 Juillet 2018 23:58:26
>>> Objet: Re: hg: amber/amber: adding method Class::isRecord

>>> On 07/11/2018 05:08 PM, Brian Goetz wrote:

>>>> I don’t think burning an ACC_RECORD flag is a terribly good use of some very
>>>> expensive real estate.

>>>> But, I had a different wonder: why not just do this from the Java side as:

>>>>     boolean isRecord() { return AbstractRecord.class.isAssignableFrom(this); }

>>> yep that was what Paul also suggested in an offline conversation. I have
>>> reversed the original patch and applied redone this as:

>>> public boolean isRecord() { return this .getSuperclass() ==
>>> java.lang.AbstractRecord. class ;
>>> }
>>> Vicente

>>>> ?

>>>>> On Jul 11, 2018, at 4:54 PM, Remi Forax [ mailto:forax at univ-mlv.fr |
>>>>> <forax at univ-mlv.fr> ] wrote:

>>>>> Hi Vicente,
>>>>> usually for the Java side (Class.java), to avoid a native call, one of the bit
>>>>> of the class modifier flags, let's call it ACC_RECORD is reserved.

>>>>> Rémi

>>>>> ----- Mail original -----

>>>>>> De: "Vicente Romero" [ mailto:vicente.romero at oracle.com |
>>>>>> <vicente.romero at oracle.com> ] À: "amber-dev" [
>>>>>> mailto:amber-dev at openjdk.java.net | <amber-dev at openjdk.java.net> ] Envoyé:
>>>>>> Mercredi 11 Juillet 2018 22:28:10
>>>>>> Objet: hg: amber/amber: adding method Class::isRecord

>>>>>> Changeset: 2c5938e024ed
>>>>>> Author:    vromero
>>>>>> Date:      2018-07-11 13:02 -0700
>>>>>> URL: [ http://hg.openjdk.java.net/amber/amber/rev/2c5938e024ed |
>>>>>> http://hg.openjdk.java.net/amber/amber/rev/2c5938e024ed ] adding method
>>>>>> Class::isRecord

>>>>>> ! make/hotspot/symbols/symbols-unix
>>>>>> ! src/hotspot/share/classfile/systemDictionary.hpp
>>>>>> ! src/hotspot/share/classfile/vmSymbols.hpp
>>>>>> ! src/hotspot/share/include/jvm.h
>>>>>> ! src/hotspot/share/oops/klass.cpp
>>>>>> ! src/hotspot/share/oops/klass.hpp
>>>>>> ! src/hotspot/share/prims/jvm.cpp
>>>>>> ! src/java.base/share/classes/java/lang/Class.java
>>>>>> ! src/java.base/share/native/libjava/Class.c


More information about the amber-dev mailing list