Re: [picocontainer-dev] annotations and comments on Pico2

Paul Hammant wrote:
> Konstantin, Erik,
>
> I have the same objections, but I've coded an 
> AnnotationInjectionComponentAdapterFactory for Pico2.  It uses @Inject.

> I have 2 main objections to use of annotation for
> wiring configuration

> 1. they introduce dependency on container ( which is 
> kind of uncool ) 

Except the conceptual problem, not sure how much of a problem this is in 
many systems. Just look at all the other projects that do have 
annotations... EJB3, Hibernate, JSF, etc. I have not heard this issue 
once. This dependency is no more than a classpath issue.

I'd be interested to know in real systems what kind of use case would 
show a real problem with such a classpath dependency.

> They are compiled into classes and can not be
> changed afterwards. This can be solved by second
> externalisable configuration system - and what value 
> do they have afterwards?
Less typing + declarative configuration. What I care the most in the end 
is the code quality. If I can have something easy to maintain, test and 
understand then it saves me time. It seemed quite obvious to me that 
having something like @Singleton (and other class level annotations):
- you don't even need to know about ComponentAdapters (I don't find this 
an obvious concept when you start with pico)
- you can have that element of configuration attached to the class 
instead of a configuration "block" somewhere else in the code
Yes in the end you need to attach a jar file to your code and always 
have it in your project. You also will need to deal with classloading. 
Other projects such as Tapestry IoC have solved most of these issues and 
they achieve IMO very nice end user code.

All this annotation stuff make my work easier - many other people seem 
to believe so but I somehow feel I'm wasting my time trying to contribute.

Erik.