Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

An annotation-based persistence framework

Use J2SE 5.0 annotations to eliminate getters and setters

By Allen Holub, JavaWorld.com, 03/21/05

 String getFoo();
void setFoo( String newValue );

The BeanBox uses the introspection APIs of the Class class to get a list of methods, then it uses pattern matching to find the getter/setter pairs. From these, it infers that a property exists and determines the property's type. (In the current example, a property called Foo is a String.) You are never expected to call these methods yourself; they exist solely for use by the BeanBox.

Interestingly, the writers of the JavaBeans spec understood just how problematic this getter/setter tagging mechanism is. (The main downside, discussed in earlier articles, is that the getter/setter methods expose too much information about the object's implementation, thereby making the underlying class much harder to maintain.) Consequently, the designers provided a more object-oriented solution in the BeanInfo and Customizer interfaces. User-provided implementations of these interfaces let you build a GUI without the getters and setters. Unfortunately, this overly complicated object-oriented approach was described poorly in the spec. The getter/setter approach was easy, and if you didn't understand the object-oriented-related maintenance issues, then the getter/setter approach seemed reasonable. Consequently, the BeanInfo/Customizer approach fell by the wayside and getter/setter strategies have been propagating like rabbits. The fact that you see the idiom everywhere doesn't make it good, however.

Back when JavaBeans were first proposed, many people (including myself) argued for a new keyword in Java to eliminate the need for the getters and setters. With the ability to introduce a new keyword, the Foo property I described earlier could be represented as:

 private @property String foo;

Since foo is private, exposing it to the BeanBox with the new keyword doesn't violate encapsulation. At the time, however, introducing new keywords was anathema, even keywords impossible to confuse with existing identifiers because they included an illegal symbol, like @.

With J2SE 5.0, however, Sun has gotten over its delicacy and made a few major syntactic changes to the language. Now, you can introduce a new keyword (called an annotation) into the language to specify an attribute that can be examined at either compile-time or runtime. You may introduce arbitrary keywords of your own choosing. The only requirements are: the annotation (the keyword) must be preceded with an @ sign, and you must use the annotation as an adjective. (Annotations can go anywhere that you might say static, final, or public.) Finally, you can toss the getters and setters for a much cleaner syntax that does the same thing.