<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sven Reinck on JAVAPRO Germany</title><link>https://javapro.svenruppert.com/authors/sven-reinck/</link><description>Recent content in Sven Reinck on JAVAPRO Germany</description><generator>Hugo</generator><language>de-DE</language><lastBuildDate>Mon, 02 Feb 2026 07:01:37 +0000</lastBuildDate><atom:link href="https://javapro.svenruppert.com/authors/sven-reinck/index.xml" rel="self" type="application/rss+xml"/><item><title>Beyond UML: Saubere Software-Architektur im Zeitalter von KI‑generiertem Code</title><link>https://javapro.svenruppert.com/beyond-uml-saubere-software-architektur-im-zeitalter-von-kigeneriertem-code/</link><pubDate>Mon, 02 Feb 2026 07:01:37 +0000</pubDate><guid>https://javapro.svenruppert.com/beyond-uml-saubere-software-architektur-im-zeitalter-von-kigeneriertem-code/</guid><description>&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;Wir schreiben heute mehr Code in kürzerer Zeit als jemals zuvor. KI‑Systeme agieren dabei wie ständig verfügbare Juniorprogrammierer: Sie produzieren in Minuten tausende Zeilen Code – aber wer übernimmt dabei die Verantwortung für die Software-Architektur?&lt;/p&gt;
&lt;p&gt;Das eigentliche Problem ist daher oft nicht „schlechter KI‑Code“, sondern die wachsende Schwierigkeit für Menschen, den Überblick zu behalten und fundierte Architekturentscheidungen zu treffen.&lt;/p&gt;
&lt;p&gt;Dieser Artikel diskutiert eine Idee, um schnell ein mentales Modell von vorhandenem Code aufzubauen, Architekturprobleme früh zu erkennen und Änderungen gezielt vorzunehmen – ohne parallel eine statische Dokumentation pflegen zu müssen.&lt;/p&gt;</description></item><item><title>Bessere Java-Desktop Deployments</title><link>https://javapro.svenruppert.com/bessere-java-desktop-deployments/</link><pubDate>Wed, 23 Dec 2020 10:18:55 +0000</pubDate><guid>https://javapro.svenruppert.com/bessere-java-desktop-deployments/</guid><description>&lt;p&gt;**Durch gravierende Änderungen bei den Java-Versionen ab Java 9, hat sich vor allem die Entwicklung klassischer Java-Desktop-Anwendungen stark verändert. Die Problematik ist sehr vielschichtig. Doch mit Java-Version-14 gibt es jetzt endlich anwenderfreundliche Lösungen für die Auslieferung von Java-Desktop-Applikationen.   **&lt;/p&gt;
&lt;p&gt;Im Jahr 2014 war die Java-Welt noch in Ordnung. Drei Jahre zuvor kam nach langer Zeit mit Java 7 endlich wieder eine neue Version. Dann wurde mit Java 8 eine Version mit vorher nie dagewesenen Neuerungen vorgestellt. Lambdas und Streams sollten die Art wie wir Java programmieren für immer verändern. Java 9 führte im Jahr 2017 ein Modulsystem mit dem Codenamen Jigsaw ein. Dieses Modulsystem war sehr umstritten und führte dazu, dass der Release verschoben werden musste. Dieses Modulsystem ist wohl der Grund dafür, warum viele Entwickler sich geweigert haben auf Version 9 umzusteigen. Java 9 war gleichzeitig auch der Startschuss für eine neue Release-Strategie von Oracle. Von nun an sollte jedes halbe Jahr eine neue Hauptversion erscheinen. Und mit jeder neuen Version wurden weitere starke Einschnitte in das Java-System vorgenommen, so dass sich in relativ kurzer Zeit sehr viele Änderungen ergaben, die mit der Abwärtskompatibilität gebrochen haben.&lt;/p&gt;</description></item></channel></rss>