This work by Marco Torchiano is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
In several application where a general purpose container needs to access specific objects, properties represent a common technique.
We can loosely define a property as an attribute of an object that can be accessed programmatically based on run-time only information. That is the accessor -- typically developed in advance and independently -- does not know anything of the accessed object structure at compile-time.
There are few Java-specific idioms that can be used to implement properties: they use different technologies, some present since the first versions of Java, some introduced more recently; they require different efforts on developer side, and they sport different time performance levels.
There are several possible solutions available in Java to let a class expose properties:
- implement a well known interface
- provide methods adhering to a predefined naming scheme
- use annotations
For the sake of simplicity here I will focus on a very simple set of properties that can be either String or int.
They can be accessed through a predefined interface:
public interface Gettable {
public int getInt(String name) throws PropertyNotFound;
public String getString(String name) throws PropertyNotFound;
}In order to understant better how the different alternatives work we consider a simple class with two properties:
- a
Stringproperty with name"s" - an
intproperty with name"i"
The first approach requires the class to implement the Gettatble interface and provide the methods that map a property name to its value, this can be done using series of if, a switch (that since Java 7 accepts also String selectors), or using a Map of command objects.
/*
* Class implementing the Gettable interface
*/
class GettableClass implements Gettable {
private int i;
private String s;
public GettableClass(int i, String s) { this.i=i; this.s=s; }
@Override
public int getInt(String name) throws PropertyNotFound {
if(name.equals("i")) return i;
throw new PropertyNotFound(name);
}
@Override
public String getString(String name) throws PropertyNotFound{
if(name.equals("s")) return s;
throw new PropertyNotFound(name);
}
}When a class implements the predefined interface its properties can accessed directly:
GettableClass go = new GettableClass(1,"value");
\\...
go.getString("s");According to the second technique, the class provides a set of getter methods that conform to a predefined naming scheme: one method for each property.
The method must start with get followed by the name of the property with initial letter capitalized, e.g. for a property named Name a method getName() must be created.
Such an approach is widely used, e.g. it is the scheme used in the Java Beans naming convention.
/*
* Java Bean convention for getters
*/
class BeanClass {
private int i;
private String s;
public BeanClass(int i, String s) { this.i=i; this.s=s; }
public int getI() { return i; }
public String getS() {return s; }
}When a class provides methods according to such a predefined naming scheme, its properties can accessed through an adapter object that makes use of reflection to access the variables:
BeanAdapter rao = new BeanAdapter(new BeanClass(1,"value"));
\\ ...
rao.getString("s");The final approach consists of a class with only the attributes related to the properties, and possibly a constructor. The attributes defined in the class defines are marked with Java Annotations that indicate that attributes are to be exposed as properties.
In this case the @Property annotator is used to indicate which attributes are considered as attributes.
/*
* Annotated class
*/
static class AnnotatedClass {
@Property int i;
@Property("s") String string;
public AnnotatedClass(int i, String s) { this.i=i; this.string=s; }
}When a class uses annotations its properties can accessed through an adapter object that can be automatically generated at compile-time or can make use of reflection to access the variables:
AnnotationAdapter aao = new AnnotationAdapter(new AnnotatedClass(1,"value"));
\\...
aao.getString("s");Another possibility for annotatote class is to leverage and annotation processo that can be automatically generate a custom adapter at compile-time:
AnnotatedClassPropAdapt caao = new AnnotatedClassPropAdapt(new AnnotatedClass(1,"value"));
\\...
caao.getString("s");The complexity of the declarations and the relative performance are summarized in the following table:
| Declaration method | LOC | Required Methods | Access method | Access time |
|---|---|---|---|---|
| Implement interface | 13 | 2 | Direct | 520 ms |
| Method naming scheme | 7 | 2 ( one per property ) | Run-time reflection adapter | 828 ms |
| Annotations | 5 | 0 | Run-time reflection adapter | 720 ms |
| " | " | " | Compile-time adapter | 402 ms |
Each declaration method require a specific access method. The annotation approach allows for two alternative access mehtods.
The times refer to 10M executions of the following block:
String s = obj.getString("s");
int j = obj.getInt("i");
s += j;The time were measured on a MacBook Pro (Retina, 15-inch, Late 2013) with a 2.3 GHz Intel Core i7 CPU.
The easiest solution consists in simply implementing a predefined interface (e.g. Gettable in the example above) that can be invoked by any accessor object to access the properties. The interface might include meta-property methods, e.g. to retrieve the list of properties.
This solution is the most expensive in terms of developer's effort because it requires the most code to be written. In addition -- and partly as a consequence -- it is the most difficult to maintain.
This solution does not require any additional code because the object properties can be accessed directly.
This method is widely used e.g. in the Java Beans naming convention where each accessor method must start with get.
Another usage of this approach (though not for property access) can be found in the JUnit 3 method naming scheme where each test method has to start with test and return void.
This solution is easier to implement, although it might turn expensive when the number of properties grows. The solution requires an adapter that implements the predefined interface and converts any general interface method invocation into a target-specific method invocation.
The properties can be accesse by means of Java Reflection API that enable a program to programmatically access class definitions.
To access a String property we can on-the-fly retrieve a method corresponding to the naming schema and invoke it:
String getStringPropertyBean(Object obj, String name) throws PropertyNotFound {
String getterName = "get"+Character.toUpperCase(name.charAt(0))+(name.length()==1?"":name.substring(1));
try{
Method m = obj.getClass().getMethod(getterName);
return (String) m.invoke(obj);
}catch(Exception e){
throw new PropertyNotFound(name);
}
}The above code, can be highly inefficient if the property is accessed several times, because the search for a method might be time-consuming.
For this reason it is preferrable to have an adapter object that on-instantion scans the target property container object and stores the pointers for the right invocation. A simplified implementation is reported in the BeanAdapter.
The usage of annotations is the most compact and readable solution. The solution requires an adapter that implements the predefined interface and converts any general interface method invocation into an access to the target attribute.
Annotations are used to attach additional meta-information to the elements of the program. Such elements may be retained up to the run-time phase according to the declaration provided in the definition of the annotation.
The annotations can be analyzed with the Java Reflection API, similarly to the naming scheme approach.
To access a String property we can on-the-fly identify the attribute annotated as property and access them (this requires proper visibility or disabling the visibility access using the method Field.setAccessible()):
public static String getStringPropertyAnnotated(Object obj, String name)throws PropertyNotFound {
for(Field f : obj.getClass().getDeclaredFields()){
Property prop = f.getAnnotation(Property.class);
if(prop!=null){
String propName = (prop.value().equals("")?f.getName():prop.value());
if(propName.equals(name)) {
try {
f.setAccessible(true);
String result = (String) f.get(obj);
f.setAccessible(false);
return result;
} catch (IllegalArgumentException | IllegalAccessException e) {
break;
}
}
}
}
throw new PropertyNotFound(name);
}As for naming scheme, the on-the-fly approach is not efficient and an adapter object that analyzes the target object and prepare a data structure with the pointers to the attributes. AnnotationAdapter.
As an alternative to run-time access, annotations can be processed at compile-time by suitable annotation processors.
An annotation processor is invoked directly by the compiler and it can generate additional code that is compiled.
An example of annotation processor is represented byt the PropertyProcessor class.
The PropertyProcessor annotation processor, applied to the AnnotatedClass shown above, generates the following adapter class:
import it.polito.po.annotations.PropertyNotFound;
import it.polito.po.annotations.Gettable;
import it.polito.prove.BeansTiming.AnnotatedClass;
public class AnnotatedClassPropAdapt implements Gettable {
private AnnotatedClass target;
public AnnotatedClassPropAdapt(AnnotatedClass target){
this.target=target;
}
public String getString( String name ) throws PropertyNotFound {
if(name.equals("s")){
return target.string;
}
throw new PropertyNotFound(name);
}
public int getInt( String name ) throws PropertyNotFound {
if(name.equals("i")){
return target.i;
}
throw new PropertyNotFound(name);
}
}The class is very similar to the original GettableClass, in particular it is automatically placed in the same package as the target class in order to be able to access the attributes that have a package visibility.