Field and Method Literals

[Chris Beams]

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