The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

jjenkov (13) [Avatar] Offline
Chapter 2 mentions that DI containers are not invasive on the code being wired up
using DI, but that is not entirely correct.

1) Lack of full method call capabilities
Spring's XML configuration can only inject into constructors or setters.
This means that you cannot inject into a method called "add(...)", nor
into at method that takes more than one parameter. If you are wiring up
a Swing application this is quite annoying, since Swing components have
a lot of add() methods. I talked to a developer from exactly such a project
once. He told me they would have to add a lot of setter methods to make
the code be configurable via Spring. This way, Springs lack of configuration
flexibility made it quite intrusive on the code being wired.

Butterfly Container doesn't have this problem, and Guice doesn't either, if
you are using Provider's, right? These two containers can inject into
anyt mehtod, with any number of parameters.

2) Guice Annotations intrude on the code being injected.
Though these annotations may seem harmless, the @Inject put into a component
to be wired up using Guice, is actually an intrusion from Guice on the
wired component. If you later want to switch away from Guice, you will need
to remove all those annotations.

Springs way of using annotations does not suffer from this problem, since
only the DI configuration code (the bean factory methods) is annotated, not the
wired up components themselves.

I would really recommend that you look at Spring's way of using annotations, and
perhaps write a bit about them in the book ?!?. It kicks ass, makes configuration easier,
more flexible and easy to read and understand.
Perhaps Guice could let itself inspire by that?

Butterfly Container does not have this Spring style annotations. The DSL is just
as simple, and in many ways more concise than the equivalent Java code in my opinion.
If you really need to add a Java factory, you can also do so in Butterfly Container.
And these factories us NO reflection at runtime, meaning they are very fast. But,
you never know. Perhaps I'll add Spring style annotations in the future smilie
dhanji.prasanna (37) [Avatar] Offline
Re: Chapter 2 - The "non-invasiveness" of DI Containers
This comes up every now and then, actually you dont need to remove the annotations if you decide to change from Guice.

You can simply change them to source level retention and they will be ignored. Annotations are just metadata so the feeling of intrusion is just that--a feeling. It is similar to Javadoc =)
jjenkov (13) [Avatar] Offline
Re: Chapter 2 - The "non-invasiveness" of DI Containers
Don't you still need the Guice JAR files on the classpath when compiling, if you have the @Inject in your code?