Method and Field Literals

Gunnar Morling gunnar at
Tue Nov 11 12:55:22 UTC 2014


2014-11-11 13:03 GMT+01:00 Mario Torre <neugens at>:

> On Tue, 2014-11-11 at 12:28 +0100, Brian Goetz wrote:
> > Method and field literals came up during lambda.  (As did method
> > handle literals ). The upshot was that while we did not dislike them,
> > they were sufficiently distant from the lambda mission that, when the
> > inevitable need to cut scope made its appearance, they didn't make the
> > cut. But they are on the list of features to b considered.
> Hi Brian,
> Very nice to hear that. Do you plan to resume the discussion for 9 or
> later?
> If 9 is the goal, is there a public space where this is being
> tracked/discussed so we can follow it?

FWIW, method/field literals would be very useful for POJO-centric libraries
such as JPA/Hibernate, Bean Validation etc.

In several Hibernate projects we have APIs which allow for some sort of
"configuration" of bean properties (e.g. to specify constraints in the case
of Bean Validation [1]). These APIs are provided as an alternative to
annotations for specifying different kinds of meta-data in more dynamic
manner. Atm. we use the tuple (property name, element type) for specifying
the configured elements. Real literals of course would be much nicer for
this and would improve type-safety of such APIs.

While method/field literals themselves already would be very helpful, being
able to specify them within annotation values (similar to class literals
today) would add another benefit e.g. for data binding scenarios.

> Mario




More information about the discuss mailing list