Field and Method Literals

[Stephen Colebourne]

Could I suggest someone (not me, as I'm on holiday) looks at various
Java frameworks and find all the places where annotations curently
define method names as strings in annotations. I suspect that there
are quite a few, perhaps including Spring and Play.

Both method references and method literals are very useful elements
for anotations, as I believe the current string usages will show.

Stephen

On 20/04/2011, Joe Darcy <joe.darcy at oracle.com> wrote:
> Hello Chris.
>
> Chris Beams wrote:
> [snip]
>> 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
>>
>>
>
> Just addressing the last points on feature selection, I've written about
> this general topic a few years back:
>
>     "Project Coin: Elephants, Knapsacks, and Language Features"
>
> http://blogs.sun.com/darcy/entry/project_coin_elephants_knapsacks_language
>
> Quoting a few paragraphs:
>
>> Therefore for Project Coin, in addition to determining whether a
>> proposal to change the language is in and of itself appropriate, a
>> determination also has to be made as to whether the change is more
>> compelling than all but four or so other proposals. In economic terms,
>> there an an opportunity cost in the proposal selection; that is,
>> because of finite resources, choosing to have a particular proposal in
>> the platform removes the opportunity to do other proposals. There will
>> be good, compelling proposals that would improve the language /not/
>> selected for Project Coin because there are a full set of better, more
>> compelling proposals that are more useful to include instead. Having
>> available prototypes for proposals, running the existing tests, and
>> writing new tests can only better inform the continuing proposal
>> evaluation and selection.
>>
>> Part of evaluating proposals is judging their utility to the Java
>> platform as a whole. In this way, I've long thought the Java platform
>> is like the elephant in the parable about the blind men and the
>> elephant <http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant>:
>>
>> While each Duke and each of us may know and understand our own usage
>> of Java quite well and have valid ideas about how Java could be
>> changed to improve programming in our own areas of interest
>> (properties! operator overloading! design by contract! your favorite
>> feature!), putting together all that accurate /local/ information
>> might just result in a patchwork elephant:
>> Rather than just a collection of local views, a broad perspective is
>> needed to have an accurate, unified picture of the platform so Java
>> can keep evolving and improving as a general-purpose programming
>> language. This approach favors features with broader applicability.
>> For example, a usability improvement to generics, like the diamond
>> operator which allows type parameters to be elided during constructor
>> calls, is usable more often than, say, one of the various proposals to
>> allow extensible or abstract |enum| types, a change that would only
>> helpful in a small minority of |enum| declarations.
>
> Cheers,
>
> -Joe
>
> PS Class literals weren't there right at the beginning of the platform,
> but they were added in 1.1:
> http://java.sun.com/docs/books/jls/first_edition/html/1.1Update.html
>
>
>
>
>