A DESCRIPTION OF THE REQUEST :
It should be possible to obtain references to Field, Method and
Constructor objects without the use of strings. Proposed syntax:

// Assuming the following class
public class Foo {

    String bar;

    public Foo(String bar) {
        this.bar = bar;
    }

    public void fly(String to) {
        bar = to;
    }
}

Field fooBarField = Foo.class.bar.field;
Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});


The construct is similar to the ClassName.class syntax and it can be treated
by the Compiler in the same way:
It could produce the getDeclaredField, getDeclaredMethod and getConstructor
bytecode. No modifications to the JVM would be necessary.


JUSTIFICATION :
I posted this as an RFE twice before. The last time I was asked me to resubmit the RFE with a link to the message ID. Here is the discussion in a newsgroup:
news:bkc2ml$qdt$01$  xxxxx@xxxxx  -online.com

My justification again:
The existance of the field/method/constructor could be checked during compile
time. Typos would no longer be possible.

A notation without strings could be very easily refactored by IDEs.

We would specifically need the feature for our typesafe querying system,
so it could work completely without strings.
http://sodaquery.sf.net/

The possibility to get Method objects without strings, would encourage many
developers to use them for more dynamic programming and would result in lots
of more flexible libraries for the Java platform.

Thanks in advance for a consideration to add this very simple compiler add-on to J2SE 1.5.
(Incident Review ID: 208397) 
======================================================================
Posted Date : 2006-11-14 21:56:09.0

N/A

The 'master' request for easier reflection.
Posted Date : 2006-11-14 21:56:09.0

[------

This is by no means an endorsement of this feature.

The syntax could be:

    Type . class . Identifier
    Type . class . Identifier ( ActualTypeArgumentList_opt )

The first form represent a field and has the compile-time type
java.lang.reflect.Field.  The second represent method and has the
compile-time type java.lang.reflect.Method.

It is a compile-time error if the ActualTypeArgumentList includes
wildcard type arguments.

------]
Posted Date : 2006-11-15 01:07:00.0

I want to suggest an alternate syntax for this RFE, as
Foo.class.bar.field is, from a logical point of view, not
really Java-like . How about a javadoc-like syntax?

Field fooBarField = Foo#bar;
Method fooFlyMethod = Foo#fly(new Object[]{String.class});
Constructor fooConstructor = Foo#(new Object[]{String.class});

That may not exactly be javadoc, but it is not as unfamilar
as the above proposal - and it is much shorter. 

Thanks Theo,

your proposal looks a lot better than mine in the RFE 
request that I wrote. I fully support your syntax.

I would like to add two comments:
(1) This RFE is a partial duplicate of 4810162.

(2) The link to the newsgroup discussion that I started 
is here:
http://groups.google.com/groups?as_umsgid=%
3Cbkc2ml%24qdt%2401%241@news.t-online.com

A valuable idea, which schould be considered 
thoroughly.
With regard to the syntax, the proposal of  theodorou 
looks much nicer.
Regarsds Peter 

About the syntax, I would like something without "new", since it should be compile-time-evaluatable.

Field fooBarField = Foo#bar;
Method fooFlyMethod = Foo#fly(String);
Constructor fooConstructor = Foo#(String);

Or:

Field fooBarField = Foo#bar.class;
Method fooFlyMethod = Foo#fly(String).class;
Constructor fooConstructor = Foo#(String).class;

>Field fooBarField = Foo#bar;
>Method fooFlyMethod = Foo#fly(String);
>Constructor fooConstructor = Foo#(String);

Those look good.

>The existance of the field/method/constructor
> could be checked during compile time.

If you know the field bar exists at compile time, then
why bother using reflection at all?

> would encourage many developers to use them for
> more dynamic programming and would result in lots
> of more flexible libraries for the Java platform

Perhaps, but at what cost?  Libraries that contain methods that accept nothing but Objects are not
easy to use because it's hard to track down what
exactly should be passed to the method.  I imagine
the added ambiguity of a library written entirely using
reflection would not be worth it, not to mention the
speed penalty.

A typical use case where this syntax would be helpful -- suppose you have a class:

public class Customers implements Set<Customer> { ... }

This class represents a set of customers, perhaps backed by a file, a database, or something else (opaque to the client).  You'd like to be able to allow the client to query the set:

// find all customers where a given property equals some value
public Customer[] find(String property, Object value) { ... }

So the usage is:

Customer[] results = customers.find("postCode", "90210");

But we have to specify the property name as a string.  The Customers class then has to use reflection to get at the actual 'getter' method for "postCode".  If we mistype the name of the property, we don't find out until runtime.  The recommended syntax solves this not-too-uncommon problem, at least partially.

we change the 'find' method to:

// find all customers where a given property equals some value
public Customer[] find(Method property, Object value) { ... }

Now the usage is:

Customer[] results = customers.find(Customer#getPostCode(), "90210");

Now at compile time we know we have at least supplied some valid property-method.  We don't know, unfortunately, that the property is appropriate (i.e. it could be a property of some unrelated class, or might have the wrong calling signature).  The compiler couldn't tell that these usages:

Customer[] results = customers.find(Customer#setPostCode(String),  "90210");
Customer[] results = customers.find(String#length(), "90210");

were incorrect.

Note that the typesafe alternative of having the Customers class define a "findBy..." method for every alternative is just plain annoying: tons of repeated code.  Everytime the Customer class changes, the Customers class has to change.  Using Method objects is much cleaner, except for the type safety issue / loss of static type checking issue (which this RFE partially resolves).

I'd like add some thing in it.
When I use something like binding, I need the following:
bind(text.value.field, user.getAddress().name.field);
so user.getAddress().name.field may have the information of an object and a Method object.

To my mind, the proposed evaluation has the most suitable syntax.

in my opinion, syntax, presented in 'Evaluation', is the simplest and most consistent with other java constructs

Well,
The above proposal forgets about  Java security. If I have defined a private field, I really want it to be private:
class Foo{
  private Bar b;
}

which would also mean that I do not want anyone to be able to introspect the class and find about  the private field b.  How can the proposal would disallow this at compile time (e.g. I may still be getting security access exception at run-time)?

The syntax using # has been written up as a proposal in FCM - http://docs.google.com/Doc?id=ddhp95vd_0f7mcns. While the proposal goes further than this RFE, the link is still useful here.

On security, the solution is that you can only access fields and methods that you could legally call using the # syntax.

I think this should be taken back to the purpose of reflection, which is to have access to the internals of the class/object.

It's very rare that you need reflection for any other purpose, and many times when you do you should probably re-evaluate your design.

Beyond this, such a syntax could be useful. 

Or to stay away from syntax, maybe rather something similar to the ".class" reference available when you use a class constant, ex. java.lang.String.class. Maybe provide a similar .members, and through this reference methods/fields. like String.members.toString() references the Method for toString in the String class. This way you don't add syntax/grammer, but simply add to the core OO design.

Another option: with whatever syntax is used it should simply translate back to a String for use by the standard reflection API. Or have a method like .toCanonicalName() or toName() as found in the .class. 

In these ways the reflection API stays what it is, and this RFE's intent is achieved, which is a compile-time safety net for referencing field/methods.

There is probably many ways something like this could be achieved. One should just be careful and not thread on dangerous grounds by bending things towards what they aren't intended for, and make sure you don't start "handing matches to toddlers".

I like the proposal, but I think this syntax would cause name clashes:
    Type . class . Identifier
    Type . class . Identifier ( ActualTypeArgumentList_opt )

A problematic case would be Person.class.getName().  Two valid interpretations of this are:
1. The getName() method of the Person class
2. Calling the getName() method of the Person class object.  In other words, (Person.class).getName()

> Field fooBarField = Foo#bar;
> Method fooFlyMethod = Foo#fly(String);
> Constructor fooConstructor = Foo#(String);

I like this syntax most!