Record Component attributes
maurizio.cimadamore at oracle.com
Thu Oct 10 08:58:35 UTC 2019
On 09/10/2019 19:34, Remi Forax wrote:
> ----- Mail original -----
>> De: "Remi Forax" <forax at univ-mlv.fr>
>> À: "Brian Goetz" <brian.goetz at oracle.com>
>> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> Envoyé: Mercredi 9 Octobre 2019 18:44:23
>> Objet: Re: Record Component attributes
>> ----- Mail original -----
>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
>>> <amber-spec-experts at openjdk.java.net>
>>> Envoyé: Mercredi 9 Octobre 2019 17:59:56
>>> Objet: Re: Record Component attributes
>>>> just to be sure, do we agree that a record component can be deprecated,
>>>> synthetic, have a generic signature, have unknown attributes, have annotation
>>>> and type annotations ?
>>> Deprecated: not clear what this would mean, since removing a component
>>> is not a BC or SC change, and therefore removal seems unlikely, but I
>>> suppose deprecation could be a "stay away" warning sign for that
>>> component? On the fence.
>>> Synthetic: I think this is a no. The philosophy is: a record is a class
>>> whose representation and API are both derived from the state
>>> description. Having a synthetic component would be weird (same reason
>>> we don't have inner records.)
>>> Generic signature: yes, definitely.
>>> Unknown attributes: I believe that Dan had an opinion here, as reflected
>>> in the current spec draft?
>>> Declaration and type annotations: yes, definitely.
>> given it's the class format representation, i will wear my JVM runtime
>> implementer hat :
>> There a lot of languages that have default value for parameters, so for
>> constructor parameters,
>> for those it makes sense to be able to deprecate a record component if at the
>> same time you provide a default value for this component.
>> for synthetic, a synthetic component is a component that the VM (or the
>> reflection) sees but that javac doesn't see. Reified generics stored as
>> parameter like in Swift is a case where you may not want javac to see your ugly
>> refiied type/witness type/etc.
> and answering to myself,
> javac doesn't directly access to the record component, it accesses to the generated fields/methods so making the record component synthetic or not has no impact on javac, so marking a record component Synthetic seems useless.
I think the problem of this question is not whether it would make sense
for Java right now, but whether it could make sense for other languages
(or even Java of tomorrow) to use records as a translation target; now,
this seems not super likely given that records are a restriction of a
more general construct (class), so a compiler would probably prefer the
more general target.
Synthetic can be useful in situations where there are 'hidden'
components that are injected by javac, pretty much as a hidden this$0 is
added on all inner classes. It's there, but you are not allowed to see
it (or match on it), not from the language, not from core reflection.
Right now we don't envisage any purpose for doing something like this,
but I also don't immediately see a reason for shutting down the door on
it either. Perhaps this _hidden_ nature of synthetic components could be
used as a motivation as to why we don't like ACC_SYNTHETIC to be added
in the mix - on the one hand we're saying "records are all about
transparent state", and, with synthetic components, this goes down the
drain a bit, as there are hidden parts of the state you can't see or
As for DEPRECATED, it doesn't make a lot of sense, but not sure whether
source/binary compatibility is a good explanation; after all, removing a
class field is neither BC nor SC (for clients that refer to that field).
The problem with records is just made worse by the fact that, with
pattern matching and, deconstructor patterns we envision that 'accessing
all components' will be a routine operation. But it's a quantitative
change, not a qualitative one, IMHO.
>>>> so the attributes with a special meaning are
>>>> SIGNATURE, DEPRECATED, SYNTHETIC, RUNTIME_VISIBLE_ANNOTATIONS,
>>>> RUNTIME_VISIBLE_TYPE_ANNOTATIONS, RUNTIME_INVISIBLE_ANNOTATIONS and
>>>> said differently, it's all the attributes allowed on a field but CONSTANTVALUE
>>>> which makes no sense on a record component.
More information about the amber-spec-experts