Consider the following:
@Reference(WEAK)
private Person client;
public Person getClient() {
return client;
}
public void setClient(Person client) {
this.client = client;
}
I chose a static import for the
ReferfenceType.WEAK enum in favor of @WeakRefernce. Contrast it with:
private Reference client;
public Person getClient(Person client) {
if (client != null) {
return client.get();
}
return null;
}
public void setClient(Person client) {
this.client = new WeakReference(client);
}
The
client object in both examples serves the exact same purpose. They should be of the same type. The fact that I know enough about this member's life cycle to allow for a certain optimization of memory usage, shouldn't mess my code too much. The compiler can and should fill the required details necessary to make this optimization happen. This would divorce my business logic from this little concern.This could be achieved with a little bytecode manipulation, but my point is, more should be handed over to the responsibility of the compiler. This is obviously nothing new, but with the introduction of annotations to Java 5, we are given an easy and backward-compatible way of declaring our intentions. More and more technical aspects of our code could be delegated to the compiler if we could define standard ways to define common and repeating intentions. I'll come up with more examples in future posts.
