Feedback for records: Accessors name() vs. getName()

[Roman Elizarov]

Alex,

> Since a TimeConfigSnapshot record is just a side-effect-free carrier for
> data, why should it get to drive the design of a broad API (TimeConfig)
> to which at least one pre-existing interface is expected to conform?
> That goes double when the pre-existing interface is not side-effect-free
> (synchronizeTimeWithServer). Why doesn't the pre-existing interface get
> to drive the design?

Having seen your explicit response with the required boilerplate I've
realized that the boilerplate is not the only problem. It goes deeper.
Let's look at it:

> record TimeConfigSnapshot(Instant currentTime, ServerInfo
> timeServerInfo) implements TimeConfig {
>      public Instant    getCurrentTime()    {...}
>      public ServerInfo getTimeServerInfo() {...}
> }

Indeed, those getters could be automated away in various ways (IDEA can
generate them in the source or a Lombok-like tool can add them during
compilation without polluting the source). However, there is no way to
opt-out of the automatically generated component accessors that I can see
in the current spec, so this kind of a TimeConfigSnapshot record class will
end up having both `currentTime()` and `getCurrentTime()` methods. Not
nice. Moreover, it seems that the only way for an API designer/architect to
mark `currentTime()` as deprecated to indicate to the users of this class
that `getCurrentTime()` is preferrable for consistency (since it is also a
part of TimeConfig interface) is only by explicitly implementing
`currentTime()` method, too.

However, having looked at the JVM spec I don't see any constraints that are
imposed on the classes with the Record attribute, so it looks like you can
write a bytecode post-processor that removes the extra component accessors
that are not preceded by the `get` verb and leave only getters. Is this
indeed the allowed kind of transformation or it might break some other
parts of the platform (like serialization) that rely on the Record
attribute?

E.g. my question is whether the auto-generation of accessors with matching
names for records is just a Java language feature, or is it intended to be
a part of an ABI for any record in JVM? Does the specification on the
Record attribute in JVM omit any constrains by design and this attribute
can, indeed, simply contain anything and does not need to be related to the
rest of the class, or is it an omission in the spec? If so, then what would
be the actual JVM requirements on the record class if other JVM languages
or byte-code engineering libraries would start generating them?

Sincerely,
Roman Elizarov