Retrofitting classes as records in the JDK

[Brian Goetz]

So, it will be very easy to get the wrong idea from what the JDK will 
eventually do here.  It is pretty likely that the JDK will not expose 
very many records at all, but instead is more likely to use them in 
implementations.

Where we've landed with records makes them more suitable for _internal_ 
abstractions and implementation details than public API abstractions if 
the API has to meet a high compatibility bar.  The reason is that 
evolving them in significant ways -- such as adding, removing, changing, 
or reordering components, or migrating them from a record to an ordinary 
class -- has compatibility consequences that are probably more than the 
JDK would be willing to take (though other libraries will surely feel 
differently.)

(Bear in mind that the JDK is surely the only library in the world that 
has this high a bar for compatibility expectations, so what is a problem 
for us is not a problem for the rest of the ecosystem.  For example, it 
is impossible to refactor an enum or record to a class with 100% 
compatibility -- because of the restricted Enum and Record 
superclasses.  This is a blocker for the JDK, but for just about the 
entire rest of the ecosystem, is often not a problem in practice, 
because the 99% you can get is generally good enough for them.)

Where we expect to use records in the JDK is in streamlining 
implementations, and maybe as far as private implementations of public 
interfaces (e.g., Map.Entry).  But I wouldn't expect a lot of public 
records.



On 2/17/2020 10:03 AM, Nir Lisker wrote:
> Hi,
>
> Is there a discussion somewhere about which existing classes in the JDK are
> planned to become records? As an OpenJFX contributor, I'd like to get a
> head start and see how we can utilize records correctly. Seeing how the JDK
> does it is the best approach in my opinion.
>
> - Nir