The basic principle behind records is that the user has given up the
ability to decouple the API from the representation. This benefits the
user with a concise declaration, and it benefits clients by being able
to reason about the existence and semantics of a fixed set of members
(ctor, dtor, accessors, object methods.) And clients are further
divided into two buckets: human clients and frameworks.
If I read your query correctly, you're concerned primarily about the
naming of the accessor methods. And your reasoning goes something like
this:
- In other languages, we might want to use a different naming
convention (for concreteness, let's call this getFoo()) for the accessors
- If we reified the mapping from components to accessor methods, then
framework clients could still do their job
First, let's note that the concision benefit is independent of
record-ness for other languages, since languages can define their own
rules about how a class is declared. So the benefits of another
language generating a record classfile exists for interop with Java
users / Java code that knows about records.
Since we're telling Java users that a record's API is derived
deterministically from its state description, I think having the
latitude to rename accessors conflicts with that. (However, there's
nothing to stop you from generating _both_ a getFoo() and foo() methods,
so that Java users will see the API they expect.)
The extent to which we validate the classfile at runtime is a separate
consideration; we can choose to fail fast (at the cost of more VM
complexity and startup cost), or treat it as "buggy compiler" and let
things fail in reflection. We have, so far, leaned towards the latter
approach.
JLS for records says that record component getter is named in the same
way as the corresponding field, and this is completely fine for Java
language. However it's unclear for me which approach is best for the
JVMS. I see several options:
- No direct link between record component and the corresponding getter
method at all. A class is free to have an arbitrary named getter or
provide no getter at all. Reflection API believes that there's a
getter named after the record component and may fail for custom
generated classes, but otherwisely these classes work fine.
- Strict requirement that a class must contain a method named exactly
like a record component and having no parameters and exactly the same
return type as the record component type, otherwise the class
verification fails.
- Flexible link: a record component has a new required attribute like
"Getter" which links an arbitrarily named method which has no
parameters and exactly the same return type as the record component
type.
The latter option may be more friendly for JVM languages other than
Java: they may also produce class files with the record components
linking them to the getter names which are traditionally generated in
given language for data classes or case classes (usually "getName" for
"name" component, etc.). In this case both bytecode analysis tools and
reflection-based frameworks could process Java records and non-Java
data-classes/case-classes uniformly.
What do you think?
With best regards,
Tagir Valeev.
