Entwicklung & Code
Clean Architecture und Co.: Softwarearchitektur mit Mustern strukturieren
Strukturierte Software basiert auf einem Plan, der die spezifischen Anforderungen an ein System berücksichtigt und in lose gekoppelte Bausteine überführt. In der arbeitsteiligen Softwareentwicklung benötigen Entwicklungsteams solche gemeinsamen Pläne, um eine harmonische und einheitliche Architektur zu entwickeln, ohne jedes Detail vorab miteinander abstimmen zu müssen. Bewähren sich die Pläne, entwickeln sich daraus Muster und Prinzipien auf unterschiedlichen Architekturebenen.
Weiterlesen nach der Anzeige
Matthias Eschhold ist Lead-Architekt der E-Mobilität bei der EnBW AG. Als Experte für Domain-driven Design gestaltet er die IT-Landschaft und Team-Topologien der E-Mobilität. Trotz strategischer Schwerpunkte bleibt er mit Java und Spring Boot nah am Code, entwickelt Prototypen und führt Refactorings durch. Als Trainer vermittelt er seit Jahren praxisnahe Softwarearchitektur, die Theorie und Projektrealität verbindet.
Bei der grundlegenden Strukturierung eines Systems muss man zwischen Architekturstilen und Architekturmustern unterscheiden, wobei sie sich nicht immer sauber abgrenzen. Ein Architekturstil ist ein Mittel, das dem System eine grundlegende Struktur verleiht. Beim Stil Event-driven Architecture basiert die Anwendung beispielsweise auf asynchroner Kommunikation, und Events beeinflussen die Architektur und den Code an vielen Stellen. Gleiches gilt für REST, das eine ressourcenorientierte Struktur vorgibt.
Entscheidet sich ein Entwicklungsteam für Microservices als Architekturstil, wählt es eine verteilte Systemarchitektur, beim Stil Modularer Monolith ist das Gegenteil der Fall. In komplexen Systemen kombinieren Architektinnen und Architekten in der Regel mehrere Stile. Manche Architekturstile ergänzen sich, etwa REST und Microservices, während sich andere gegenseitig ausschließen, wie Microservices und der Modulare Monolith.
Ob Microservices oder Modularer Monolith – beides sagt wenig über die Gestaltung der internen Strukturen aus. Auf dieser inneren Architekturebene, der Anwendungsarchitektur, kommen Muster zum Einsatz, die Entwurfsprinzipien und -regeln kombinieren und eine Basisstruktur der Anwendung prägen. Architekturmuster der Anwendungsarchitektur nutzen Verantwortungsbereiche und Beziehungsregeln als Strukturierungsmittel. Im Muster Clean Architecture sind dies beispielsweise konzentrische Ringe, wobei die Beziehungsrichtung stets zum inneren Kern des Ringmodells führt. Die geschichtete Architektur (Layered Architecture) hingegen unterteilt die Verantwortungsbereiche in hierarchische Schichten, wobei jede Schicht nur mit der darunter liegenden kommunizieren darf (siehe Abbildung 1).
Vergleich zwischen Clean Architecture und Schichtenarchitektur (Abb. 1).
Mustersprache als Fundament
Eine Mustersprache ergänzt Architekturmuster für einen ganzheitlichen Konstruktionsplan – von Modulen und Paketen bis hin zum Klassendesign. Sie bildet das Fundament für eine konsistente und verständliche Umsetzung der Muster und beschreibt eine Reihe von Entwurfsmustern für die Programmierung auf der Klassenebene.
Weiterlesen nach der Anzeige
Die Klassen der Mustersprache bilden Geschäftsobjekte, Fachlogik und technische Komponenten ab. Sie werden unter Einhaltung der definierten Beziehungsregeln in einem Klassenverbund implementiert. Diese Regeln bestimmen, wie die Klassen miteinander interagieren, wie sie voneinander abhängen und welche Aufgaben sie haben. Ein Geschäftsobjekt ist charakterisiert durch seine Eigenschaften und sein Verhalten, während ein Service Geschäftslogik und fachliche Ablaufsteuerung implementiert. Eine derartige, genaue Differenzierung gestaltet Architektur klar und nachvollziehbar.
Ein wichtiger Aspekt einer Mustersprache ist die Organisation des Codes in einer gut verständlichen Hierarchie. Dadurch fördert sie die Verteilung von Verantwortlichkeiten auf unterschiedliche Klassen. Prinzipiell kann jedes Projekt seine eigene Mustersprache definieren oder eine bestehende als Basis verwenden und mit individuellen Anforderungen ausbauen. Eine Mustersprache sorgt auch im Team dafür, dass alle Mitglieder dieselben Begriffe und Prinzipien verwenden.
Dieser Artikel wählt die DDD Building Blocks als Grundlage für eine Mustersprache, wie die folgende Tabelle und Abbildung 2 zeigen.
| Value Object | Ein Value Object repräsentiert einen unveränderlichen Fachwert ohne eigene Entität. Das Value Object ist verantwortlich für die Validierung des fachlichen Werts und sollte nur in einem validen Zustand erzeugt werden können. Ferner implementiert ein Value Object dazugehörige Fachlogik. |
| Entity | Eine Entity ist ein Objekt mit einer eindeutigen Identität und einem Lebenszyklus. Die Entität wird beschrieben durch Value Objects und ist verantwortlich für die Validierung fachwertübergreifender Geschäftsregeln sowie die Implementierung dazugehöriger Fachlogik. |
| Aggregate | Ein Aggregate ist eine Sammlung von Entitäten und Value Objects, die durch eine Root Entity (oder Aggregate Root bzw. vereinfacht Aggregate) zusammengehalten werden. Die Root Entity definiert eine fachliche Konsistenzgrenze, klar abgegrenzt zu anderen Root Entities (oder Aggregates). |
| Domain Service | Ein Domain Service implementiert Geschäftslogik, die nicht zu einer Entität oder einem Value Object gehört. Weiter steuert der Domain Service den Ablauf eines Anwendungsfalls. Ein Domain Service ist zustandslos zu implementieren. |
| Factory | Eine Factory ist für die Erstellung von Aggregates, Entitäten oder Value Objects verantwortlich. Die Factory kapselt die Erstellungslogik komplexer Domänenobjekte. |
| Repository | Ein Repository ist verantwortlich für die Speicherung und das Abrufen von Aggregaten und Entitäten aus einer Datenquelle. Das Repository kapselt den Zugriff auf eine Datenbank oder auch andere technische Komponenten. |
Mustersprache des taktischen Domain-driven Design (Abb. 2).
Ein Beispiel verdeutlicht den Unterschied zwischen einem Value Object und einer Entity: Eine Entity könnte ein bestimmtes Elektrofahrzeug sein. Entities sind also eindeutig und unverwechselbar. In der realen Welt zeigt sich das an der global eindeutigen Fahrgestellnummer (VIN). Der aktuelle Zustand eines E-Fahrzeugs wird zu einem bestimmten Zeitpunkt beispielsweise durch seinen Ladezustand beschrieben, ein Wert, der sich im Laufe der Nutzung des Fahrzeugs verändert. Der Ladezustand entspricht einem Value Object. Er verfügt über keine eigene Identität, sondern definiert sich ausschließlich durch seinen Wert.
Erweiterung der Mustersprache auf Basis der Stile und Muster
Die Mustersprache der Building Blocks ist nicht vollständig. Sie benötigt weitere Elemente, die von den eingesetzten Architekturstilen und -mustern abhängen. REST als Architekturstil führt beispielsweise zwei Elemente in die Mustersprache ein: Controller und Resource. Bei der Integration von REST als Provider liegt der Fokus auf der Resource, die als Datentransferobjekt (DTO) über den API-Endpunkt bereitsteht. Der Controller fungiert als Schnittstelle zwischen der Anfrage des Konsumenten und der Fachlogik des Systems. Das heißt, der Controller nutzt den bereits eingeführten Domain Service und delegiert die Ausführung von Fachlogik an diesen.
Bei der Integration von REST als Consumer erhält die Mustersprache das Element Service Client, das dem Abrufen von Daten oder Ausführen von Funktionen über einen externen API-Endpunkt dient. Der Domain Service triggert dies als Teil der Fachlogik über den Service Client.
Der Stil Event-driven Architecture erweitert die Mustersprache um die Elemente Event Listener, Event Publisher und das Event selbst. Ein Event Listener hört auf Ereignisse und ruft den entsprechenden Domain Service auf, um die Ausführung der Geschäftslogik auszulösen. Der Event Publisher veröffentlicht eine Zustandsveränderung in der Fachlichkeit über ein Event. Der Domain Service triggert die Event-Veröffentlichung als Teil seiner Fachlogik und nutzt hierfür den Event Publisher.
Die in diesen Beispielen aufgeführten Begriffe sind im Vergleich zu den DDD Building Blocks nicht in der Literatur definiert und entstammen der Praxis. Abbildung 3 zeigt die Klassen der erweiterten Mustersprache.
Elemente der Mustersprache des taktischen Domain-driven Design (Abb. 3).
Architekturmuster kombinieren Regeln, Entwurfsmuster und Prinzipien. Muster wie Clean Architecture, die sich besonders für komplexe Systeme mit hohen Anforderungen an den Lebenszyklus eignen, bündeln mehrere Konzepte und beeinflussen daher die Mustersprache stärker als andere Muster. Ein Beispiel ist das Konzept Use Case in der Clean Architecture, das ein zentrales Element darstellt und die Mustersprache um die Elemente Use Case Input Port, Use Case Output Port und Use Case Interactor erweitert. Ein weiteres Beispiel ist die Anwendung des Dependency Inversion Principle (DIP) in der Clean Architecture, das zu dem Musterelement Mapper führt.
Nach dem Exkurs über die Mustersprachen stellt dieser Artikel verschiedene Architekturmuster vor, die sich in schichten- und domänenbasierende unterteilen.
Schichtenbasierende Architekturmuster
Schichtenbasierende Architekturmuster sind datenzentrisch strukturiert. Je nach Muster ist dieser Aspekt mehr oder weniger ausgeprägt. Die Schichtung unterscheidet sich in technischer (horizontal geschnitten) und fachlicher (vertikal geschnitten) Hinsicht. Für die weitere Beschreibung eignet sich die Begriffswelt von Simon Brown mit „Package by …“ .
Package by Layer: Dieses Muster organisiert die Anwendung nach technischen Aspekten, zum Beispiel nach Controller, Service und Repository (Abbildung 4). Es kommt jedoch schnell an seine Grenzen: Mittlere und große Systeme mit komplizierter Fachlichkeit erfordern eine vertikale Schichtung anhand fachlicher Aspekte, andernfalls enden die Projekte erfahrungsgemäß in komplizierten Monolithen mit vielen Architekturverletzungen.
Vorteile:
- Bekannt und verbreitet
- Einfach zu verstehen und anzuwenden
- In kleinen Projekten praktikabel
Nachteile:
- Enge Kopplung zwischen Schichten, mit der Gefahr chaotischer Abhängigkeiten bei Wachstum des Systems
- Fachlich zusammenhängende Funktionalitäten sind über viele Pakete verteilt
- Schwer wartbar und erweiterbar bei mittleren bis großen Anwendungen
Das Architekturmuster Package by Layer (Abb. 4).
Package by Feature: Der Code organisiert sich vertikal anhand fachlicher Aspekte. Eine Schnitt-Heuristik, wie genau das Feature von den fachlichen Anforderungen abzuleiten ist, definiert das Architekturmuster nicht. Es definiert nur, dass dieser fachliche Schnitt zu erfolgen hat. Wird das taktische DDD angewendet, erfolgt der Schnitt entlang der Aggregates (siehe Abbildung 5).
Vorteile:
- Fachlich kohäsiver Code ist lokal zusammengefasst, was zu hoher Wartbarkeit und Erweiterbarkeit führt.
- Modularisierung ermöglicht die unabhängige Entwicklung fachlicher Module.
- Fachliche Ende-zu-Ende-Komponenten sind lose gekoppelt.
- Abhängigkeiten zwischen fachlichen Modulen müssen explizit gehandhabt werden, was die Robustheit der Architektur gegenüber ungewünschten Abhängigkeiten erhöht.
- Fachlich komplexe, mittelgroße bis große Anwendungen lassen sich mit vertikalen Schichten besser beherrschen als mit Package by Layer und Package by Component.
Nachteile:
- Abhängigkeiten zwischen fachlichen Modulen erfordern fortgeschrittene Kommunikationsmuster (zum Beispiel Events), was die architektonische Komplexität erhöht.
- Vertikale Modularisierung muss gut durchdacht werden, um enge Kopplung zwischen Modulen zu vermeiden.
Das Architekturmuster Package by Feature (Abb. 5).
Package by Component: Das Muster strukturiert die Anwendung sowohl fachlich (vertikal) als auch technisch (horizontal), wobei sich ein fachliches Feature in eine Inbound-Komponente und eine Domain-Komponente aufteilt (siehe Abbildung 6). Die Domain-Komponente kapselt Geschäftslogik und die dazugehörige Persistenzschicht. Diese Unterteilung in fachliche Module ist ein entscheidender Unterschied zu Package by Layer.
Vorteile:
- Gute Modularisierung durch fachliche Grenzen zwischen Komponenten
- Hohe Wiederverwendbarkeit der Domain-Komponenten, durch unterschiedliche Inbound-Komponenten
- Erleichterte Testbarkeit durch gesteigerte Modularisierung im Vergleich zu Package by Layer
Nachteile:
- Enge Kopplung zwischen Inbound- und Domain-Schicht, mit dem Risiko indirekter Abhängigkeiten und Seiteneffekten bei Änderungen, insbesondere wenn die Anwendung wächst
- Komponentenkommunikation schwer beherrschbar bei erhöhter fachlicher Komplexität
- Schwerer erweiterbar für mittlere bis große Anwendungen mit höherer fachlicher Komplexität
Das Architekturmuster in Package by Component (Abb. 6).
Entwicklung & Code
30 Jahre Java – Interview mit Community-Vertretern (Teil 3)
In den vergangenen 30 Jahren hat sich eine rege Community im Java-Umfeld gebildet. Ich habe im Laufe des Jahres einige deutschsprachige Vertreter zu ihren Erfahrungen befragt. Die Resonanz war überwältigend. Vielen Dank an alle, die mitgemacht haben. In diesem dritten Teil kommen Jens Schauder (Spring Data Team und ehemaliger Organisator der JUG Ostfalen), Richard Fichtner (Java Champion und Organisator JCON), Cay Horstmann (Java Champion, Buchautor), Ralf D. Müller (Open Source Committer und arc42 Contributor) und Mark Paluch (Spring Data Team und ehemaliger Organisator der majug) zu Wort.
Weiterlesen nach der Anzeige
Falk Sippach ist bei der embarc Software Consulting GmbH als Softwarearchitekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen. Falk twittert unter @sippsack.
Java prägt viele Entwicklerinnen und Entwickler seit ihren ersten Schritten in der IT – und hat in dieser Zeit Höhen, Tiefen und mehrere Neuerfindungen erlebt. Die folgenden Antworten spiegeln persönliche Anfänge, prägende Erlebnisse, kritische Momente und eine Einordnung von Javas Rolle in der heutigen Softwareentwicklung wider. Abschließend wagen sie einen Blick nach vorn: mit Tipps für die eigene Weiterentwicklung und Erwartungen an Java in den kommenden Jahren.
-
Alexander Culum , Birgit Kratz, Simon Martinelli , Dierk König, Christian Stein
-
Bernd Müller, Heinz Kabutz, Patrick Baumgartner, Wolfgang Weigend, Gernot Starke
-
Jens Schauder, Richard Fichtner, Cay Horstmann, Ralf D. Müller, Mark Paluch
Wann und mit welcher Version bist du erstmals mit Java in Berührung gekommen?
Jens Schauder: Das war 1997. Ich habe zu der Zeit mit Fortran 90 an meiner Diplomarbeit gearbeitet und ein Bekannter hat mir total begeistert von Java erzählt. Ich habe mir dann das JDK heruntergeladen und ein kleines Applet gebaut, in dem ich Würfel gezeichnet habe. Im Wesentlichen eine Portierung eines der ersten Programme, die ich auf meinem ersten Rechner geschrieben habe, einem Apple. Ich kann mich an die Versionsnummer nicht wirklich erinnern, aber es war vermutlich 1.1.
Richard Fichtner: Meine erste Java-Anwendung habe ich im Jahr 2003 mit der Version J2SE 1.4 geschrieben. Java hat mir nicht gefallen. Ich war damit nicht produktiv. In Visual Basic 6.0 gab es einen GUI-Builder und mit PHP ließen sich schnell Webanwendungen bauen. Zum Glück hat Java hier nachgelegt.
Cay Horstmann: 1995 rief Gary Cornell mich an und teilte mir mit: „Cay, wir schreiben ein Java-Buch.“ Wir waren beide bekannte Buchautoren, ich für C++ und er für Visual Basic. Ich wusste dagegen nichts über Java, außer ein paar Gerüchten. Und er auch nicht. Aber er hatte es fertiggebracht, einen Buchvertrag mit Sun Microsystems Press zu bekommen. Denn Sun Microsystems Press hatte ein Problem. James Gosling und Ken Arnold hatten Sun Microsystems Press umgangen und den Vertrag für „The Java Programming Language“ mit einem angesehenen Verlag geschlossen. Also verbrachten wir den Herbst und Winter 1995, um Java gründlich zu lernen. Es half, dass ich als Professor eine „Research License“ für den Quellcode bekam. Das war lange vor Open Source. Dadurch konnten wir schreiben, was wirklich funktionierte und wo man vorsichtig sein musste. Das machte das „Core Java“-Buch, das zusammen mit Java 1.0 erschien, zum Bestseller.
Weiterlesen nach der Anzeige
Ralf D. Müller: Das war ganz früh an der Uni Frankfurt. Am 12. April 1996 haben einige Studenten die Java User Group Frankfurt (Vorgänger der heutigen JUG Frankfurt) gegründet. Damals war Java 1.0 aktuell.
Mark Paluch: Java 1.1, kurz bevor 1.2 im Dezember 1998 released wurde.
Was war rückblickend dein schönstes Erlebnis mit der Sprache oder dem Ökosystem Java?
Jens Schauder: Am meisten Spaß mit der JVM hatte ich in der Zeit, als ich mich mit Scala beschäftigt habe. Ich habe unglaublich viel darüber gelernt, was eine Programmiersprache, ein Compiler, ein Typsystem tun kann. Ich bin ständig mit Knoten im Hirn rumgelaufen und das war sehr, sehr cool.
Richard Fichtner: Das Schönste an Java sind die Menschen in der Community. Java hat sicherlich auch technisch viele tolle Sachen zu bieten, aber die Haltung und Kultur der Java-Community machen es aus. Open Source war für viele vor 20 Jahren unvorstellbar. Bei Java User Groups Wissen teilen – seid ihr wahnsinnig? Heute haben viele Organisationen verstanden, dass man zusammen erfolgreicher ist und offene Standards sowie Austausch uns alle voranbringen.
Cay Horstmann: Ich habe viele schöne und produktive Erfahrungen mit Java gemacht, aber wenn ich mir eine Erfahrung aussuchen muss, wäre das der Violet UML Editor. Ich weiß, heutzutage kräht kein Hahn mehr nach UML, aber wir fanden es damals (2002) wichtig. Ich wollte meinen Studenten Sequence-Diagramme beibringen. Die damals erhältlichen Produkte versagten mit diesem Diagrammtyp und außerdem waren sie sehr teuer. Ich schrieb eine Swing-Anwendung und war begeistert, dass ein Großteil der Routinearbeit durch die Java-Standardbibliothek abgedeckt war. Einige Jahre später hatte ich ein anderes Problem. Meine Studenten hatten Probleme mit Schleifen. Sie brauchten einfach mehr Übung. Ich entwickelte eine Webanwendung. Zum Glück in Java, denn ich bekam seitdem stetig Fragen von Studenten aus der ganzen Welt, ob sie nicht bei meinem Open-Source-Projekt mitmachen können. Dann lade ich sie gerne ein, um ein offenes Problem zu bearbeiten. Weil das Projekt in Java ist, finden sich die Studenten zurecht. Bei Rails (zu unbekannt) oder JavaScript (zu chaotisch) wäre es nicht so einfach, Mitstreiter zu finden. Und Java ist wahnsinnig stabil. Die Webanwendung hat sich über die Jahre von Glassfish zu Play und jetzt zu Quarkus gewandelt, aber der Kerncode besteht weiterin.
Ralf D. Müller: Ich hatte immer viel Spaß mit Groovy und Grails im Java-Ökosystem. Groovy hat es geschafft, eine leichtgewichtige Skriptsprache im Java-Ökosystem zu etablieren, die auch ohne IDE beherrschbar ist.
Mark Paluch: Für mich ist es wichtig, Wissen an andere Entwickler weiterzugeben und dabei auch von ihnen zu lernen, wie sie Java verwenden und in welchem Kontext. Konferenzen sind eine großartige Möglichkeit, mich mit der Java Community auszutauschen, und ein ganz besonderes Highlight.
Aber es ist nicht alles Gold, was glänzt. Was hat dich negativ beeinflusst beziehungsweise was war ein unschöner Moment im Java-Umfeld?
Jens Schauder: Das war Gradle. Ich habe eine Zeit lang Gradle als Build-Tool genutzt und es geliebt, da es mir erlaubte, kleine Skripte direkt im Build-Tool zu schreiben. Ich konnte damit Probleme lösen, die durch kafkaeske Architekturvorgaben eines Kunden verursacht wurden. Sehr cool! Das böse Erwachen kam, als ich ein Projekt, das ein Jahr lang herumlag, versuchte wiederzubeleben. Durch Updates von was auch immer funktionierte nichts mehr und ich habe mein eigenes Build-Skript nicht mal ansatzweise mehr verstanden.
Richard Fichtner: Die große Verunsicherung um die Lizenzierung von Java vor einigen Jahren war unschön und bedurfte viel Erklärung. Das hat sich zum Glück heute alles gelegt und die Auswahl an JDKs ist so groß wie noch nie.
Cay Horstmann: Circa 2009 war ich schon unglücklich mit der langsamen Weiterentwicklung von Java. Ich lernte Scala, benutzte es für einige Projekte und schrieb ein Buch darüber. Scala ist wirklich eine schöne und elegante Sprache, aber einfach ist sie nicht. Und auch nicht sonderlich stabil. Seitdem hat sich Java enorm weiterentwickelt. Scala ist immer noch eleganter, aber Java hat eine bessere Infrastruktur.
Ralf D. Müller: Die Open-Source-Community ist in der Java-Welt recht stark. Demgegenüber stehen im starken Kontrast die Rechtsstreitigkeiten zwischen den großen Firmen, die aus Java Kapital schlagen wollen. Das hat immer wieder die Community verunsichert.
Mark Paluch: Es ist schade, dass ein guter HTTP-Client (Java 11) und so etwas wie Single-File Programs es erst so spät in ein Java Release geschafft haben. Das sind Features, die gerade für den Einstieg in die Sprache eine große Rolle spielen. Es ist auch schön, dass Java nun eine API für Bytecode-Interaktion bereitstellt und ASM vielleicht langsam nicht mehr notwendig sein wird. JPMS ist für das JDK ein großer Schritt nach vorn gewesen. Für Bibliotheken ist es schade, dass Module-Info so sehr viel restriktiver (z. B. ein Modul pro JAR) gehandhabt wird, was zu der Wahrnehmung führt, dass Bibliotheken Bürger zweiter Klasse sind.
(Bild: DOAG)
Vom 10. bis 12. März 2026 findet die JavaLand-Konferenz statt. In diesem Jahr zieht die Community-Konferenz in den größten deutschen Freizeitpark, den Europa-Park Rust. Das Programm bietet knapp 130 Vorträge in 13 Themenbereichen.
Glaubst du, dass Java auch nach 30 Jahren noch relevant ist? Welche Rolle spielt Java deiner Meinung nach in der modernen Softwareentwicklung, insbesondere im Vergleich zu anderen Sprachen und Technologien?
Jens Schauder: Java ist das langweilige Arbeitstier unserer Zeit und wird es noch lange bleiben. Projekte im Enterprise-Umfeld, in dem Java besonders stark ist, laufen lange und werden noch länger gewartet. Ich vermute daher, dass auch in 30 Jahren Java noch relevant sein wird. Ich sehe momentan nur einen Weg, das zu verhindern: Wenn es ein Tool gäbe, das Code in einer Sprache in hochwertigen Code einer anderen Sprache überführen kann. Viele Tools versuchen etwas Derartiges, um Cobol-Programme in Java umzuwandeln. Das Ergebnis ist aber meist noch schlimmer als der ursprüngliche Cobol-Code. Wer weiß, was KI da noch für uns tun wird. Und generell darf man nicht vergessen, wie viel 30 Jahre sind. Vor 30 Jahren hatten Handys das Format einer kleinen Werkzeugkiste. Und ein Rechner mit der Leistung eines aktuellen Mobiltelefons würde vermutlich einen Raum füllen.
Richard Fichtner: Ich hoffe, dass Java noch relevant ist. Mit dem neuen sechsmonatlichen Release-Zyklus und den zweijährlichen LTS-Releases ist viel Bewegung und Erneuerung in die Java-Welt gekommen. Java hat viele moderne Features und ist gleichzeitig noch sehr rückwärtskompatibel zu Code von vor 30 Jahren. Ich bin zuversichtlich.
Cay Horstmann: Die am meisten benutzten Programmiersprachen (C++, Python, Java, JavaScript) sind alle etwa 30 Jahre alt. Neuere Sprachen wie Go, Ruby, Rust und Swift haben ihre Nischen, aber es ist nicht einfach, darüber hinaus zu wachsen. Die Programmiersprache ist nur ein Teil der Infrastruktur. Java hat ausgezeichnete Tools und Bibliotheken sowie ein technisch kompetentes und motiviertes Team, das die Sprache weiterentwickelt. Die JVM gibt Stabilität und Einsicht in das Verhalten laufender Programme. Das ist für viele Anwendungen wichtig. Ich sehe zurzeit keine Sprache oder Technologie, die Java das Wasser abgraben würde. Zumindest abgesehen von KI. Es ist natürlich vorstellbar, dass es bald keine menschlichen Entwickler mehr gibt, sondern dass ein Manager der KI einfach erzählt, was sie programmieren soll. In irgendeiner Sprache. Aber ganz glauben kann ich das nicht. Ich benutze gerne KI für „Autocomplete“-Vorschläge. Aber selbst da geht genug schief, dass ich meine, wir sind nicht so schnell ersetzbar.
Ralf D. Müller: Java ist etabliert. Die Sprache hat zwar ihr ursprüngliches Versprechen „Write once, run anywhere“ nicht so erfüllen können, wie andere Sprachen es gefühlt schaffen, aber Java-Programme laufen auf einer Vielzahl von Systemen, die den Betrieb unserer modernen Welt sicherstellen. Durch Python und JavaScript gibt es zwei Herausforderer, denen Java in verschiedenen Bereichen (ML, Web) das Feld überlassen muss. Hier wird es spannend zu sehen, welchen Einfluss GenAI auf die weitere Entwicklung haben wird. Da die Large Language Models gerade in der Erzeugung von Python-Code sehr stark sind, wird hier ein verstärkter Effekt entstehen. Java ist durch seine Struktur eher nicht optimal für die Generierung durch LLMs aufgestellt.
Mark Paluch: Java ist ein fundamentaler Baustein moderner Softwareentwicklung und gleichzeitig wird Java jedes Jahr neu totgesagt. Jetzt sind wir hier nach 30 Jahren Java. Die Veränderungen in der Sprache und der Standardbibliothek zeigen, wie relevant Java ist. Derzeit ist für mich das Wichtigste, dass die Sprachentwicklung durch eine diverse Community vorangetrieben wird. Valhalla, Babylon und Leyden sind die bedeutendsten Projekte seit Generics und Functional Interfaces.
Entwicklung & Code
Microsoft: XAML Studio ist jetzt Open Source
Microsoft hat sein Entwicklungstool XAML Studio Open Source gestellt, acht Jahre nach dessen erstmaliger Veröffentlichung. Als nächstes steht Version 2.0 an, und es sind einige Neuerungen geplant, die Interessierte dank dem auf GitHub befindlichen Quellcode bereits ausprobieren können.
Weiterlesen nach der Anzeige
XAML Studio ist ein Rapid-Prototyping-Tool für WinUI-Developer, die die XML-basierte Markup-Sprache XAML (eXtensible Application Markup Language) nutzen. Zu den Features von XAML Studio zählen Live-Editierung und -Interaktion, ein Binding-Debugger, ein Data-Context-Editor sowie automatisches Speichern und Wiederherstellen von Dokumenten. Nachdem Entwicklerinnen und Entwickler ihren Code in XAML Studio geprüft haben, können sie diesen in Visual Studio kopieren.
XAML Studio 2.0 bringt Eigenschaften-Panel und Fluent UI
Derzeit ist Version 1.1 das aktuelle Release, das sich aus dem Microsoft Store beziehen lässt. Auf GitHub ist jedoch schon der Quellcode für die nächste geplante Version XAML Studio 2.0 mit neuen, teils experimentellen Features zu finden.
Die GitHub-Diskussion #44 bietet einen Blick auf das neue Live Properties Panel.
(Bild: Microsoft)
Zu den neuen Features zählen die überarbeitete Optik im Fluent-UI-Design, ein Echtzeit-Panel für den Umgang mit Eigenschaften (Ändern, Inspizieren und Experimentieren), Visual-Tree- und Visual-State-Explorer als Teil des Eigenschaftspanels und ein Rechtsklick-Menü zum Duplizieren des geöffneten Tabs. Daneben wurden die Libraries aktualisiert und Bugs behoben.
XAML Studio ging einst aus einem experimentellen Projekt im Rahmen der Microsoft Garage hervor. Laut der neuen Ankündigung auf Microsofts Entwicklerblog bestand bereits seit einer frühen Phase das Ziel, XAML Studio quelloffen zur Verfügung zu stellen. Die Roadmap bietet die Möglichkeit, den Weg zu Version 2.0 mitzuverfolgen.
Weiterlesen nach der Anzeige
(mai)
Entwicklung & Code
Software Testing: Thermomanagement bei E-Autos testen
In dieser Episode sprechen Richard Seidl und Patrick Meuth über Thermomanagement-Software in Elektroautos. Getestet wird bei Fahrten auf der Straße und mit Hardware-in-the-Loop (HIL). Zur Nutzung kommt ein virtuelles Steuergerät, das nur die Thermofunktionen ausführt. So sinken Kosten und Fehler werden früher sichtbar.
Weiterlesen nach der Anzeige
Im Fokus stehen Alltagsszenarien zwischen Wüste und Tiefgarage: Batterie schützen, Innenraum kühlen, Leistung priorisieren, Reichweite sichern.
Über Patrick Meuth
Patrick Meuth begann 2016 seine berufliche Laufbahn bei der TKI Automotive mit seiner Bachelorarbeit im Bereich modellbasiertes Testen. Anschließend wurde er 2017 als Testingenieur für Systemabsicherungen an HIL-Prüfständen übernommen. Durch seine Erfahrungen in verschiedenen Projekten entwickelte er sich kontinuierlich weiter und wurde 2020 zum Senior Test Engineer und anschließend zum Testmanager ernannt. Mit dem Übergang zur Cariad 2021 setzte er seine Tätigkeit als Testmanager fort. Seither leitet er das Team zur Systemabsicherung in einer agilen Struktur und übernahm als Product Owner die fachliche Verantwortung.
Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.
Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Thermomanagement bei E-Autos testen – Patrick Meuth“ und steht auf YouTube bereit.
Weiterlesen nach der Anzeige
(mdo)
-
UX/UI & Webdesignvor 3 MonatenIllustrierte Reise nach New York City › PAGE online
-
Künstliche Intelligenzvor 3 MonatenAus Softwarefehlern lernen – Teil 3: Eine Marssonde gerät außer Kontrolle
-
Künstliche Intelligenzvor 3 Monaten
Top 10: Die beste kabellose Überwachungskamera im Test
-
UX/UI & Webdesignvor 3 MonatenSK Rapid Wien erneuert visuelle Identität
-
Künstliche Intelligenzvor 3 MonatenNeue PC-Spiele im November 2025: „Anno 117: Pax Romana“
-
Entwicklung & Codevor 2 MonatenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
Künstliche Intelligenzvor 3 MonatenDonnerstag: Deutsches Flugtaxi-Start-up am Ende, KI-Rechenzentren mit ARM-Chips
-
UX/UI & Webdesignvor 2 MonatenArndt Benedikt rebranded GreatVita › PAGE online
