[External] : Re: Method and Field Literals

[arjan tijms]

Hi,

On Sat, Apr 23, 2022 at 6:11 PM Ethan McCue <ethan at mccue.dev> wrote:

> I think we should clearly define what you mean by type safety in this
> context.
>
> In usage, invoke will still take an arbitrary array of objects and throw
> some gnarly exceptions. So the "type safety" is clearly limited.
>
> Even so, it sounds like "earlier error checking that you specified a
> method that exists" is what you want.
>

And, of course, the ability to refactor using tools. If I'd rename the
"validateRequest" method to say "validate" the rename would also rename the
literal. It's not so different as with "HttpAuthenticationMechanism.class",
which we use throughout reflective code. If that syntax wouldn't have
value, we would have used Class.forName("HttpAuthenticationMechanism")
everywhere, but we don't.

Kind regards,
Arjan



>
> On Sat, Apr 23, 2022 at 11:07 AM arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>> Hi,
>>
>> Found one more example, in Jakarta Security/Soteria:
>>
>> public final static Method validateRequestMethod = getMethod(
>>         HttpAuthenticationMechanism.class,
>>         "validateRequest",
>>         HttpServletRequest.class, HttpServletResponse.class,
>> HttpMessageContext.class);
>>
>> The class and parameters are typesafe, but the method name is not. Would
>> also be useful if that could be made typesafe.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>> On Thu, Apr 21, 2022 at 1:17 AM arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > One of the main use cases is for referring to methods in a typesafe way.
>> >
>> > E.g. in Jakarta Persistence (previously JPA), one now has to either use
>> a
>> > string to reference a method, or generate a meta model that effectively
>> > fakes method reference (technically JavaBean property references):
>> >
>> > Root<Student> root = criteriaQuery.from(Student.class);
>> > criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear),
>> > 2015));
>> >
>> > This is not ideal. Generating the meta model is such a hassle that it's
>> > often not done. Much nicer would be a method literal syntax of some
>> kind,
>> > so we can do:
>> >
>> > Root<Student> root = criteriaQuery.from(Student.class);
>> >
>> criteriaQuery.select(root).where(cb.equal(root.get(Student#gradYear.method
>> > ), 2015));
>> >
>> > Another example that came up lately is in method handlers, for instance
>> > here one for a dynamic proxy implementing multiple interfaces:
>> >
>> > public static class LambdaHandler implements InvocationHandler {
>> >
>> >         private ELContext elContext;
>> >         private LambdaExpression lambdaExpression;
>> >
>> >         @Override
>> >         public Object invoke(Object proxy, Method method, Object[] args)
>> > throws Throwable {
>> >            if (method.getDeclaringClass().equals(BiConsumer.class) &&
>> >                method.getName().equals("accept") {
>> >
>> >            }
>> >         }
>> >
>> > The declaring class can be checked for in a type-safe way, but for the
>> > method a String needs to be used.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> > On Wed, Apr 20, 2022 at 6:30 PM Brian Goetz <brian.goetz at oracle.com>
>> > wrote:
>> >
>> >>
>> >> > It's again a couple of years later, is there already any desire to
>> >> > pursue the method and field literals topic?
>> >>
>> >> The term "method and field literals" is somewhat overloaded, so let's
>> be
>> >> more specific: what do you expect the _type_ of a method literal is?
>> Is
>> >> it just jlr.Method?  Or is MethodHandle / VarHandle also part of the
>> >> story?   Is the goal simply to get earlier error checking that you
>> >> specified a method that exists (errors at compile time vs run time)? Or
>> >> to just have syntactic sugar for the reflective call?  Or somehow an
>> >> expectation that the lookup can be more efficient, such as LDC
>> >> MethodHandle + MH.unreflect?
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>