PROPOSAL: Method and Field Literals

[David Goodenough]

There are several good use cases for Field literals.  All of them remove 
the need to have field names expressed as String values, and all of them
allow a compiler/IDE to check the correctness of the code in a way that
can not (sensibly) be done with String values.

1) If you look at Bean Binding systems, such as JSR-295 BeansBinding
or JGoodies Bean Binding or the SWT JFace bindings, you will find lots of
cases where bindings are done using String field names.  Assuming the
code was originally coded correctly (and we are all after all human and
therefore prone to mistooks) if the field name is changed the compiler
or IDE can not flag up the problem.  The code will compile cleanly, and
will load cleanly, but will then do sneaky things like ignoring an existing
value or failing to save a new value.  And that might not happen until
an end user gets to the program.

2) If you look at JPA, its new incarnation has what is known as a Criteria
API.  This means that rather than writing JPQL (a variant of SQL) statements
as Strings, you write what look a bit like expressions so express the JPQL.
This is an improvement on writing native JPQL statements, but it is once
again flawed in that it requires the field names to be encoded as Strings.

You are right that getting Field or Method literals into Annotations 
would be difficult, because the Annotation rules require compile time
constants as arguements (that is not what it says in the language
spec but it is what it means).  Because Field and Method objects are not
stored in the class file directly (they are reconstructed at run time when 
they are used from a binary form) it would be extreemly difficult to regard
these as compile time constants, and it would require not only a language
syntax change, compiler changes and run time changes, but also a change
to the class file format.

David

On Thursday 12 March 2009, Reinier Zwitserloot wrote:
> I find both use-cases given so far not very compelling.
>
> Stephen Colebourne's Use-Case 'annotations for OVal framework':
>
> That can't work with this proposal because Fields aren't allowed in
> annotations. This was part of my point: You need to do quite a job on
> the rest of the JLS and a good chunk of the reflection API to make
> this useful. It's not a bad idea perse, but the value of this proposal
> divided by the effort and impact isn't a very high number (IMO).
>
> Adrian Kuhn's 'jexample' jUnit extension:
>
> Again with the annotations. Also, that's rather exotic. I'd just solve
> this differently. First off, between checking the stacktrace at the
> point of a failed assertion, -or- doing some class-file-fu to see that
> a given fixture calls another unit test method, any fixtures calling
> another fixture for setup purposes can be skipped without any
> annotation. Most unit tests are sequential in design so an annotation
> of the form "@Sequential" would tell the unit test framework to skip
> the test if any previous tests failed. Methods are given in order in
> the class file itself, but technically Class.getMethods() does not
> return the methods in order according to the javadoc, though in
> practice it does. A proposal to make that official works for me.
>
>
> If I compare this to other project coin proposals, the use cases just
> don't have the wow factor for me.
>
> The intent of this nit is to improve the proposal by making sure it
> lists all the changes needed to make it useful, and includes a listing
> of excellent use-cases so that, if the proposal is adopted, the
> proposal can be explained to the masses that use java in a way that
> makes them go: Ah, how useful!
>
> It would be a shame if they went: Why is this in here? Proposal
> <insert pet proposal here> is so much simpler and has so much better
> value. Java7 sucks! Bad java7! I'm going to go blog about it now! -
> Developers are a bunch of whiny kids sometimes :P Alternatively they
> forget all about it because it wasn't compelling to them and then you
> get the unfortunate situation that there's another piece of syntax
> that most java developers don't know about. I'd prefer to keep such
> niches of the JLS (like strictfp) to a minimum. It's not good for the
> language.
>
>   --Reinier Zwitserloot
>
> On Mar 12, 2009, at 11:36, Stephen Colebourne wrote:
> > Reinier Zwitserloot wrote:
> >> What's this useful for, exactly? Can anyone name me one non-exotic
> >> use-
> >> case?
> >
> > This is a basic feature of most modern languages. Its certainly a lot
> > better than using hard coded strings which happes today. I gave one
> > use
> > case in the Click framewok. IIRC the Genesis framework is similar.
> >
> > For example, consider bean validation as an example. Today, we at $job
> > use this based on the OVal framework (custom extension):
> >
> > public class SearchRequirements {
> >   @MaxLength(length=30)
> >   private String search;
> >   @DateNotInFutue
> >   pivate LocalDate dateRangeStart;
> >   @DateNotInFutue
> >   @DateNotBefore(field="dateRongeStart")
> >   pivate LocalDate dateRangeEnd;
> > }
> >
> > This allows validation of each of the three fields by a tool, and
> > appopiate error messages to be produced. Of course, the above code
> > has a
> > bug - the reference in @DateNotBefore has mispelled the reference to
> > the
> > "dateRangeStart" field. What field literals allows is to replace the
> > above with this:
> >
> > public class SearchRequirements {
> >   ...
> >   @DateNotInFutue
> >   @DateNotBefore(field=SearchRequirenents#dateRangeStart)
> >   pivate LocalDate dateRangeEnd;
> > }
> >
> > which is now compile time checked.
> >
> >> I can see quite a lot of good coming from method /handles/ but if
> >> that's the only relevant use case, then this is some sort of closures
> >> light. The problem with that is future expansion: If closures do show
> >> up in java down the road (Closures are not going to be in java 7, but
> >> I don't think its valid to say they'll never be in java ever,
> >> either),
> >> then the one use case fizzles out, and this is going to be a niche
> >> feature almost never used that nevertheless has to be maintained
> >> forever, and the complexity tax on the parser can never be removed.
> >> Even if this + method handles would serve as java's only closure
> >> proposal, I don't really like it - I at least want a way to define a
> >> block on the spot. method handles are neither TCP-compliant (google
> >> "TCP BGGA" for info) nor do they even allow you the simple courtesy
> >> of
> >> in-place creation that anonymous inner class literals give you.
> >
> > By method "handles", I'm reading method references (handles are a
> > whole
> > other issue). Neal has already commented that he believes this
> > proposal
> > is forward compatible with method references, and I'm pretty certain
> > its
> > compatible with FCM or BGGA style closues.
> >
> > I don't believe the use case for this goes away when method references
> > are added. You still need a compile-safe way to reference fields,
> > mthods
> > and constructors. If you didn't, then why would new languages be
> > including this feature?
> >
> >> Even if there are common use-cases, Method and Field (the classes),
> >> well, suck. They aren't parameterized, and worse, they don't carry
> >> their type at runtime either in case of generified field types. In
> >> other words, a Field class does not carry, at compile time, the type
> >> of the field. However, it also doesn't carry the type of the field
> >> *at
> >> runtime* if the field is 'T' or 'List<T>' or anything else with
> >> generics in there. The few use-cases I did think of just aren't going
> >> to work particularly well without this information.
> >
> > I agree that the proposal is more useful with generified field/
> > method. I
> > disagree that the proposal isn't useful without them. I think its
> > considerably better than what we have now.
> >
> >> You also can't use
> >> them in annotations (only primitives, String, and Class).
> >
> > The proposal will probably have to address this.
> >
> >> And a very minor nit: # shows up in various closure proposals. I
> >> would
> >> at the very least require something on the LHS and not let just
> >> "#foo"
> >> default to "Field foo of my own class". For future expansion's sake.
> >
> > Currently, I'd tend to agree with requiring something on the LHS. It
> > does offer more future growth.
> >
> > Stephen