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