Javalobby - Comments for "Dependency Injection and Type Safety"

Or Springy (A Ruby based

alarmnummer — Tue, 04 Mar 2008 06:01:10 -0500

Or Springy (A Ruby based Spring DSL).

http://code.trampolinesystems.com/springy

Or just use the Groovy

puredanger — Mon, 03 Mar 2008 09:19:48 -0500

Or just use the Groovy Spring Builder. :)

I think/hope that dynamic

alarmnummer — Mon, 03 Mar 2008 09:13:19 -0500

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.

>I also forgot to mention

jj83777 — Thu, 28 Feb 2008 16:09:09 -0500

>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.

"I try to load them all

peter_lawrey — Thu, 28 Feb 2008 15:50:44 -0500

"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"

I also forgot to mention

peter_lawrey — Thu, 28 Feb 2008 15:39:24 -0500

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

I think Spring XML is good

peter_lawrey — Thu, 28 Feb 2008 15:32:44 -0500

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

Compiletime typesafety is

alarmnummer — Thu, 28 Feb 2008 09:34:39 -0500

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.

The static typing they are

andrewm — Thu, 28 Feb 2008 04:25:13 -0500

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

It would be nice to hear

jj83777 — Thu, 28 Feb 2008 03:46:51 -0500

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.