Draft JLS spec for records
Brian Goetz
brian.goetz at oracle.com
Thu Sep 5 19:24:55 UTC 2019
>
> There needs to be a deterministic,
> mechanically-derivable-from-the-state-vector way to construct a
> record instance. Serialization, for example, would use this for
> reconstructing the object; frameworks like O/R mappers would do
> the same. Allowing the user to withdraw the constructor from the
> API would undermine this.
>
>
> Serialization is an opt-in mechanism, i've not problem with the
> constructor of a record being always public if the record is marked as
> Serializable.
I have a big, big problem with that. I don't want the accessibility of
the mandated members to depend on something as ephemeral as what
interfaces you implement; this is a giant leap towards the slippery
slope of "Please, can I have 37 knobs on the code generator, kthxbye".
No knobs. There are no knobs.
> But i don't think it's a good idea to make all records "serializable"
> (in the general sense) by default
No one is suggesting that. Serialization was an example; OR mappers was
another. These are examples of the general principle that "we want
records to be instantiable by frameworks", which means they need a way
to find the constructor reflectively.
> Java serialization is not the best mechanism, mostly because of its
> implementation, but at least there is one thing right, being
> serializable is opt-in.
> I believe we should follow the same principle by allowing the
> constructor to be public or private, you are opting for being
> serializable (in the general sense) or not.
Among other things, unless we're willing to have _yet a third_ default
accessibility (one for classes, one for interfaces, and yet another for
records), then the obvious thing people will type:
record R(int x) {
R { ... }
}
would leave the ctor as package-private, which is probably not what
people want either. Nope.
I sympathize with the concern that "public ctor is not the best thing to
expose". Until someone offers something better, though, this is the
best we've got so far.
More information about the amber-spec-observers
mailing list