[External] : Re: Method and Field Literals

[arjan tijms]

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