Method references in annotations?

[Ben Evans]

Hi Brian,

Thanks for clearing that up. Lack of method references altogether would be a
critical shortcoming - lack of them in annotations is merely a continuing
frustration.

Having said that, I fully support the need to keep scope down in order to
deliver JDK 8 in a sensible time frame - all the more reason why the lack of
public read access to the archives is an issue. It's a great deal easier
when non-EG members can actually see the debate that's gone on, rather than
badgering people here to precis the EG discussion for us.

Thanks,

Ben

On Sun, Aug 14, 2011 at 10:52 PM, Brian Goetz <brian.goetz at oracle.com>wrote:

> Method references which are convertible to functional (SAM) interfaces are
> in scope, and have in fact been part of the plan all along.  Method
> references may be converted to SAM types just like a lambda, with the same
> rules.
>
> Converting method references to other things (e.g.,
> java.lang.reflect.Method) for purposes of enabling convenience in
> annotation-based frameworks is quite a different thing.  Neal's
> characterization of "tangential" (and criticism of the term "omission") is
> accurate.
>
> As to the mailing list, we are (still!) working on overcoming internal
> procedural roadblocks that will let us move the mailing list to somewhere
> more public.  The archives will be published when we are able to.
>
>
>
> On 8/14/2011 5:06 PM, Ben Evans wrote:
>
>> I don't see why method references are "only tangentially related" to the
>> scope of Project Lambda.
>>
>> Methods which expect a lambda must be able to accept either an anonymous
>> function or a named method.
>>
>> Surely, no-one is suggesting otherwise?
>>
>> Given that, the mechanism for named methods we have is presumably to pass
>> a
>> MethodHandle which contains a reference to the named method. This is
>> incredibly cumbersome and exactly the kind of overly verbose,
>> boilerplate-y
>> code that we should be able to do better than.
>>
>> I'm really failing to see why method references are not a consideration
>> here.
>>
>> Also - can we please have a link to public archives for the EG?
>>
>> Thanks,
>>
>> Ben
>>
>> On Sat, Aug 13, 2011 at 11:59 AM, Neal Gafter<neal at gafter.com>  wrote:
>>
>>  It's is a bit of a stretch to call it an "omission" that project lambda
>>> hasn't specified language constructs only tangentially related to it's
>>> scope.
>>>
>>>
>>> On Saturday, August 13, 2011, Ben Evans<benjamin.john.evans@**gmail.com<benjamin.john.evans at gmail.com>
>>> >
>>> wrote:
>>>
>>>> On Thu, Aug 11, 2011 at 12:14 AM, Stephen Colebourne
>>>> <scolebourne at joda.org>wrote:
>>>>
>>>>  On 10 August 2011 20:24, Dan Smith<daniel.smith at oracle.com>  wrote:
>>>>>
>>>>>> Discussions along the lines of "yeah, those are things we should get
>>>>>>
>>>>> to
>>>
>>>> sometime" have happened here, internally at Oracle, and in the JSR 335
>>>>> expert group.
>>>>>
>>>>> I will just note that I've raised this before. Frameworks in
>>>>> particular constantly have to wrestle with how to handle the lack of
>>>>> method references, generally using strings. Adding method references
>>>>> to the main body of code helps those framework writers a bit, but not
>>>>> being usable in annotations is a major limitation and a huge missed
>>>>> opportunity.
>>>>>
>>>>>
>>>> Nor is this situation static.
>>>>
>>>> E.g. both JSR 349 (Bean Validation) and JSR 350 (effectively, Container
>>>> Managed State) have glaringly obvious places where a method reference in
>>>>
>>> an
>>>
>>>> annotation would be very useful.
>>>>
>>>> Have the reasons for this omission been discussed in detail on the JSR
>>>>
>>> 335
>>>
>>>> EG? Is there a public Observers alias for that EG?
>>>>
>>>> Thanks,
>>>>
>>>> Ben
>>>>
>>>>
>>>>
>>>
>>