This weekly summary actually encompasses the last three weeks. Sigh.

Lots of activity throughout dev is centered around the Terracotta 2.6 and 2.6.1 releases, as well as the upcoming 2.6.2 release.

Primarily I’ve been working on updating Terracotta’s Spring support to 2.5.x. Currently we only support up to 2.0.5. I had thought I had gotten it working up through Spring 2.0.8, but late last week we fixed a bug in our build process which then revealed three failing automated TC Spring tests which were previously (incorrectly) passing. So Spring 2.0.8 is not quite there…but close. Meanwhile, my compadre Nitin had made some changes that got TC working with Spring 2.5, but those changes are not backwards compatible to Spring 2.0.x, so I’m investigating whether they can be merged together somehow. Since we are dependent on the Spring source code in order to instrument their code (by using Aspectwerkz), we are subject to the whims of whatever source code changes occur between even minor releases (such as differences between Spring 2.0.5 and 2.0.8).

The other thing of note that I got accomplished was to respond to this post on our forums about a deadlock occurring in Terracotta L1. The poster had nicely laid it all out for us, with a stack trace excerpt clearly showing the deadlock. My teammates and I reviewed the pertinent class, and I cleaned up a number of synchronization bugs or missing synchronization. The deadlock itself was cleaned up by moving to a CopyOnWriteArrayList for a collection, which previously was being locked while iterating through it (read-only) and doing expensive stuff. The fix will be in 2.6.2 release.

I was without internet connection at my house a couple weeks ago for a few days. I had to do bloody battle with Charter to get that fixed. Ultimately a technician came and found that the line to my house had been put on a splitter at some undetermined point in the past, and so my signal strength was no longer strong enough. Meanwhile, luckily, I was able to go to my parents’ house and get some work done there. Have I mentioned that I love my MacBook Pro, and wireless internet?

I gave my Guice presentation tonight. The best part of the talk for me is that a lot of people chimed in with comments and questions, which is just the way I like it. Thanks to everyone for attending and for generating some good discussion. My talk was comprised mostly of code samples, the presentation materials will soon be available on the JUG knowledge base.

It was great to see some old compadres (Greg, Rasesh, Jeff C and Dennis) as well as introduce myself to some familiar faces in the St. Louis Java community (Michael, Mark, Jeff G, Weiqi, Kyle).

The differences between Guice and Spring were definitely a frequent line of questions and comments. Some open questions and comments that came up related to this are:

• Is it ever preferable to have your application’s configuration truly outside of the source code (a la Spring xml)? Is there value in reconfiguring the app without rebuilding, or is that just a pipe dream? Is external configuration desirable so that non-developers can reconfigure a system, or is that fraught with peril?
• What would be a reason to integrate Guice into an existing code base which uses Spring, especially if you are already leveraging Spring 2.5’s annotation-based dependency injection? I conceded there may be no reason. Kyle Cordes pointed out that in a pristine, pie-in-the-sky world this may be true, but so often in the real world there are large clunky heterogeneous revenue-generating apps and components which need integrating, and you may be in a situation where you have no choice but to integrate Guice with Spring. In that department, Guice scores points for having integration with Spring built in.
• Is there a Guice parallel to Spring’s named instances? That is, in Spring you can configure beans which are named multiple instances of a single concrete type, and said beans can be injected. Jeff C suggested that a Guice Provider might supply that behavior. Kyle pointed out that, by Guice’s very nature you may not need to declaratively configure named instances because Guice entirely operates as Java, and you should be able to just programmatically get or create whatever instances you want. It’s definitely a different mindset than Spring.

Weiqi urged some of us to read the Guice source code, particularly to be impressed by some clever use of generics. I plan to read a little of it right now.

This just in - Weiqi has already written a writeup of my talk on his own blog. Thanks Weiqi, I’m flattered!

This Thursday night I’m giving a presentation on Guice at the St. Louis Java Users Group. Come on out and see!

My talk is shaping up to be mostly code and very few slides. In the first half I will be demonstrating the basics of Guice, what it is and what it can do, via the usual simple contrived code samples that you would expect. In the second half I hope to address how you might introduce Guice to an existing codebase. Specifically, I want to look at Guice’s integration with Spring, and also look at some basic strategies for refactoring out smelly code like Singletons or tightly coupled spaghetti code.

Boy, I hope it turns out as good as the above paragraph suggests!

If you’ve never been to the JUG before I encourage you to come check it out. It’s very informal and relaxed, it’s a great place to network and plug in to the St. Louis Java community. Plus there’s food and refreshments, and almost always cool swag being given away.

One last thing - I would be remiss if I didn’t mention that my company, Terracotta, has support for clustering both Spring and Guice at the JVM level. (There - now I can expense this blog.)