Solving the Constructor Ambiguity Problem with Spring 3 & Annotations

Our continued look at Spring 3, and how to develop Spring 3 applications both with and without XML, continues. Here we look at spitting out JavaBeans from the Spring IoC container by invoking a non-default constructor, as opposed to just using a default constructor, and setting properties after the instance is created.

Of course, if you've worked with Spring, you know the issues that arise with regards to constructor ambiguity. This tutorial demonstrates how to avoid constructor ambiguity by appropriately configuring your Spring configuration file with index and type attributes.

However, the tutorial also demonstrates how to do the exact same thing using a Java class as your @Configuration file. Even if you hate annotation based development, you can't help but recognize that Java based configurations do help to avoid the types of runtime bugs associated with the constructor ambiguity problem.

Solving the Constructor Ambiguity Problem with Spring 3 & Annotations

Some of the Other Spring 3 Tutorials

Oh, and if you're interested, here are some of the other Spring 3 tutorials and discussions we've been providing over here at TheServerSide.com

Spring 3: Configuring the Development Environment
Video Tutorial on Configuring a Spring 3 Environment
An Introduction to Spring 3 IoC: With and Without XML
Video Tutorial: An Introduction to IoC with Spring 3, Annotations and XML

There will be more. We haven't even really got into Dependency Injection and the @Inject annotation. So, there's plenty more to come!

Recommended Books for Learning Spring

Spring in Action  ~ Craig Walls
Spring Recipes: A Problem-Solution Approach  ~ Gary Mak
Professional Java Development with the Spring Framework ~ Rod Johnson PhD
Pro Java EE Spring Patterns: Best Practices and Design Strategies ~ Dhrubojyoti Kayal

Sorry guys, but you are using a made up example to convince me that hardcoding my spring configuration inside a compiled Java class is better than having it in a standalone XML file.

I am deeply unconvinced that annotation-based config is any better that XML-based config, especially given that the modern development tools provide brilliant support for Spring XML, including custom namespaces. Using annotations means effectively hard-coding your Spring config: you cannot see it once compiled, you cannot change it once compiled.

The problem with anonymised method and constructor parameters has always been there. In Spring XML it is always a good idea to specify index attribute on constructor-arg tags, you just have to make a habit out of it. But it is the same on java code level: you always have to pay attention to the order of parameters.

As a made-up counter example: consider that you have to use a 3rd-party financial library, which has a class with a constructor of TwoWayPrice(double ask, double bid). If you don't check it and stupidly assume that it follows market convention of bid coming before ask, then you create new TwoWayPrice(bid, ask) and end up in a trouble. Can annotations help you avoid this mistake?