Fragen? Antworten! Siehe auch: Alternativlos
Die mußten unterwegs ihre Arbeitsgruppe umbenennen, weil die Leute ihnen auf die Schliche gekommen sind, und keinen Bock auf diesen Bullshit hatten! Wenn jemand einen Satz wie diesen hier von sich gibt:
JSR 299 bietet ein neues Set an Funktionen für Java EE. Grundlage ist eine Menge von definierten Lebenszykluskontexten.Da hilft doch nur noch Einschläfern! Wenn die so einen Satz sagen, fällt denen dann nicht selber auf, dass sie auf dem Holzweg sind? Beim Formulieren im Kopf meine ich jetzt?
Darauf aufbauend bietet der JSR Modularisierung, übergreifende Aspekte (Decorators und Interceptors) sowie typsicheres Injizieren von Objekten, alles Dinge, die Java-EE-Komponenten zu einer geschmeidigen Kooperation bewegen sollen.Wenn jemand soweit ist, dass er Decorators und Interceptors braucht und Objekte injizieren will, dann sollte man das Projekt in einem Glassarg im Ozean versenken, alle Kopien und Dokumente darüber vernichten, und neu anfangen. Sicherheitshalber würde ich außerdem für eine Sicherheitsverwahrung aller Beteiligten plädieren.
Schon der erste Satz räumt schon alle Zweifel aus, dass man solche Leute nicht Software entwickeln lassen darf:
Dependency Injection ist eine Anwendung des Inversion-of-Control-Prinzips (IoC) und als solches ein Entwurfsmuster für die objektorientierte Softwareentwicklung.Inversion of Control, ja? Lest euch mal bei Wikipedia durch, in was für einer Traumwelt die Leute leben:
Replacing systems will have no side effect on other systems.Nee, klar, so läuft das ja immer bei komplexen Systemen!1!! Und damit das so bleibt, packen wir noch ein bisschen mehr Komplexität oben drauf!
Guckt euch auch mal an, was sie da für Probleme zu lösen versuchen:
Dank dieser Konstruktion ist es erstmals möglich, EJBs als JSF Managed Beans einzusetzen.Mit anderen Worten lösen Sie da selbsterzeugte Probleme. Probleme, die sie dank verkackten Designs in vorigen Pseudotechnologien haben. Meine Fresse ist das alles eine Bankrotterklärung für Java. Unglaublich. Und wieder machen sie da XML-Metadaten, die man mitpflegen muss. Die lernen halt nicht aus ihren Fehlern. Na dann, guten Absturz, liebe Java-Leute.
Oooooder vielleicht verstehe ich ja auch einfach nicht genug von modernen OO-Dingen, um die Genialität hinter diesem ganzen Framework-Gedudel würdigen zu können. Will mir das vielleicht mal jemand erklären? Das müsste aber jemand sein, der ein größeres Projekt vorzuweisen hat, dass dank dieser Technik funktioniert und sonst nichts geworden wäre.
Update: Mir erklärt gerade jemand, dass sich hierunter im Wesentlichen eine Indirektionsschicht zwischen einer Klasse und dem Class Loader verbirgt. Die Klasse gibt die Instanziierung eines benutzten Interfaces komplett an das Framework ab. Für mich liest sich das genau wie ich oben meinte: eigentlich wollten sie Lisp-Closures haben, aber das kann die Sprache halt nicht, daher pfuschen sie sich jetzt eine Callback-Struktur zurecht. Und dadurch, dass man die Implementation nicht kennt, und die jemand anderes instanziiert, kann man auch nicht am Interface vorbeiarbeiten (was ja eigentlich schon durch das Interface selber verhindert werden sollte, aber offenbar nicht genug…?). Insgesamt scheint es bei Java ein Riesenproblem zu sein, anderer Leute Code benutzen zu müssen, ohne ihn anfassen zu können. Und die existierenden Komponenten müssen so furchtbare Modularitätsverletzungen haben, dass man das architekturell erzwingen muss in Java. Was bin ich froh, dass ich nicht in so einem Umfeld programmieren gelernt habe. Die Leute sind sicher für ihr Leben gezeichnet und werden nie ordentlichen Code schreiben können.
Update: Mir mailt gerade jemand völlig zu Recht diesen Link, der schön illustriert, was hier gerade passiert (Spalte 1, Zeile 2).