Java

Inkrementelle Codegenerierung mit CobiGen: Brückenbauer in der Open-Source-Welt – Teil 3

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?

Wer mit wem reden darf: Architekturpatterns in Modulithen – Teil 2

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.

In dubio pro Dukeo: JavaFX in einer neuen Ära mit GraalVM

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.

Schutzmechanismen gegen Java-Deserialisierungs-Exploits: Deserialisierungsschwachstellen im Java-Programmcode

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.

Was geht, GraalVM? Eine ausführliche Einführung in die GraalVM – Teil 1

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.

Selenium IDE: Capture-and-Replay-Testing

Selenium, in seiner (noch) aktuellen Version 3, besteht aus drei Bestandteilen: Selenium WebDriver, Selenium IDE und Selenium Grid. Während Selenium WebDriver im Grunde ein API bereitstellt, um programmatisch Tests zu schreiben, erlaubt Selenium Grid die Ausführung von mit Selenium WebDriver implementierten Tests auf mehreren Systemen und über mehrere Plattformen hinweg. Was aber ist nun die Selenium IDE?

Java Coding Problems

Programmieren ist eine jener Wissenschaften, die man am besten durch Übung erlernt. Da man oft nicht die Zeit hat, stundenlang sinnlos zu programmieren, bietet der PackT-Verlag nun ein Lehrbuch mit Java-Problemen an. Der didaktische Aufbau ist gelungen. Auf 809 Seiten stellt der Autor eine Gruppe verschiedener Probleme vor, die er in insgesamt 13 Kapitel unterteilt.

Ordnung ins Chaos bringen: Architekturpatterns in Modulithen – Teil 1

„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.

Kein Buch mit sieben Siegeln: JEP 360 – Sealed Classes (Preview)

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.

Bastelstunde: Deserialisierungs-Exploits – Deserialisierungsschwachstellen im Java-Programmcode

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.

Bye Java Web Start, hello OpenWebStart

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.