[records] Summary so far
gavin.bierman at oracle.com
Tue Feb 18 15:19:48 UTC 2020
In  Brian asked for comments on some remaining design decisions concerning
records (and asked for any new ones that you'd like to raise).
First, thank you for your feedback so far! I have been through the threads, and
tried to summarize the question and the current status below. Of course,
these decisions are not set in stone, but the point of this email is to warn you
that they are hardening :-) So, if you disagree, or would like further
discussion, *now* is the time to speak up!
Q1. Should the distinguished supertype of records java.lang.Record be
[Since the original post, it seems that inline types will be able to inherit
from abstract classes.]
Is the name "Record" a good one? It has good clash
potential :-) possible alternatives are RecordClass, or AbstractRecord?
A: No consensus so far.
Q2. Accessibilty of mandated members.
Currently the mandated members are public regardless of the accessibility of
the record type. What should be the default accessibility for record
A: Currently the most popular proposal is that mandated members get
accessibility of the record type. Other members get package level
accessibility as per a regular class. (Note: it should be legal for explicit
declarations of mandated members to specify something _more_ accessible
(same rules as overriding.) )
A: We are working on a new spec that removes a lot of restriction regarding
Q4. Abstract records.
Should we allow the declaration of abstract classes, possibly supporting
some form of record subtyping?
A: No support for this.
Q5. Deconstruction patterns.
A: We will be proposing deconstruction patterns in the patterns v2 preview.
Should we allow record components to be marked as @deprecated?
A: We don't want to add any additional support for @deprecated beyond the
fact that it is an annotation and it can be inspected via reflection.
Q7. .equals and .toString are slow.
Remi  points out that the current implementations of .equals and
.toString are slow.
A: We will look into this.
Q8. Translation strategy.
John  suggested changing the compilation strategy of records so we can
future-proof the evolution of members from the record supertype.
A: No change.
John  proposed weakening of the .hashCode spec.
A: Agreed. John has written candidate text .
Q10. Special annotation for explicit declaration of accessors.
Tagir  proposes a new `@RecordAccessor` annotation to mark explicit
accessors, much as `@Override` is used to mark method overrides.
A: Rather than introduce a new accessor, we will consider extending the
meaning of the `@Override` annotation to include this case.
Q11. Changing the spec of .toString method
We should weaken the spec of the .toString method so it explicitly states
that the form of the string produced is subject to change and can not be
Q12. Transactional methods
Canonical constructors are an instance of a general pattern where a set of
variables are in scope for a given block, and assigned values at the end.
This could be a useful abstraction to be given first-class representation.
A: No change. More research needed.
Q13. Factory methods instead of constructors.
Should "new R(v1, ..., vn)" be compiled to a factory method, to allow
future-proofing with inline types?
A: No change for now.
Thanks for your comments and discussions so far. If you disagree with anything
written here, please reply!
More information about the amber-spec-experts