Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Dependency Injection and Type Safety

02.27.2008
| 11100 views |
  • submit to reddit

I've had a couple interesting discussions recently about dependency injection and type safety. In particular there is a new article up discussing type safety in the Butterfly DI framework. I think Jakob makes some good points and argues well that perhaps too much is made of the lack of type safety in Spring XML config. (And yes, I know you don't have to do it in XML.)

Guice is perhaps the other end of the scale as the type safety of the configuration seems to be one of the guiding principles of Guice.

Personally, I find myself sympathetic to the benefits of static typing. I've worked on big systems (1M+ LOC) and have had these kinds of problems before; not with Spring in particular, but in general with code that references classes and methods by name rather than by a strong reference. Over the years, I've seen a number of little problems that cost me a tiny amount of time to find and correct - usually found quickly at runtime or in unit tests. And I've had big subtle problems a few times that cost me lots of time. Sometimes these are more subtle than just a bad class/method name and relate back to implicit typing of string vs numeric values or something like that.

To me, one of the things that Java is really good at it is static typing. If you're going to use Java to build your system, especially Java 5+ with generics and annotations, you should leverage the heck out of it. Otherwise, why are you using Java anyways? My feeling is that Guice was created in this spirit.

But I see all of these choice as valid options and to some degree a matter of preference on a continuum. Where do you fall? How much static typing do you like in your DI?

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jakob Jenkov replied on Thu, 2008/02/28 - 3:46am

It would be nice to hear concrete examples of exactly *what* errors people have experienced as a result of Springs XML, Butterfly Container Script or similar DI configuration mechanisms of your favourite DI framework. Type safety issues *can* arise, but do they? And exactly what kind of errors do you get?

Knowing more about what errors occur in reality, perhaps Spring XML, Butterfly Container Script and similar mechanisms could be improved to check for such errors in the future.

Andrew McVeigh replied on Thu, 2008/02/28 - 4:25am in response to: Jakob Jenkov

The static typing they are talking about is static typing enforced by the compiler.

 Of course, it's perfectly possible to write a small checker to examine the spring config (or whatever config) and act as a type checker.  I do this in my work for my own DI framework, but I have also added type inference (types are propagated along connectors).

 Cheers,
Andrew

 

Peter Veentjer replied on Thu, 2008/02/28 - 9:34am

Compiletime typesafety is useful because you can check a lot of problems compiletime (instead of runtime). To make sure that my Spring applicationcontext files are correct, I try to load them all compiletime by adding a junit test. This way I know that my spring context is valid. So although I'm someone with a love for cool typing systems (even null pointers can be prevented compiletime by a good type system) I don't see the extra value here because there already is a working solution.

Peter Lawrey replied on Thu, 2008/02/28 - 3:32pm

I think Spring XML is good for introducing a standard because it is widely used, therefor it must be good.

However, having used and written various frameworks I am convinced that you can achieve similar if not better results with Java code and some disipline.  i.e. You can do DI with Java code!

The problems I see with Spring XML (compared with plain old java code) are; code completion, pre compiling (to ensure it isn't changed), static type checking, code analysis support, refactoring tools, debugging support, constructs which are like programming in XML (using XML in a way it was not designed for). Profiling is not easy either... :)

While it is not perfect, the tools for Spring are improving and an increasing number of people are familar with it

Peter Lawrey replied on Thu, 2008/02/28 - 3:39pm in response to: Peter Lawrey

I also forgot to mention generics type checking (which are difficult to check at runtime), and code coverage reporting.

Peter Lawrey replied on Thu, 2008/02/28 - 3:50pm in response to: Peter Veentjer

"I try to load them all compiletime by adding a junit test."

This does sound easier that making the compiler to the checking. :)

I find strategies which work well for me, don't scale well to a team of developers who have diverse opinions on how to develop. More so when there are multiple teams who feel under pressure to cut corners and/or lots of legacy code, say millions of lines.

However, if you work with people who have a different view on unit tests, (e.g. "unit tests are for time wasters" is but one) you might find they start breaking your code, if for example they only test their code and don't write unit tests every time they make a significant change to the configuration.

Usually, (and only say usually) you can be sure they have compiled some code before checking in a change. (Unless you use eclipse in which case not all the code needs to compile to run :) Some developers love this "feature"

 

Jakob Jenkov replied on Thu, 2008/02/28 - 4:09pm

>I also forgot to mention generics type checking (which are difficult to check at runtime), and code coverage reporting.

It is actually possible to check the type of a generic collection at runtime in certain situations:

Field and Method objects (reflection objects) have two methods:

Field.getGenericType() 
Method.getGenericReturnType()
Method.getGenericParameterTypes()

Using these two methods you can actually obtain the generic type of a return type of a Method, the parameters of a Method, or a Field. In other words, it is possible to determine the type put inside the <> in

List<String>

I know some people will claim that this is impossible due to "type erasure". Nevertheless it is possible. Both Spring and Butterfly Container uses that to further verify the config files at parse time. It seems to me that type erasure only truly happens for local variables (do they?), and for methods and fields in the sense that it is possible to assign a List<Integer> to a List<String> at runtime. However, you can actually do some checking using reflection.

Peter Veentjer replied on Mon, 2008/03/03 - 9:13am

I think/hope that dynamic languages are going to play a more important role in a lot of configuration stuff. Spring is nice, but the fact that you need to resort to all kinds of FactoryBeans for the most simplest things, is the consequence of Spring-XML being an external domain language. A Ruby DSL for Spring could transform the DSL in an internal one and thereby reducing the need to FactoryBeans (and large amounts of XML).

And Dynamic Languages normally are not very strong in the compiletime type-checking departement.

Alex Miller replied on Mon, 2008/03/03 - 9:19am

Or just use the Groovy Spring Builder.  :)

Peter Veentjer replied on Tue, 2008/03/04 - 6:01am

Or Springy (A Ruby based Spring DSL).

http://code.trampolinesystems.com/springy

Arbi Sookazian replied on Sun, 2009/03/01 - 11:21pm in response to: Peter Veentjer

I'm surprised nobody has yet to mention Web Beans (JSR-299) in this thread.  Well, there was mention of Google Guice which contributed to JSR299 as did Seam.  But one of the main goals of Web Beans (now Java Contexts and Dependency Injection?) was to provide static type safety, something that Seam 2.x currently lacks.

 I know that Spring framework has made annotations available so perhaps this "Spring XML" problem will go away? Even if it did,what about the stateless vs. stateful architecture debate (i.e. Spring vs. Seam)?  And the LIEs that have been fixed by Seam with the Seam Managed Persistence Contex?  Is this still a problem in Spring/Hibernate projects?  Apparently the OSIV pattern is not a good solution to LIEs.

 Anybody have any comments on why there are so few Seam developer job postings in dice.com?  I spoke to an Exadel employee about this recently and he said that "Seam is a complex framework with large learning curve".  Likewise for Spring, no?  And yet there are hundreds of Spring related jobs on dice.com...

Carla Brian replied on Mon, 2012/04/16 - 10:08am

I've heard that this is an efficient software. I will download this one and will use this. I think it is effective. - Tire Works

James Walker replied on Wed, 2012/06/20 - 7:25am

Failing that do you know of any other tool that will allow that? Cheers, parkjet

Passion Lab replied on Sun, 2012/09/02 - 3:41pm

if you work with people who have a different view on unit tests, (e.g. "unit tests are for time wasters" is but one) you might find they start breaking your code, if for example they only test their code and don't writing essay paper http://www.term-papers.cc/ unit tests every time they make a significant change to the configuration.

Lucifer Williams replied on Fri, 2012/11/16 - 1:28pm

I've had big subtle problems a few times in fashion schools in texas that cost me lots of time. Sometimes these are more subtle than just a bad class/method name and relate back to implicit typing of string vs numeric values or something like that.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.