Retrofitting classes as records in the JDK

[Nir Lisker]

>
> By the way, it would be nice to have a default implementation for setValue
> throwing UnsupportedOperationException, similar to Iterator.remove. WDYT?
>

That could work if backwards compatibility allows it. I took a quick look
and found about 6 implementing classes that throw UOE.

On Tue, Feb 18, 2020 at 5:45 PM Tagir Valeev <amaembo at gmail.com> wrote:

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