A Non-Proposal related to Properties (original) (raw)

Alan Snyder javalists at cbfiddle.com
Sat Mar 28 12:50:02 PDT 2009

A Non-Proposal related to Properties

This is not a proposal, but it seems related to Properties, so knowing that there are people on this list who are knowledgeable and care about Properties, I was hoping to get some useful feedback and suggestions. (I'll apologize in advance if this is old news...)

As background, I have for a long time been a strong believer in static type checking and using methods for public access to data. Therefore, many years ago, when Java and JavaBeans decided to represent each property or attribute as a get/set method pair, I believed they made a good decision.

However, after spending a year or two applying this approach to large sets of configuration parameters and winding up with huge interfaces and way too many wrapper classes, I have changed my mind. It's not that I think that all get and set methods are bad, but I now believe that dynamic access to properties is the right way to go in many cases (especially when there are large numbers of properties and/or an extensible set of properties, where extension can happen by subclassing or by introducing new versions of the class). By dynamic access, I mean one get method (or a small number) and one set method (or a small number) that each take a parameter identifying the property to get or set.

The only problem is the loss of static type checking. If my code accesses a specific property (the property identifier is known at compile time), I want the compiler to type check my code, and I don't want to have to use a type cast.

Fortunately, there are clever people out there who have figured out a way to do this using the current Java generics. The basic idea is to define a class whose instances contain the basic property identifier (a String, say) along with a class object indicating the type of values that are acceptable for that property.

Something like this:

public class PropertyName { private String name; private Class type;

public PropertyName(String name, Class<T> type)
{
    this.name = name;
    this.type = type;
}

public String getName()
{
    return name;
}

public Class<T> getType()
{
    return type;
}

}

So, for example, if I want to define an integer valued property named "width", I would write:

PropertyName<Integer> WIDTH = new PropertyName<Integer>("width",

Integer.class);

Not ideal with that pesky class literal, but the best we can do for now.

Now, using the magic of type inference, one can define a get method that is statically type checked:

public <T> T get(PropertyName<T> p);

Here is an example use:

Integer n = o.get(WIDTH);

where o is defined to support the above get method. No type cast is required in my program (although one happens under the covers).

This gets me what I want: a simple interface for getting and setting properties by name, and static type checking when I access properties in a non-dynamic way.

This idea is obviously not appropriate for COIN because it is too simple... no language changes required!

My questions:

This idea can be realized with a small set of classes and interfaces. How would one go about getting them into the JDK? Is someone already doing this?

What other support would be useful?

One issue is how a class documents the properties that it understands, so that clients of the class will know what properties can usefully be set and how they will be interpreted. We could just rely on ad hoc commentary, but would it be useful to have annotations and/or javadoc constructs that can make this information available in a better way?

More information about the coin-dev mailing list