Reflection on records

[David Alayachew]

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 <artyomcool2 at gmail.com> 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 <davidalayachew at gmail.com>:
>
>> Understood. Thanks @Stephen Colebourne <scolebourne at joda.org>.
>>
>> And yes @Attila Kelemen <attila.kelemen85 at gmail.com>, 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 <attila.kelemen85 at gmail.com>
>> 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 <davidalayachew at gmail.com> 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<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
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251201/71e04d9a/attachment.htm>