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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: >> >>> Understood. Thanks @Stephen Colebourne <[email protected]>. >>> >>> And yes @Attila Kelemen <[email protected]>, 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 <[email protected]> >>> 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 <[email protected]> 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 < >>>>> [email protected]> 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<String> >>>>>> FIRST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>>>>> "firstName"); >>>>>> public static final RecordComponentWrapper<String> >>>>>> LAST_NAME_COMPONENT = new RecordComponentWrapper(User.class, >>>>>> "lastName"); >>>>>> public static final RecordComponentWrapper<ComplexObject> >>>>>> 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 >>>>>> >>>>>>
