Draft JLS spec for records

Brian Goetz brian.goetz at oracle.com
Thu Sep 5 20:55:13 UTC 2019

> We are circulating back to my first question, why the constructor has 
> to be public.

Think about it some more.  Suppose the default was that the constructor 
was private.  Now, without specifying a constructor, no record could be 
instantiated at all, without the user declaring a constructor!  That 
would be terrible.  Part of the point here is that the require acquires 
a standard, sensible external API _without_ the user having to declare 
these elements.  Users's get to say `record Foo(String s)`, and get 
everything they need to use the record.

If Java had factories, then we could quite sensibly decide the mandated 
API is a private ctor and a public factory.  But it doesn't, so we can't.

OK, I suppose the next thing you are going to say is "Sigh, I guess the 
default (implicit) constructor has to be public, but if I _explicitly_ 
provide a constructor, I should be able to 'remove' it from the API."  
But, why do that for the constructor, and not for the accessors?  In 
addition to it violating the "there's one, uniform, mandated API" 
principle, it would be yet another gratuitous sharp edge.

Or, maybe you're going to say "yes, the user should be able to 'edit' 
the API as they see fit; if they don't want an x() accessor, they can 
make it private."  That's a valid alternate point in the design space, 
but that's not the design center we chose for records.  There is a lot 
of value to the fact that a fully functional API (construction, 
deconstruction, access) can be mechanically derived from the record 
descriptor.  Once you start letting the user tweak each aspect, we lose 
this benefit -- and for what?

Sure, we could opt for an approach where records are their own little 
world of special-case complexity.  Which might be a valid alternate 
design philosophy -- but the reason we didn't go there is that the 
return-on-complexity just isn't there.  In fact, one by one, we've been 
_removing_ gratuitous differences between records and classes, and each 
time we did, the design seems to have gotten better.

More information about the amber-spec-experts mailing list