[records] Time to re-read JEP 359
brian.goetz at oracle.com
Mon Jan 6 15:42:51 UTC 2020
On 1/4/2020 10:35 AM, Tagir Valeev wrote:
> I was watching a Twitch stream by Nicolai Parlog  who explored the
> records feature. Quite expectedly he did this reading JEP 359, rather
> than the spec draft. He noticed at least two inconsistencies:
> 1. The record's body may declare static methods, static fields, static
> initializers, constructors, instance methods, instance initializers,
> and nested types.
> "intance initializers" part should be removed, to match the spec draft.
> 2. Any of the members that are automatically derived from the state
> description can also be declared explicitly.
> private final fields that match the record components are members and
> derived from the state description, so from this statement, one could
> conclude that explicit field declaration is also possible (which is
> not an unreasonable thing to do: one may want to customize the field
> annotations). If we don't allow such a declaration, this statement
> should be refined (probably changing 'members' to 'methods and
> constructor' or 'members except field' or something like this).
This is a fair question; do we want to allow this? There are several
reasons one might want to do so:
- Consistency (though this is generally the reason you give when you
have no other reason), you can do it for the other members;
- Maybe the author wants the fields public;
- Maybe the author wants annnotations on the fields that, were they to
be put on the components, would be spread to places where they are _not_
The last of these is the only one that is mildly compelling here, but, I
wonder whether this is purely theoretical, or whether someone actually
The reasons against include:
- It is not likely to be something people want to do very often, and
so the return on spec complexity here is probably negative.
More information about the amber-spec-experts