[External] : Re: Method and Field Literals

Ethan McCue ethan at mccue.dev
Sat Apr 23 23:17:36 UTC 2022


Before moving on with the discussion, can you also address Brain Goetz's
questions directly?

1. what do you expect the _type_ of a method literal is?

2. Is it a goal to have
    a. earlier error checking that you specified a method that exists
    b. syntactic sugar for the reflective call
    c. the lookup can be more efficient

And then from me

3. What in your first example disqualifies a normal method reference lambda
(Class::method) from being appropriate?
4. This pattern of

    var thing = Lookup.find("externalUncheckedName", TypeA.class,
TypeB.class)
    var result = (TypeB) thing.invoke(new TypeA()); // Object... as arg
type and throws some exceptions

is also used in the API for Panama. If we are going to add new goo, is
there a way to address this sort of API as well?

On Sat, Apr 23, 2022 at 1:56 PM arjan tijms <arjan.tijms at gmail.com> wrote:

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


More information about the discuss mailing list