Field and Method Literals

Mon Apr 18 00:31:27 PDT 2011

[Sorry I actually posted this at coin-dev where the original discussion is located, but despite having already registered there my messages are handled as non-registered and awaiting approval. As Remi has pulled the topic over here already, I dare to do so as well ]:-> )]
---

Hi List!

(I will surely mess up the Thread again because I still didn't figured out how to respond to java dev lists in a way that the message gets associated correctly. Sry about that. Anyway:)

I read once somewhere (i think remi explained it) that this discussion has to distinguish between Field and Method _references_ (which can be "executed"/"read" rightaway) and Field and Method _literals_ (which just resolve to java.lang.reflect.Field and java.lang.refelct.Method objects).
IIRC, for example Remi is strongly in favor of (only) handling references. For methods, those are also the (only) types implemented for project lamba if I understood it correctly.

I think what Chris (and Stephan, too) talks about would be Method _literals_ (right?).

As far as I observed it, every time someone asks for ~ literals, the topic gets mixed up with ~ references (no offence, it's just about ambiguity of terms)

And because they hardly ever get into the discussion, I want to give a similar example for Field _literals_ as well:

If you want to build frameworks using reflection in a more flexible way (somehow most stuff i do with reflection ends up that way), you want to better control the things that happen by providing specific Fields.
For example:
<T> copyInstance(T source, T target, Field... fieldsToCopy)
or
<T> copyInstanceExcluding(T instance, T target, Field... fieldsToExclude)

You can do that "Field..." already, of course. But you can hardly provide the fields in a static context.
E.g.
copyInstance(oldPerson, newPerson, Person#firstname, Person#lastname)

Which is very sad. It's like running out of fuel 2 meters before the objective.
The copy stuff is of course only a simple case. More relevant in practice are things like (*cough* advanced) OR-Mappers, where you want to be able to control more precisely and compact which fields to include/exclude (e.g. for lazy loading, partial saving, etc.)
This is a big (granted not too serious, but still big) hole in the language and I wonder that it is so seldomly addressed in discussions.
Replacing reflective Fields accesses in low-level operations like that by reflective calls of getters and setters is not really nice and sometimes not even possible, so Fields are definitely needed as well (somewhen...)

Field and Method references are sexy as well (of course; probably even in more cases), but as far as I understand it, the _literals_ things are still needed in many other cases for both Fields and Methods.

Thanks & regards

Subject: Field and Method Literals (Wed Apr 13 23:31:37 PDT 2011)
From: scolebourne at joda.org

> 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> 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
>>>
>>>
>>
>>