Method and Field Literals
Gunnar Morling
gunnar at hibernate.org
Tue Nov 11 12:55:22 UTC 2014
Hi,
2014-11-11 13:03 GMT+01:00 Mario Torre <neugens at redhat.com>:
> 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.
Cheers,
> Mario
>
Cheers,
--Gunnar
[1]
https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-programmatic-api
More information about the discuss
mailing list