Im Rahmen dieses Vortrags von der JAX 2017 stellt Michael Plöd die Patterns auf Basis einer einfachen Spring-Boot-basierten Anwendungslandschaft vor. Hierbei geht er unter anderem auf folgende Patterns ein: Customer/Supplier, Open Host Language, Anti-Corruption Layer, Conformist oder Separate Ways.

Spring Boot als Beispiel für DDD Strategic Design from JAX TV on Vimeo.

The post Spring Boot als Beispiel für DDD Strategic Design appeared first on JAX.

Datenarchitekturen nicht nur für Microservices from JAX TV on Vimeo.

Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u. a. zu Continuous Delivery und Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps, Microservices und NoSQL.

The post Datenarchitekturen (nicht nur) für Microservices appeared first on JAX.

Die verborgenen Schätze der Java-Plattform

Programmiersprachen sind das Salz in der Suppe eines jeden Entwicklers. Wer der Java-Plattform die Treue hält, wird mit einer riesigen Vielfalt an Sprachen belohnt, die die verschiedensten Programmierparadigmata abdecken: von der Objektorientierung bei Java, JRuby oder Ceylon über die funktionale Programmierung mit Clojure, Frege oder Erjang, bis hin zu dynamischem Scripting mit Groovy, Jython oder Nashorn.

Einen Überblick über die Sprachen-Landschaft der Java-Plattform bietet die Infografik Pirates of the JVM. Hier finden sich zur Orientierung die verschiedenen Sprachen-Inseln in ihren jeweiligen Paradigmen-Ozeanen – und, mit einem dicken Augenzwinkern versteht sich, alle Details zu Entdeckern, klimatischen Verhältnissen und Population der Sprachen.

Pirates of the JVM – das Gewinnspiel

Auf der Infografik tummeln sich so manche JVM-Piraten – erkennen Sie welche? Dann wird es Ihnen nicht schwer fallen, das untere Rätsel zu lösen!

Zu gewinnen gibt es:

1. Preis: Das Video-Tutorial “Microservices” von entwickler.tutorials.de
2. Preis: Buch: IT Survival Guide 3. Auflage
3. Preis: 1 Magazin digital – freie Auswahl im Kiosk

Tragen Sie die Namen der gesuchten Personen in die Kästchen ein. Als Lösungswort ergibt sich in der roten Vertikalen ein Programmierkonzept, das momentan besonders en vogue ist…

[contact-form-7]

Tipp: Schauen Sie zur Lösung des Rätsels doch ab und zu auf die unten aufgeführte Infografik…

Viel Spaß mit den JVM-Piraten und viel Glück beim Gewinnspiel! Einsendeschluss ist der 19. April.

Pirates of the JVM – die Infografik

The post Pirates of the JVM – das Gewinnspiel appeared first on JAX.

JAXenter: Hallo Rafael! Auf GitHub bezeichnest du dich als “Software Consultant who likes static types”. Das statische Typensystem in Java scheint es dir also angetan zu haben – so sehr, dass du das Projekt Byteboddy gestartet hast, um Java dynamischer zu machen Was findest du am Java-Typensystem gut – was stört dich daran?

Rafael Winterhalter: Grundsätzlich empfinde ich Javas Typensystem als eines der pragmatisch besten, das ich kenne. Durch die durchgehend statische Typisierung kann man meistens sehr einfach auch durch unbekannte Java-Anwendungen navigieren, was es sehr einfach macht, sich mit einem Programm bekannt zu machen. Das hilft oft beim Onboarding neuer Entwickler, was meiner Meinung nach Java als Enterprise-Sprache erfolgreich macht.

Gleichzeitig ist Javas Typensystem einfach zu lesen, gerade weil Javacode teils ein bisschen weitschweifiger ist als andere Sprachen. Diese Explizität macht Java-Programme nach meiner Erfahrung oft sehr ausdrucksstark.

Kritik kann man vielleicht an der mangelnden Flexibiliät des Typsystems üben. Gerade generische Typen könnten natürlich in einer erweiterten Form umfangreichere Typensicherheit zulassen. Aber diese zusätzlichen Mittel würden mit einem hohen Preis kommen, gerade für beginnende Javaentwickler, denen viel Code nicht mehr zugänglich wäre.

Making Java more dynamic

JAXenter: Auf der JAX hältst du eine Session zum Thema „Making Java more dynamic.“ Darin bringst du die Möglichkeit der Code-Generierung zur Laufzeit ins Spiel. Wie genau funktioniert das?

Rafael Winterhalter: Die Java Virtual Machine führt ja eigentlich keine Java-Programme aus, sondern verarbeitet sogenannten Java Bytecode. Dieser ist ein wenig technischer aufgebaut als die Sprache Java, ist in seiner Struktur aber relativ einfach. Byte Buddy generiert dabei zur Laufzeit Java-Programme mittels einer API statt einen Compiler anzubieten. Diese Java-Klassen werden dann ins laufende Programm geladen, um dessen Verhalten zu verändern.

Dies ist manchmal notwendig, um zum Beispiel Proxies zu generieren. Solche lassen sich mit dem Compiler nur schwer erzeugen, unter anderem wegen Javas Typsystem. Weiterhin ist es möglich, existierenden Code mittels sogenannter Java-Agenten umzuschreiben. Das ermöglicht es, Anwendungen zu erweitern, ohne diese neu zu kompilieren. Dieses Verfahren nutzen beispielsweise APM-Tools, um Metriken zur Laufzeit zu sammeln.

1. Class&lt<?> dynamicType = new ByteBuddy()
2.     .subclass(Object.class)
3.     .method(ElementMatchers.named("toString"))
4.     .intercept(FixedValue.value("Hello World!"))
5.     .make()
6.     .load(getClass().getClassLoader())
7.     .getLoaded();
8.    
9.   assertThat(dynamicType.newInstance().toString(), is("Hello World!"));

The post „Das Typensystem von Java ist eines der pragmatischsten, das ich kenne“ appeared first on JAX.

Das Release von Java 9 ist für den 27. Juli 2017 vorgesehen. Mit Version 8 hat Java eine Menge neuer Features bekommen, von denen sicherlich die Unterstützung von Lambdas die weitesten Kreise gezogen hat. Aber auch die dadurch möglichen Bulk Operations auf Collections und das neue Date-Time-API verbessern das tägliche Leben des Java-Entwicklers. Ein lange gewünschtes Feature hat es allerdings nicht mehr in Java 8 geschafft und soll nun das Markenzeichen der kommenden Version 9 werden – die Modularisierung mit Project Jigsaw.

Project Jigsaw soll zwei Probleme angehen, unter denen Java bisher leidet, die JAR-Hölle und das Fehlen eines starken Kapselungsmechanismus oberhalb von Klassen. Von Anfang hatte Java ein Package-Konstrukt. Eine Klasse kann innerhalb eines Pakets eine von zwei Sichtbarkeiten haben. Entweder sie ist public, dann kann von überall auf die Klasse zugegriffen werden. Wenn sie nicht public ist, kann nur von innerhalb des Packages auf sie zugegriffen werden. Aber Packages können nicht geschachtelt werden. Das führt dazu, dass man entweder unstrukturierte große „Big Ball of Mud“-Pakete hat oder solche, die nur aus öffentlichen Klassen bestehen. JARs (Java Archives) wiederum sind nur eine Menge von komprimierten Class-Dateien plus Daten. Sie sind keine Komponenten und bieten keine Kapselung. Deshalb haben sie auch keine Schnittstelle oder besser gesagt ist die Schnittstelle eines JARs alles, was das JAR enthält. Denn es kann ja wegen fehlender Kapselung nichts vor dem Zugriff von außen verstecken. Mit Version 9 erhält Java die Möglichkeit, Module zu definieren. Ein Modul ist eine benannte, selbstbeschreibende Programmkomponente, die aus einem oder mehreren Paketen (und Daten) besteht. Module lassen sich wie in Listing 1 definieren.

Listing 1: Ein Java-Modul"]module de.modul.a {
exports de.modul.a.paket.x;
}
module de.modul.b {
exports de.modul.a.paket.y;
exports de.modul.a.paket.z;
}
module de.modul.c {
requires de.modul.a;
requires de.modul.b;
}

Mit dieser Schnittstellendefinition wird bekanntgegeben, welche Packages ein Modul nach außen anbietet (mit dem Schlüsselwort exports) und welche Module es von außen benötigt (mit dem Schlüsselwort requires). Achtung: Das ist kein Tippfehler im vorherigen Satz; ein Modul exportiert Packages, benötigt aber Module. Das kann auf den ersten Blick verwirrend sein, da Pakete und Module per Konvention gleiche oder sehr ähnliche Namen haben. Alle Pakete eines Moduls, die nicht explizit exportiert werden, lassen sich nur innerhalb des Moduls verwenden. Wird versucht von außerhalb des Moduls auf sie zuzugreifen, kommt es zu einem Compilerfehler.
modulares JAR (engl. modular JAR) zu erzeugen. Es ist wie eine herkömmliche JAR-Datei aufgebaut, mit dem Unterschied, dass es eine Datei module-info.class in seinem Wurzelverzeichnis hat. So ein modulares JAR lässt sich als Modul verwenden. Aus Gründen der Abwärtskompatibilität kann es auch als klassisches JAR-File und in einem classpath zum Einsatz kommen. Dann wird die module-info.class einfach ignoriert. Apropos classpath: Mit der Einführung des Modulkonzepts wird er durch einen modulepath ersetzt. Im modulepath kann dann angegeben werden, wo im Dateisystem bestimmte Module gefunden werden können.

Der Core JAVA & JVM Languages Track auf der W-JAX 2018

Früher hatte man einen classpath mit einem Haufen ungeordneter JARs, die sich unkontrolliert gegenseitig benutzen konnten. Außerdem durfte auf alles innerhalb der JARs zugegriffen werden. Nun können wir mit dem Modulmechanismus klar definieren, welches Modul welche anderen Module verwenden soll und kann. So wird es auch endlich möglich, mehrere Versionen der gleichen Bibliothek parallel zu verwenden. So kann ein Modul A die Bibliothek in Version 1 nutzen, Modul B in Version 2 und schließlich das Modul C die beiden Module A und B.

Java 9: Architektur endlich in der Sprache ausdrücken

Mit dem Modulkonzept kann man die Architektur von Software viel besser ausdrücken. So können z. B. Schichten als Module dargestellt und ihre Schnittstellen klar definiert werden. Architekturverletzungen kann zumindest teilweise schon der Compiler finden und verhindern. Betrachten wir als Beispiel eine Bankanwendung, die mit Domain-driven Design entworfen ist (Listing 2 und Abb. 1).

Listing 2: Beispiel Bankanwendung"]module de.wps.bankprogramm.domainLayer {
exports de.wps.bankprogramm.domainLayer.valueObject;
exports de.wps.bankprogramm.domainLayer.entity;
}
module de.wps.bankprogramm.infrastructurelayer {
exports de.wps.bankprogramm.infrastructureLayer.database;
}
module de.wps.bankprogramm.applicationLayer {
requires de.wps.bankprogramm.infrastructureLayer;
requires de.wps.bankprogramm.domainLayer;
exports de.wps.bankprogramm.applicationLayer.repositories;
}
module de.wps.bankprogramm.uiLayer {
requires de.wps.bankprogramm.domainLayer;
requires de.wps.bankprogramm.applicationLayer;
}

Hier sind die vier Schichten des Systems als Module implementiert. Das Modul der Fachlogikschicht (d. h. das Modul domainLayer) ist so deklariert, dass es keine Abhängigkeiten zu anderen Modulen hat. Wir wollen unseren fachlichen Code ja nicht mit Abhängigkeiten zu technischem Code verschmutzen. Es enthält ein Paket für die entities unseres Systems und eines für seine value objects. Die repositories wiederum dürfen auf die Infrastrukturschicht (Modul infrastructureLayer) zugreifen. Deshalb sind sie in diesem Entwurf in das Modul der Anwendungsschicht (applicationLayer) gesteckt. Dieses darf nach obiger Deklaration auf Infrastruktur- und Fachlogikschicht zugreifen. Die Oberflächenschicht (Modul uiLayer) darf dann auf Fachlogik- und Applikationsschicht zugreifen. Eine Nutzung des Pakets mit dem Datenbankzugriffcode würde einen Compilerfehler ergeben, weil dieser im Infrastrukturpaket liegt und es nicht in den requires von uiLayer angegeben wurde. Die Zuordnung der repositories in die Anwendungsschicht ist architektonisch nicht ganz sauber, wurde hier aber vorgenommen, um das Beispiel nicht zu kompliziert zu machen.

Das JDK zerlegt sich selbst

Der Modulmechanismus ist für viele Projekte interessant, insbesondere aber auch für das JDK selbst. Daher kommt auch der Name des Projekts, der auf Deutsch „Stichsäge“ lautet. Und genau mit dieser Stichsäge soll Java auch in Module aufgeteilt werden. Denn bisher muss immer das ganze JRE ausgeliefert werden, auch wenn nur kleine Programme laufen sollen, die z. B. vielleicht gar kein GUI haben oder nicht auf eine Datenbank zugreifen. Mit Java 9 werden JRE und JDK selbst in Module zerlegt. So kann jedes Programm definieren, welche es benötigt, und Speicherverbrauch verringern und Performance erhöhen.

Verschiedene solcher Java-Standardmodule sind geplant, z. B. java.base, java.sql, java.desktop und java.xml. Klar ist jetzt schon, dass java.base immer implizit eingebunden wird – so wie das Package java.lang nicht extra importiert werden muss. Das Modul java.base wird u. a. die Pakete java.lang, java.math und java.io enthalten. Für die Module des JDK selbst reichen JAR-Dateien nicht aus, denn sie müssen z. B. auch nativen Code enthalten. Deshalb wurden hier die so genannten JMOD-Dateien eingeführt. O-Ton Mark Reinhold, Chefarchitekt von Java: „JMOD files are JAR files on steroids.“ Project Jigsaw ist sicherlich die große Änderung, die mit Java 9 kommen wird, und ihr Markenzeichen. Aber es gibt auch noch eine ganze Reihe weiterer Features, die das Entwicklerleben verbessern werden.

Was passiert sonst noch in Java 9?

Viele Programmiersprachen haben eine Read-Eval-Print-Loop (kurz REPL), d. h. eine Art Kommandozeile, die direkt Code in dieser Sprache ausführt und das Ergebnis ausgibt. Java hatte so etwas bisher im Standard-JDK nicht. Es gibt Third-Party-Produkte wie BeanShell oder Java REPL und ein Plug-in für IntelliJ IDEA. Das Projekt Kulla führt nun die JShell ins JDK ein – die offizielle REPL für Java. Damit erhofft man sich, dass sich Java leichter lernen lässt. Denn ein interaktiver Modus kann dem Programmierer viel schnelleres Feedback geben als der klassische Schreiben-/Kompilieren-/Ausführen-Zyklus. Es wird ein CLI-Programm jshell für die Kommandozeile geben. Außerdem soll ein API bereitgestellt werden, damit auch andere Anwendungen diese Funktionalität verwenden können. Dies ist insbesondere für die IDE-Hersteller interessant, welche die JShell in Eclipse, NetBeans und Co. einbauen können.

Der Core JAVA & JVM Languages Track auf der W-JAX 2018

Unterstützt Unicode

Um die Zeichen verschiedener Sprachen zu kodieren, existiert Unicode. Der Standard wird laufend erweitert, und Java fehlt bisher die Unterstützung für die letzten beiden Releases 7.0 und 8.0. Unicode 7.0 enthält u. a. Verbesserungen für bidirektionale Texte, also solche, die Abschnitte sowohl in lateinischer als auch in nicht lateinischer Schrift enthalten. Mit Version 8.0 werden z. B. die Emojis um Smileys in verschiedene Hautfarben und neue Gesichter wie das der Weihnachtsfrau (Mother Christmas) erweitert. Des Weiteren schafft ein eigener JEP (Nr. 226) die Möglichkeit, Property-Dateien in UTF-8 zu speichern. Bisher wurde nur ISO 8859-1 als Encoding unterstützt. Dazu wird das RessourceBundle-API erweitert.

Bequeme Collections erzeugen

Möchte man mehrere Objekte zusammen definieren, so geht das mit einem Array einfach.

String[] vornamen = { "Hinz", "Kunz", "Fritz" };

Mit Collections ist es bisher leider nicht so einfach möglich. Um eine kleine unveränderliche Collection zu erzeugen, muss sie konstruiert und zugewiesen werden, dann die Element hinzugefügt und schließlich ein Wrapper drumherum gebaut werden.

List<String> vornamenListe = new ArrayList<>();
vornamenListe.add("Hinz");
vornamenListe.add("Kunz");
vornamenListe.add("Fritz");
vornamenListe = Collections.unmodifiableList(vornamenListe);

Statt einer Zeile Quellcode haben wir hier auf einmal fünf. Außerdem kann man es nicht als einen einzelnen Ausdruck ausdrücken. Es gibt verschiedene Alternativen, z. B. mit Arrays.asList(). Aber wenn man damit eine Menge definieren will, wird es doch wieder ziemlich lang:

Set<String> vornamenMenge = Collections.unmodifiableSet(
new HashSet(Arrays.asList("Hinz", "Kunz", "Fritz")));

Deshalb werden mit Java 9 Bequemlichkeitsmethoden eingeführt, mit denen sich Ähnliches leichter ausdrücken lässt.

List<String> vornamenListe = List.of("Hinz", "Kunz", "Fritz");

Mithilfe von varargs wird es möglich sein, eine verschiedene Anzahl von Parametern an diese Fabrikmethoden zu übergeben. Diese Funktionalität wird für Set und List angeboten und in ähnlicher Form auch für Map. Durch die erst mit Java 8 eingeführten Methodenimplementierungen in Interfaces, den so genannten Default-Methoden ist es möglich, diese Bequemlichkeitsmethoden direkt in den Interfaces List, Set und Map zu definieren.

HTTP/2 ist mit dabei

HTTP, das Protokoll zur Übertragung von Webseiten, wurde in seiner aktuellen Version 1.1 schon 1997 verabschiedet. Erst 2015 wurde dann die neue Version 2 zum Standard erhoben. Ziel der neuen Fassung ist die Verringerung der Latenz, um so zu ermöglichen, dass Webseiten schneller geladen werden können. Dies wird durch verschiedene Techniken erreicht:

• Kompression der Header
• Server-Push
• Pipelining
• Multiplexen von mehreren HTTP-Requests über eine TCP-Verbindung

Dabei bleibt die Kompatibilität zu HTTP 1.1 gewahrt. Große Teile der Syntax bleiben sogar unverändert; so z. B. die Methoden (GET, PUT, POST usw.), der URI, Statuscodes und Headerfelder.

Java wird mit der Implementierung von JEP 110 Out-of-the-box-Unterstützung von HTTP/2 erhalten. Außerdem wird das veraltete HttpURLConnection-API ersetzt. Es entstand noch zu Zeiten von HTTP 1.0 und hat einen protokollagnostischen Ansatz gewählt. Das passte in die Neunziger, als noch nicht klar war, wie erfolgreich HTTP sein würde. Heutzutage ist allerdings Unterstützung für beispielsweise Gopher weniger wichtig. Des Weiteren soll ALPN unterstützt werden. In der neuen Welt kann man dann ein zeitgemäßes Fluent-API verwenden.

HttpResponse response = HttpRequest
.create(new URI("http://www.javamagazin.de")
.body(noBody())
.GET()
.send();

An der so erhaltenen HTTP-Antwort können dann Statuscode und Inhalt abgefragt werden:

int statusCode = response.responseCode();
String body = response.body(asString());

Kompakte Strings brauchen weniger Speicher

Seit Version 1 werden Zeichenketten in Java mithilfe der Klasse java.lang.String dargestellt. Von Anfang an enthielt diese Klasse ein Array von char. Dieser Datentyp belegt in Java zwei Bytes. So lassen sich Zeichen in UTF-16 bequem darstellen und es wird nicht nur das lateinische Alphabet unterstützt. Allerdings werden in vielen Anwendungen nur Zeichen aus der Kodierung Latin-1 verwendet, die nur ein Byte benötigen. Hier ist jedes zweite Byte leer und vergeudet Speicherplatz. JEP 254 führt daher eine Implementierung der String-Klasse ein, die statt eines char-Arrays ein byte-Array plus ein Kodierungsfeld enthält. In dem Kodierungsfeld wird angegeben, ob der String entweder eine klassische Reihenfolge von UTF-16-Zeichen enthält, die jeweils zwei Bytes belegen, oder ob er eine Reihe von Latin-1-Zeichen enthält, die dann nur jeweils ein Byte belegen. In welcher Kodierung der jeweilige String angelegt wird, soll automatisch am Inhalt der Zeichenkette erkannt werden.

Das Angenehme an dieser Optimierung ist, dass man ganz automatisch davon profitiert. Es handelt sich nämlich um ein reines Implementierungsdetail, das hundertprozentige Kompatibilität mit alten Java-Versionen wahrt. Anwendungen, die viele Strings verwenden, werden so ihren Speicherbedarf deutlich senken – und das durch einfaches Installieren der neuesten Version von Java. Dazu werden neben der Klasse String auch verwandte Klassen wie StringBuilder und StringBuffer sowie die HotSpot VM angepasst.

Erweiterungen an JavaDoc

Aus Javadoc wird bisher HTML in der in die Jahre gekommenen Version 4.01 erzeugt. Mit Java 9 wird es möglich sein, auch HTML5 zu erzeugen. Dazu soll das Kommando javadoc einen Switch erhalten, mit dem die Version des generierten HTML-Codes angegeben werden kann. Ausdrückliches Nichtziel (non-goal) des zugehörigen JEP 224 ist es, die Struktur mit den drei Frames abzuschaffen. Bleibt zu hoffen, dass das mit einer zukünftigen Fassung geschehen wird. Des Weiteren sollen die generierten HTML-Seiten einen Suchmechanismus bekommen, mit dem nach bestimmten Java-Elementen gesucht werden kann. Die Ergebnisse werden dann kategorisiert z. B. nach „Modules“, „Package“ oder „Types“.

HiDPI-Grafiken: Anzeige skaliert automatisch

Auf dem Mac unterstützt das JDK bereits Retina-Displays, unter Linux und Windows bisher nicht. Dort sehen Java-Programme auf den aktuellen hochauflösenden Bildschirmen unter Umständen so klein aus, dass sie sich nicht verwenden lassen. Das liegt daran, dass auf diesen Systemen Pixel zu Größenberechnung verwendet werden – unabhängig davon wie groß ein Pixel tatsächlich ist. Und der Witz von hochauflösenden Displays ist eben, dass Pixel sehr klein sind. JEP 263 erweitert das JDK so, dass auch unter Windows und Linux die Größe von Pixeln berücksichtigt wird. Dazu werden modernere APIs als bisher verwendet: Direct2D unter Windows und GTK+ statt Xlib unter Linux. Damit werden Fenster, Grafiken und Text automatisch skaliert. JEP 251 schafft außerdem die Möglichkeit, so genannte Multi-Resolution Images zu verarbeiten, d. h. Dateien, die dasselbe Bild in unterschiedlichen Auflösungen enthalten. Abhängig von der DPI-Metrik des aktuellen Bildschirms wird dann das Bild in der jeweils passenden Auflösung verwendet.

Was sonst noch kommt

Wie jedes Java-Release enthält auch das mit der Version 9 eine Reihe von Kleinigkeiten und Aktualisierungen. Dazu gehören:

• Die neue ARM-Architektur AArch64, die ARM-Prozessoren in die 64-Bit-Architektur hebt, wird nun unterstützt.
• Java benutzt seit Version 1.2 ein proprietäres eigenes Format, mit dem kryptografische Schlüssel gespeichert werden können: JKS. JEP 229 führt nun das Standarddateiformat PKCS12 in Java ein.
• Update 40 von Java 8 führte den Garbage Collector G1 (Garbage First) ein. Java 9 erhebt G1 nun in den Status des Standard-Garbage-Collectors.
• Bis Java 8 unterstützt das Image-I/O-Framework nicht das Bildformat TIFF. Das wird mit JEP 262 geändert und javax.imageio entsprechend erweitert.
• Mit Nashorn hat Java eine JavaScript-Ausführungsumgebung. Für IDEs und ähnliche Werkzeuge wird mit JEP 236 das bisher nur intern verfügbare API des Parsers für Zugriffe auf den AST öffentlich gemacht.
• Seit zwanzig Jahren beginnt die interne Versionsnummer von Java mit 1. Das soll nun geändert werden.

Fazit und Ausblick

Ursprünglich sollte dieser Artikel beginnen mit: “Im September 2016 wird die neue Java Version 9 erscheinen.” Doch wurde der Release-Termin von Java 9 mittlerweile auf Juli 2017 verschoben. Das ist sicher zu verschmerzen, denn viele der Änderungen fallen in die Kategorie „Housekeeping“. So werden dann die aktuellen Versionen der Standards Unicode und HTTP unterstützt. Außerdem gibt es kleinere Änderungen, die das Entwicklerleben vereinfachen, wie das bequeme Erzeugen von Collections und die Implementierung von kompakten Strings.

Das wichtigste Feature ist ganz klar das Modulkonzept von Jigsaw. Davon profitieren werden vor allem große Projekte und solche, bei denen der Speicherbedarf eine Rolle spielt. Große Projekte, weil erstens das Problem der JAR-Hölle mit dem ModulePath gelöst wird und zweitens die Architektur dieser Systeme mit Modulen klarer ausgedrückt werden kann. Speichersensitive Projekte profitieren, weil das JDK selbst in Module aufgeteilt wird und nicht mehr als Monolith im Ganzen geladen werden muss.

Spannend ist auch der Blick auf das, was nach Java 9 kommen wird. Als größtes Feature sind für Java 10 Value Types angekündigt. Damit werden benutzerdefinierte Werttypen möglich. Aber erstmal freuen wir uns auf Java 9!

The post Java 9: neuer, toller, bunter? appeared first on JAX.

Die Umfrage war einen Monat lang Online auf JAXenter.de und JAXenter.com verfügbar und gliederte sich in 10 Teilbereiche:

• Programmiersprachen
• UI Technologien
• Web Frameworks
• Microservices / Dev Frameworks
• Cloud Platforms / Technologies
• Continuous Delivery & Automatization
• DevOps, Container & Service Discovery
• Data Storage & Processing
• Software Architecture
• More & mixed things

Wir schauen uns die Ergebnisse diese Woche im Detail an – und beginnen heute mit den Programmiersprachen.

Der Core JAVA & JVM Languages Track auf der JAX 2017

Programmiersprachen-Trends 2017

Die Teilnehmer der Umfrage waren aufgerufen, die Relevanz verschiedener Technologien auf einer Skala von 1 (sehr interessant) bis 5 (gar nicht interessant) zu bewerten. Bei den Programmiersprachen zeichnete sich deutlich das Bild ab, dass eine Beschäftigung mit Java ganz vorne in Ihrer To-do-Liste für 2017 steht.

Zählen wir die Abstimmungen für “Very interesting” und “Interesting” zusammen, so landet Java 9 im Gesamtergebnis auf Platz 1 dicht gefolgt von Java 6/7/8.

Der Sieger “Java 9” lässt eine große Neugier an der neuen Java-Version erkennen, die bekanntlich im Juli 2017 erscheinen wird. Nun ist dieses Ergebnis auf einem Portal mit Java-Schwerpunkt sicherlich nicht verwunderlich. Interessant deshalb sind die danach folgenden Platzierungen. So legen die Plätze 3 und 4  – JavaScript und TypeScript – nahe, dass JavaScript auch in der Java-Welt längst Fuß gefasst hat.

Scala ist die relevanteste JVM-Sprache nach Java. Dicht gefolgt dann aber schon vom Shooting-Star Kotlin! Noch vor Go, DSLs, Python, Groovy und Rust reiht sich Kotlin auf dem 6. Platz ein – bemerkenswert.

Lesen Sie auch: Kotlin: Ein Tutorial für Einsteiger

Vergleich zu 2016

Im letzten Jahr hatten wir Kotlin noch gar nicht auf dem Radar – deshalb fehlte die Sprache in der Umfrage 2016. Ansonsten ist im Vergleich zur aktuellen 2017-Umfrage auf den vorderen Plätzen wenig Bewegung zu sehen. 2016 lautete die Top 5: Java 8, Java (general), JavaScript, TypeScript, Scala.

Vergleicht man die Umfragen, so kann man einen Aufwärtstrend für Google Go und Mozilla Rust feststellen. Beide Sprachen konnten 2017 Plätze gut machen. Den Sprachen Dart, PHP, (J)Ruby und Perl stehen Sie weniger gewogen gegenüber.

Lesen Sie auch: Die Top-17-Programmiersprachen: Nachfrage und Gehalt

Demografisches

An der Umfrage haben sich 926 Personen beteiligt. Das Gros der Teilnehmer verfügt über mehr als 10 Jahre Berufserfahrung im Programmieren, ist zwischen 31 und 50 Jahren alt und männlich.

Die Umfrage war international ausgelegt. Demografisch bewegen sich die Daten indes zu 39,3% in der DACH-Region:

The post Programmiersprachen – Das sind die Trends 2017 appeared first on JAX.

Für IT-Profis steht die Welt nie still: Neue Technologien gibt es immer zu entdecken, vorhandenes Wissen auszubauen, Lücken zu schließen. In unserer Jahresumfrage wollen wir deshalb herausfinden, mit welchen Sprachen, Tools und Architektur-Themen Sie sich 2017 verstärkt beschäftigen möchten.

Nehmen Sie sich 5 Minuten Zeit und bewerten Sie die unteren Technologien und Trends nach ihrer Relevanz für Sie im Jahr 2017!

Wir sind gespannt auf Ihre ganz persönlichen Technologie-Trends 2017!

The post Mit welchen Sprachen, Frameworks & Tools wollen Sie sich 2017 beschäftigen? appeared first on JAX.

Der Flexibilisator

Der Flexibilisator implementiert seine Komponenten oder Systeme am liebsten so: generisch, möglichst auf viele zukünftige Gegebenheiten vorbereitet, universell einsetzbar und grenzenlos flexibel in alle Richtungen. Er findet den ultimativen Kick, wenn er über den beschränkten Spezialfall der aktuellen User Story hinaus quasi ein zeitloses Denkmal der Flexibilität erschaffen kann. Kennen Sie das auch, diesen Drang nach Verallgemeinerung, den tiefen Wunsch, etwas Großes zu schaffen? Wir möchten in dieser Folge zuerst etwas über mögliche Arten der Flexibilität von Software klarstellen, auf einige Vor- und Nachteile davon eingehen und anschließend kräftiges Bashing auf Flexibilisatoren betreiben.

Flexibilität kann bei Software verschiedene Dinge bedeuten. Wir erklären das anhand des Begriffs „Komponente“, wobei diese Komponente eine beliebige Größe oder einen beliebigen Leistungsumfang haben kann, von einzelnen Klassen bis hin zu umfangreichen Systemen:

• Flexibilität zur Laufzeit (Konfigurierbarkeit zur Laufzeit): Zur Laufzeit der Komponente lassen sich unterschiedliche Parameter setzen oder verändern. Beispiele dafür sind konfigurierbare Benutzungsoberflächen (etwa: skinnable UI), konfigurierbare Abläufe, Prozesse, Pfade, Gültigkeitsregeln oder sogar Datenstrukturen.
• Flexibilität bezüglich Installation oder Inbetriebnahme (Konfigurierbarkeit zum Lade- oder Startzeitpunkt): Die Komponente lässt sich in verschiedenen Umgebungen in Betrieb nehmen, mit verschiedener Hardware, Betriebssystemen oder Netztopologien. Wesentliche Parameter wie Speicher, Netzwerk oder Datenbank lassen sich bei der Installation konfigurieren.
• Flexibilität bezüglich Test: Die Komponente lässt sich in verschiedenen Umgebungen oder Konfigurationen testen. Beispielsweise ist sie unabhängig von der konkreten Ressourcenausstattung oder Konfiguration der Testumgebung. Oder es können zum Test Mocks oder Stubs für Teilsysteme eingesetzt werden.
• Flexibilität bezüglich der Entwicklungszeit: Eine Komponente bietet eine flexible oder universell verwendbare Schnittstelle an, sodass sie in unterschiedlichen Verwendungssituationen oder von unterschiedlichen Konsumenten benutzt werden kann, möglicherweise über Grenzen einzelner Programmiersprachen hinweg.

Bei manchen Systemen freuen wir uns als Benutzer über die Konfigurierbarkeit zur Laufzeit, beispielsweise bei Firefox. Viele Aspekte seines Aussehens und auch Verhaltens können wir in der etwas unübersichtlichen, aber sehr mächtigen about:config [1] zur Laufzeit anpassen. Eine gefährliche Eigenschaft, wenn sie in die falsche Hände gerät. Es ist diese Laufzeitflexibilität, der wir uns an dieser Stelle primär widmen.

Generisch ist nicht gut

Mit ausreichend Bosheit, Dummheit oder Verwirrung ausgestattet, können wir als Benutzer unseren Browser, um bei diesem Beispiel zu bleiben, ganz schön verunstalten: Schwarze Schrift auf schwarzem Grund, den Proxyserver auf eine nicht existente Adresse eingestellt und dann noch die Adresszeile ausgeblendet. Damit ist der schöne Browser praktisch nicht mehr zu gebrauchen. Wenn der Flexibilisator voll zuschlägt, schenkt er den späteren Nutzern seiner Software eine Menge an Freiheitsgraden. Allerdings setzt er sie gleichzeitig gravierenden Risiken aus. Aber der meist jugendlich-leichtsinnige Flexibilisator denkt sich: „No risk, no fun.“ Hochgradig generisch oder allgemein verwendbar bedeutet, auf teilweise sinnvolle oder sogar notwendige Grenzen zu verzichten. Nennen wir die ultraflexiblen Produkte des Flexibilisators mal „übermäßig laufzeitkonfigurierbare Systeme“ (Overly Runtime Configurable Systems, kurz ORCS). Diese Abkürzung weckt doch hoffentlich auch bei Ihnen Assoziationen zum Herr-der-Ringe-Filmepos.

Wie kommt es zu ORCS?

Bekommen normale Entwicklungsteams halbwegs vernünftige Anforderungen, so entsteht hoffentlich klar strukturierte Software, die eben genau diese Anforderungen erfüllt. Schematisch finden Sie das in Abbildung 1 oben dargestellt (Variante 1), vom klar umrissenen Problem zur klar abgegrenzten Lösung. Sind die Anforderungen hingegen nur teilweise klar, ergibt sich eine leicht diffuse Lösung (in der Abbildung Variante 2). Schlimm wird es, wenn Anforderungen völlig vage oder unklar daherkommen, also im klassischen Fall von unterspezifiziert à la „die wissen nicht, was sie wollen“. Das finden Sie in Variante 3 der Abbildung: wolkige Software, die auf zu viele Eventualitäten vorbereitet ist, ohne klare Abgrenzung. In praktisch allen Fällen enthält Variante 3 viel viel mehr Code als Variante 1, ist viel größer und ungleich schwerer verständlich. Von Wartbarkeit mögen wir in Variante 3 schon gar nicht mehr reden.

Unser Flexibilisator bringt dieses Schema kräftig durcheinander. Er schafft es nämlich, aus einer glasklar und präzise formulierten Anforderung ein schwer fassbares Oeuvre zu produzieren – ein nach allen Seiten offenes Wunderding der Softwarekunst. In Abbildung 2 zeigen wir sein Wirken schematisch.

Flexibilisatoren verletzten die Forderung nach Kohäsion. Sie bauen Systeme oder Komponenten, die wesentlich mehr als eine einzige Sache erledigen. Jetzt können Sie berechtigt sagen: „Ist doch gut, wenn das System schön flexibel ist und sich an viele Nutzerbedürfnisse anpassen lässt.“ Das ist richtig. Doch dem halten wir Aufwände und Kosten entgegen – schematisch in Abbildung 3 dargestellt. Kompakte, wohlstrukturierte Software, bestehend aus Komponenten hoher Kohäsion hat tendenziell deutlich geringere Erstellungs- und Wartungskosten als ORCS.

Die Kurve verläuft nicht linear. Ein bisschen Flexibilität über die heutigen Anforderungen hinaus hält die Wartungskosten und -aufwände im Rahmen. Doch noch mehr Flexibilität und die Kosten steigen exponentiell. Wir sehen primär drei Gründe, die zu ORCS führen:

• Unsäglich schlechte, unklare und vage Anforderungen.
• Die Sippschaft der Flexibilisatoren, die es trotz klar umrissener Aufgaben- oder Problemstellung schaffen, ihre Lösungen noch generischer, noch allgemein verwendbarer, noch konfigurierbarer zu gestalten.
• Schließlich ist da noch die Freude am Komplexen: Es bereitet manchen unsägliche Freude, komplizierte oder komplexe Probleme zu lösen. Warum sollen wir nur das triviale Problem der aktuellen Anforderung lösen, wenn wir doch ganz leicht ein viel spannenderes Problem darum herum erfinden können?

Fazit

Sicherlich gibt es noch viele andere Gründe, warum Software ORCS-mäßig wird. Sicherlich gibt es auch viel mehr Vorteile (laufzeit-)flexibler Systeme, als wir sie hier dargestellt haben. In jedem Fall aber gilt: Je mehr Stellschrauben ein System besitzt, desto schwerer lässt es sich ändern, desto aufwendiger ist das Testen, desto teurer sind Bugfixes und desto schneller degradiert es zu höllischem Treibsand, in dem Nebenwirkungen nicht mehr zu kalkulieren sind. Besonders flexible und generische Komponenten sind meist umfangreicher und schwerer verständlich als ihre spezifischen Pendants. Verzichten Sie auf die Herausforderung der Allgemeinverwendbarkeit oder Generalität. Finden Sie den adäquaten Kompromiss zwischen zu starr und zu flexibel. Bereiten Sie Ihre Software für sehr wahrscheinliche Änderungen und Ergänzungen vor, aber nicht für alle potenziell denkbaren Eventualitäten, die dann doch nicht eintreten und auch nicht gebraucht werden.

Links & Literatur
[1] Firefox Configuration: http://lifehacker.com/the-best-about-config-tweaks-that-make-firefox-better-1442137111
[2] Pope, Daniel: „Misconfigure your browser“: http://mauveweb.co.uk/posts/2007/10/misconfigure-your-browser.html

The post Knigge für Softwarearchitekten appeared first on JAX.

Intelligenzbandbreiten

Immer wieder führt mein Weg mich in Organisationen, die wachsen. Das ist innerhalb unseres Systems gut so, denn so lange Organisationen wachsen, sind sie ökonomisch gesehen gesund. Handelt es sich bei den Organisationen um Unternehmen, bedeutet das Wachstum auf absehbare Zeit Arbeitsplatzsicherheit und einige andere Annehmlichkeiten für Mitarbeiter, Management und für Kunden, denn Unternehmen, die wachsen, haben eine Perspektive.

Allerdings hat dieses Wachstum auch eine Schattenseite. Die wird irgendwann bei jeder wachsenden Organisation sichtbar: Die Intelligenz in Organisationen wächst nicht mit.

Ich vertrete die Theorie, dass die Menge der Intelligenz in einer Organisation bereits am Tag ihrer Gründung feststeht. Je mehr Menschen in die Organisation kommen, auf desto mehr Köpfe wird diese Intelligenz verteilt. Und irgendwann wird der Punkt der atomaren Intelligenz erreicht. Sie kann nicht weiter verteilt werden. Für jeden Menschen, der jetzt in die Organisation kommt, muss man einem anderen die Intelligenz wegnehmen. Oder man kann diesem neuen Menschen keine Intelligenz mehr geben. Der neue Mensch bleibt von Anfang an unintelligent.

Die Gemeinsamkeiten von Balsamico, Eiern und schwarzen Löchern

Nun gibt es etliche Versuche, dem entgegenzuwirken. Ein moderner Klassiker ist die Balsamico-Stragie: Der Zukauf von anderen Organisationen, die diese Grenze noch nicht erreicht hat. Die Hoffnung dabei ist, dass man die Intelligenz dieser Organisationen dann einfach zum Weiterverteilen nutzen kann. Leider lassen sich Intelligenzen nicht so gut mischen wie Wasserfarben, so dass das nur hin und wieder erfolgreich ist. Meistens ist es wie Balsamico und Olivenöl. Es mischt sich nicht gut, sondern bildet bestenfalls Blasen und trennt sich, sobald es die Chance dazu hat. Strategieberater nennen das Synergieeffekte. Mitarbeiter erleben es als geringer werdende Intelligenz in der Organisation.

Ein anderer Weg ist die Neudefinition von Intelligenz, auch bekannt als Black-Hole-Strategie. Das lässt sich ganz hervorragend durch Berater machen, die der Organisation helfen, Prozesse zu definieren. Hat die Organisation Abläufe über Prozesse geregelt, müssen die Mitarbeiter weniger intelligent sein. Die Intelligenz der Organisation wird dabei Schritt für Schritt in Prozesse umgebaut.

Die Hoffnung dabei ist, dass dadurch Intelligenz von Mitarbeitern frei gemacht wird, die sich ja nun die Prozessschritte teilen können. Leider triff auch hier die bekannte Erkenntnis zu, dass der Unterschied zwischen Theorie und Praxis in der Praxis größer ist als in der Theorie. Anders gesagt: es funktioniert so nicht, weil Prozesse auf Intelligenz die gleiche Wirkung ausüben wie schwarze Löcher auf Materie. Sie lassen sie nicht los, sondern binden sie. Die Intelligenz ist im Prozess gefangen. Leider kann der Prozess mit der Intelligenz nichts anfangen, das können nur Menschen. Die können aber nur bis zum Ereignishorizont blicken und erleben es als geringer werdende Intelligenz in der Organisation.

Zurück in’s Ei

Eine dritte Strategie ist das Zentralisieren von Intelligenz. Diese Strategie hat keinen Namen, wohl aber der Effekt, den sie auslöst: Es ist der Retro-Ovum-Effekt (Zurück in’s Ei). Hier wird die Hoffnung umgesetzt, dass alles besser wird, wenn man die Intelligenz, die man vor kurzem noch über die Mitarbeiter verteilt hat, zurück ins Zentrum der Organisation holt. Die Zentralisierung führt dazu, dass sich die Intelligenz vor allem im Management und in Stabsstellen konzentriert und die Menschen in der Organisation unwissend werden. Das Ergebnis sind häufig Entscheidungen, die sehr intelligent aber dennoch absurd sind, weil Intelligenzkonzentration in der Regel einen Kapselungseffekt auslöst.

Die konzentrierte Intelligenz wird von ihrer Umwelt abgeschnitten und erlebt nur noch eine stark gefilterte Realität. Die Kapsel bildet innerhalb sehr kurzer Zeit eine richtig harte Schale, ähnlich der eines Eis. Durch diese Schale dringt kaum noch etwas nach innen, so dass die Zentrale der Organisation Entscheidungen treffen kann, ohne Angst vor allzu viel Realitätskompatibilität haben zu müssen. Mitarbeiter außerhalb der Schale erleben diese Entwicklung als geringer werdende Intelligenz in der Organisation.

Es mag noch weitere Strategien zum Umgang mit der Intelligenz von Organisationen geben, die ich noch nicht erlebt habe; ich wage aber zu behaupten, dass diese auch nicht funktionieren. Noch schlimmer als für die Mitarbeiter ist das häufig für die Kunden, aber über deren Sichtweise schreibe ich ein andermal.

Die einzige mir bekannte sinnvolle Strategie für Organisationen ist es, irgendwann mit dem Wachsen aufzuhören. Nicht unbedingt mit dem ökonomischen, wohl aber mit dem organischen. Es kann durchaus nützlich sein, sich über alternative Geschäftsmodelle Gedanken zu machen, die die Verteilung der Intelligenz erhalten und dennoch eine gute Perspektive für die Zukunft bringen.

Ich empfehle, darüber zu meditieren.

The post Meditations on Agile: Warum Intelligenz nicht mitwächst appeared first on JAX.

Wie weit kommt man ohne esoterische Frameworks, Abhängigkeiten und ausschließlich minimalistischen Ansätzen im Microservice-Umfeld? In dieser Session werde ich „Thin War“, kB-Microservices implementieren, versionieren, kommunizieren lassen, konfigurieren, deployen und überwachen. Da wir auf Slides verzichten, sollte die Zeit für die Implementierung der Patterns wie Bulkheads oder Circuit Breaker ausreichen.

The post Microservices gehen auch ohne Esoterik appeared first on JAX.