I think you are right that the number of classes to wire inside a bundle
is much lower than the number of classes in a spring application. So
there is less need for a DI solution.
The question is though how to do the wiring with java in practice. Do
you have some larger examples for this? What I am especially concerned
with is the handling of instance creation and DI setup when classes are
partly created by hand and partly by DS.
Christian
On 17.02.2014 20:19, Peter Kriens wrote:
I do not think this is the idea of DS. Spring was invented to handle the
byzantine complexity of an average Java application at the time. Trying to wire
it all together had become a nightmare because there are ordering issues in
initialization. The complexity of apps exploded because the complexity
increases exponentially with the number of dependencies. So Spring provided a
fantastic solution to this problem. However, it also introduced XML programming
which is fundamentally bad (it is probably the worst language to code in ever
devised by mankind). In the early naughties this was ok since Spring solved a
real problem.
I think a natural DS application uses normal plain run of the mill Java code to
wire the private beans. Since these are normally a small number, there are in
general no ordering issues, specifically since the scope is private, no
unexpected surprises. Also the wiring is much better done in Java because it
gives you 100% type safety, error checking in the compiler, and lots of context
help in your IDE. Since the problem is so much smaller and all your types are
in private scope and you really want automatic wiring then there are lots of
solutions: Picocontainer, Guice, etc.
DS works so well because it is highly cohesive. It basically does one thing,
wiring services, and it does that extremely well. I would really think it would
be shame if we try to turn it into another bloated monster ... :-)
Kind regards,
Peter Kriens
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
