Reflection on records

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Archie Cobbs" <archie.cobbs at gmail.com>
> Cc: "Chen Liang" <chen.l.liang at oracle.com>, "David Alayachew"
> <davidalayachew at gmail.com>, "amber-dev" <amber-dev at openjdk.org>
> 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<T, U> {
> U access(T t);
> }

> <R extends Record, U> RecordComponent component(Accessor<R, U> 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: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251201/e9d0ebe1/attachment-0001.htm>