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