Wozu eigentlich ein Depency-Injection-Framework?

[Guest]

Den nutzen von Depency Injection will ich nicht in Frage stellen. Es ist schon gut, wenn man Abhängigkeiten nicht über den ganzen Code verstreut und fest verdrahtet. Bei Spring werden die Abhängigkeiten dazu in einer XML-Datei beschrieben und von der Beanfactory werden die Objekte verschaltet.

Man könnte doch genauso gut mit Java alle Abhängigkeiten beschreiben und sie trotzdem an einem Ort konzentrieren, so dass nicht jedes Objekt selbst die abhängigen Objekte erzeugen bzw. suchen muss. Was ist aber nun der Vorteil, das mit einer XML-Datei statt mit Java zu tun?

 

[FArt]

Der von dir beschriebene Vorteil von DI ist nur einer von vielen... Google mal nach den Vorteilen von DI, das hilft...

... XML muss man z.B. nach einer Änderung nicht mehr kompilieren...

 

[maki]

Durch die xml Datei kannst du eben deine Anwendung konfigurieren, ohne den Javacode zu ändern.
Sehr praktisch wenn man zum testen mal eine andere Konfig als die Prod Konfig braucht, eben viel flexibler.

 

[deamon]

Durch die xml Datei kannst du eben deine Anwendung konfigurieren, ohne den Javacode zu ändern.
Sehr praktisch wenn man zum testen mal eine andere Konfig als die Prod Konfig braucht, eben viel flexibler.

Ok, also scheint der wesentliche Vorteil genau dieses Nicht-Kompilieren zu sein. Ist das vielleicht der Grund, warum es sowas wie Spring in Skriptsprachen nicht gibt?

 

[maki]

Ist das vielleicht der Grund, warum es sowas wie Spring in Skriptsprachen nicht gibt?

Warum sollte es das nicht in Skriptsprachen geben?

Für DI braucht man kein Framework, solange so etwas wie parameter an Methoden/Konstruktoren gibt steht einem DI als Option offen.

Martin Fowler hat hier ein gute Erklärungl:
http://martinfowler.com/articles/injection.html

Interessant wird das ganze wenn man relativ einfach (Konfigdateien oder eben Code) die Implementierung von Klassen austauschen kann.

 

[ps]

Die Frage stellt sich mir auch oft. Zumal das JDK ab Version 5 sowieso eine IoC Möglichkeit mitbringt (über META-INF/services)

Wer es etwas komfortabler haben will benutzt die Lookup API von NetBeans welche natürlich auch ausserhalb der Plattform benutzt werden kann. Das ist so ziemlich die leichtgewichtigste (und komfortabelste) DI welche ich kenne

Natürlich reichen die Möglichkeiten nicht immer - aber oftmals ist es mehr als Genug. Vor allem eröffnen sich auch neue Möglichkeiten welche reine DI Container nicht mitbringen. (Lookup vorhandener Implementationen während der Laufzeit. Sehr praktisch um zB. Bezahlmöglichkeiten in Webshops zu integrieren...)

-> http://openide.netbeans.org/lookup/

 

[deamon]

Der Konsens dieser gut ein Jahr alten Diskussion scheint zu sein, dass der wesentliche Vorteil eines DI-Frameworks die Verwendung von XML-Konfigurationsdateien ist, die ohne Kompilierung geändert werden können.

Aber die Verdrahtung der Objekte ist ja keine Konfiguration, die ein Endanwender oder Systemadministrator machen würde. Diese Art von Konfiguration macht der Entwickler selbst. Da der Entwickler ohnehin alles mögliche kompiliert, ist es auch kein Problem wenn dazu auch die Verdrahtung der Objekte gehört. Das ist ja eigentlich ein ganz grundlegendes Prinzip bei objektorientierten Programmen und ich sehe keinen Vorteil, wenn man das per XML macht.

Im Gegenteil ist XML eine weitere Technologie, mit der man sich beschäftigen muss, für die man spezielle Werkzeugunterstützung braucht (wenn es nicht zu grausam werden soll). Man fängt an, in XML Dinge nachzubilden, die logische Zusammenhänge beschreiben, was mit Programmiersprachen besser geht. Und sei es nur, dass man in der Spring-Doku gucken muss, wie man eine Map mit XML befüllt.

Der Wildwuchs an Konfigurationsdateien in der Java-Welt ist eine Seuche! Statt die in vielen problemlos anwendbare und allen Java-Entwicklern vertraute Sprache Java zu verwenden, erfindet jeder Konfigurationsdateischöpfer eine neue Syntax für bestimmte Aufgaben (befüllen von Maps). Deswegen finde ich es schon grundsätzlich gut, auf XML soweit wie möglich zu verzichten.

"I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism."
(Martin Fowler)

Bei Spring gibt es ja auch eine Bewegung weg von XML und hin zu Java-Konfiguration. Bloß wo ist eigentlich der Mehrwert von Spring DI, wenn man Konfigurationen wie die folgende schreibt?

@Configuration
public class AppConfig {
    private @Value("#{jdbcProperties.url}") String jdbcUrl;
    private @Value("#{jdbcProperties.username}") String username;
    private @Value("#{jdbcProperties.password}") String password;

    @Bean
    public FooService fooService() {
        return new FooServiceImpl(fooRepository());
    }

    @Bean
    public FooRepository fooRepository() {
        return new HibernateFooRepository(sessionFactory());
    }

    @Bean
    public SessionFactory sessionFactory() {
        // wire up a session factory
        AnnotationSessionFactoryBean asFactoryBean = 
            new AnnotationSessionFactoryBean();
        asFactoryBean.setDataSource(dataSource());
        // additional config
        return asFactoryBean.getObject();
    }

    @Bean
    public DataSource dataSource() { 
        return new DriverManagerDataSource(jdbcUrl, username, password);
    }
}

Mit Spring EL gibt es hier einen bequemen Weg (@Value), auf Konfigurationsdateien zuzugreifen, aber SpringSource hat hier mal wieder das Rad neu erfunden, denn Property-Dateien mit Java auzulesen ist auch nicht schwer. Dann gibt es noch Annotationen wie @DependsOn, womit angegeben werden kann, dass eine Bean auf Seiteneffekte einer anderen Bean angewiesen ist, also eine indirekte Abhängigkeit über die Umgebung besteht. Abgesehen davon, dass die Notwendigkeit dafür auf schlechtes Design hindeuten könnte, könnte man genau solche Abhängigkeiten auch mit Java schreiben.

Die Konfiguration als XML zu schreiben ist aus meiner Sicht eher Nachteil als Vorteil und kein Grund ein DI-Framework einzusetzen. Was Spring in der Java-Konfiguration mit Annotationen macht, könnte man genauso gut mit Java pur machen.

Was ist dann also der Vorteil von Spring DI? Ist der eigentliche Vorteil von Spring nicht das, was über DI hinaus geht? Wie etwa Unterstützung bei der Internationalisierung, event-propagation, resource-loading, AOP oder Abstraktion von anderen Frameworks?

Bloß wenn der eigentliche Vorteil von Spring nicht DI ist, welchen Grund gibt es dann, Spring DI einzusetzen?

 

[maki]

Der Konsens dieser gut ein Jahr alten Diskussion scheint zu sein, dass der wesentliche Vorteil eines DI-Frameworks die Verwendung von XML-Konfigurationsdateien ist, die ohne Kompilierung geändert werden können.

Ungenau/vereinfacht ausgedrückt: ja, genauer ausgedrückt: Wenn man die Konfiguration der zu injectenden Objekte von der Verwendung trennt, ist man flexibel. Ob dabei XML, Java Annotationen oder gar Java Code selber verwendet werden ist von untergeordneter Rolle.

Aber die Verdrahtung der Objekte ist ja keine Konfiguration, die ein Endanwender oder Systemadministrator machen würde. Diese Art von Konfiguration macht der Entwickler selbst. Da der Entwickler ohnehin alles mögliche kompiliert, ist es auch kein Problem wenn dazu auch die Verdrahtung der Objekte gehört. Das ist ja eigentlich ein ganz grundlegendes Prinzip bei objektorientierten Programmen und ich sehe keinen Vorteil, wenn man das per XML macht.

Hmm.. da wiederspreche ich
Kompiliert wird von einem Build Tool, u.U. wird dieses auch von einem CI Server aufgerufen.
In einem "echtem" Unittest will man die einzelnen Komponenten isoliert testen, d.h. die Abhängigkeiten der Komponente werden ersetzt.
Wäre doch schlecht wenn da alles festverdrahtet wäre in so einem Fall
Auch kann man Konfigurationsdateien im Textformat (Proeprties, XML, etc.) einfacher filtern, da diese nicht mehr kompiliert werden müssen.
Das gehört übrigens nicht zu Grundlagen der OO, DI & Komponentenarchitektur sind weiterführende Themen, die kaum beachtet wurden bevor Testen populär wurde.

Im Gegenteil ist XML eine weitere Technologie, mit der man sich beschäftigen muss, für die man spezielle Werkzeugunterstützung braucht (wenn es nicht zu grausam werden soll). Man fängt an, in XML Dinge nachzubilden, die logische Zusammenhänge beschreiben, was mit Programmiersprachen besser geht. Und sei es nur, dass man in der Spring-Doku gucken muss, wie man eine Map mit XML befüllt.

Der Wildwuchs an Konfigurationsdateien in der Java-Welt ist eine Seuche! Statt die in vielen problemlos anwendbare und allen Java-Entwicklern vertraute Sprache Java zu verwenden, erfindet jeder Konfigurationsdateischöpfer eine neue Syntax für bestimmte Aufgaben (befüllen von Maps). Deswegen finde ich es schon grundsätzlich gut, auf XML soweit wie möglich zu verzichten.

"I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism."
(Martin Fowler)

Da bist du leider zu spät, die XML Konfigurationshölle ist schon vorbei, Spring setzt seit 2.5 mehr auf Annotationen und weniger auf XML, JEE 5 auch.
Wer XDoclet nicht als Erleichterung schätzen gelernt hat, war nie wirklich in der XML konfig Hölle *g*
Hibernate, EJBs2.x, Struts1.x, Spring 2.0.x etc. pp.
Das war die wirkliche XML Konfig Hölle.

Bei Spring gibt es ja auch eine Bewegung weg von XML und hin zu Java-Konfiguration. Bloß wo ist eigentlich der Mehrwert von Spring DI, wenn man Konfigurationen wie die folgende schreibt?

Weniger XML Konfiguration

Mit Spring EL gibt es hier einen bequemen Weg (@Value), auf Konfigurationsdateien zuzugreifen, aber SpringSource hat hier mal wieder das Rad neu erfunden, denn Property-Dateien mit Java auzulesen ist auch nicht schwer. Dann gibt es noch Annotationen wie @DependsOn, womit angegeben werden kann, dass eine Bean auf Seiteneffekte einer anderen Bean angewiesen ist, also eine indirekte Abhängigkeit über die Umgebung besteht. Abgesehen davon, dass die Notwendigkeit dafür auf schlechtes Design hindeuten könnte, könnte man genau solche Abhängigkeiten auch mit Java schreiben.

Schreib doch mal die Konfig mit java Properties, wetten dass es länger wird und schwerer zu warten?
"depends-on" hat übrigens nix mit indirekten Abhängigkeiten zu tun, sondern damit, das Komponenten nunmal Abhängigkeiten von anderen Komponenten haben die erfüllt sein müssen, wenn nicht meldet dir Spring hier ein Fehler, es ist also guter & sauberer Stil Depends-On zu verwenden.

Die Konfiguration als XML zu schreiben ist aus meiner Sicht eher Nachteil als Vorteil und kein Grund ein DI-Framework einzusetzen. Was Spring in der Java-Konfiguration mit Annotationen macht, könnte man genauso gut mit Java pur machen.

Na dann nimm doch "Java Pur", hält dich ja keiner davon ab.
Die Vorteile von Textdateien zur Konfiguration hatte ich oben ja schon erwähnt (Filtering zB.).

Was ist dann also der Vorteil von Spring DI? Ist der eigentliche Vorteil von Spring nicht das, was über DI hinaus geht? Wie etwa Unterstützung bei der Internationalisierung, event-propagation, resource-loading, AOP oder Abstraktion von anderen Frameworks?

Bloß wenn der eigentliche Vorteil von Spring nicht DI ist, welchen Grund gibt es dann, Spring DI einzusetzen?

Spring bietet DI, sehr einfach sogar
Spring bietet aber auch noch viel mehr, schreibst ja selber schon einige Bespiele hin.
Spring DI ist halt immer noch mächtiger als JEE DI, GoogleJuice, PicoContainer, etc. pp.
Wenn dir das reicht was die anderen leisten nimm doch die anderen

Weiss noch nicht wohin du willst mit deiner Argumentation..
contra Spring?
contra XML?
contra DI?

 

[bygones]

verzeiht dass ich nicht alles hier gelesen habe bzw nur halbherzig gelesen habe..

dennoch mein Senf:

ich bin auch kein grosser Fan von XML configurationen - ich verstehe die Vorteile, aber es fuegt eine weitere Komplexitaet in das System.

Den Vorteil des einfachen Austauschens kann man zb mit Guice auch bekommen und muss da nicht eine weitere Ebene in sein System reinbringen.

Da nutzt ich lieber die Sprache die ich so und so fuer meine Applikation nutze.

 

[deamon]

Hmm.. da wiederspreche ich
Kompiliert wird von einem Build Tool, u.U. wird dieses auch von einem CI Server aufgerufen.
In einem "echtem" Unittest will man die einzelnen Komponenten isoliert testen, d.h. die Abhängigkeiten der Komponente werden ersetzt.
Wäre doch schlecht wenn da alles festverdrahtet wäre in so einem Fall

In einem Unittest kann man die Abhängigkeiten direkt verdrahten. Oder fängt du für jeden Unitttest an, die XML-Konfiguration von Spring zu ändern?

Da bist du leider zu spät, die XML Konfigurationshölle ist schon vorbei, Spring setzt seit 2.5 mehr auf Annotationen und weniger auf XML, JEE 5 auch.

Abgesehen davon, dass bei Spring meiner Meinung Annotationen auch massiv missbraucht werden (siehe Spring MVC 3), braucht man nur mal einen Blick in die Doku zu werfen, um zu sehen, dass XML immer noch der de-facto-Standard ist.

Schreib doch mal die Konfig mit java Properties, wetten dass es länger wird und schwerer zu warten?

Was ist an einer Property-Datei und getProperty(String key) schwer? Stattdessen belästigt einen Spring mit wieder einen neuen Technologie namens Spring EL.

"depends-on" hat übrigens nix mit indirekten Abhängigkeiten zu tun, sondern damit, das Komponenten nunmal Abhängigkeiten von anderen Komponenten haben die erfüllt sein müssen, wenn nicht meldet dir Spring hier ein Fehler, es ist also guter & sauberer Stil Depends-On zu verwenden.

Normale Abhängigkeiten wären Referenzen. Die API-Doku schreibt zu @DependsOn:

Beans on which the current bean depends. Any beans specified are guaranteed to be created by the container before this bean. Used infrequently in cases where a bean does not explicitly depend on another through properties or constructor arguments, but rather depends on the side effects of another bean's initialization.

Spring DI ist halt immer noch mächtiger als JEE DI, GoogleJuice, PicoContainer, etc. pp.

Aber was leistet Spring denn bei DI mehr als die anderen?

Weiss noch nicht wohin du willst mit deiner Argumentation..
contra Spring?
contra XML?
contra DI?

Ich hinterfrage die Berechtigung von Spring DI und überlege, ob es nicht ohne einfacher oder besser wäre.

 

[tfa]

In einem Unittest kann man die Abhängigkeiten direkt verdrahten. Oder fängt du für jeden Unitttest an, die XML-Konfiguration von Spring zu ändern?

Es gibt eine Konfiguration für Test, eine für das Produktivsystem, eine für das Entwicklungssystem. Wo ist das Problem? Die Unterschiede (d.h. die Parameter) speichert man am besten in normalen Property-Dateien (property-placeholder), die XML-Datei gibt es nur einmal.

Grundsätzlich finde ich XML auch doof als Konfigurationssprache. Bei Spring erstreckt sich XML aber auf ein Minimum, das ist tolerabel. Ich weiß nicht, ob du mit Spring schon etwas experimentiert hast - also praktisch. Eigene Anschauung ist immer noch das beste, um sich eine Meinung zu bilden.

 

[maki]

In einem Unittest kann man die Abhängigkeiten direkt verdrahten. Oder fängt du für jeden Unitttest an, die XML-Konfiguration von Spring zu ändern?

Je nachdem was alles getestet wird, wird entweder gar keine XML verwendet und nur Java setter, oder eben eine XML Datei für den ApplicationContext.

Abgesehen davon, dass bei Spring meiner Meinung Annotationen auch massiv missbraucht werden (siehe Spring MVC 3), braucht man nur mal einen Blick in die Doku zu werfen, um zu sehen, dass XML immer noch der de-facto-Standard ist.

Was gäbe es denn sonst für Alternativen zu XML oder Annotationen im Web Bereich?

Was ist an einer Property-Datei und getProperty(String key) schwer? Stattdessen belästigt einen Spring mit wieder einen neuen Technologie namens Spring EL.

Wie gesagt, schreib den Code und vergleiche
Die EL kann auch noch mehr, zB. in den XML Dateien eingesetzt werden.
Es wird keiner gezwungen die Spring EL zu verwenden, bleibt ja noch XML... irgendeinen Tod muss man sterben.
Aber wenn du einerseits von "Annotations-Missbrauch" sprichst und andererseits von XML nichts hälst, was bleibt dir eigentlich noch ausser zu sagen das alles schlecht ist???

Normale Abhängigkeiten wären Referenzen. Die API-Doku schreibt zu @DependsOn:

Da geht es um Abhängigkeiten die per DI injiziert werden, aber das hatte ich doch schon erklärt, da steht auch nix anderes.
"Normale Abhängigkeiten" sollten doch durch DI injiziert werden, genau darum geht es doch.

Aber was leistet Spring denn bei DI mehr als die anderen?

Ach mensch, müssen wir jetzt wieder all das durchkauen?
Die Untestützung für Unittests zB. findest du bei keinem anderen Framework in diesem Umfang und Qualität.
Dann die Untertützung für Standard APIs & die Vereinfachung der APIs, usw. usw. usw. usw. usw...

Ich hinterfrage die Berechtigung von Spring DI und überlege, ob es nicht ohne einfacher oder besser wäre.

Hast du denn schon mal mit Spring DI gearbeitet, ich meine so richtig?
Oder anders gefragt: Hast du denn schon an einem richtig komplexen Projekt gearbeitet ohne DI?

DI ist DI, lässt sich auch nur in Java ohne Annotationen umsetzen, mit viel Boilerplate Code... und etwas unflexibel.
Ganz ohne DI zu arbeiten ist jedoch ein Rückschritt in die Zeit vor Unittests & sauberem Design, die Zeit in der das GoF Singleton eine gute Sache war und autom. Tests nur in Büchern vorkam, die Zeit in der für das Debuggen fast soviel Zeit investiert wurde wie da schreiben des Codes, die Zeit als Refacoring ohne tests gemacht wurde und es jedesmal ein Spiel mit dem Feuer war, weswegen es nicht mehr gemacht wurde.

Was also nehmen anstatt Spring DI?
Wie gesagt, die anderen Frameworks können eben nur DI, und manched avon nur sehr eingeschränkt wie zB. JEE5

Irgendwie habe ich den Eindruck dass du versuchst Spring schlecht zu machen, ohne es wirklich zu kennen oder dessen Vorzüge zu verstehen.
Mir macht das nix aus, ist nur überflüssig zu diskutieren, kannst ja nehmen was du für besser hälst

 

[byte]

Der große Vorteil von XML gegenüber Sourcecode liegt darin, dass sich Properties beim Build Management leichter austauschen lassen. Der Sinn eines guten Build Managements liegt ja darin, mit einem Klick Builds für unterschiedliche Umgebungen machen zu können (z.b. TEST, QS, PROD). Das geht halt wesentlich einfacher, wenn man nur Resourcen ändern muss (XML kopieren, Werte aus Properties ersetzen) anstatt Java Quellcode anfassen zu müssen. Ähnliches gilt beim Ausführen von Unittests (Test-DB, Mock-Objekte).

Aber natürlich ist Spring DI nicht nur wegen der XML-Konfiguration interessant. DI ist viel mehr als das Verbannen des new Operators aus dem Sourcecode. DI ermöglicht nicht nur das Instanzieren und Verdrahten der Objekte. DI bietet die Möglichkeit, den gesamten Lebenszyklus von Objekt-Kaskaden zu steuern. DI bietet die Möglichkeit, technische Details vor den POJOs zu verbergen. DI bietet die Möglichkeit, Objekte mittels AOP zu erweitern.

Natürlich sind das alles Dinge, die man auch ohne DI erreichen kann. Aber das ist halt wesentlich komplizierter und umständlicher als der Einsatz einer DI Library. Denn im Grunde macht man dann nichts anderes, als das Rad neu zu erfinden. Das kann natürlich auch Spaß machen, aber ist selten sinnvoll.

 

[JanHH]

Sollte man nicht auch zwischen "klassischer" DI, wo die Objekte einmal zur Initialisierung fest verdrahtet werden, und der dynamischen DI bei sowas wie seam unterscheiden, wo die Abhängigkeiten bei jedem Funktionsaufruf neu aufgelöst werden? Jede Komponente ist unter einem eindeutigen Namen bekannt, und kann beliebig da, wo sie gebraucht wird, injiziert werden - äusserst komfortabel, z.B. bei dem klassischen Problem, wie bekommt man die Auswahl eines Users auf einer Webseite komfortabel auf die nächste Seite mit rüber, oder ein Objekt ohne "Klebstoffcode" von einer Session Bean in eine andere.

 

[deamon]

Eine Alternativ zu XML und Annotationen wäre ... Java! Warum muss ich @Controller an einen Controller schreiben, statt einfach von einer Controller-Klasse abzuleiten. Ist Vererbung auf einmal böse? Die ganzen Annotationen gaukeln einem vielleicht lose Kopplung vor, aber ohne sie funktioniert halt nichts mehr (wie es soll). Stattdessen weichen Annotationen in vielen Fällen Schnittstellen auf und verlagern manche Dinge von der Übersetzungszeit in die Laufzeit.

Aber was leistet Spring denn bei DI mehr als die anderen?

Ach mensch, müssen wir jetzt wieder all das durchkauen?
Die Untestützung für Unittests zB. findest du bei keinem anderen Framework in diesem Umfang und Qualität.
Dann die Untertützung für Standard APIs & die Vereinfachung der APIs, usw. usw. usw. usw. usw...

Die Frage war, was Springs Dependency Injection mehr leistet als andere DI-Frameworks und nicht, was Spring noch so alles neben DI anbietet.

Aber ich sehe schon, dass wir irgendwie auf der Stelle treten. Ein Teil meiner Gedanken hat Bob Lee, der Erfinder von Guice, beschrieben. crazybob.org: I Don't Get Spring

 

[byte]

Eine Alternativ zu XML und Annotationen wäre ... Java! Warum muss ich @Controller an einen Controller schreiben, statt einfach von einer Controller-Klasse abzuleiten. Ist Vererbung auf einmal böse? Die ganzen Annotationen gaukeln einem vielleicht lose Kopplung vor, aber ohne sie funktioniert halt nichts mehr (wie es soll). Stattdessen weichen Annotationen in vielen Fällen Schnittstellen auf und verlagern manche Dinge von der Übersetzungszeit in die Laufzeit.

Wenn ich Business Logik in einem Service implementiere, dann möchte ich das eben als POJO implementieren und nicht von irgendeinem Remote Service ableiten. Heute publiziere ich meinen Service vielleicht per RMI, morgen per SOAP und übermorgen per Burlap. Vererbung finde ich hier in der Tat böse. Denn ich binde meinen Code an technische Details, die sich in Zukunft ändern könnten.

Den verlinkten Artikel finde ich übrigens komisch. Bob Lee kritisiert Dinge, die ich für absolute Lapalien halte.

 

[tfa]

Der verlinkte Artikel ist knapp 4 Jahre alt. Im Zusammenhang mit DI-Frameworks kann man das schon als antik bezeichnen.

 

[maki]

Eine Alternativ zu XML und Annotationen wäre ... Java! Warum muss ich @Controller an einen Controller schreiben, statt einfach von einer Controller-Klasse abzuleiten. Ist Vererbung auf einmal böse? Die ganzen Annotationen gaukeln einem vielleicht lose Kopplung vor, aber ohne sie funktioniert halt nichts mehr (wie es soll). Stattdessen weichen Annotationen in vielen Fällen Schnittstellen auf und verlagern manche Dinge von der Übersetzungszeit in die Laufzeit.

Vererbung ist nunmal die stärkste Form der Kopplung, und in Java kann man halt nur einmal erben, ist aber nicht neu...

Annotationen sind deiner Meinung nach schlecht, XML auch, aber Vererbung ist ok, oder wie?

Die Frage war, was Springs Dependency Injection mehr leistet als andere DI-Frameworks und nicht, was Spring noch so alles neben DI anbietet.

Nein, die Frage war:

Ich hinterfrage die Berechtigung von Spring DI und überlege, ob es nicht ohne einfacher oder besser wäre.

Ohne Spring DI aber dafür mit einem anderen Framework?
Das hatten wir doch schon, nimm doch ein anderes Framework wenn es dir nur um DI geht.
Was kann man denn bei so etwas simplen wie DI nochmehr bieten?
Ausser vielleicht was bei SEAM "Dependency Bijection" heisst.

Dein Link ist, wie tfa schon sagte, viel zu alt um überhaupt ernst genommen zu werden, das Thema hatte ich doch auch schon erklärt, um mich selbst zu zitieren:

Da bist du leider zu spät, die XML Konfigurationshölle ist schon vorbei, Spring setzt seit 2.5 mehr auf Annotationen und weniger auf XML, JEE 5 auch.

Aber ich sehe schon, dass wir irgendwie auf der Stelle treten

Nicht "wir" deamon, sondern du...