<div dir="auto">Oh wow, thank you all for the responses!<div dir="auto"><br></div><div dir="auto"><span dir="auto"><a href="mailto:chen.l.liang@oracle.com" style="color:rgb(17,85,204)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">@Chen Liang</a></span> - Thanks for asking this. I am asking an X-Y problem. Let me quickly summarize both the X and Y.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><div dir="auto"><br></div><div dir="auto"><span dir="auto"><a href="mailto:ethan@mccue.dev" style="color:rgb(17,85,204)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">@Ethan McCue</a></span> - ty vm for the link, I remember reading that, but forgot it while typing this one. Nice complement to this thread.</div><div dir="auto"><br></div><div dir="auto"><span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:archie.cobbs@gmail.com" style="color:#15c;text-decoration:underline" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">@Archie Cobbs</a></span><span> and <span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:brian.goetz@oracle.com" style="color:#15c;text-decoration:underline" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">@Brian Goetz</a></span><span> - 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.</span></span></div><div dir="auto"><span><span><br></span></span></div><div dir="auto"><span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:forax@univ-mlv.fr" style="color:#15c;text-decoration:underline" rel="noreferrer noreferrer" target="_blank">@Remi Forax</a></span><span> and </span><span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:amaembo@gmail.com" style="color:#15c;text-decoration:underline" rel="noreferrer noreferrer noreferrer" target="_blank">@Tagir Valeev</a></span><span> - 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?</span></div><div dir="auto"><span><br></span></div><div dir="auto"><span>Thanks for the responses everyone!</span></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 1, 2025, 2:53 PM Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">attila.kelemen85@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Artyom Drozdov <<a href="mailto:artyomcool2@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">artyomcool2@gmail.com</a>> ezt írta (időpont: 2025. dec. 1., H, 20:35):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Yes, it sounds like an issue without good solution.</div><div dir="auto">For me sounds ok for your example having just raw types:</div><div dir="auto"><br></div><div dir="auto">Method hello = Foo::hello[Object];</div><div dir="auto"><br></div><div dir="auto">But I understand it could be non-intuitive for most users. Another approach would be to allow your notation:</div><div dir="auto"><br></div><div dir="auto">Method hello = Foo<T>::hello[T];</div><div dir="auto"><br></div><div dir="auto">But disallow specifying types like:</div><div dir="auto"><br></div><div dir="auto">Method helloString = Foo<String>::hello[String];</div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">пн, 1 дек. 2025 г., 20:21 Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">attila.kelemen85@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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).</div><div><br></div><div>So, if you have</div><div><br></div><div>```</div><div>interface Foo<T> { String hello(T a); }</div><div>```</div><div><br></div><div>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.</div><div><br></div><div>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`.</div><div><br></div><div>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.</div><div><br></div><div>Attila</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Artyom Drozdov <<a href="mailto:artyomcool2@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">artyomcool2@gmail.com</a>> ezt írta (időpont: 2025. dec. 1., H, 19:59):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Symbolic reflective constants is a something I was always dreamed about.</div><div dir="auto">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).</div><div dir="auto">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:</div><div dir="auto"><br></div><div dir="auto">Method m = Foo::method[String, int];</div><div dir="auto"><br></div><div dir="auto">Or even (argument names here is an optional hint for the reader and IDE/linters):</div><div dir="auto"><br></div><div dir="auto">Method m = Foo::method[String name, int size];</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br>
</div>
</div>

</blockquote></div></div></div>
</blockquote></div></div>
</blockquote></div></div></div>
</blockquote></div></div>
</blockquote></div>