JAXenter

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.

„Gotta make a move to a town that’s right for me … take me to Funqytown“, so oder so ähnlich sang schon Lipps, Inc. im Discoklassiker von 1979. Jetzt hat mit Funqy ein einfaches API Einzug in Quarkus gehalten, das es dank Abstraktion sehr einfach machen soll, kleine, schlanke (HTTP-)Services für verschiedene Serverless-Umgebungen zu schreiben, ohne mit zu viel Umgebungsdetails vertraut sein zu müssen. Ist das nun endlich der (die) heilige Graal(VM)?

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.