[External] : Re: Method and Field Literals

[Ethan McCue]

I think we should clearly define what you mean by type safety in this
context.

For the last example, even if the compiler were to statically infer that
the method does exist and that the parameter types are correct

public final static Method validateRequestMethod = getMethod(
        HttpAuthenticationMechanism.class,
        MAGIC[validateRequest],
        HttpServletRequest.class, HttpServletResponse.class,
        Integer.class); // This is wrong, compiler will tell you

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.

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