Etablierte Referenzarchitekturen wie devonfw machen es möglich, ein hohes Maß an Standardisierung über verschiedene Softwareprojekte hinweg zu etablieren. Starke Vorgaben, wie beispielweise Namenskonventionen für Quellcodeartefakte, bieten darüber hinaus eine klare Sichtbarkeit der Architektur auf der Quellcodeebene. Sind solche Vorgaben für (agile) Entwickler durchzuhalten und führt Schichtenbildung nicht teilweise zu nervigem Boilerplate-Code?

So manche Codebase macht nur auf den ersten Blick einen aufgeräumten Eindruck. Schön in Packages sortierter Code ohne Abhängigkeitsmanagement ist wie ein „aufgeräumtes“ Kinderzimmer, bei dem einem die Lawine entgegenkommt, wenn man es wagt, die Schranktür aufzumachen. Um zu verhindern, dass Abhängigkeitszyklen und wuchernde Queraufrufe den Code zu einem „Big Ball of Mud“ machen, gilt es, höllisch aufzupassen.

Anwendungen mit JavaFX kommen nicht nur unter Android zum Einsatz, sondern auch auf Desktops. Sie laufen auf Computern, an denen unterschiedliche Bildschirme angeschlossen sind. Mit diversen Tricks sehen JavaFX-Anwendungen auf unterschiedlichen Bildschirmgrößen gleich gut aus.

Gluon veröffentlichte im September 2020 JavaFX 15 [1]. Die perfekte Gelegenheit, darüber zu sprechen, warum JavaFX [2] auf Desktop und Mobilgeräten so relevant ist. Nachfolgend wird das Cross-Kompilieren von Java-Anwendungen mit JavaFX für die Benutzeroberfläche, vom Backend bis zum Frontend, betrachtet. Oberstes Ziel jeder neuen Version von JavaFX ist es, die Abwärtskompatibilität sicherzustellen und mehr Software- und Hardwaretreiber zu unterstützen. Dabei steht Plattformstabilität und deren Kompatibilität für Entwickler und Unternehmen im Vordergrund, die in ihren geschäftskritischen Anwendungen auf Java und JavaFX angewiesen sind. Die GraalVM in Verbindung mit JavaFX ermöglicht neue Wege der Codekompilierung vom Backend bis zum Frontend.

In diesem Teil unserer Artikelserie zu Deserialisierungsschwachstellen in Java sehen wir uns an, welche Schutzmechanismen existieren, um erste Maßnahmen vor dem Eintreffen eines geeigneten Patches zu treffen. Letztlich geht es um die Frage, wie man das Erstellen von Gadget Chains verhindern oder gleich ganz auf das Serialisierungs-API verzichten kann.

GraalVM und SubstrateVM, native Java-Programme: Schlagworte, die im Moment in ganz vielen Artikeln die Runde machen. Worum geht es da?

Nun ist sie also draußen, die neue Java Virtual Machine (JVM) mit dem Namen GraalVM, über die einer von uns (Stephan) schon im vergangenen Frühjahr gebloggt hat [1]. Seit damals hat sich viel getan, die GraalVM hat die Java-Landschaft deutlich verändert. Twitter verwendet sie schon seit Jahren für seine Scala Microservices [2]. Die GraalVM beginnt jetzt, auch in der etwas konservativeren Businesswelt Fuß zu fassen, insbesondere im Bereich der Cloud-nativen Anwendungen. Grund genug also, sich die GraalVM noch einmal genau und ausführlich anzusehen und die Frage zu beantworten, ob es sich lohnt, die gute alte JVM durch etwas Neues zu ersetzen.

Value Objects sind einer der fundamentalen Building Blocks in Domain-driven Design. Sie in Java zu erstellen, erforderte bisher allerdings einigen Boilerplate-Code. Das ändert sich mit Java 15: Es wird ein neues Sprachkonstrukt eingeführt – und zwar die Records. Und diese erfüllen alle technischen Anforderungen zur einfachen Umsetzung von Value Objects.

Die Möglichkeit, Java-Code auf einem Mikrocontroller auszuführen, hilft bei der Reduktion der Softwarekopplung. MicroEJ bringt allerdings auch einen reichhaltigen GUI-Stack mit.

Möchte man eine Konsolenanwendung entwickeln, gibt es unter Java gleich mehrere Bibliotheken. Zu den bekanntesten zählen JCurses, CHARVA und Lanterna. Allen ist gemeinsam, dass die textbasierten grafischen Oberflächen mit Java Swing beziehungsweise Java AWT realisiert werden. Doch welche Gemeinsamkeiten oder Unterschiede weisen diese Bibliotheken sonst noch auf?

Bei Projekten der Unternehmensarchitektur (auch Enterprise Architecture) ist meist die oberste Ebene des Managements die treibende Kraft. Doch wie ist das mit den Regeln und Best Practices der agilen Softwareentwicklung vereinbar?

„Wir haben diesen Legacy-Monolithen, den wollen wir in Microservices aufbrechen“. So einen Satz hört man als Berater in der Softwarebranche oft. Auf die Frage „Warum“ erhält man oft die Antwort „Modularisierung“. Denn es herrscht die weitverbreitete Ansicht, dass Monolithen grundsätzlich aus schlecht strukturiertem Legacy-Code bestehen und sich Monolithen und Modularisierung gegenseitig ausschließen. Dass dem nicht so ist, zeigt die Architekturform der Modulithen. In dieser Artikelserie wird sie beleuchtet und beschrieben, mit welchen Patterns ein Modulith gelingen kann und welche Antipatterns man dabei vermeiden sollte.

Das Vorgehen hat sich bewährt – auch im JDK 15 hat mit Sealed Classes ein neues Sprachkonstrukt vorerst als Preview-Feature Einzug gehalten. Es gibt Entwicklern Kontrolle darüber, welche Klassen von einem bestimmten Interface oder einer Klasse erben dürfen. Wem das neue Sprachkonstrukt nützt, wann man es einsetzen kann und was man jetzt und in Zukunft alles damit anstellen können wird, wird in diesem Artikel zusammengefasst.

Im diesem Teil unserer Artikelserie zu Deserialisierungsschwachstellen in Java wollen wir selbst einen Exploit Code schreiben. Wir sehen uns an, wie anhand der BeanShell Gadget Chain [1], [2] eine Deserialisierungsschwachstelle unter realen Bedingungen ausgenutzt werden kann. Hiermit sollten wir dann in der Lage sein, eigene Befehle im Betriebssystem auszuführen.

Zwei Jahre ist es mittlerweile her, dass der neue Java-Release-Train und verschiedene Ankündigungen von Oracle die Java-Community so richtig durchgerüttelt haben. Eine der Neuerungen war die von Oracle angekündigte Entfernung von Java Web Start aus dem Oracle JDK. Vielen Entwicklern wurde erst damals wirklich bewusst, dass Web Start kein Bestandteil des OpenJDK ist, sondern von Oracle Closed Source entwickelt wurde.