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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190905/cb8facae/attachment-0001.html>
More information about the amber-spec-experts
mailing list