Evan Summers's Blog

Gotcha Property Descriptor

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.

Comments

• Couldn't we use this mechanism to access Annotations in general?

  Posted by: pcwheels on January 11, 2007 at 08:56 AM

• i think it would be great if all class artifacts where explicitly referencable as "literals" ie. Field's, Method's, and PropertyDescriptor's :) then our IDE can help us to the fullest potential, and of course the compiler can catch the errors too, eg. caused to renaming and misspelling eg. when not using an IDE. One can access an array of annotations on a specified Field, but i'm not sure i understand you about "accessing annotations"?

  Posted by: evanx on January 11, 2007 at 09:39 AM

• I clarified my opinion here

  In addition to those comments, I'd like to point out that using ProperyDescriptor directly is probably too restrictive. What I want is to be able to implement property objects that wrap a database or a Map. And those property objects should be completely compatible with bean property objects.

  And if you're confused - what you call property, I've called meta-property, and what you call bound-property I call property.
  

  Posted by: scolebourne on January 12, 2007 at 02:28 AM

• 
  stephen, I see your point that PropertyDescriptor is restrictive if you are considering storage other than "beans" eg. Map, ResultSet, DynaBeans et al.

  My personal usecase is however restricted to "beans" by which i mean, using java.bean.Introspector and PropertyDescriptor, for simplistic beans binding, eg. to support Presentation Model pattern, persistence, etcetera.

  I don't write tools, or JavaBeans per se, but it seemed like a good idea to reuse java.beans package for toolkits that need to get and set values on POJOs.

  So i'm naturally in favour of improving "the programmers' experience" for programming java beans, in particular my experience ;) as follows

  (1) property literals - which might or might not wrap PropertyDescriptor, but if they have the beanClass/bean and propertyName, that would do

  (2) avoiding boilerplate for bound properties ie. firing PropertyChangeEvents - i see AOP as solution here, to enhance POJO's into JavaBeans

  Posted by: evanx on January 12, 2007 at 05:01 AM

• I'd suggest that the best solution for bound properties is not AOP. Simply have a wrapper around the meta-property that does the event firing when the set is called. This means that the code for firing the events is just normal Java code, and ideally replaceable by developers.

  The only problem is ensuring that all sets occur via the meta-property. And thats where code-generation of a simple get/set may help.

  And are you sure that you wouldn't like to connect your presentation layer directly to the database? Or a map-based data structure exposed by JavaScript or Groovy?
  

  Posted by: scolebourne on January 12, 2007 at 05:22 AM

• 
  how i like to structure things, is the application classes program directly to the bean eg. person.setSurname(""), and the toolkit classes (eg. a GUI form or JTable model) reference the property descriptor wrappers, eg. property.set(bean, textField.getText()) eg. when refreshing the bean from the UI.

  I really like the Presentation Model pattern, where you connect your UI to a presentation bean, which is a POJO'esque representation of the data in your presentation layer. The presentation bean might wrap an entity bean eg. in a CRUD scenario. It is more tedious than a direct or mixin connection from UI to entity beans (or even directly to SQL table), but affords more flexibility. Subjectively speaking, i think it's neat and i like it and so i do things this way ;)

  My personal silver bullet is to increase the number of the classes in an application, which is probably an anti-trend. But i contend that the complexity of individual classes and methods will be decreased. With an IDE's refactoring, auto-completion et cetera, i find that such an approach is relatively inexpensive. But without an IDE, it is of course prohibitively expensive.

  By the way, i'm a swing programmer using java exclusively ie. not JavaScript or Groovy.
  

  Posted by: evanx on January 12, 2007 at 05:44 AM

• I still like Person.&surname more than say Person@surname. As I mention in my comment on rbair's blog, it could also be used for method references (as in PrintWriter.&println(String)) and harks back to a more related concept in ancient C days (since -> is about getting values, not addresses). I think adding the concept of bound Methods and Properties would be nice, too. That is, already attached to a particular object, as in person.&surname.

  Posted by: tompalmer on January 12, 2007 at 08:35 AM

• And to clarify: By bound property, I didn't mean data binding and events and so on. I meant just attached to a particular object instead of at the class level (like current Methods and Fields are that need an object passed in to be useful).

  Posted by: tompalmer on January 12, 2007 at 08:43 AM

This work is licensed under a Creative Commons License.