Method and Field Literals

[Remi Forax]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "arjan tijms" <arjan.tijms at gmail.com>, "discuss" <discuss at openjdk.java.net>
> Envoyé: Mardi 19 Juin 2018 20:15:27
> Objet: Re: Method and Field Literals

> There are a number of concepts being conflated here.
> 
> Java already has _method references_, which are a way to describe the
> operational, but not the nominal, behavior of a method.  (You can
> convert the method reference String::isEmpty to a Predicate<String>, but
> you can't (easily) recover the provenance that it comes from
> String::empty.)

The non easy way is to make the method reference Serializable, serialize it and extract the Serialization proxy which contains the class, the method etc.
Tagir has recently posted a code that does that:  
https://gist.github.com/amaembo/cbe9e1a8f3f8d240beb080343670f0c2

> 
> Java does not yet have _field references_, but extending the notion of
> method references to fields is likely to be fairly tractable.
> 
> But, you asked for method and field _literals_.  I think what you want
> here is a symbolic reference to a method or field, which allows you to
> get at the nominal description, but not necessarily (directly) the
> operational behavior.
> 
> Finally, you didn't ask for this, but you probably meant to: you'd like
> to be able to use method and field literals as arguments to annotations,
> as you can currently do with class literals.
> 
> 
> There are a number of dimensions in which we might extend the current
> notion of method references:
>  - Other conversion targets (jlr.Method, jli.MethodHandle) in addition
> to functional interfaces;
>  - control over overload selection, so that you could say (for example)
> Foo::bar(int, int) rather than saying Foo::bar and relying on overload
> selection via target typing (needed if your target type doesn't provide
> enough information to do overload selection for you, such as such as
> jlr.Method);
>  - extending to fields, either with functional interface target types,
> or others, as above;
>  - exposing nominal information in addition to operational
> capabilities, so that callers can reconstruct the nominal information
> from which the references was constructed;
>  - supporting the above sorts of references as annotation parameters.
> 
> 
> You probably want some or all of these; others may want a different
> subset.  The current status is that, while we've spent a fair amount of
> time analyzing the bounds of the various problems, they're not features
> we've prioritized to deliver right now, because there are other features
> that we feel offer better return-on-effort.  But, that could change.
> 

BTW, if we want to support MethodHandle (or j.l.r.Method) at some point, we should re-use the same idea we use for the Serialization, use a non-conventional cast:
  MethodHandle mh = (MethodHandle & Predicate<String>)String::isEmpty;

with Predicate<String> used only to provide the necessary type information, this has the advantage of not requiring to change the grammar thus lowering the cost to introduce such feature.

cheers,
Rémi


> 
> On 11/22/2014 10:51 AM, arjan tijms wrote:
>>> FWIW, method/field literals would be very useful for POJO-centric libraries
>> such as JPA/Hibernate, Bean Validation etc.
>>
>> Absolutely, in fact JPA is now simulating Field Literals by means of
>> generating a so-called Metamodel for every entity class. See
>> https://docs.oracle.com/javaee/6/tutorial/doc/gjiup.html#gjivl
>>
>> In short, given a class:
>>
>> public class Foo {
>>      public String bar;
>> }
>>
>> JPA generates a class Foo_:
>>
>> @Static @Metamodel(Foo.class)
>> public class Foo_ {
>>      public static volatile SingularAttribute<Foo, String> bar;
>> }
>>
>> Everywhere a Field Literal would be actually needed, we then use
>> Foo_.bar, half telling ourselves that there's the imaginary operator
>> "_.".
>>
>> While this works, it's a nasty workaround and for some reason it's
>> always an issue to generate that Metamodel. Real Field Literals would
>> make this so much easier.
>>
>> Kind regards,
> > Arjan Tijms