Alef Arendsen

Uri and Arjen in their blog entries (listed below) already touched the subject of overuse of annotations.

Arjen posed the interesting statement recently that there’s a different between a primary key and the identity of an object. This might sound kind of obvious, but when using annotations to configure each one of them, it all of a sudden becomes a bit more vague.

When for example tagging an object’s field as the primary key using the JSR-220 @Id annotation, I tend to think that’s not so bad at all. When however one starts to customize the column in which the primary key is stored using the @Column annotation or specifying how the primary key should be generated using the @SequenceGenerator annotation I’m getting a bit uneasy and it’s not only about the readability of the code (as Uri showed to be getting worse and worse each time you put a new technology and its annotations to use in [1]).

A question of definition: Arjen tells us about an interesting discussion of whether or not an annotated POJO could still be called a POJO (see [2]). Keeping this in mind, we can start to think about about why we wanted to use POJOs in the first place. To keep our classes decoupled from the environment first of all. To escape the so-called technology cycle as my colleague Rod has presented on (see [3]). Our code should be able to survive environmental and infrastructural changes resulting from the different specifications published each year by various vendors and organizations. To insulate our core code from the way the core code will be used:

• as a web service,
• as a remote service,
• as part of a old-school web interface,
• as part of an AJAX web interface or
• as part of whatever we come up with in the coming years

Arjen and myself also discuss this shortly (see [4] and [5]).

I guess what it comes down to is that annotations internal to our systems–required to have our internal components and classes function–are okay. An example of such a usecase could be the checking of whether or not a required dependency has been injected (see [6]). If you’re in the position where you have to solve a problem dealing with rapidly changing infrastructural elements (see the examples above), I think it’s best to think twice before starting to use annotations.

Then for a concrete example, which shows us that it’s difficult to come up with a general rule. When I teach people on how to use Spring, we also touch base on the @Transactional annotation Spring provides. The @Transactional annotation is used to set transaction boundaries on a service class. It allows you to fully customize transaction semantics such as propagation behavior, isolation levels and transaction timeout values. I actually like this annotation although it does deal with infrastructural issues. Transaction management however is something that’s been there for quite some time already and I don’t think the basics of TX-management are going to change any time soon. Defining the annotation on your service class (and not on the interface) hides it from the user (be it a web service or remote client or Spring Web MVC Controller, JSF Managed Bean, et cetera) and the chance that you’ll ever be using the service class in a non-transactional context is pretty unlikely. In other words, using an annotation to define transaction semantics is quite attractive and not so bad at all. I still don’t use it that much though–don’t ask me why .

So when do you use annotations?

[1] Uri Boness in Dude, where’s my class?
[2] Arjen Poutsma in Annotations/Attributes: How do they help us?
[3] Rod Johnson in Ecsaping the Technology Cycle
[4] Arjen Poutsma in Annotations vs. Interoperability
[5] myself in Re: Annotations vs. Interoperability
[6] Uri Boness in Verifying configuration in Spring

I just got back from Oslo. Together with Kaare Nilsen, I did a Core Spring training there. We had good fun; not only during the training days, but also in the social events after that. We went out to a couple of bars on Tuesday and Thursday and I also did a presentation on Spring 2.0 for somewhat more than 100 people at the Oslo Java User Group (javaBin).

I didn’t exactly think about this beforehand, but there’s a lot of snow in Norway. I could have known of course but simply forgot. Half a meter snow everywhere! That really sucks when you don’t have a chance to put on some skis.

So now I’m back in Utrecht and for a change, I actually like the weather .

I do have to buy new shoes though, because the shoes I took to Oslo are completely ruined by all the salt on the streets that is supposed to let the snow melt (and I can tell you, it didn’t exactly work all that well).

In a recent post on the Pulihora blog, the author questions Spring’s capability of handling non-singleton objects, amongst others.

While there’s truth in some of his arguments, I’d like to elaborate on two of them.

First of all I’d like to touch base on what Spring offers (and will offer in the near future) in the area of support for non-singleton objects. Spring has had support for prototypes and other instantiation and scoping strategies since the early beginning. There are some limitations.

For the ‘Singleton A that needs Prototype B’ problem, Spring provides several options such as lookup-methods, target sources and manual lookups. I’m not going to discuss these in detail here and if you’re reading more about them, you’ll find out that each one of them has its pros and cons, but that’s not what I’m here to talk about. The bottom-line is that Spring’s DI container provides support for solving this problem and although it might not be perfect, it’s still better than what we used to code (custom factories, et cetera). Dependency Injection is a good idea and when you keep in mind the limitations of the underlying technology in practice it actually works out pretty well.

The author of the blog entry also mentions another limitation, namely the lack of support for temporal objects and sharing (stateful) prototypes. Spring has had support for this for a long time already through the use of the ThreadLocalTargetSource for example. This target source allows you to create thread-bound objects. Target sources can be implemented for different scopes if you like and something like this is exactly what Spring 2.0 will be offering. Through the use of a generic scoping mechanism you can create objects in any arbitrary scope (with out-of-the-box support for the HttpSession scope and the HttpServletRequest scope). Implementing new scopes is pretty easy and creating scoped objects is merely a matter of (something like) the following:

Another thing I’d like to say is that we’re certainly not there yet. Through the use of ApsectJ and by improving the core container itself, we’ll continue to improve the capabilities of the DI features in the coming time.

On the subject of remoting; the author of the blog entry has clearly not read Spring’s documentation well enough. Spring has support for several remoting protocols, including Hessian, Burlap and HttpInvoker. Spring however does support exporting RMI services and RMI-IIOP services as well. With respect to transaction propagation, I guess it’s just a matter of getting the right infrastructure in place (a remote capable JTA transaction manager and so on).

Resources:

• Transaction: How Distributed Are You? by Peter Holditch, 2004
• Spring Instance Management – part I – pooling by myself in 2005