[External] : Re: Method and Field Literals

[arjan tijms]

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?
>>
>>
>>
>>
>>