Retrofitting classes as records in the JDK

[Tagir Valeev]

> 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.

Speaking specifically about Map.Entry, records are not ideal fit
there. Taking aside weird component names like Entry(K getKey, V
getValue), one should redefine hashCode because its contract is
specified for the Map.Entry and it differs from record hashCode
contract. Also, setValue should be defined. By the way, it would be
nice to have a default implementation for setValue throwing
UnsupportedOperationException, similar to Iterator.remove. WDYT?

In general, I agree: records are totally great for
local/private/package-private usages, and I see dozens of places in
IntelliJ IDEA sources where they could be used. However, I'm not sure
there are many places where they could be exposed as an API.

With best regards,
Tagir Valeev.



On Tue, Feb 18, 2020 at 1:20 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> 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.)
>
>
>
>
> 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
>