A 'bean' keyword?

In the talk about properties, I don't think I've seen anyone mention using a 'bean' keyword. Here's a thought experiment to see how it might work.

Bean keyword

  public bean Person {
    // properties
    property String forename;
    property String surname;

    // normal fields and methods
    private String ordinaryField;
    public boolean validate() { ... }
  }

This would be compiled to:

  public class Person implements Bean {
    // properties
    private String forename;
    private String surname;
    public String getForename() { ... }
    public void setForename(String forename) { ... }
    public String getSurname() { ... }
    public void setSurname(String surname) { ... }

    // normal fields and methods
    private String ordinaryField;
    public boolean validate() { ... }

    // from Bean interface
    public MetaBean metaBean() { ... }
    public Property property(String propertyName) { ... }
    public Map<String, Property> propertyMap() { ... }
  }

So what have we got? Firstly, neither the 'bean' or 'property' keyword would break existing code. Keyword 'bean' would a contextual keyword, used in place of 'class'. Keyword 'property' is also contextual, in that it can only appear inside a bean.

The 'bean' keyword acts like the 'enum' keyword. It causes the generated class to implement a JDK interface - Bean. Code is generated to implement the interface allowing dynamic access to the property objects of the bean. The keyword also triggers the code generation of the get/set methods.

The trouble is that the 'bean' keyword hasn't really changed the nature of the problem. There are still two basic types of bean (simple semi-encapsulated classes, often server-side data transfer objects, and rich event-firing classes, usually client-side). The keyword hasn't helped us define the scope of the property, readonly/writeonly, bound/constrained, validation, etc.

Abandoning the past

What if we leave existing bean conventions in the past? Well, then we might have something that makes more sense. What if the 'bean' keyword generated this code instead:

  public class Person implements Bean {
    // public final properties
    public final Property<Person,String> forename = ...
    public final Property<Person,String> surname = ...

    // normal fields and methods
    private String ordinaryField;
    public boolean validate() { ... }

    // from Bean interface
    public MetaBean<Person> metaBean() { ... }
    public Property<Person,?> property(String propertyName) { ... }
    public Map<String, Property<Person,?>> propertyMap() { ... }
  }

Now, each property is actually no more than a public final field on the bean. But, using this code-generation is very different from at present:

  String surname = person.surname.get();
  person.surname.set( person.surname.get().toUpperCase() );
  person.surname.addListener(someListener);   // client-side only?

So, application code has to use person.surname.get() instead of person.getSurname(), to access data. This is true property objects - and a much better design than a get/set method naming convention.

Is this viable? Yes, although performance would need careful analysis. The beans Introspector could probably cope with the new structure, so most existing frameworks would still work.

But is it realistic? Well, I can hear the howls of protest now, so probably not. The change could be sweetened by generating regular get/set methods on the Person class itself that delegate to the property object. But if this is truly a new beans feature in the language then why look to the past?.

Summary

On its own, a 'bean' keyword doesn't look that useful. The main problem is still in defining the properties. The main use I could think of was using it to identify a completely new type of JavaBean, following a specification completely different to JavaBean spec 1.0. And that seems unrealistic.