Oh wow, thank you all for the responses! @Chen Liang <[email protected]> - 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 <[email protected]> - ty vm for the link, I remember reading that, but forgot it while typing this one. Nice complement to this thread. @Archie Cobbs <[email protected]> and @Brian Goetz <[email protected]> - 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 <[email protected]> and @Tagir Valeev <[email protected]> - 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: >> >>> 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 <[email protected]> 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. >>>> >>>>> >>>>>
