Reflection on records

[David Alayachew]

Oh wow, thank you all for the responses!

@Chen Liang <chen.l.liang at oracle.com> - Thanks for asking this. I am asking
an X-Y problem. Let me quickly summarize both the X and Y.

For the X, I want a j.l.r.RecordComponent, but I don't want to ask my
clients to pass around String literals or do String comparison that could
get out-of-sync on later compilations. Method references looked like the
way to get there.

For the Y, what I really want is some way to reference a records
components, and be informed at compile time when my use of them is
out-of-date/sync.

@Ethan McCue <ethan at mccue.dev> - ty vm for the link, I remember reading
that, but forgot it while typing this one. Nice complement to this thread.

@Archie Cobbs <archie.cobbs at gmail.com> and @Brian Goetz
<brian.goetz at oracle.com> - Thanks for highlighting the gist of my question.
I do see the pain point of method overloads, so I understand if that is the
nail in the coffin here for my idea.

@Remi Forax <forax at univ-mlv.fr> and @Tagir Valeev <amaembo at gmail.com> -
Thanks for the IDE perspective. But I'm curious -- if I update my record by
changing one of its components type or name, would all of those string
references to that component become red squiggles? And what about if there
is a layer of indirection, like passing the string through a helper method?
Or multiple layers of methods?

Thanks for the responses everyone!

On Mon, Dec 1, 2025, 2:53 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> Also, by the way, these method literals have limited usefulness, if you
> just declare them `Method` or `MethodHandle`, because sure the compiler can
> check the method name, but it won't be able to check for the number of
> parameters and their type, and so sure, a little better, but not that much.
> If method literals (etc) would be a thing, then I would expect arbitrary
> function types with them as well (which could have a common base of
> course). Like `function<long(String, int)>`, and in this case, accepting
> the raw type becomes a lot more problematic, because returning
> `Object.class` when a declaration clearly states `String` is a bit
> troubling (for me it is for sure).
>
> Artyom Drozdov <artyomcool2 at gmail.com> ezt írta (időpont: 2025. dec. 1.,
> H, 20:35):
>
>> Yes, it sounds like an issue without good solution.
>> For me sounds ok for your example having just raw types:
>>
>> Method hello = Foo::hello[Object];
>>
>> But I understand it could be non-intuitive for most users. Another
>> approach would be to allow your notation:
>>
>> Method hello = Foo<T>::hello[T];
>>
>> But disallow specifying types like:
>>
>> Method helloString = Foo<String>::hello[String];
>>
>>
>> пн, 1 дек. 2025 г., 20:21 Attila Kelemen <attila.kelemen85 at gmail.com>:
>>
>>> 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<T> { String hello(T a); }
>>> ```
>>>
>>> Then if you write (in your notation): `Foo<T>::hello[T]`, where T is a
>>> type argument, then you have to return `Object.class` as the parameter type.
>>>
>>> However, if you have `Foo<String>::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 <artyomcool2 at gmail.com> 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: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251201/672594d4/attachment-0001.htm>