Die Details kann man überall nachlesen, und ausprobieren kann der geneigte Leser den WildFly auch direkt nach dem Download durch einfaches Auspacken einer ZIP-Datei. Aber wie genau sieht denn der WildFly aus?
Die Neuigkeit ist schon ein paar Tage alt: Red Hat hat mit dem WildFly 8 den Nachfolger des JBoss AS 7 vorgestellt. Neben der Namensänderung ist die unterstützte Java-EE-Spezifikation das eigentliche Highlight. Nun kann Red Hat auch offiziell das „certified Java EE 7“-Logo führen und damit womöglich dem Oracle-eigenen GlassFish den finalen Todesstoß versetzen.
Die Liste der Neuerungen ist lang. Undertow als neuer Webserver könnte dabei die größte Änderung bedeuten. Auch für Administratoren wird das Leben einfacher, da der neue Server die blockierten Ports reduziert. Natürlich gehören auch Anpassungen zur Lauffähigkeit mit dem bald verfügbaren Java 8 dazu. Die komplette Liste der Änderungen findet sich in der Release-Bekanntmachung.
Ein anderer Blickwinkel
Es gibt diverse Möglichkeiten, Software darzustellen. Diese Darstellungen wurden entwickelt, um große Projekte auf einfache Art und Weise mit beispielsweise Metaphern navigierbar zu machen.
Eine der bekannteren ist die Stadt-Methapher. Das wohl bekannteste Werkzeug ist hier Codecity, ein schon etwas in die Jahre gekommenes Smalltalk-Programm, das ein proprietäres Intermediate-Format (MSE) verwendet, um aus Sourcecode Städte zu zeichnen. Was früher noch problemlos mit freier Software aus Java-Sourcen erstellt werden konnte, erzeugt heute nur noch inFusion Hydrogene in der kommerziellen Variante. Ich habe eine Testlizenz gestellt bekommen und konnte die WildFly-8-Sourcen aus dem GitHub-Repository entsprechend verarbeiten und exportieren. Fertig gerendert sieht der WildFly dann als Stadt folgendermaßen aus:
WildFly 8 Source Code als Stadt visualisiert 
Bild: Markus Eisele
Der grün umrandete Bereich verdeutlicht die Teile, die noch unter dem Package-Namen org.jboss.* sind. Die kleine Ecke rechts unten entspricht den Teilen, welche mit org.wildfly.* beginnen. In der Skyline-Perspektive kann man besonders die hohen Gebäude gut erkennen:
Skyline Ansicht der WildFly Stadt
Bild: Markus Eisele
Hohe, schlanke Gebäude sind Klassen mit vielen Methoden und wenigen Attributen. Die Antenne im linken Bereich ist die EjbMessages-Klasse. Schaut man aus der Draufsicht auf die Stadt und packt auch alle Test-Klassen mit in die Untersuchung, dann stellt sich das Bild so dar:
WildFly Stadt in der Draufsicht mit Tests
Bild: Markus Eisele
Spätestens hier wird auch klar, dass der Code im WildFly-Repository eigentlich nicht der komplette Server ist, sondern nur das Hauptprojekt. Alle notwendigen Implementierungen für weitere Spezifikationen wie Weld, Hibernate und andere sind hier gar nicht enthalten.
Ein paar Metriken
InFusion wurde zur Beurteilung der Softwarequalität entwickelt. Daher sei mir ein kurzer Blick auf die Befunde hier gestattet. Der WildFly Kern hat 626.388 Lines of Code (einschließlich Kommentaren und Leerzeichen). Die sogenannte Metrik-Pryramide von inFusion gibt einen guten Indikator für die Bewertung der Code-Basis im Vergleich mit den Ergebnissen anderer Open-Source-Projekte.
iPlasma Pyramide
Bild: Markus Eisele
Klassenhierarchien sind hoch und weit, Vererbung wird ausgiebig verwendet, und Klassen haben viele Basisklassen mit vielen direkt abgeleiteten Klassen. In Summe sind die Klassen vergleichsweise klein, haben also wenige Methoden und befinden sich in durchschnittlich großen Packages. Die Methoden wiederum sind durchschnittlich in der Länge und enthalten durchschnittlich komplexe Logik. Sie verwenden allerdings viele Methoden aus anderen Klassen. Fazit: Die Softwarequalität ist durchaus respektabel und entspricht den Erwartungen an ein Serverprodukt bzw. Framework. Wer ein wenig mehr hinter der Theorie verstehen möchte, dem kann ich meinen Blog-Eintrag zum Thema Qualität bei JSF Libraries empfehlen.
Eine komplette Bewertung der Ergebnisse möchte ich hier gar nicht vornehmen. Mir ging es in diesem Post in erster Linie um die schönen Stadtvisualisierungen. Natürlich sind auch ein paar Code-Probleme vorhanden. Die Themen Komplexität und Kopplung sind dabei vergleichsweise stark ausgeprägt. Aber auch das spielt für die Anwender von Produkten weniger eine Rolle als für die Hersteller. Für Anwender ist es viel aussagekräftiger, die Arbeit am Code zu bewerten. Und da steht das WildFly-Projekt in gleicher Linie wie viele Open-Source-Projekte, welche von Red Hat verantwortet werden. Allein im letzten Monat haben 50 Autoren an 1283 Dateien gearbeitet und drei Issues behoben.
Screenshot GitHub Pulse
Bild: https://github.com/wildfly/wildfly/pulse/monthly
Der Vergleich mit dem GlassFish ist leider nicht so einfach und transparent möglich, da JIRA keine so schönen Auswertungen bereitstellt und eine Auswertung des SVN nicht so schön einfach ist. Aber vielleicht finde ich dafür ja bald mal Zeit.
News Magazin Nachrichten Magazin