Spring: improving on Java Reflection
Even though Spring is the de-facto dependency injection platform, it's almost more winsome for its plenitude of utility classes making life easier with everything from JMS to JPA. It's a little less known that the plenitude covers Java Reflection API as well.
In the rare times we need the Java Reflection API, we remember it's a bit of a pain. What with all the checked exceptions it declares, the setAccessible() and the declared fields vs just fields? Spring to the rescue - in the far corner of spring-core the aptly named ReflectionUtils has us covered.
DISCLAIMER: it is marked "for internal use only", but due to its undisputed usefulness it's been cropping up in more and more projects of late. On the off chance SpringSource personnel might be reading this - guys, now might be the time to legalize :-).
Now, add the following to your POM:
and take a look at ReflectionUtils. There are convenience methods to handle fields and methods by either name or type, with an optional cap on how far up the inheritance chain to go. The most mileage, however, gets had from the two families of visitor functions: doWithFields(...) and doWithMethods(...). All you need to do is implement a callback, and you have yourself a clean way to iterate over a class' reflection attributes: You can provide a filter if desired - for example, to weed out parental implementations of overridden methods. Enjoy!Google Collections: transforming and filtering
Quite often in Java we have to do this:
Run through a collection, calculate something for every element, and return a new collection. To those who've programmed languages with first-class functions (e.g. Ruby, Scala) this time-tested construct looks wordy. The equivalent Scala is this:
Makes one wish for something at least half as eloquent to be available in Java. Well, there is. Enter Google Collections - a library of improvements on the JDK collections that would do well to become a staple in your repertoire. Add the following to your POM: and the function above becomes this: Line-count is the same, but the intention is expressed in obvious (functional) terms: we are transforming a collection into another collection by applying a function to every member. Real-world examples tend to be somewhat more complex than simply calling toString(), and as complexity grows, the benefits of clear expression do become obvious. If you wonder why Collections2.transform()returns a Collection instead of a specific subclass, it's because the TransformedCollection that it actually returns is a lazy-evaluation wrapper. No new collections get created; instead, your original ones gets stored, and apply(T from) only gets called as elements are accessed. This helps when your transformation function is heavy or has expensive side-effects (e.g. hitting the database). The Collections2 utility class also contains a useful shorthand for a lazy-evaluation filtering iterator: Its tremendous improvements upon Iterable and Comparable, as well as its awfully convenient support for multi-collections (collections and maps of collections) will be subjects to the next couple of posts. Enjoy!
