Field and Method Literals

[Chris Beams]

Stephen's comment reflects our concern - that method literal support limited to or designed for lambda contexts does not go far enough.  The "State of the Lambda" document linked below uses the following example for static method literals:


Arrays.sort(people, #Person.compareByAge);


Then goes on to differentiate syntax for instance method literals:


Arrays.sort(people, #comparatorHolder.comparePersonByAge);


The proposal for static method syntax would be fine for our purposes, but the the proposal for instance method syntax assumes that a receiver variable (comparatorHolder in this case) is available in the first place.  For Spring's purposes, this would invalidate a number of use cases, and rules out use within annotations entirely.

We're looking for a general purpose constant-expression method literal syntax usable in any programmatic context and that may refer to any type of method.  We particularly care about usability within annotations, thus the necessity for evaluation as constant expressions.  Toolability is also key - for example, Eclipse users should be able to hit 'F3' on the use of a method literal and arrive at its associated method declaration, just as doing the same on a class literal opens the class declaration. Such support would be straightforward for tool vendors to implement.

Method (and field) literals seem to me an obvious addition to the language; I've often wondered why they weren't there from the beginning, just as class literals have been.  Is there a theoretical reason why they should not or cannot be introduced?  I would think they are more fundamental than any closure proposal, and that closure proposals would build atop field/method literal support as opposed to the other way around.

- Chris


On Apr 14, 2011, at 2:31 PM, Stephen Colebourne wrote:

I would note that the use case below (use of a method reference in an
annotation) is not yet in P.Lambda AFAIK.
I consider that a highly desirable use case.
Stephen

On 14 April 2011 03:30,  <joe.darcy at oracle.com<mailto:joe.darcy at oracle.com>> wrote:
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