Retrofitting classes as records in the JDK

[Nir Lisker]

>
> Bear in mind that the JDK is surely the only library in the world that has
> this high a bar for compatibility expectations


>From my past work on OpenJFX, we have the same backwards compatibility
obligations (or at least very close).

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.


I agree. This is mostly what I would be looking at.

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


I take it that these migrations are only at the abstract discussion level
then? I'm interested in a more concrete list of places where migration
would happen. What list/issue should I be monitoring?

On Mon, Feb 17, 2020 at 8:20 PM 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.)
>
> 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
>
>
>