Method and Field Literals

[Brian Goetz]

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.)

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.


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