Die "besten" Java Frameworks, Libraries und Tools

Bestes Framework?
 Francis Mariani

Welche Java Frameworks, Libraries und Tools sind die "besten"? Welche gelten, noch ohne auf Spezifika der Projekte Rücksicht zu nehmen, als die "besten"? Welche sollte jeder Senior Java Entwickler beherrschen? Ist Hibernate "besser" als EclipseLink? Oder sollte man doch zu MyBatis oder gar JDBC greifen?

Leider wird bei der Frage nach den besten Technologien oft "beste" mit "persönlich liebste" verwechselt. Ich durfte schon in vielen Projekten mitarbeiten, wo nicht die besten, sondern die einem Entwickler / Architekten / Projektleiter / Auftraggeber persönlich liebsten Frameworks, Libraries und Tools eingesetzt wurden. Selbstverständlich wird da nie ehrlich mit persönlichen Vorlieben argumentiert, sondern meist mit Totschlagargumenten, die - forscht man ein wenig nach - sich meist in Luft auflösen.

Dabei ist es gar nicht so schwer die generell "besten" Java Frameworks, Libraries und Tools zu bestimmen. Dafür benötigt es nur folgende Erkenntnisse:

Die "wichtigsten" Java Frameworks, Libraries und Tools

Meist nachgefragte Java Skills
@joinvision.com

Welche Java Frameworks, Libraries und Tools soll man in einem Projekt einsetzen, welche muss man als Java Entwickler beherrschen? Welche sind ausgereift, welche sind state-of-the-art, welche sind zukunftssicher? Auf welche kann ich meine Software bauen, ohne befürchten zu müssen, dass ich mir damit Probleme wie Bugs, unausgereifte Features, ungenügender Support, fehlende Literatur, kaum vorhandenes Know-How oder Vendor-Lock-In einkaufe.

Die Frage, "welche sind die richtigen Frameworks, Libraries und Tools für ein Projekt", ist so einfach nicht zu beantworten. Ich widme ihr daher diesen und die nächsten beiden Blog Artikel:

Java Seniors - Fools with Tools?

Alt = Senior?
 lyzadanger

Was macht einen Java Senior aus? Diese Frage sollte sich jeder Java Recruiter, Manager und auch Entwickler stellen. Seniorität ist weit mehr als nur ein Mascherl, es sagt etwas darüber aus, welche Erwartungen man stellen darf und welche man erfüllen muss.
Folgende Eigenschaften muss ein Java Senior aber auf jeden Fall vorweisen können:

• Einige Jahre Erfahrung mit kommerzieller Java Entwicklung
• Erfahrung mit den wichtigsten Java Tools, Techniken und Frameworks
• Fähigkeit zwischen persönlichem Interesse und Sinnhaftigkeit für den Auftraggeber unterscheiden zu können
• Teamarbeit, Emotionale Intelligenz und Führung durch Vorbildwirkung

Oracle Java 7 Zertifizierungen

Oracle Certified Professional
 Sebastian Dietrich

Bei der Zertifizierung zum Java 7 Programmierer hat sich einiges geändert, weit mehr als sich in der Syntax von Java 6 auf Java 7 geändert hat. Klar war, dass mit der Übernahme von Java durch Oracle der Name auch angepasst wird. Vormals "Sun Certified Programmer for the Java Platform" heisst nunmehr "Oracle Certified Professional Java Programmer". Damit wird der bei Oracle typischen Einstufung der Zertifikate auf "Associate", "Professional", "Expert" und "Master" Ebene entsprochen.

Klarerweise wurde die Zertifizierung auch auf die neue Java Version umgestellt. Wobei sich bei der Syntax zwischen Java 6 und Java 7 nicht allzuviel geändert hat. "Simple" Fragen wie die folgende können aber auch alte Java Hasen vor ein Problem stellen (Antwort siehe ganz unten):

Kommunikationsstruktur sticht Architektur

Wer definiert die Architektur?
 M.C.Escher: "Relativiteit", Juli 1953

Quizfrage: Wer hat den größten Einfluss auf die Architektur einer Software?

• Die Enterprisearchitekten, die organisationsweite und softwaresystemübergreifende Entscheidungen treffen (wie z.B. die Einführung von SOA im gesamten Unternehmen)?
• Die Solutionsarchitekten, die die Architekturentscheidungen für applikationsübergreifende Softwaresysteme treffen (wie z.B. die Verwendung von Domain-Driven Design)?
• Die Applikationsarchitekten, die die Architektur der einzelnen Applikationen definieren (wie z.B. die Verwendung von Hibernate für den Zugriff auf die DB)?
• Die Entwickler, die die Architektur schlussendlich umsetzen - potentiell anders, als durch alle vorangegangenen Architekten definiert?

Falsch geraten. Gemäß des Gesetzes von Conway hat die Kommunikationsstruktur der die Software umsetzenden Organisation den größten Einfluss auf die Architektur der Software.

Raumaufteilung und Projekterfolg

Kommunikationsproblem à Projekterfolg?
 Pieter Bruegel der Ältere 1563

Wie schon Frederick Brooks im "Mythical Man Month" feststellte, scheitern Softwareentwicklungsprojekte reihenweise an Kommunikationsproblemen. Klare Zielvorstellungen, genügend Personal, Zeit und Geld, sowie state-of-the-art Werkzeuge und Frameworks helfen genauso wie beim Turmbau zu Babel nichts, wenn die Kommunikation nicht passt. Kommunikationsprobleme sind die Hauptursache dafür, dass ein großer Teil der Softwareentwicklungsprojekte scheitern.

Was aber ist Hauptverursacher für Kommunikationsprobleme? In den wenigsten Fällen liegt es an den handelnden Personen. Der immer wieder zitierte ungepflegte, langhaarige, bebrillte, introvertierte Informatiker ist seit längerem so gut wie ausgestorben. In den meisten Fällen ist die ungeeignete Kommunikationsstruktur des handelnden Unternehmens für die Kommunikationsprobleme verantwortlich. Und diese wiederum ist abhängig von der räumlichen Aufteilung der Projektmitarbeiter.

Java Architekten im Elfenbeinturm und Maulwurfshügel

Was sieht man von dort oben?
 - peperoni -

Java Architekten nennen sich viele, doch werden sie auch wirklich ihrer Rolle gerecht? Die einen fühlen sich zuständig für die Definition der High-Level-Architektur sämtlicher Software, die in ihrem Unternehmen entwickelt wird. Sie nennen sich selbst "Enterprise Architekt", andere nennen sie "Theoretiker" und behaupten sie säßen im Elfenbeinturm. Andere wiederum definieren die detaillierte Architektur einzelner Applikationen, deren Schichten, Komponenten, interne und externe Schnittstellen sowie zu verwendende Frameworks. Sie nennen sich selbst "Systemarchitekt" oder "Applikationsarchitekt", andere nennen sie "kurzsichtig" und "technologiegeil" und behaupten, sie sehen die Aufgaben vor lauter Tools nicht.

Architekten laufen Gefahr abzuheben (die Architektur ausschließlich aus der 10.000 Meter = applikationsübergreifenden Perspektive zu betrachten) oder unterzutauchen (die Architektur ausschließlich aus der Maulwurfs = Framework Perspektive betrachten).

Nein liebe Enterprise Architekten, SOA, MDA, Cloud-Computing sind keine Architekturkonzepte die einfach so und überall funktionieren, und liebe Applikationsarchitekten, Spring, OSGi, JSF ... sind keine Architekturkonzepte und bringen in der Praxis oft mehr Nachteile als Vorteile. Dogfooding und ein bisschen mehr Reflexion über den tatsächlichen Nutzen ihrer Architekturentscheidungen würde vielen Architekten gut bekommen.

Was macht gute Modultests aus?

Hohe Code-Coverage - gute Qualität?
 Sebastian Dietrich

Gute Modultests (engl. Unit-Tests) können einen Großteil der Fehler finden, die sich während der Entwicklung eingeschlichen haben. Üblicherweise geht man davon aus, dass mit Modultests 80 - 90% aller Fehler gefunden werden können. Dies ist jedoch nur dann möglich, wenn diese Modultests (wie Regressiontests) laufend ausgeführt werden und eine ausgezeichnete Qualität aufweisen.

Limbo mit Softwarequalität

Limbo mit Softwarequalität?

Was tun, wenn die technische Qualität einer Software zu wünschen übrig lässt, aber kein Budget vorhanden ist, die Qualität zu verbessern? Unternimmt man nichts, so wird die Qualität weiter sinken - bis die Kosten für Wartung und Weiterentwicklung so hoch sind, dass die Software aufgegeben werden muss. Oft ist aber kein Budget vorhanden um die Qualität zu verbessern - diese Projekte ähneln Hungerkatastrophen - sie leben von der Hand in den Mund wohlwissend, dass sie bald verhungern werden, wenn nicht ein Wunder passiert. In dieser Situation hilft nur eines: Limbo mit Softwarequalität.

Schuldentilgung

Technische Schulden à Pleitegeier?
 Adrian Korte

Nimmt man in einem Softwareprojekt Technische Schuld auf sich, so könnte man versucht sein diese ähnlich zu betrachten, wie private finanzielle Schulden. Doch im Gegensatz zu privaten Schulden gibt es keine Konten auf denen die Technische Schuld beziffert wird, keine halbwegs fixen Zinssätze, die bei Aufrechthaltung der Schulden zu zahlen sind, keine Umschuldungen oder Schuldentilgungspläne. Im Gegenteil: Das Ausmaß der Technischen Schuld ist meist unbekannt, gleichzeitig zahlt man dafür Wucherzinsen.