From scolebourne at joda.org Mon Dec 1 02:30:23 2025 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 1 Dec 2025 02:30:23 +0000 Subject: Reflection on records In-Reply-To: References:

Message-ID: You'll need to write the annotation processor yourself I'm afraid, this is a design outline. Stephen On Sun, 30 Nov 2025, 21:19 David Alayachew, wrote: > Thanks Stephen. > > Hmmmmm, so this is definitely the best solution I have seen thus far. The > only real downside is that the static final field has a different name than > the actual record component. But I can probably fix that by making it an > inner class or something, as opposed to sharing the same namespace as the > record itself. > > Can you link me to the annotation code? > > On Sun, Nov 30, 2025 at 4:05?PM Stephen Colebourne > wrote: > >> There is a way to do this, but it isn't pretty. Use annotation processing. >> >> @GeneratedRecordComponentInterface >> record User(String firstName, String lastName, ComplexObject >> complexColumn) implements UserColumns {} >> >> // annotation processor generates: >> public interface UserColumns { >> public static final RecordComponentWrapper >> FIRST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >> "firstName"); >> public static final RecordComponentWrapper >> LAST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >> "lastName"); >> public static final RecordComponentWrapper >> COMPLEX_COLUMN_COMPONENT = new RecordComponentWrapper(User.class, >> "complexColumn"); >> } >> >> where `RecordComponentWrapper` is some suitable type-safe wrapper for >> record components. >> >> Although there is a string for each record component, it is in >> generated code, thus won't get out of sync. >> >> (This is the annotation processing equivalent to how Joda-Beans >> meta-properties have worked for many years) >> Stephen >> >> On Sun, 30 Nov 2025 at 20:39, David Alayachew >> wrote: >> > >> > Thanks everyone for the context. The answers I am getting are very >> helpful. I do see a comment about XY problem, so here is the full context >> of my problem. >> > >> > Unlike normal classes, record are transparent data carriers. Which make >> them useful for simple DTO's and serialization. Specifically, I wanted to >> create a De/serialization format for a CSV file. >> > >> > Let's say I have record User(String firstName, String lastName, >> ComplexObject complexColumn) {}, and each RecordComponent corrsponds to a >> column of my CSV, while each instance of User corresponds to a single row. >> Let's also assume that firstName and lastName are computationally cheap to >> deserialize, but complexColumn is expensive (complex but necessary regex). >> > >> > Well, I want to create a CSV De/Serialization tool that allows me to >> not only deserialize the object in full, but also deserialize only the >> specific component I want. In this case, if all I care about is firstName >> and lastName, then why should I pay the price of also deserializing >> complexColumn, which I won't use at all? >> > >> > Hence why I requested these various things in the thread -- such as the >> ability to reference RecordComponents, or why I wanted to use a method >> reference to a records accessors. I wanted some way to get compile time >> type safety about the column I am requesting. If I change my User data type >> such that firstName now says first instead, I want all callers of my tool >> to get compile time errors. But I don't see how to do it. >> > >> > I really do think that, if records claim to be transparent carriers of >> data, then being able to isolate and point to a single RecordComponent in a >> type safe way that will fail at compile time if I am out of sorts sounds >> like a reasonable thing to want from a record. >> > >> > >> > On Sun, Nov 30, 2025 at 3:04?PM Kirill Semyonkin >> wrote: >> >> >> >> Hello David, >> >> >> >> I've seen some people (ab)use Serializable and SerializedLambda to get >> names of the class and the method, with numerous examples like >> https://stackoverflow.com/a/53397378/16208077. From there you can >> traverse usual reflection with those strings to get the exact >> RecordComponent or some other reflection object. But those strings come >> from users doing method references, so you will get the behavior that you >> wanted, at least to some extent. Although it slightly feels like an XY >> problem. >> >> >> >> - Kirill Semyonkin >> >> >> >> ??, 30 ????. 2025??. ? 22:57, Attila Kelemen < >> attila.kelemen85 at gmail.com>: >> >>> >> >>> I guess, if your record type is fixed, then you can have a dummy >> instance of that record with all fields being different (hopefully, no 3 >> boolean components :)), and then you can do the same hack as with the >> interface + proxy combo. >> >>> >> >>> Attila Kelemen ezt ?rta (id?pont: 2025. >> nov. 30., V, 20:51): >> >>>> >> >>>> I think that is impossible. What I did when I needed something >> similar is that I used an interface instead of a record and built utilities >> around it, because in that case you can imitate what you want. >> >>>> >> >>>> That is, consider that you have `interface User { String >> firstName(); String lastName() }`. In this case, you could have methods >> taking a `Function` and then you can create an instance of `User` >> via `Proxy.newProxyInstance` in which you record which method was called, >> and pass the proxy instance to the `Function`. Assuming that someone passed >> `User::firstName` for the `Function`, you can detect which method was >> passed. The drawbacks are obvious, but it is better than passing strings in >> my opinion. >> >>>> >> >>>> David Alayachew ezt ?rta (id?pont: 2025. >> nov. 30., V, 20:41): >> >>>>> >> >>>>> Thanks for the response Attila. >> >>>>> >> >>>>> Let me try and loosen the constraints then -- is there any way for >> me to get a RecordComponent corresponding to firstName without needing to >> do String comparison? >> >>>>> >> >>>>> At the end of the day, that's all that I really need. >> >>>>> >> >>>>> As is now, the only way I can see to get a RecordComponent is to >> drill down from j.l.Class --> j.l.r.RecordComponent, then do String >> comparison against a provided String to get the record component that I >> want. That is unsafe and stringly typed, so, very much undesirable. After >> all, if I change my record to say first instead of firstName, I want a >> compiler error. But doing it that way, I won't -- I'll get a runtime error. >> >>>>> >> >>>>> So that's what I really want -- a type-safe way to isolate a record >> component from a record, without forcing my users to have to provide a >> String corresponding to the record component name. >> >>>>> >> >>>>> On Sun, Nov 30, 2025 at 2:16?PM Attila Kelemen < >> attila.kelemen85 at gmail.com> wrote: >> >>>>>> >> >>>>>> I'm pretty sure there is no such thing, because that essentially >> implies the existence of some kind of method literal (well, it would not be >> strictly necessary, but the JLS would feel strange without it), and there >> is no such thing (though it would be awesome, if there was). >> >>>>>> >> >>>>>> Also, note that if this was a thing, then your case is just a very >> special case, and you would want more (I would for sure). That is, in that >> case, I would also want type safety. So, something like >> MethodReference<(MyRecord) -> String> (which of course would require >> function types in Java). >> >>>>>> >> >>>>>> When I needed this, luckily I could restrain my need to interface >> methods (as opposed to your record getters) where I could create a `Proxy` >> and see which method gets called (nasty hack, has its downsides, but felt >> like the safest to me). >> >>>>>> >> >>>>>> Attila >> >>>>>> >> >>>>>> David Alayachew ezt ?rta (id?pont: >> 2025. nov. 29., Szo, 20:50): >> >>>>>>> >> >>>>>>> And by all means, add more parameters to foo if you want. For >> example, if a User.class helps, please do so! >> >>>>>>> >> >>>>>>> I just don't want to do anything like this. >> >>>>>>> >> >>>>>>> foo("firstName"); >> >>>>>>> >> >>>>>>> That's stringly typed, and undesirable for my use case. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Mon Dec 1 09:55:31 2025 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Mon, 1 Dec 2025 10:55:31 +0100 Subject: Reflection on records In-Reply-To: References:

Message-ID: There are some other downsides as well: You will have to force your clients to specifically design their records to your API (i.e., annotate it, and configure the annotation processor). Though, in your case that is probably not too bad, because likely they want to design their DTO for your API anyway. The other downside is that you will have to write the IDE support as well (e.g., Idea's editor will have red curlys around without it). Which, aside from the additional maintenance cost, can be a problem for a user who is not allowed to install arbitrary IDE plugins. Also, compared to the original outline, you probably want an additional generic argument for the record type on `RecordComponentWrapper` for type safety. David Alayachew ezt ?rta (id?pont: 2025. dec. 1., H, 1:53): > Thanks Stephen. > > Hmmmmm, so this is definitely the best solution I have seen thus far. The > only real downside is that the static final field has a different name than > the actual record component. But I can probably fix that by making it an > inner class or something, as opposed to sharing the same namespace as the > record itself. > > Can you link me to the annotation code? > > On Sun, Nov 30, 2025 at 4:05?PM Stephen Colebourne > wrote: > >> There is a way to do this, but it isn't pretty. Use annotation processing. >> >> @GeneratedRecordComponentInterface >> record User(String firstName, String lastName, ComplexObject >> complexColumn) implements UserColumns {} >> >> // annotation processor generates: >> public interface UserColumns { >> public static final RecordComponentWrapper >> FIRST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >> "firstName"); >> public static final RecordComponentWrapper >> LAST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >> "lastName"); >> public static final RecordComponentWrapper >> COMPLEX_COLUMN_COMPONENT = new RecordComponentWrapper(User.class, >> "complexColumn"); >> } >> >> where `RecordComponentWrapper` is some suitable type-safe wrapper for >> record components. >> >> Although there is a string for each record component, it is in >> generated code, thus won't get out of sync. >> >> (This is the annotation processing equivalent to how Joda-Beans >> meta-properties have worked for many years) >> Stephen >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Mon Dec 1 10:22:31 2025 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 1 Dec 2025 11:22:31 +0100 Subject: Reflection on records In-Reply-To: References: Message-ID: I think this will surely be possible for RecordComponents with code reflection (project Babylon), using the syntax you propose. You can create a quotable function like this: import jdk.incubator.code.*; @Reflect @FunctionalInterface interface Accessor { Object get(Record r); } Then create something like (just a sketch, sorry, I have no time now to provide a full-fledged sample): static RecordComponent foo(Accessor acc) { Quoted q = Op.ofQuotable(acc).orElseThrow(); // extract a method handle from q using Babylon API // unreflect it and find the corresponding RecordComponent } With best regards, Tagir Valeev On Sat, Nov 29, 2025 at 8:45?PM David Alayachew wrote: > Hello @amber-dev , > > I asked this on core-libs-dev already, but I figured I should ask here too. > > Let's say I have some record User(String firstName, String lastName) {}. > > Is there any possible way for me to do the following? > > java.lang.reflect.RecordComponent firstName = foo(User::firstName); > > I'll even accept this. > > java.lang.reflect.Method lastName = foo(User::lastName); > > Thank you for your time and consideration. > David Alayachew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Dec 1 13:33:05 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 1 Dec 2025 08:33:05 -0500 Subject: Reflection on records In-Reply-To: References:

Message-ID: Understood. Thanks @Stephen Colebourne . And yes @Attila Kelemen , I agree that it being an annotation does make it less ideal. Plus, I lose out on other things that the compiler might one day give us, like exhaustiveness checking. All in all, it is still the best solution, but not one I am a fan of. On Mon, Dec 1, 2025, 4:55?AM Attila Kelemen wrote: > There are some other downsides as well: You will have to force your > clients to specifically design their records to your API (i.e., annotate > it, and configure the annotation processor). Though, in your case that is > probably not too bad, because likely they want to design their DTO for your > API anyway. The other downside is that you will have to write the IDE > support as well (e.g., Idea's editor will have red curlys around without > it). Which, aside from the additional maintenance cost, can be a problem > for a user who is not allowed to install arbitrary IDE plugins. Also, > compared to the original outline, you probably want an additional generic > argument for the record type on `RecordComponentWrapper` for type safety. > > David Alayachew ezt ?rta (id?pont: 2025. dec. > 1., H, 1:53): > >> Thanks Stephen. >> >> Hmmmmm, so this is definitely the best solution I have seen thus far. The >> only real downside is that the static final field has a different name than >> the actual record component. But I can probably fix that by making it an >> inner class or something, as opposed to sharing the same namespace as the >> record itself. >> >> Can you link me to the annotation code? >> >> On Sun, Nov 30, 2025 at 4:05?PM Stephen Colebourne >> wrote: >> >>> There is a way to do this, but it isn't pretty. Use annotation >>> processing. >>> >>> @GeneratedRecordComponentInterface >>> record User(String firstName, String lastName, ComplexObject >>> complexColumn) implements UserColumns {} >>> >>> // annotation processor generates: >>> public interface UserColumns { >>> public static final RecordComponentWrapper >>> FIRST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>> "firstName"); >>> public static final RecordComponentWrapper >>> LAST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>> "lastName"); >>> public static final RecordComponentWrapper >>> COMPLEX_COLUMN_COMPONENT = new RecordComponentWrapper(User.class, >>> "complexColumn"); >>> } >>> >>> where `RecordComponentWrapper` is some suitable type-safe wrapper for >>> record components. >>> >>> Although there is a string for each record component, it is in >>> generated code, thus won't get out of sync. >>> >>> (This is the annotation processing equivalent to how Joda-Beans >>> meta-properties have worked for many years) >>> Stephen >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Dec 1 13:35:15 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 1 Dec 2025 08:35:15 -0500 Subject: Reflection on records In-Reply-To: References: Message-ID: Thanks @Tagir Valeev . I am still not great at the stuff Babylon is doing, so I can only roughly follow along. Regardless, it sounds like this is depending on Babylon features which have not yet landed in the mainline jdk, yes? On Mon, Dec 1, 2025, 5:22?AM Tagir Valeev wrote: > I think this will surely be possible for RecordComponents with code > reflection (project Babylon), using the syntax you propose. > > You can create a quotable function like this: > > import jdk.incubator.code.*; > > @Reflect > @FunctionalInterface > interface Accessor { > Object get(Record r); > } > > Then create something like (just a sketch, sorry, I have no time now to > provide a full-fledged sample): > > static RecordComponent foo(Accessor acc) { > Quoted q = Op.ofQuotable(acc).orElseThrow(); > // extract a method handle from q using Babylon API > // unreflect it and find the corresponding RecordComponent > } > > With best regards, > Tagir Valeev > > On Sat, Nov 29, 2025 at 8:45?PM David Alayachew > wrote: > >> Hello @amber-dev , >> >> I asked this on core-libs-dev already, but I figured I should ask here >> too. >> >> Let's say I have some record User(String firstName, String lastName) {}. >> >> Is there any possible way for me to do the following? >> >> java.lang.reflect.RecordComponent firstName = foo(User::firstName); >> >> I'll even accept this. >> >> java.lang.reflect.Method lastName = foo(User::lastName); >> >> Thank you for your time and consideration. >> David Alayachew >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Mon Dec 1 14:01:36 2025 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 1 Dec 2025 15:01:36 +0100 Subject: Reflection on records In-Reply-To: References:

Message-ID: Yes, you have to build it from the Babylon repo. On Mon, Dec 1, 2025, 14:35 David Alayachew wrote: > Thanks @Tagir Valeev . > > I am still not great at the stuff Babylon is doing, so I can only roughly > follow along. Regardless, it sounds like this is depending on Babylon > features which have not yet landed in the mainline jdk, yes? > > > On Mon, Dec 1, 2025, 5:22?AM Tagir Valeev wrote: > >> I think this will surely be possible for RecordComponents with code >> reflection (project Babylon), using the syntax you propose. >> >> You can create a quotable function like this: >> >> import jdk.incubator.code.*; >> >> @Reflect >> @FunctionalInterface >> interface Accessor { >> Object get(Record r); >> } >> >> Then create something like (just a sketch, sorry, I have no time now to >> provide a full-fledged sample): >> >> static RecordComponent foo(Accessor acc) { >> Quoted q = Op.ofQuotable(acc).orElseThrow(); >> // extract a method handle from q using Babylon API >> // unreflect it and find the corresponding RecordComponent >> } >> >> With best regards, >> Tagir Valeev >> >> On Sat, Nov 29, 2025 at 8:45?PM David Alayachew >> wrote: >> >>> Hello @amber-dev , >>> >>> I asked this on core-libs-dev already, but I figured I should ask here >>> too. >>> >>> Let's say I have some record User(String firstName, String lastName) {}. >>> >>> Is there any possible way for me to do the following? >>> >>> java.lang.reflect.RecordComponent firstName = foo(User::firstName); >>> >>> I'll even accept this. >>> >>> java.lang.reflect.Method lastName = foo(User::lastName); >>> >>> Thank you for your time and consideration. >>> David Alayachew >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Dec 1 14:07:55 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 1 Dec 2025 09:07:55 -0500 Subject: Reflection on records In-Reply-To: References:

Message-ID: Understood. Thanks for clarifying. For now, I'll hold off on that, as I don't know how stable that is, and I don't really want to.build this new library off of it. Maybe when the respective JEP goes into preview. Could you link me to that JEP, or is there not one yet? On Mon, Dec 1, 2025, 9:01?AM Tagir Valeev wrote: > Yes, you have to build it from the Babylon repo. > > On Mon, Dec 1, 2025, 14:35 David Alayachew > wrote: > >> Thanks @Tagir Valeev . >> >> I am still not great at the stuff Babylon is doing, so I can only roughly >> follow along. Regardless, it sounds like this is depending on Babylon >> features which have not yet landed in the mainline jdk, yes? >> >> >> On Mon, Dec 1, 2025, 5:22?AM Tagir Valeev wrote: >> >>> I think this will surely be possible for RecordComponents with code >>> reflection (project Babylon), using the syntax you propose. >>> >>> You can create a quotable function like this: >>> >>> import jdk.incubator.code.*; >>> >>> @Reflect >>> @FunctionalInterface >>> interface Accessor { >>> Object get(Record r); >>> } >>> >>> Then create something like (just a sketch, sorry, I have no time now to >>> provide a full-fledged sample): >>> >>> static RecordComponent foo(Accessor acc) { >>> Quoted q = Op.ofQuotable(acc).orElseThrow(); >>> // extract a method handle from q using Babylon API >>> // unreflect it and find the corresponding RecordComponent >>> } >>> >>> With best regards, >>> Tagir Valeev >>> >>> On Sat, Nov 29, 2025 at 8:45?PM David Alayachew < >>> davidalayachew at gmail.com> wrote: >>> >>>> Hello @amber-dev , >>>> >>>> I asked this on core-libs-dev already, but I figured I should ask here >>>> too. >>>> >>>> Let's say I have some record User(String firstName, String lastName) {}. >>>> >>>> Is there any possible way for me to do the following? >>>> >>>> java.lang.reflect.RecordComponent firstName = foo(User::firstName); >>>> >>>> I'll even accept this. >>>> >>>> java.lang.reflect.Method lastName = foo(User::lastName); >>>> >>>> Thank you for your time and consideration. >>>> David Alayachew >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Mon Dec 1 14:09:59 2025 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 1 Dec 2025 15:09:59 +0100 Subject: Reflection on records In-Reply-To: References:

Message-ID: I don't think there are any published JEPs. Here's some information about the project: https://openjdk.org/projects/babylon/ On Mon, Dec 1, 2025, 15:08 David Alayachew wrote: > Understood. Thanks for clarifying. For now, I'll hold off on that, as I > don't know how stable that is, and I don't really want to.build this new > library off of it. Maybe when the respective JEP goes into preview. Could > you link me to that JEP, or is there not one yet? > > On Mon, Dec 1, 2025, 9:01?AM Tagir Valeev wrote: > >> Yes, you have to build it from the Babylon repo. >> >> On Mon, Dec 1, 2025, 14:35 David Alayachew >> wrote: >> >>> Thanks @Tagir Valeev . >>> >>> I am still not great at the stuff Babylon is doing, so I can only >>> roughly follow along. Regardless, it sounds like this is depending on >>> Babylon features which have not yet landed in the mainline jdk, yes? >>> >>> >>> On Mon, Dec 1, 2025, 5:22?AM Tagir Valeev wrote: >>> >>>> I think this will surely be possible for RecordComponents with code >>>> reflection (project Babylon), using the syntax you propose. >>>> >>>> You can create a quotable function like this: >>>> >>>> import jdk.incubator.code.*; >>>> >>>> @Reflect >>>> @FunctionalInterface >>>> interface Accessor { >>>> Object get(Record r); >>>> } >>>> >>>> Then create something like (just a sketch, sorry, I have no time now to >>>> provide a full-fledged sample): >>>> >>>> static RecordComponent foo(Accessor acc) { >>>> Quoted q = Op.ofQuotable(acc).orElseThrow(); >>>> // extract a method handle from q using Babylon API >>>> // unreflect it and find the corresponding RecordComponent >>>> } >>>> >>>> With best regards, >>>> Tagir Valeev >>>> >>>> On Sat, Nov 29, 2025 at 8:45?PM David Alayachew < >>>> davidalayachew at gmail.com> wrote: >>>> >>>>> Hello @amber-dev , >>>>> >>>>> I asked this on core-libs-dev already, but I figured I should ask here >>>>> too. >>>>> >>>>> Let's say I have some record User(String firstName, String lastName) >>>>> {}. >>>>> >>>>> Is there any possible way for me to do the following? >>>>> >>>>> java.lang.reflect.RecordComponent firstName = foo(User::firstName); >>>>> >>>>> I'll even accept this. >>>>> >>>>> java.lang.reflect.Method lastName = foo(User::lastName); >>>>> >>>>> Thank you for your time and consideration. >>>>> David Alayachew >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Dec 1 14:15:33 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 1 Dec 2025 09:15:33 -0500 Subject: Reflection on records In-Reply-To: References:

Message-ID: ? David reacted via Gmail On Mon, Dec 1, 2025, 9:10?AM Tagir Valeev wrote: > I don't think there are any published JEPs. Here's some information about > the project: > https://openjdk.org/projects/babylon/ > > On Mon, Dec 1, 2025, 15:08 David Alayachew > wrote: > >> Understood. Thanks for clarifying. For now, I'll hold off on that, as I >> don't know how stable that is, and I don't really want to.build this new >> library off of it. Maybe when the respective JEP goes into preview. Could >> you link me to that JEP, or is there not one yet? >> >> On Mon, Dec 1, 2025, 9:01?AM Tagir Valeev wrote: >> >>> Yes, you have to build it from the Babylon repo. >>> >>> On Mon, Dec 1, 2025, 14:35 David Alayachew >>> wrote: >>> >>>> Thanks @Tagir Valeev . >>>> >>>> I am still not great at the stuff Babylon is doing, so I can only >>>> roughly follow along. Regardless, it sounds like this is depending on >>>> Babylon features which have not yet landed in the mainline jdk, yes? >>>> >>>> >>>> On Mon, Dec 1, 2025, 5:22?AM Tagir Valeev wrote: >>>> >>>>> I think this will surely be possible for RecordComponents with code >>>>> reflection (project Babylon), using the syntax you propose. >>>>> >>>>> You can create a quotable function like this: >>>>> >>>>> import jdk.incubator.code.*; >>>>> >>>>> @Reflect >>>>> @FunctionalInterface >>>>> interface Accessor { >>>>> Object get(Record r); >>>>> } >>>>> >>>>> Then create something like (just a sketch, sorry, I have no time now >>>>> to provide a full-fledged sample): >>>>> >>>>> static RecordComponent foo(Accessor acc) { >>>>> Quoted q = Op.ofQuotable(acc).orElseThrow(); >>>>> // extract a method handle from q using Babylon API >>>>> // unreflect it and find the corresponding RecordComponent >>>>> } >>>>> >>>>> With best regards, >>>>> Tagir Valeev >>>>> >>>>> On Sat, Nov 29, 2025 at 8:45?PM David Alayachew < >>>>> davidalayachew at gmail.com> wrote: >>>>> >>>>>> Hello @amber-dev , >>>>>> >>>>>> I asked this on core-libs-dev already, but I figured I should ask >>>>>> here too. >>>>>> >>>>>> Let's say I have some record User(String firstName, String lastName) >>>>>> {}. >>>>>> >>>>>> Is there any possible way for me to do the following? >>>>>> >>>>>> java.lang.reflect.RecordComponent firstName = foo(User::firstName); >>>>>> >>>>>> I'll even accept this. >>>>>> >>>>>> java.lang.reflect.Method lastName = foo(User::lastName); >>>>>> >>>>>> Thank you for your time and consideration. >>>>>> David Alayachew >>>>>> >>>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/vnd.google.email-reaction+json Size: 37 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Dec 1 14:16:02 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 1 Dec 2025 09:16:02 -0500 Subject: Reflection on records In-Reply-To: References:

Message-ID: Ty vm. Will look into it, and more. On Mon, Dec 1, 2025, 9:10?AM Tagir Valeev wrote: > I don't think there are any published JEPs. Here's some information about > the project: > https://openjdk.org/projects/babylon/ > > On Mon, Dec 1, 2025, 15:08 David Alayachew > wrote: > >> Understood. Thanks for clarifying. For now, I'll hold off on that, as I >> don't know how stable that is, and I don't really want to.build this new >> library off of it. Maybe when the respective JEP goes into preview. Could >> you link me to that JEP, or is there not one yet? >> >> On Mon, Dec 1, 2025, 9:01?AM Tagir Valeev wrote: >> >>> Yes, you have to build it from the Babylon repo. >>> >>> On Mon, Dec 1, 2025, 14:35 David Alayachew >>> wrote: >>> >>>> Thanks @Tagir Valeev . >>>> >>>> I am still not great at the stuff Babylon is doing, so I can only >>>> roughly follow along. Regardless, it sounds like this is depending on >>>> Babylon features which have not yet landed in the mainline jdk, yes? >>>> >>>> >>>> On Mon, Dec 1, 2025, 5:22?AM Tagir Valeev wrote: >>>> >>>>> I think this will surely be possible for RecordComponents with code >>>>> reflection (project Babylon), using the syntax you propose. >>>>> >>>>> You can create a quotable function like this: >>>>> >>>>> import jdk.incubator.code.*; >>>>> >>>>> @Reflect >>>>> @FunctionalInterface >>>>> interface Accessor { >>>>> Object get(Record r); >>>>> } >>>>> >>>>> Then create something like (just a sketch, sorry, I have no time now >>>>> to provide a full-fledged sample): >>>>> >>>>> static RecordComponent foo(Accessor acc) { >>>>> Quoted q = Op.ofQuotable(acc).orElseThrow(); >>>>> // extract a method handle from q using Babylon API >>>>> // unreflect it and find the corresponding RecordComponent >>>>> } >>>>> >>>>> With best regards, >>>>> Tagir Valeev >>>>> >>>>> On Sat, Nov 29, 2025 at 8:45?PM David Alayachew < >>>>> davidalayachew at gmail.com> wrote: >>>>> >>>>>> Hello @amber-dev , >>>>>> >>>>>> I asked this on core-libs-dev already, but I figured I should ask >>>>>> here too. >>>>>> >>>>>> Let's say I have some record User(String firstName, String lastName) >>>>>> {}. >>>>>> >>>>>> Is there any possible way for me to do the following? >>>>>> >>>>>> java.lang.reflect.RecordComponent firstName = foo(User::firstName); >>>>>> >>>>>> I'll even accept this. >>>>>> >>>>>> java.lang.reflect.Method lastName = foo(User::lastName); >>>>>> >>>>>> Thank you for your time and consideration. >>>>>> David Alayachew >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From artyomcool2 at gmail.com Mon Dec 1 14:57:33 2025 From: artyomcool2 at gmail.com (Artyom Drozdov) Date: Mon, 1 Dec 2025 15:57:33 +0100 Subject: Reflection on records In-Reply-To: References:

Message-ID: Hello David, If you absolute sure that you need that, it is possible to extract method name and signature from method reference (and access via MethodHandle or Reflections later) by analyzing class file and InvokeDynamic instruction (you probably will need some time to learn how it works if you are not familiar yet). Personally, I'd prefer annotations + reflections + method handle approach (or drop the idea at all). I also think that resources like StackOverflow might suit your goal better than amber-dev mailing list) Regards, Artyom Drozdov ??, 1 ???. 2025??., 15:47 David Alayachew : > Understood. Thanks @Stephen Colebourne . > > And yes @Attila Kelemen , I agree that it > being an annotation does make it less ideal. Plus, I lose out on other > things that the compiler might one day give us, like exhaustiveness > checking. All in all, it is still the best solution, but not one I am a fan > of. > > > On Mon, Dec 1, 2025, 4:55?AM Attila Kelemen > wrote: > >> There are some other downsides as well: You will have to force your >> clients to specifically design their records to your API (i.e., annotate >> it, and configure the annotation processor). Though, in your case that is >> probably not too bad, because likely they want to design their DTO for your >> API anyway. The other downside is that you will have to write the IDE >> support as well (e.g., Idea's editor will have red curlys around without >> it). Which, aside from the additional maintenance cost, can be a problem >> for a user who is not allowed to install arbitrary IDE plugins. Also, >> compared to the original outline, you probably want an additional generic >> argument for the record type on `RecordComponentWrapper` for type safety. >> >> David Alayachew ezt ?rta (id?pont: 2025. dec. >> 1., H, 1:53): >> >>> Thanks Stephen. >>> >>> Hmmmmm, so this is definitely the best solution I have seen thus far. >>> The only real downside is that the static final field has a different name >>> than the actual record component. But I can probably fix that by making it >>> an inner class or something, as opposed to sharing the same namespace as >>> the record itself. >>> >>> Can you link me to the annotation code? >>> >>> On Sun, Nov 30, 2025 at 4:05?PM Stephen Colebourne >>> wrote: >>> >>>> There is a way to do this, but it isn't pretty. Use annotation >>>> processing. >>>> >>>> @GeneratedRecordComponentInterface >>>> record User(String firstName, String lastName, ComplexObject >>>> complexColumn) implements UserColumns {} >>>> >>>> // annotation processor generates: >>>> public interface UserColumns { >>>> public static final RecordComponentWrapper >>>> FIRST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>>> "firstName"); >>>> public static final RecordComponentWrapper >>>> LAST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>>> "lastName"); >>>> public static final RecordComponentWrapper >>>> COMPLEX_COLUMN_COMPONENT = new RecordComponentWrapper(User.class, >>>> "complexColumn"); >>>> } >>>> >>>> where `RecordComponentWrapper` is some suitable type-safe wrapper for >>>> record components. >>>> >>>> Although there is a string for each record component, it is in >>>> generated code, thus won't get out of sync. >>>> >>>> (This is the annotation processing equivalent to how Joda-Beans >>>> meta-properties have worked for many years) >>>> Stephen >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Dec 1 16:09:31 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 1 Dec 2025 11:09:31 -0500 Subject: Reflection on records In-Reply-To: References:

Message-ID: Thank you Artyom. This mailing list is actually my final stop. I already asked in multiple other places. And thanks for the suggestions about MethodHandles and InvokeDynamic. I think that might be overkill, so I'll probably just abandon the idea for now. Either way, I sent a new message on the mailing list, asking for a new feature for records. All of the suggestions I've received thus far feel like trying to fit 10 pounds of dirt in a 5 pound bag. It feels like the language/compiler could step in and provide us with better tools. On Mon, Dec 1, 2025, 9:57?AM Artyom Drozdov wrote: > Hello David, > > If you absolute sure that you need that, it is possible to extract method > name and signature from method reference (and access via MethodHandle or > Reflections later) by analyzing class file and InvokeDynamic instruction > (you probably will need some time to learn how it works if you are not > familiar yet). > > Personally, I'd prefer annotations + reflections + method handle approach > (or drop the idea at all). > > I also think that resources like StackOverflow might suit your goal better > than amber-dev mailing list) > > Regards, > Artyom Drozdov > > ??, 1 ???. 2025??., 15:47 David Alayachew : > >> Understood. Thanks @Stephen Colebourne . >> >> And yes @Attila Kelemen , I agree that it >> being an annotation does make it less ideal. Plus, I lose out on other >> things that the compiler might one day give us, like exhaustiveness >> checking. All in all, it is still the best solution, but not one I am a fan >> of. >> >> >> On Mon, Dec 1, 2025, 4:55?AM Attila Kelemen >> wrote: >> >>> There are some other downsides as well: You will have to force your >>> clients to specifically design their records to your API (i.e., annotate >>> it, and configure the annotation processor). Though, in your case that is >>> probably not too bad, because likely they want to design their DTO for your >>> API anyway. The other downside is that you will have to write the IDE >>> support as well (e.g., Idea's editor will have red curlys around without >>> it). Which, aside from the additional maintenance cost, can be a problem >>> for a user who is not allowed to install arbitrary IDE plugins. Also, >>> compared to the original outline, you probably want an additional generic >>> argument for the record type on `RecordComponentWrapper` for type safety. >>> >>> David Alayachew ezt ?rta (id?pont: 2025. >>> dec. 1., H, 1:53): >>> >>>> Thanks Stephen. >>>> >>>> Hmmmmm, so this is definitely the best solution I have seen thus far. >>>> The only real downside is that the static final field has a different name >>>> than the actual record component. But I can probably fix that by making it >>>> an inner class or something, as opposed to sharing the same namespace as >>>> the record itself. >>>> >>>> Can you link me to the annotation code? >>>> >>>> On Sun, Nov 30, 2025 at 4:05?PM Stephen Colebourne < >>>> scolebourne at joda.org> wrote: >>>> >>>>> There is a way to do this, but it isn't pretty. Use annotation >>>>> processing. >>>>> >>>>> @GeneratedRecordComponentInterface >>>>> record User(String firstName, String lastName, ComplexObject >>>>> complexColumn) implements UserColumns {} >>>>> >>>>> // annotation processor generates: >>>>> public interface UserColumns { >>>>> public static final RecordComponentWrapper >>>>> FIRST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>>>> "firstName"); >>>>> public static final RecordComponentWrapper >>>>> LAST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>>>> "lastName"); >>>>> public static final RecordComponentWrapper >>>>> COMPLEX_COLUMN_COMPONENT = new RecordComponentWrapper(User.class, >>>>> "complexColumn"); >>>>> } >>>>> >>>>> where `RecordComponentWrapper` is some suitable type-safe wrapper for >>>>> record components. >>>>> >>>>> Although there is a string for each record component, it is in >>>>> generated code, thus won't get out of sync. >>>>> >>>>> (This is the annotation processing equivalent to how Joda-Beans >>>>> meta-properties have worked for many years) >>>>> Stephen >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Mon Dec 1 16:45:54 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 1 Dec 2025 16:45:54 +0000 Subject: Reflection on records In-Reply-To: References:

Message-ID: Hi David, before we investigate solutions, what is the problem you want to resolve? If you want to obtain a Method on a record class, you can do recordClass.getMethod("variable") to find that accessor method. Note that the Java Virtual Machine does not validate a record, that it may recognize a class with the record attribute but has no corresponding accessor methods or canonical constructor as a record class. -Chen Confidential- Oracle Internal ________________________________ From: amber-dev on behalf of David Alayachew Sent: Monday, December 1, 2025 10:09 AM To: Artyom Drozdov Cc: amber-dev Subject: Re: Reflection on records Thank you Artyom. This mailing list is actually my final stop. I already asked in multiple other places. And thanks for the suggestions about MethodHandles and InvokeDynamic. I think that might be overkill, so I'll probably just abandon the idea for now. Either way, I sent a new message on the mailing list, asking for a new feature for records. All of the suggestions I've received thus far feel like trying to fit 10 pounds of dirt in a 5 pound bag. It feels like the language/compiler could step in and provide us with better tools. On Mon, Dec 1, 2025, 9:57?AM Artyom Drozdov > wrote: Hello David, If you absolute sure that you need that, it is possible to extract method name and signature from method reference (and access via MethodHandle or Reflections later) by analyzing class file and InvokeDynamic instruction (you probably will need some time to learn how it works if you are not familiar yet). Personally, I'd prefer annotations + reflections + method handle approach (or drop the idea at all). I also think that resources like StackOverflow might suit your goal better than amber-dev mailing list) Regards, Artyom Drozdov ??, 1 ???. 2025??., 15:47 David Alayachew >: Understood. Thanks @Stephen Colebourne. And yes @Attila Kelemen, I agree that it being an annotation does make it less ideal. Plus, I lose out on other things that the compiler might one day give us, like exhaustiveness checking. All in all, it is still the best solution, but not one I am a fan of. On Mon, Dec 1, 2025, 4:55?AM Attila Kelemen > wrote: There are some other downsides as well: You will have to force your clients to specifically design their records to your API (i.e., annotate it, and configure the annotation processor). Though, in your case that is probably not too bad, because likely they want to design their DTO for your API anyway. The other downside is that you will have to write the IDE support as well (e.g., Idea's editor will have red curlys around without it). Which, aside from the additional maintenance cost, can be a problem for a user who is not allowed to install arbitrary IDE plugins. Also, compared to the original outline, you probably want an additional generic argument for the record type on `RecordComponentWrapper` for type safety. David Alayachew > ezt ?rta (id?pont: 2025. dec. 1., H, 1:53): Thanks Stephen. Hmmmmm, so this is definitely the best solution I have seen thus far. The only real downside is that the static final field has a different name than the actual record component. But I can probably fix that by making it an inner class or something, as opposed to sharing the same namespace as the record itself. Can you link me to the annotation code? On Sun, Nov 30, 2025 at 4:05?PM Stephen Colebourne > wrote: There is a way to do this, but it isn't pretty. Use annotation processing. @GeneratedRecordComponentInterface record User(String firstName, String lastName, ComplexObject complexColumn) implements UserColumns {} // annotation processor generates: public interface UserColumns { public static final RecordComponentWrapper FIRST_NAME_COMPONENT = new RecordComponentWrapper(User.class, "firstName"); public static final RecordComponentWrapper LAST_NAME_COMPONENT = new RecordComponentWrapper(User.class, "lastName"); public static final RecordComponentWrapper COMPLEX_COLUMN_COMPONENT = new RecordComponentWrapper(User.class, "complexColumn"); } where `RecordComponentWrapper` is some suitable type-safe wrapper for record components. Although there is a string for each record component, it is in generated code, thus won't get out of sync. (This is the annotation processing equivalent to how Joda-Beans meta-properties have worked for many years) Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Mon Dec 1 16:53:42 2025 From: ethan at mccue.dev (Ethan McCue) Date: Mon, 1 Dec 2025 11:53:42 -0500 Subject: Reflection on records In-Reply-To: References:

Message-ID: Here is a thread from ~ a year ago which hit some similar notes https://mail.openjdk.org/pipermail/amber-dev/2024-December/009121.html On Mon, Dec 1, 2025 at 11:51?AM David Alayachew wrote: > Thank you Artyom. > > This mailing list is actually my final stop. I already asked in multiple > other places. > > And thanks for the suggestions about MethodHandles and InvokeDynamic. I > think that might be overkill, so I'll probably just abandon the idea for > now. > > Either way, I sent a new message on the mailing list, asking for a new > feature for records. All of the suggestions I've received thus far feel > like trying to fit 10 pounds of dirt in a 5 pound bag. It feels like the > language/compiler could step in and provide us with better tools. > > > On Mon, Dec 1, 2025, 9:57?AM Artyom Drozdov wrote: > >> Hello David, >> >> If you absolute sure that you need that, it is possible to extract method >> name and signature from method reference (and access via MethodHandle or >> Reflections later) by analyzing class file and InvokeDynamic instruction >> (you probably will need some time to learn how it works if you are not >> familiar yet). >> >> Personally, I'd prefer annotations + reflections + method handle approach >> (or drop the idea at all). >> >> I also think that resources like StackOverflow might suit your goal >> better than amber-dev mailing list) >> >> Regards, >> Artyom Drozdov >> >> ??, 1 ???. 2025??., 15:47 David Alayachew : >> >>> Understood. Thanks @Stephen Colebourne . >>> >>> And yes @Attila Kelemen , I agree that it >>> being an annotation does make it less ideal. Plus, I lose out on other >>> things that the compiler might one day give us, like exhaustiveness >>> checking. All in all, it is still the best solution, but not one I am a fan >>> of. >>> >>> >>> On Mon, Dec 1, 2025, 4:55?AM Attila Kelemen >>> wrote: >>> >>>> There are some other downsides as well: You will have to force your >>>> clients to specifically design their records to your API (i.e., annotate >>>> it, and configure the annotation processor). Though, in your case that is >>>> probably not too bad, because likely they want to design their DTO for your >>>> API anyway. The other downside is that you will have to write the IDE >>>> support as well (e.g., Idea's editor will have red curlys around without >>>> it). Which, aside from the additional maintenance cost, can be a problem >>>> for a user who is not allowed to install arbitrary IDE plugins. Also, >>>> compared to the original outline, you probably want an additional generic >>>> argument for the record type on `RecordComponentWrapper` for type safety. >>>> >>>> David Alayachew ezt ?rta (id?pont: 2025. >>>> dec. 1., H, 1:53): >>>> >>>>> Thanks Stephen. >>>>> >>>>> Hmmmmm, so this is definitely the best solution I have seen thus far. >>>>> The only real downside is that the static final field has a different name >>>>> than the actual record component. But I can probably fix that by making it >>>>> an inner class or something, as opposed to sharing the same namespace as >>>>> the record itself. >>>>> >>>>> Can you link me to the annotation code? >>>>> >>>>> On Sun, Nov 30, 2025 at 4:05?PM Stephen Colebourne < >>>>> scolebourne at joda.org> wrote: >>>>> >>>>>> There is a way to do this, but it isn't pretty. Use annotation >>>>>> processing. >>>>>> >>>>>> @GeneratedRecordComponentInterface >>>>>> record User(String firstName, String lastName, ComplexObject >>>>>> complexColumn) implements UserColumns {} >>>>>> >>>>>> // annotation processor generates: >>>>>> public interface UserColumns { >>>>>> public static final RecordComponentWrapper >>>>>> FIRST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>>>>> "firstName"); >>>>>> public static final RecordComponentWrapper >>>>>> LAST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>>>>> "lastName"); >>>>>> public static final RecordComponentWrapper >>>>>> COMPLEX_COLUMN_COMPONENT = new RecordComponentWrapper(User.class, >>>>>> "complexColumn"); >>>>>> } >>>>>> >>>>>> where `RecordComponentWrapper` is some suitable type-safe wrapper for >>>>>> record components. >>>>>> >>>>>> Although there is a string for each record component, it is in >>>>>> generated code, thus won't get out of sync. >>>>>> >>>>>> (This is the annotation processing equivalent to how Joda-Beans >>>>>> meta-properties have worked for many years) >>>>>> Stephen >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Mon Dec 1 17:13:48 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 1 Dec 2025 11:13:48 -0600 Subject: Reflection on records In-Reply-To: References:

Message-ID: I'm guessing what underlies David's question is this thought: Why can't the compiler provide more compile-time checking of Field and Method reflection objects? After all, it does this for Class objects by providing us with Class literals (remember in the old days you could only obtain them via Class.forName()). I have wondered the same thing, though I also appreciate that the devil is in the details. For example, David's question could be addressed by adding Method and Field literals: public class Foo { public static void meth(int x) { ... } } Method m = Foo::meth.method; m.invoke(123); Of course, this is still imprecise because Method is not generic and so this would fail if there were overloads, among other problems. So I think the intuition is valid. Whether a practical solution exists is another question. -Archie On Mon, Dec 1, 2025 at 10:46?AM Chen Liang wrote: > Hi David, before we investigate solutions, what is the problem you want to > resolve? > If you want to obtain a Method on a record class, you can do > recordClass.getMethod("variable") to find that accessor method. > Note that the Java Virtual Machine does not validate a record, that it may > recognize a class with the record attribute but has no corresponding > accessor methods or canonical constructor as a record class. > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Mon Dec 1 18:10:10 2025 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Mon, 1 Dec 2025 19:10:10 +0100 Subject: Feature Request -- Enumerate the RecordComponents of a record In-Reply-To: References: Message-ID: Hi, My concern with the actual proposal (not with the problem it is trying to solve) is that it doesn't generalize well. That is, imagine if function types get added to the language with support to query the parameters, etc. of the underlying function. Then immediately this change becomes a useless (in fact, harmful) noise. So, let me give a counter proposal (even though I'm quite certain it will not be added anytime soon given all the important stuff in the queue): Allow the following construct: ``` RecordComponentAccessor accessor = MyRecord::myComponent; ``` where the `RecordComponentAccessor` could look like it (of course, doesn't have to be an interface): ``` interface RecordComponentAccessor { Type recordType(); Class recordRawType(); String componentName(); Type componentType(); Class componentRawType(); MethodHandle getter(); default V getValue(R record) { // TODO: Deal with `throws Throwable` return getter().invoke(record); } } ``` The benefit of this is that, if function types ever become a thing, then of course this can be retrofitted to implement (or extend) the function type `(R) -> V` (or whatever notation it would have), which would likely have more generic methods like `List> parameterRawTypes()`, etc. In my opinion, this is not harder to implement than the original proposal, and more future proof. And if it is only implemented for records, then no massive changes to the JVM needed (unlike with the introduction of a full blown function type). Attila David Alayachew ezt ?rta (id?pont: 2025. nov. 30., V, 22:51): > Hello @amber-dev , > > (this is a follow-up from the previous thread -- > https://mail.openjdk.org/pipermail/amber-dev/2025-November/009472.html) > > Since records are *transparent* carriers of data, then that means that > all of the record components are known at compile time and visible to all > consumers who can reach the record itself. > > Right now, the only way to reach these record components is by drilling > down via j.l.Class ---> j.l.r.RecordComponent. And even then, you are > forced into doing String comparison against what you *expect* the record > component to be named. That means that you will get a runtime error, not a > compile time error, if a record component changes names. > > I propose that we enumerate the Record Components of a record. > > My naive way of accomplishing this would be to literally provide each > record with its own inner enum, each value corresponding to the respective > record component on a record. > > Consider the following record. > > record User(String firstName, String lastName, int age) {} > > I ask that record get access to its own inner enum (let's call it VALUES), > that can be referenced. Like this. > > record User(String firstName, String lastName, int age) > { > enum Values { > firstName, > lastName, > age, > ; > public final java.lang.reflect.RecordComponent recordComponent = > Arrays > .stream(User.class.getRecordComponents()) > .filter(rc -> rc.getName().equals(this.name())) > .findAny() > .orElseThrow() > ; > } > } > > This is better than the current situation for all sorts of reasons. > > 1. Currently, if I want a RecordComponent, I must make a > String-comparison. I lose compile time safety of checking if my hard-coded > string no longer matches because someone changed the record. > 2. I now get exhaustiveness checking, which really should have been > there from the beginning. > > And of course, I am not tied to the idea of using an enum or an inner > class. My real goal is to be able to enumerate over the components of a > record. Not even necessarily over the j.l.r.RecordComponents of a record. > Whatever form that takes is fine with me. > > But not being able to enumerate over a records components (obviously, in a > type-safe, non-*stringly*-typed way) is making records less powerful for > seemingly no reason. The contract and spec enables it, it's just not being > utilized. > > Thank you for your time and consideration. > David Alayachew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Dec 1 18:37:56 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 1 Dec 2025 18:37:56 +0000 Subject: Reflection on records In-Reply-To: References:

Message-ID: Let me replay some analysis that was done on this topic in the past. There are two separate things going on here: - Can we use symbolic constants instead of string constants to do reflective lookups - Can we have more kinds of symbolic reflective constants (field literals, method literals, record component literals, method handle literals, etc.) The first one is more shallow; David is exploiting a special case of records where (a) there is already a method reference form for accessors, which could potentially be bootstrapped into service here and (b) very luckily, the shape of all such accessor method references vary only parametrically in shape. So one could write a method: interface AccessorShape { U access(T t); } RecordComponent component(Accessor c) { ? } Which would allow us to say RecordComponent rc = component(Foo::component) Where the parameter is a method reference but from which we can strip-mine the name and type and turn it into a component lookup. That?s a clever trick, and there is no intrinsic reason why we couldn?t do this, but it doesn?t scale beyond this particular case. Field and method lookups would still use strings and could fail at runtime for all the reasons. The second is one that was explored fairly deeply during Lambda. Reflective literals for jlr.{Field,Method,Constructor} are an obvious move, and have a few challenges, some of which are workable, but the biggest of which is: overloading. With method reference targeted at functional interfaces, the functional interface provides a signature shape with which we can do overload selection. But if we had an overloaded method m, then Method m = Foo::m We have no information with which to select the proper m. (Please, don?t take this as an invitation for a syntax discussion; they?ve all been explored, and besides, there are deeper problems here than syntax.) On Dec 1, 2025, at 12:13 PM, Archie Cobbs > wrote: I'm guessing what underlies David's question is this thought: Why can't the compiler provide more compile-time checking of Field and Method reflection objects? After all, it does this for Class objects by providing us with Class literals (remember in the old days you could only obtain them via Class.forName()). I have wondered the same thing, though I also appreciate that the devil is in the details. For example, David's question could be addressed by adding Method and Field literals: public class Foo { public static void meth(int x) { ... } } Method m = Foo::meth.method; m.invoke(123); Of course, this is still imprecise because Method is not generic and so this would fail if there were overloads, among other problems. So I think the intuition is valid. Whether a practical solution exists is another question. -Archie On Mon, Dec 1, 2025 at 10:46?AM Chen Liang > wrote: Hi David, before we investigate solutions, what is the problem you want to resolve? If you want to obtain a Method on a record class, you can do recordClass.getMethod("variable") to find that accessor method. Note that the Java Virtual Machine does not validate a record, that it may recognize a class with the record attribute but has no corresponding accessor methods or canonical constructor as a record class. -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From artyomcool2 at gmail.com Mon Dec 1 18:59:02 2025 From: artyomcool2 at gmail.com (Artyom Drozdov) Date: Mon, 1 Dec 2025 19:59:02 +0100 Subject: Reflection on records In-Reply-To: References:

Message-ID: Symbolic reflective constants is a something I was always dreamed about. I'm currently using old-but-gold CLDC HI for my pet project and I'm really struggling without class literals (so I'll probably add them). The same way I feel about fields/methods references. I suppose it was discussed before, but it would be great to know, why can't we ask user for the full signature? Like: Method m = Foo::method[String, int]; Or even (argument names here is an optional hint for the reader and IDE/linters): Method m = Foo::method[String name, int size]; Of course, the syntax is not something that really worth to discuss here. Probably, we might want to specify the return type as well, but, again, that's about syntax. ??, 1 ???. 2025??., 19:38 Brian Goetz : > Let me replay some analysis that was done on this topic in the past. > > There are two separate things going on here: > > - Can we use symbolic constants instead of string constants to do > reflective lookups > - Can we have more kinds of symbolic reflective constants (field > literals, method literals, record component literals, method handle > literals, etc.) > > The first one is more shallow; David is exploiting a special case of > records where (a) there is already a method reference form for accessors, > which could potentially be bootstrapped into service here and (b) very > luckily, the shape of all such accessor method references vary only > parametrically in shape. So one could write a method: > > interface AccessorShape { > U access(T t); > } > > RecordComponent component(Accessor c) { ? } > > Which would allow us to say > > RecordComponent rc = component(Foo::component) > > Where the parameter is a method reference but from which we can strip-mine > the name and type and turn it into a component lookup. That?s a clever > trick, and there is no intrinsic reason why we couldn?t do this, but it > doesn?t scale beyond this particular case. Field and method lookups would > still use strings and could fail at runtime for all the reasons. > > The second is one that was explored fairly deeply during Lambda. > Reflective literals for jlr.{Field,Method,Constructor} are an obvious move, > and have a few challenges, some of which are workable, but the biggest of > which is: overloading. With method reference targeted at functional > interfaces, the functional interface provides a signature shape with which > we can do overload selection. But if we had an overloaded method m, then > > Method m = Foo::m > > We have no information with which to select the proper m. (Please, don?t > take this as an invitation for a syntax discussion; they?ve all been > explored, and besides, there are deeper problems here than syntax.) > > > On Dec 1, 2025, at 12:13 PM, Archie Cobbs wrote: > > I'm guessing what underlies David's question is this thought: Why can't > the compiler provide more compile-time checking of Field and > Method reflection objects? > > After all, it does this for Class objects by providing us with Class > literals (remember in the old days you could only obtain them via > Class.forName()). > > I have wondered the same thing, though I also appreciate that the devil is > in the details. > > For example, David's question could be addressed by adding Method and > Field literals: > > public class Foo { > public static void meth(int x) { ... } > } > > Method m = Foo::meth.method; > m.invoke(123); > > Of course, this is still imprecise because Method is not generic and so > this would fail if there were overloads, among other problems. > > So I think the intuition is valid. Whether a practical solution exists is > another question. > > -Archie > > On Mon, Dec 1, 2025 at 10:46?AM Chen Liang > wrote: > >> Hi David, before we investigate solutions, what is the problem you want >> to resolve? >> If you want to obtain a Method on a record class, you can do >> recordClass.getMethod("variable") to find that accessor method. >> Note that the Java Virtual Machine does not validate a record, that it >> may recognize a class with the record attribute but has no corresponding >> accessor methods or canonical constructor as a record class. >> > -- > Archie L. Cobbs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Dec 1 19:00:31 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 1 Dec 2025 20:00:31 +0100 (CET) Subject: Reflection on records In-Reply-To: References:

Message-ID: <50578952.52395295.1764615631422.JavaMail.zimbra@univ-eiffel.fr> > From: "Brian Goetz" > To: "Archie Cobbs" > Cc: "Chen Liang" , "David Alayachew" > , "amber-dev" > Sent: Monday, December 1, 2025 7:37:56 PM > Subject: Re: Reflection on records > Let me replay some analysis that was done on this topic in the past. > There are two separate things going on here: > - Can we use symbolic constants instead of string constants to do reflective > lookups > - Can we have more kinds of symbolic reflective constants (field literals, > method literals, record component literals, method handle literals, etc.) > The first one is more shallow; David is exploiting a special case of records > where (a) there is already a method reference form for accessors, which could > potentially be bootstrapped into service here and (b) very luckily, the shape > of all such accessor method references vary only parametrically in shape. So > one could write a method: > interface AccessorShape { > U access(T t); > } > RecordComponent component(Accessor c) { ? } > Which would allow us to say > RecordComponent rc = component(Foo::component) > Where the parameter is a method reference but from which we can strip-mine the > name and type and turn it into a component lookup. That?s a clever trick, and > there is no intrinsic reason why we couldn?t do this, but it doesn?t scale > beyond this particular case. Field and method lookups would still use strings > and could fail at runtime for all the reasons. > The second is one that was explored fairly deeply during Lambda. Reflective > literals for jlr.{Field,Method,Constructor} are an obvious move, and have a few > challenges, some of which are workable, but the biggest of which is: > overloading. With method reference targeted at functional interfaces, the > functional interface provides a signature shape with which we can do overload > selection. But if we had an overloaded method m, then > Method m = Foo::m > We have no information with which to select the proper m. (Please, don?t take > this as an invitation for a syntax discussion; they?ve all been explored, and > besides, there are deeper problems here than syntax.) yes, the current status quo is that IDEs (at least IntelliJ) are able to typecheck the creation of Method, Field, MethodHandle, VarHandle, etc so it's not in the language but it's good enough. We still have to make all those pesky exceptions unchecked but that's another story ... R?mi >> On Dec 1, 2025, at 12:13 PM, Archie Cobbs < [ mailto:archie.cobbs at gmail.com | >> archie.cobbs at gmail.com ] > wrote: >> I'm guessing what underlies David's question is this thought: Why can't the >> compiler provide more compile-time checking of Field and Method reflection >> objects? >> After all, it does this for Class objects by providing us with Class literals >> (remember in the old days you could only obtain them via Class.forName() ). >> I have wondered the same thing, though I also appreciate that the devil is in >> the details. >> For example, David's question could be addressed by adding Method and Field >> literals: >> public class Foo { >> public static void meth(int x) { ... } >> } >> Method m = Foo::meth.method; >> m.invoke(123); >> Of course, this is still imprecise because Method is not generic and so this >> would fail if there were overloads, among other problems. >> So I think the intuition is valid. Whether a practical solution exists is >> another question. >> -Archie >> On Mon, Dec 1, 2025 at 10:46 AM Chen Liang < [ mailto:chen.l.liang at oracle.com | >> chen.l.liang at oracle.com ] > wrote: >>> Hi David, before we investigate solutions, what is the problem you want to >>> resolve? >>> If you want to obtain a Method on a record class, you can do >>> recordClass.getMethod("variable") to find that accessor method. >>> Note that the Java Virtual Machine does not validate a record, that it may >>> recognize a class with the record attribute but has no corresponding accessor >>> methods or canonical constructor as a record class. >> -- >> Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Mon Dec 1 19:17:54 2025 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 1 Dec 2025 20:17:54 +0100 Subject: Reflection on records In-Reply-To: <50578952.52395295.1764615631422.JavaMail.zimbra@univ-eiffel.fr> References:

<50578952.52395295.1764615631422.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hello! On Mon, Dec 1, 2025, 20:01 Remi Forax wrote: > the current status quo is that IDEs (at least IntelliJ) are able to > typecheck the creation of Method, Field, MethodHandle, VarHandle, etc so > it's not in the language but it's good enough. > Yes, thank you, Remi! David said that he wants to avoid stringly-typed code, but what is string is solely a question of a tool you use to interpret your program. For an old-school text editor, the whole Java program is simply a string. For example, a typo in a called method name will be unnoticed by such a tool in the same way, as a typo inside a string literal. The Java compiler understands proper Java identifiers but doesn't understand Java strings. A good IDE goes further: it treats certain strings as full-fledged references. When you type MyRecord.class.getField("myComponent"), you get code completion, inspection highlighting of incorrect reference (distinct from compilation error and suppressable, of course), find usage, navigation to the declaration (you can jump from "myComponent" string to an actual component and back). You can even initiate a 'Rename' refactoring inside the string, and the component will be renamed! From the tool point of view, these strings are first-class citizens. So it's not always necessary to change your code to avoid being stringly-typed. Instead, use proper tools or convince your tool vendor to add first-class reflective references support. With best regards, Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Mon Dec 1 19:21:23 2025 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Mon, 1 Dec 2025 20:21:23 +0100 Subject: Reflection on records In-Reply-To: References:

Message-ID: One thing I can think of is that generics makes life a hell here, and can spawn a lot of reasonable questions with non-obvious answers (especially if you still believe in reified generics in the future, and try to prepare for it). So, if you have ``` interface Foo { String hello(T a); } ``` Then if you write (in your notation): `Foo::hello[T]`, where T is a type argument, then you have to return `Object.class` as the parameter type. However, if you have `Foo::hello[String]`, then one could reasonably expect it to return `String.class` as the parameter type, but doing so would also be strange, because the actual type (queried via reflection) would be `Object.class`. Not to mention that `hello` can be overloaded with a concrete type, but I guess that is a theoretical problem even in today's Java. Attila Artyom Drozdov ezt ?rta (id?pont: 2025. dec. 1., H, 19:59): > Symbolic reflective constants is a something I was always dreamed about. > I'm currently using old-but-gold CLDC HI for my pet project and I'm really > struggling without class literals (so I'll probably add them). > The same way I feel about fields/methods references. I suppose it was > discussed before, but it would be great to know, why can't we ask user for > the full signature? Like: > > Method m = Foo::method[String, int]; > > Or even (argument names here is an optional hint for the reader and > IDE/linters): > > Method m = Foo::method[String name, int size]; > > Of course, the syntax is not something that really worth to discuss here. > Probably, we might want to specify the return type as well, but, again, > that's about syntax. > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From artyomcool2 at gmail.com Mon Dec 1 19:35:05 2025 From: artyomcool2 at gmail.com (Artyom Drozdov) Date: Mon, 1 Dec 2025 20:35:05 +0100 Subject: Reflection on records In-Reply-To: References: