Sometimes it's refreshing to write a useful little aspect. Just last night I was reviewing some code that colleagues wrote for thread safety and I found this to be a really efficient way to find likely danger spots:
public aspect TrackCollectionAccess {
declare warning: set(java.util.Collection+ *.*) || get(java.util.Collection+ *.*): "collection field access";
declare warning: set(java.util.Map+ *.*) || get(java.util.Map+ *.*): "map field access";
}
I was able to weave this into the project and quickly review places in the code where fields containing collections and maps were being used to see if they were used in a way that wasn't thread safe. This is a nice example of a development-time aspect: using them to help you develop without using them in production.
On the other extreme, I recently extended Glassbox to allow for various kinds of application-specific plugins. There are a number of points where plugins need to interact with the underlying system, and it turns out to be a good example of how you can use aspects to modularize a feature variation. For example, here is how the DefaultPluginManager aspect allows a plugin to define new kinds of operations:
Object around() : getOperations() {
Collection result = (Collection)proceed();
for (Iterator it=operationPlugins.values().iterator(); it.hasNext();) {
OperationPlugin plugin = (OperationPlugin)it.next();
Collection added = plugin.getOperations();
if (added != null) {
for (Iterator inner=added.iterator(); it.hasNext();) {
OperationSummary summary = (OperationSummary)inner.next();
summary.getOperation().setPlugin(plugin);
}
result.addAll(added);
}
}
return result;
}
