Retrofitting classes as records in the JDK

Tue Feb 25 12:47:33 UTC 2020

Was this missed? I could not find the answers still.

On Tue, Feb 18, 2020 at 6:05 PM Nir Lisker <nlisker at gmail.com> wrote:

> I took a quick look at sun.util.logging.PlatformLogger to start with. The
> class does not declare an accessor for its field 'PlatformLogger.Bridge
> loggerProxy', so it seems like records are not suitable here.
> However, this brings up a question: can the visibility of an accessor
> method be changed or the method removed? Looking at the specs I found [1],
> it seems that the answer is no, but it's not that clear to me:
>
> 8.10.3 Record Members
>> A record type R has the following members:
>> An implicitly declared public accessor method with the same name as the
>> record component, whose return type is the declared type of the record
>> component, unless a public method with the same signature is explicitly
>> declared in the body of the declaration of R.
>
>
> So if a non-public method with the same signature is explicitly declared,
> is it a compile time error? Compile time error is only mentioned in:
>
> It is a compile-time error if an explicitly declared accessor method has a
>> throws clause.
>
>
> [1]
> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html#jls-8.10.3
>
> On Tue, Feb 18, 2020 at 5:33 PM Nir Lisker <nlisker at gmail.com> wrote:
>
>> Given that record is a preview feature, there is no point to try to
>>> convert those classes now, but in the future why not, it will make those
>>> classes more readable.
>>
>>
>> Yeah, OpenJFX N maintains backwards compatibility with JDK N-1, so we
>> have some time until we do the conversion. I want to get a head start on
>> this large task and test preview records while at it.
>>
>> The script is a nice idea, I'll try it. Thanks!
>>
>> On Tue, Feb 18, 2020 at 4:57 PM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>> Here is a small script [0] using ASM that tries to find classes that can
>>> be retrofitted to be records.
>>> A potential record is a non-visible class (non public or public but non
>>> in an exported package) that have only final fields and have methods that
>>> looks like accessors (the logic is fuzzy, it looks for variation of "return
>>> this.foo" with possible operations in between).
>>>
>>> Given that record is a preview feature, there is no point to try to
>>> convert those classes now, but in the future why not, it will make those
>>> classes more readable.
>>>
>>> One fun thing (at least for me) is that the class "ConstantDynamic",
>>> "Handle" and "TypeReference" of ASM (that are vendorized/shaded in the
>>> package jdk/internal/org/objectweb/asm) can be converted to record.
>>> But again, it will take time given that the source code of ASM is
>>> compatible with Java 8.
>>>
>>> cheers,
>>> Rémi
>>>
>>> [0]
>>> https://github.com/forax/amber-record/blob/master/src/main/java/fr.umlv.record.recordfinder/fr/umlv/record/recordfinder/RecordFinder.java
>>>
>>> On java.base, you get
>>> sun/util/logging/PlatformLogger
>>> sun/util/locale/LocaleExtensions
>>> sun/security/x509/AVA
>>> sun/security/x509/CertificatePolicySet
>>> sun/security/x509/GeneralNames
>>> sun/security/x509/GeneralSubtrees
>>> sun/security/util/ConstraintsParameters
>>> sun/security/ssl/SecureKey
>>> sun/security/ssl/SessionId
>>> sun/security/internal/spec/TlsKeyMaterialSpec
>>> sun/security/internal/spec/TlsMasterSecretParameterSpec
>>> sun/security/internal/spec/TlsPrfParameterSpec
>>> sun/reflect/generics/tree/ArrayTypeSignature
>>> sun/reflect/generics/tree/ClassSignature
>>> sun/reflect/generics/tree/ClassTypeSignature
>>> sun/reflect/generics/tree/FormalTypeParameter
>>> sun/reflect/generics/tree/MethodTypeSignature
>>> sun/reflect/generics/tree/SimpleClassTypeSignature
>>> sun/reflect/generics/tree/TypeVariableSignature
>>> sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl
>>> sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl
>>> sun/reflect/generics/factory/CoreReflectionFactory
>>> sun/reflect/annotation/AnnotationType
>>> sun/reflect/annotation/TypeAnnotation
>>> sun/nio/ch/NativeSocketAddress
>>> sun/nio/ch/ThreadPool
>>> jdk/internal/org/objectweb/asm/ConstantDynamic
>>> jdk/internal/org/objectweb/asm/Handle
>>> jdk/internal/org/objectweb/asm/TypeReference
>>> jdk/internal/org/objectweb/asm/tree/analysis/BasicValue
>>> jdk/internal/org/objectweb/asm/tree/analysis/SourceValue
>>> jdk/internal/org/objectweb/asm/commons/Method
>>> jdk/internal/module/IllegalAccessMaps
>>> jdk/internal/module/ModuleHashes
>>> jdk/internal/module/ModulePatcher
>>> jdk/internal/module/ModuleResolution
>>> jdk/internal/module/ModuleTarget
>>> jdk/internal/loader/LoaderPool
>>> jdk/internal/jrtfs/JrtFileAttributes
>>> jdk/internal/jimage/ImageHeader
>>> jdk/internal/jimage/decompressor/CompressedResourceHeader
>>> java/util/KeyValueHolder
>>> java/time/chrono/ChronoLocalDateTimeImpl
>>> java/time/chrono/ChronoZonedDateTimeImpl
>>> java/net/UrlDeserializedState
>>> java/lang/NamedPackage
>>> java/lang/invoke/InfoFromMemberName
>>> java/lang/invoke/LambdaFormEditor
>>> java/lang/constant/DirectMethodHandleDescImpl
>>> java/lang/constant/MethodTypeDescImpl
>>> java/lang/constant/ReferenceClassDescImpl
>>>
>>>
>>> ----- Mail original -----
>>> > De: "Nir Lisker" <nlisker at gmail.com>
>>> > À: "Brian Goetz" <brian.goetz at oracle.com>
>>> > Cc: "amber-dev" <amber-dev at openjdk.java.net>
>>> > Envoyé: Mardi 18 Février 2020 00:17:48
>>> > Objet: Re: Retrofitting classes as records in the JDK
>>>
>>> >>
>>> >> 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
>>> >>
>>> >>
>>>
>>