Getters vs. public final fields in records

[Ron Pressler]

If I understand correctly, you have two complaints:

1. The requirements from record classes that client code is able to rely on are 
   not the ones you’d like them to be. In fact, as Brian hinted, the actual
   requirements are weaker than the ones you discussed. They’re just the ones
   needed to allow the reasonable use of records in collections (such as sets or
   map keys), pattern-matching, and serialization. 

2. Some assumptions on records --  whatever they are -- are not strongly enforced 
   in a way that the client code can "know for certain" that they hold.

As for 1, Brian explained why, for reasons involving mutability in general and
arrays in particular, we chose not to assume/enforce "tupleness". While we
like treating records as tuples, they are not strictly formally so, but we
believe the assumptions we chose to make are the right ones for a Java data
carrier. If the need for stronger tuples is great, and if records are "flawed
in a way that is not yet well-known to the Java community" then a new feature
could hypothetically be added when the flaw *and its severity* are well known.
At this point in time, the bar for adding another feature is a clear demonstration
that it’s required to solve a *serious/frequent* problem encountered *in the field*.
I don’t think anyone has the sufficient experience to clear that bar right now.

And here's the important point: while the properties of records are objectively
as you said, and might even be characterised as objective flaws, your
alternative suffers from other objective flaws. You're suggesting that we
prefer your objectively flawed design to our objectively flawed design;
that's no longer objective, and we disagree with your prioritisation. BTW, it 
is also not objectively true that every error -- accepting your premise -- is 
always worth correcting.

When domain experts are in disagreement, we listen to all of them but, 
objectively, must reject the opinion of some. You have been respectfully 
listened to and engaged, your suggestion was considered and for now rejected.
Had it been otherwise, we’d be listening and rejecting other domain experts 
who wish the decision went the other way. The suggestion that we’re not being
responsible stewards of the platform, or not listening, because after
consideration we must rule in favour of one domain expert over another
is disrespectful of the work we must do.


As for 2, I will try not to get carried away because the subject has been of
great interest to me for years, both in the field of programming languages and
the field of formal methods. The general question is in which situations is
the cost/benefit of soundness justified compared to unsound approaches. The
formal methods community in particular has seen a shift in favour of
unsoundness in recent decades. We try to find a balance in every particular
case.

More specifically, when it comes to Java, static guarantees are not always what
they seem. For example, in your motivating example, it is not true that `if
(r.foo != null) r.foo.bar();` is sufficient to "know for certain" that r.foo
will not be null without other checks or a special configuration. The reason is
that due to separate compilation and binary compatibility, the class of r at
runtime might not be the same as its class at compilation time (Even if your
alternative the Record class did not allow its subclasses to be defined with
non-final fields, binary compatibility would still require you to check, at
runtime, that r is a subclass of Record). So really we’re comparing the
cost/benefit of different levels of unsoundness. The strong guarantees we
provide in Java — needed for, say, security — often take a more dynamic form.
Indeed, there is a stronger guarantee for records made in OpenJDK, and that is
that an instance of a record class cannot be instantiated without calling its
canonical constructor.

Anyway, given that, on balance, the non-strict-tupleness of records was deemed
insufficient to merit action at this time, I’d be happy to continue the
discussion off-list, but there’s little point arguing further on amber-dev.

— Ron