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. пн, 1 дек. 2025 г., 19:38 Brian Goetz <[email protected]>: > 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.) > > > On Dec 1, 2025, at 12:13 PM, Archie Cobbs <[email protected]> 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 <[email protected]> > 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 > > >
