Jan Bernecke

Jan Bernecke
Jan Bernecke ist seit 2019 Online-Redakteur bei S&S Media. Zuvor war der rugbyspielende Literaturwissenschaftler im Bereich Online-Marketing tätig.
Beiträge dieses Autors

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.

Take me to Funqy Town! Das neue Serverless API in Quarkus

„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)?

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.