Field and Method Literals

[joe.darcy at oracle.com]

Hi Chris.

In Project Lambda/JSR 335 targeted for Java SE 8, method references are 
currently supported in all the same SAM conversion contexts as lambdas, 
with the same rules. 

The "State of the Lambda" document from a few months back, including a 
description of method references is:
    http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
and the public archive of the mailing list for Project Lambda is at:
    http://mail.openjdk.java.net/pipermail/lambda-dev/

Cheers,

-Joe

On 4/12/2011 8:58 PM, Chris Beams wrote:
> Jesse Wilson submitted a proposal for field and method literals on March 10th 2009 [1], which was followed by quite a thread of discussion.  As far as I can tell, however, the last mention of this work was just two days later on March 12th 2009 [2].  Since that time, the Method Handles work has become a reality, but quoting John Rose in his 'nutshell' article [3],
>
> "[T]he point is not calling or using these things from Java; the point is using them, down near the metal, to assemble the next 700 witty and winsome programming languages"
>
> In the spirit of Mark's recent call for JDK8 proposals [4], I'd like to inquire about the status (if any) of Jesse's original proposal.  Simply put, are field and method literals in any way on the roadmap for JDK8?  If not, are there any reasons that submitting such a proposal (or simply re-submitting Jesse's work) would be a non-starter?  When I asked Jesse directly about the status of the proposal in December of 2009, he suggested it was dependent upon decisions in the closure space [5].  Perhaps that's still the case, but as closures will be decided in JDK8, perhaps we can make sure that method/field literals are as well.
>
> For context, we would find method literals in particular to be beneficial for various features of the Spring Framework.  To cite one: in Spring's code-based (i.e., non-XML) application configuration style, it is often necessary for the user to specify a method that the framework should call on their behalf at a certain point in the application lifecycle.  For example, calling the 'close()' method on a Spring-managed Hibernate SessionFactory object.  Currently, users are forced to use strings to represent these method names (and annotations such as @PostConstruct are not applicable in the case of configuring third-party code).  Method literals would Spring users to go from writing:
>
> @Configuration
> public class AppConfig {
> @Bean(destroyMethod="close")
> public SessionFactory sessionFactory() {
> // create, configure and return the Hibernate SessionFactory
> }
> }
>
> to something like the following:
>
> @Configuration
> public class AppConfig {
> @Bean(destroyMethod=SessionFactory#close)
> public SessionFactory sessionFactory() {
> // create, configure and return the Hibernate SessionFactory
> }
> }
>
> Again this is just one example, but you can see from the above how proper method literals would aid Spring users (as opposed to implementers) in writing safer, more navigable and IDE-friendly code.
>
> Thanks,
>
> - Chris Beams
>
>
> [1]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000388.html
> [2]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000414.html
> [3]: http://blogs.sun.com/jrose/entry/method_handles_in_a_nutshell
> [4]: http://mail.openjdk.java.net/pipermail/discuss/2011-March/001704.html
> [5]: http://twitter.com/#!/jessewilson/status/6557984814
>
>