Jacob Hookom has been vocal about doing properties right rather than simply generating getFoo/setFoo methods. Of course, you still want the JavaBeans introspector to work correctly. I thought it would be interesting to run with this idea and see where it gets.

The Rules of the Game

???

Mangled Methods

The way I understand Jacob's argument is that the get/set naming convention deserves to be laid to rest as a historical {accident|mistake|good idea at the time}. Thus, a native property must be manipulated with the property operator. If you define

public class Employee
{ public Π double salary; . . . }

then you must use

double x = joe π salary;

or

joe π salary += 1000;

You cannot use

double x = joe.getSalary();

or

joe.setSalary(joe.getSalary() + 1000);

Conversely, when translating the expression

x = joe π foo; // never calls getFoo

the compiler would not start hunting for a getFoo method. If there was no property foo , the expression would simply be an error.

By default, properties would presumably be implemented as a private field and a pair of public methods, with mangled names, similar to mangling in inner classes. For example,

public class Employee
{ private double $salary; public void $salary$set(double); public double $salary$get(); . . .
}

The getReadMethod and getWriteMethod of java.beans.PropertyDescriptor return the Method objects of these methods, so they can be invoked reflectively in tools.

The JavaBeans specification makes it quite clear that properties are intended for tools. The GUI builder or the persistence provider has a legitimate need to access properties that may be different from the needs of the programmer. Maybe one shouldn't even have a property access operator? Or should tool properties simply be private?

When you have a private property, the methods would still be generated, but they are only accessible through introspection (when access control permits), or as this π property in other methods of the same class.

Property Annotation Issues

Of course, annotations should be updated to work with native properties. Something like

@OneToMany
private Π Collection<Choice> choices;

Ideally, a property annotation is associated with the property itself and not with a method or field. But annotations are placed into the class files. Do we want to have yet another class file format change that can express properties and property annotations???

What about compatibility with existing tools and standards? The JPA annotation processor currently handles annotations of either fields or getters. Should annotating a property automatically produce a field annotation? Should there be syntax for moving the annotation to the getter method instead? Or the other way around???

Stuff that Needs Syntax

The most common use case--a field with a trivial getter and setter--should require no boilerplate. There need to be various variations for get-only properties, properties with nontrivial getters and setters, etc. etc. I don't want to propose syntax for them, so I just tabulate what needs to be supported with some syntax

Get-only property object π property cannot be an lvalue
Set-only property object π property cannot be an rvalue
Public getter/private getter? Does one want such a fine-grained control, or should the programmer just supply a private property and a public getter method?
Explicit getter/setter that does something else The programmer supplies a getter/setter that does something else than just reading or writing the underlying field. For example, a getter for a name property might concatenate firstName and lastName. Of course, the method is still anonymous. For example, something like
public Π String name get { return firstName + " " + lastName; }
would produce a method with a mangled name such as $name$get.
Explicit getter/setter that accesses hidden field The programmer supplies a getter/setter that accesses the hidden field and also does something else, e.g. logging. What is the syntax for accessing the hidden field?
No field Not all properties give rise to a field, e.g. the name property described above. Perhaps the compiler should simply see whether the getter and setter don't access the hidden field?
Bound properties Bound properties fire listeners when the setters are called. Apparently, they are very important to some people in the Swing world. This blog article discusses some subtleties. I am really muddled about these. Would users want a separate listener for each property, or a single listener for all properties of an object? Would it be ok to synthesize the listener firing method by calling the getter before and after invoking the setter, or would users want to customize that?
Constrained properties? Constrained properties allow a veto before property changes. These are really obscure. I have never used them (except for JInternalFrame, and then only because the API forced me to). Does anyone care?
Indexed properties? The JavaBeans spec defines array-valued indexed properties with getter and setter methods for individual elements, but I have never seen them used in practice.
Property literals? A comment to this article suggests that one might want to pass around a typed property literal (such as joe π salary) for some purpose, e.g. querying its capabilities, deferred execution of the getter/setter, etc.

All of this seems pretty easy to do. The challenge is to come up with syntax that makes people happy.