Looks like I’ve got a bit of time on my hands, so I’m going to be reinvigorating this blog, attempting to spread some good words. Upcoming posts include a lot of stuff on Scala, Clojure, Software Transactional Memory, the Actor concurrency model, and much more.

When I was a boy, I read fantastic science fiction stories, in which the heroes possessed amazing devices. Some of these devices would allow the heroes access to the full range of human knowledge, at little more than a thought. Some would grant the heroes instant communication with anyone or everyone. Some would offer the heroes entertainments, with all of the books, music, or movies every created available whenever the heroes wanted.

Now that I actually carry around anywhere between three and six of these devices on a regular basis, I mostly spend my time annoyed at battery lifetime.

One functionality that I always felt was missing from Spring 2.0 and earlier was the ability to easily quantify over the components in your application. For instance, I often want some piece of code to have knowledge of every servlet in my application, or every repository, e.g. to monitor them for component management purposes. This could be hacked in earlier versions of Spring, but only at the cost of making some of your components dependent on the Spring container, or by using some fairly hairy aspect-oriented trickery. In Spring 2.5, quantification over components becomes much easier, using the new @Autowired annotation, applied to Collection or array-typed setters.

In this case, Rule1 and Rule2 are some random rules, and are instantiated automatically via Spring 2.5’s component package-scanning functionality. RuleEngine is also instantiated by package-scanning, and then injected with the set of all Rule components that are in the application context. At injection time, ruleEngine.setRules() gets called with a Set containing Rule1 and Rule2, which it can then use for whatever nefarious rule-engine purposes it may require. Note that there are no references to Rule1 or Rule2 anywhere in either the Java code or the Spring configuration. It’s tough to get much more loosely-coupled than that.

To add a new rule, just create a new class which fulfills the Rule interface, is annotated as a @Component, and lives in a package that Spring has been instructed to scan for components. The new rule class need not even be shipped in the same jar as the the RuleEngine component or Spring configuration file. Anywhere in the classpath is fine. This is weaker than the hot-swapping functionality provided by various application servers and OSGi containers, but does at least allow for separate builds of core components and the “plug-in” components which get automatically injected into them.

Spring 2.5 offers several possibilites for tweaking this plugin behaviour, such as only injecting some annotated subset of your plugin classes. For instance, here’s a rule engine that only knows about those rules marked as “High Security”

Hi, my name’s Dave, and I am passionate about software engineering. Utterly, ridiculously, head-over heels in love with the capabilities it gives, the challenges it provides, and the enormous variety of processes behind it all. Have been since fourth grade. Will be when they throw dirt in my face. Every bit of it: analysis, architecture, design, coding, testing, refactoring, release, deployment, issue tracking, performance tuning, down to the smallest bug fix. I love thinking about it, questioning its practitioners, stretching its boundaries, and most of all doing it. Usually, they pay me quite a lot to do software engineering, and when they don’t, I do it for free. Passionately.

This is where I share that passion with the world.

What I’m hoping to accomplish with this blog

To explore and clarify my learnings from thirty years of developing software, acquired through trial and much painful error

To centralize all the stuff I have had to teach to every junior developer I ever mentored. That way, when they ask me a question about a mistake they were about to make, I can just send them a URL. This should make the process of ignoring my advice and making their own damn mistakes that much more efficient.

To find and converse with like-minded fools, passionate about software development in all of its aspects. To be challenged by them, and challenge them in turn.

To rejuvenate my passions, by reexamining just what brought me to software development in the first place.

What I’m not looking to accomplish with this blog

To push any particular set of technologies. There will probably be more posts about technologies in the Java ecosystem, simply because that’s where I’ve been working for the last decade, but I don’t intend to limit my comments to the Java world.

To play host to Round #1,458,608 of any technical-religious arguments.

To sell my professional services. Really.

To speak for my current employer, my former employer, or indeed anyone but me.

To rake in those sweet, sweet affiliate program dollars. I’ll occasionally recommend books and products, but will not be doing so for advertising purposes.

What you won’t find here

Views sugar-coated or toned-down to achieve consensus, or to spare anyone’s feelings. Most likely you are doing software development wrong, in some particular, wasting time and money to produce software that is not as good as it could be. I certainly have, and undoubtedly still am. I am not going to be shy about pointing these out

Self-pity about the state of the the software development profession, or any given sub-population thereof. I truly believe software development is the best gig going (with the possible exception of Scarlett Johansson’s masseur) and have limited patience for griping about it.

If that’s your sort of thing, stick around, and don’t hesitate to let me know what you think.