This article is updated at the following permalink.

-->

As Richard Bair points out we really need a way to get a PropertyDescriptor easily, ie. meta data and support for bean properties. For example, we wanna reference bean properties for beans binding in a safe and auto-completable way, as discussed in Gooey Beans Info.

Since hash (#) already denotes fields and methods in the javadoc notation, I reckon hash might be used to get fields and methods, rather than property descriptors. I guess candidates for denoting a PropertyDescriptor include a colon eg. Person:surname, and at eg. Person@surname. I was so happy to leave behind arrows (->) when i moved from C to Java, and the thought of now seeing them in Java, is um, too terrible to contemplate ;)

One could argue that if one's favourite IDE supported this notation, eg. where Person@surname is a code-fold of sorts for a static utility invocation eg. BeanInfoSupport.getPropertyDescriptor(Person.class, "surname"), and the IDE supported auto-completion, verification and refactoring of these references, then that would do. However, a big part of why we need property references, is because these are useful in other APIs, eg. beans binding and what-not. So they need to be supported in the language if they are to positively influence the design of other APIs.

For instance, APIs might consider referencing properties by PropertyDescriptor in addition to property names, in the event of convenient PropertyDescriptor references coming into the language eg. Person@surname. Also, new PropertyDescriptor wrappers might be introduced eg. BoundPropertyDescriptor, which wraps a PropertyDescriptor together with a specified bean instance, eg. theChoosenOne@surname as opposed to Person@surname.

Incidently, on the issue of observable properties, i believe that AOP might be the answer eg. to fire PropertyChangeEvent's eg. using dynamic proxies, CGLIB, or compile-time code generation from annotation processing. If property setters and getters are to be generated by the compiler where these don't exist, hopefully this would be performed by a tool which supports code generation from aspects indicated by annotations eg. a @JavaBeanAspect declared on the class.