Anmelden
(Bild: Pincasso / Shutterstock.com)
Ein Upgrade einer File-based App zu einem normalen C#-Projekt ist möglich.
Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps [1]. Wenn die Anforderungen höher werden, sind File-based Apps keine Sackgasse.
Entwicklerinnen und Entwickler können per Kommandozeilenbefehl aus einer File-based App ein C#-Projekt mit .csproj-Projektdatei machen:
dotnet project convert .\Dateiname.cs
Dabei wird ein neuer Ordner angelegt und eine Projektdatei angelegt, die die Präprozessor-Informationen aus der C#-Datei übernimmt.
Sollten die Dateien Dateiname.settings.json und Dateiname.run.json vorhanden sein, werden sie beim Konvertieren allerdings ignoriert.
URL dieses Artikels:
https://www.heise.de/-11257899
Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-10-0-13-Kompilieren-und-Starten-einzelner-C-Dateien-11201372.html
[2] mailto:rme@ix.de
Copyright © 2026 Heise Medien
(Bild: SWstock / Shutterstock.com)
Die Foreign Function & Memory API bietet in Java einen deutlich einfacheren Zugang zu Funktionen in C-Libraries als das veraltete JNI.
Javas Foreign Function & Memory API (FFM) dient dazu, auf Code in einer Shared Library beziehungsweise DLL zuzugreifen, der in einer Programmiersprache wie C oder Rust geschrieben ist. Allerdings muss der Code dazu einige Voraussetzungen erfüllen. Diese dreiteilige Artikelserie zeigt anhand einer in C geschriebenen Demo-Library, wie eine Java-Anwendung die Funktionen der Bibliothek aufruft, welche Vorbereitungen erforderlich sind und welche Regeln zu beachten sind. Der Sammelbegriff „Shared Library“ steht in den Artikeln gleichermaßen für eine Shared Library unter Unix wie für eine Windows-DLL.
Der Ausgangspunkt der Arbeit mit FFM war meine Suche nach einem Weg, per Java auf ein Hardware-Sicherheitsmodul (HSM) zuzugreifen. Da aber noch kein physisches HSM vorhanden war, suchte ich nach einer softwaregestützten Umsetzung. Die Applikation SoftHSM2 lässt sich mit PKCS11 ansprechen, aber der Pkcs#11-Treiber von Sun ist veraltet. Da ich keine passende Open-Source-Anwendung gefunden habe, entwickelte ich selbst einen PKCS11-Wrapper für Java auf Basis der FFM-API.
Da das Projekt sehr umfangreich ist, steht für diese dreiteilige Artikelserie eine eigens entwickelte C-Library im Fokus, die dazu dient, die Konzepte der FFM-API zu erläutern. Die kleine Demo-Library [1] ist auf Windows und Linux getestet.
In Java gab es vor dem FFM mit dem Java Native Interface (JNI) seit Langem einen Weg, um auf in C geschriebenen Code zuzugreifen. Das JNI war allerdings sehr kompliziert und fehlerbehaftet.
Daher begannen im JDK 14 (Java Development Kit) die Arbeiten an einer neuen Schnittstelle: Foreign Function & Memory API [2]. Die Java-Community hat sie über einige JDK-Versionen und JEPs hinweg verfeinert und schließlich in JDK 22 finalisiert. Allerdings erschien sie im JDK 24 [3] nochmals in veränderter Form. Wegen einiger Breaking Changes ist die API aus Java 24 nicht zu der in Java 22 kompatibel. Dieser Artikel beschreibt die aktuelle Version aus dem JDK 24.
Um die FFM-API zu nutzen, gelten folgende Voraussetzungen:
Der Ausgangspunkt für FFM ist immer eine Header-Datei, die in C die Funktionen und gegebenenfalls Typen der Shared Library beschreibt.
Die in C entwickelte Beispiel-Library enthält nur wenige Funktionen und einen Datentyp:
FreshRSS #ifdef _WIN32
#define EXPORT __declspec(dllexport)
#else
#define EXPORT
#endif
typedef struct
{
double x;
double y;
} Point;
#define VERSION 1
EXPORT void initialize(void);
EXPORT int getVersion(void);
EXPORT void getVersion2(int *version);
EXPORT long add(long a, long b);
EXPORT double calcAverage(int *lvalues, int size);
EXPORT double distance(Point *p1, Point *p2);
Es gibt nur eine einzige Typdefinition (Point) und wenige Funktionen. Die Direktive #ifdef im Header-File sorgt dafür, dass sich der Code sowohl unter Linux als auch unter Windows kompilieren lässt.
Das Tool jextract [4] hilft beim Zugriff auf native Funktionen. Ausgangspunkt ist auch hier wieder eine Header-Datei, um die notwendigen Zugriffsmethoden für die Funktionen aus der Shared Library zu erzeugen.
jextract kämpft jedoch mit diversen Schwierigkeiten. Zunächst ist es nicht für jedes JDK verfügbar – nach JDK 22 erst wieder für JDK 25. Für die Demo-Library zum Artikel hat die Version aus JDK 22 zwei Klassen generiert: Point für den Zugriff auf die Datenstruktur und DemoLib_h, um auf die Funktionen zuzugreifen. Die Klasse Point hat einen Umfang von etwa 170 schlecht leserlichen Codezeilen, und die Klasse DemoLib_h hat weitere 390 Zeilen Code, die ebenfalls schwer lesbar sind.
Bei komplexen Header-Files ist der Einsatz von jextract noch schwieriger. Beim Versuch, einen Wrapper für PKCS11 zu erzeugen, brach jextract im Zusammenspiel mit dem JDK 22 ab. Die Header-Datei pkcs11.h lädt zwei weitere Header-Dateien nach. Das führte zum Abbruch mit Fehlermeldungen, dass inkompatible Typ-Redefinitionen vorhanden seien.
jextract ist derzeit nur für kleine Projekte einsatzbereit – und auch das mit Einschränkungen. Aufgrund des schwer lesbaren Codes ist es keine Vorlage für eigenen Code. Daher ist der deutlich bessere Ansatz, den Code selbst zu entwickeln und das entsprechende Know-how aufzubauen, um den Code zu verstehen.
Die Vorgehensweise ist ähnlich wie beim Einsatz von Reflection in Java. Um Funktionen aufzurufen, muss man ein MethodHandle erzeugen, das die Klasse Linker benötigt. Zusätzlich muss man die Shared Library laden.
Folgendes Listing zeigt die Vorbereitungen in der Klasse Main und den Aufruf der Demolib:
public class Main
{
private final Linker linker;
private final SymbolLookup lookup;
private final Path libPath;
private String pathWindows = "D:/DemoLib/DemoLib.dll";
private String pathLinux = "/opt/projects/c/DemoLib/DemoLib.so";
public Main()
{
linker = Linker.nativeLinker();
libPath = getLibPath();
lookup = SymbolLookup.libraryLookup(libPath, Arena.ofAuto());
}
public static void main(String[] args) throws Throwable
{
Main app = new Main();
app.runDemo();
}
public void runDemo()
{
int version;
try
{
initialize();
version = getVersion();
System.out.println("Version (1) DemoLib = " + version);
version = getVersion2();
System.out.println("Version (2) DemoLib = " + version);
int a = 7;
int b = 9;
int result = add(a, b);
System.out.println(a + " + " + b + " = " + result);
double average = calcAverage(new int[] {1, 2, 3, 4, 5});
System.out.println("Average : " + average);
Point p1 = new Point(1, 1);
Point p2 = new Point(3, 3);
double distanz = distance(p1, p2);
System.out.println("Distanz zwischen Punkt " + p1 + " und " + p2 + " : " +
distanz);
}
catch (Throwable e)
{
e.printStackTrace();
}
}
}
Die Methode libraryLookup() der Klasse SymbolLookup lädt die Shared Library. Mit SymbolLookup lassen sich anschließend die einzelnen Funktionen der Library bereitstellen.
Zum Laden der Library ist neben dem Pfad auch eine Arena erforderlich. Eine Arena ist analog zur Garbage Collection ein Memory Manager für fremden Speicher, den die Java Virtual Machine (JVM) nicht verwaltet. Es gibt mehrere Arten von Arenas:
| Arena-Methode | Lebensdauer | Typische Verwendung |
| Arena.ofConfined() | Der Speicher lässt sich nur im aktuellen Thread nutzen und wird beim Aufruf von close() freigegeben, beispielsweise bei try-with-resources. | Standardfall |
| Arena.ofAuto() | Der Speicher wird vom Garbage Collector freigegeben, wenn das Arena-Objekt nicht mehr erreichbar ist. | Wenn im Vorfeld nicht bekannt ist, wann der Speicher freigegeben werden soll und deshalb keine manuelle Freigabe möglich ist. Beispiel: SymbolLookup beim Laden der Library. |
| Arena.ofShared() | Der Speicher kann von mehreren Threads genutzt werden und muss manuell geschlossen werden. | Wenn mehrere Threads auf denselben nativen Speicher zugreifen müssen. |
| Arena.ofGlobal() | Der allokierte Speicher wird nie freigegeben und lebt bis zum Prozessende. | Für alle dauerhaften Daten |
| Arena.ofScope() | Ermöglicht benutzerdefinierten Scope. Die Freigabe des Speichers erfolgt, wenn der Scope endet. | Spezialfall, wenn eine komplexe Lebenszyklus-Steuerung erforderlich ist. |
Das Aufrufen von externen Funktionen erfordert folgende Schritte:
lookup.find() nach der gewünschten Funktion. Die Suche nach einer nicht vorhandenen Funktion löst eine NoSuchElementException aus.lookup.find() ein passendes MemorySegment zurück: eine Referenz, mit der man auf das Native Memory zugreifen kann.downcallHandle des Linkers erzeugt aus dem MemorySegment und einem FunctionDescriptor einen MethodHandle.FunctionDescriptor dient dazu, die Signatur der Funktion (Rückgabewert, Parameter) zu beschreiben.WrongMethodTypeException aus.MethodHandle kann die Java-Anwendung mit der Methode invoke die gewünschte Funktion mit den passenden Parametern aufrufen.Als Erstes soll die Beispielanwendung die einfachste Funktion der Library aufrufen: initialize hat weder einen Rückgabewert noch Parameter. Die Java-Methode in der Main-Klasse, die die Library-Funktion aufruft, heißt ebenfalls initialize():
public void initialize() throws Throwable
{
MethodHandle initialize =
linker.downcallHandle(lookup.find("initialize").orElseThrow(),
FunctionDescriptor.ofVoid());
initialize.invoke();
}
Die Systematik ist bei jedem Funktionsaufruf identisch und erfordert lediglich eine Anpassung der Namen und Signaturen. invoke() ruft die externe Funktion auf. Falls die Funktion einen Rückgabewert hat, muss die aufrufende Java-Methode ihn auf den richtigen Typ casten.
Da die Vorgehensweise immer dieselbe ist, lohnt sich eine kleine Helper-Methode, die den MethodHandle holt:
public MethodHandle getMethodHandle(String methodName,
FunctionDescriptor funcDescriptor) throws Throwable
{
MethodHandle method =
linker.downcallHandle(lookup.find(methodName).orElseThrow(),
funcDescriptor);
return method;
}
Dadurch vereinfacht sich die Methode initialize() zu
public void initialize() throws Throwable
{
MethodHandle method = getMethodHandle("initialize",
FunctionDescriptor.ofVoid());
return method.invoke();
}
Eine weitere Möglichkeit zur Vereinfachung wäre, in einer Methode invokeFunction das Throwable zu fangen und stattdessen eine eigene RuntimeException auszulösen. Dadurch muss nicht jeder Aufrufer das generische Throwable abfangen und behandeln.
Etwas komplizierter wird es, wenn man Funktionen aufrufen will, die Parameter benötigen, oder wenn die Anwendung die Rückgabewerte der Library-Funktion auswerten muss. Das nächste Beispiel zeigt anhand der Funktion getVersion(), wie sich zurückgegebene Werte auswerten lassen.
Dafür ist ein FunctionDescriptor erforderlich, der einen int-Wert zurückgibt:
public int getVersion() throws Throwable
{
MethodHandle method = getMethodHandle("getVersion",
FunctionDescriptor.of(ValueLayout.JAVA_INT));
return (int) method.invoke();
}invoke() ruft wieder die externe Funktion auf und erfordert diesmal einen Cast auf den korrekten Rückgabewert int.
Die Methode FunctionDescriptor.of() nimmt einen oder mehrere Parameter entgegen, die den Rückgabewert und die Parameter beschreiben. Der Rückgabewert steht dabei immer an der ersten Stelle. Im Beispiel hat die Funktion getVersion keine Parameter, sodass der FunctionDescriptor folgendermaßen lautet:
FunctionDescriptor.of(ValueLayout.JAVA_INT)
Das Interface ValueLayout beschreibt die Java-Datentypen, die den C-Datentypen entsprechen: ValueLayout.JAVA_INT ist das Pendant zum Datentyp int in C.
Die Entwicklerinnen und Entwickler sind selbst dafür verantwortlich, die korrekten Mappings für die Datentypen auszuwählen. Der Compiler hilft dabei nur wenig. Im obigen Beispiel würde er nur dann einen Fehler melden, wenn der Typecast und der Rückgabewert der Java-Methode getVersion() nicht zusammenpassen. Würde man dagegen fälschlicherweise einen long-Wert verwenden (FunctionDescriptor.of(ValueLayout.JAVA_LONG)), gäbe es keine Fehler beim Kompilieren, sondern eventuell eine ClassCastException zur Laufzeit.
Wenn in der Anwendung alle Werte als long gekennzeichnet sind, könnte die Exception jedoch ausbleiben und das Ergebnis je nach Plattform unterschiedlich und eventuell nicht korrekt sein.
Anhand der Funktion add zeigt der Artikel im Folgenden den Aufruf von Funktionen mit Parametern. add hat long als Rückgabewert und zwei long-Werte als Parameter. Zu beachten ist, dass es sich um long-Werte aus C handelt, die nicht unbedingt identisch mit den Datentypen in Java sind.
In C ist die Größe des Datentyps von der Plattform abhängig: In Windows hat ein long-Wert 4 Bytes, in Linux dagegen 8 Bytes. Das verursacht in der Regel keine Probleme, wenn es sich um Parameter handelt, die der Aufrufer als Wert übergibt (Call by Value). Wenn die C-Funktion die übergebenen Werte allerdings verändert, muss der Aufrufer die Adresse übergeben (Call by Reference). In dem Fall muss der Typ der übergebenen Variable unbedingt zur Angabe im FunctionDescriptor passen.
Das folgende Beispiel betrachtet zunächst die einfache Variante mit Call by Value:
public int add(int a, int b) throws Throwable
{
MethodHandle method = getMethodHandle("add", FunctionDescriptor.of(
ValueLayout.JAVA_INT, // return value
ValueLayout.JAVA_INT, // a
ValueLayout.JAVA_INT // b
));
return (int) method.invoke(a, b);
}
Auch wenn der FunctionDescriptor komplexer ist als die Deskriptoren ohne Parameter, ist er leicht zu verstehen: Der erste Parameter beschreibt wieder den Rückgabewert und die anderen beiden die Parameter der Funktion add(). Es handelt sich also um eine Funktion mit dem Datentyp int als Ergebnis und zwei Parametern, die ebenfalls int-Werte sind.
Die Typbeschreibung bezieht sich auf Java, hat also jeweils 4 Bytes. In C können das je nach Zielplattform Werte mit 4 oder 8 Bytes sein.
Der Aufruf von Funktionen in externen C-Libraries ist mit der Foreign Function & Memory API deutlich einfacher und weniger fehleranfällig als über das veraltete JNI. Wichtig ist eine exakte Beschreibung der aufzurufenden Funktion inklusive des Rückgabewerts und der Parameter.
Nachdem der erste Teil der dreiteiligen Artikelserie gezeigt hat, wie man in Java eine in C geschriebene Shared Library lädt und einfache Funktion dieser Shared Library aufruft, wird sich der nächste Teil komplexeren Szenarien widmen. Er wird zeigen, wie man aus Java C-Funktionen mit veränderbarem Parameter aufrufen und Arrays sowie Strukturen übergeben kann.
URL dieses Artikels:
https://www.heise.de/-11255043
Links in diesem Artikel:
[1] https://github.com/rz259/ffm-demo/
[2] https://openjdk.org/jeps/454
[3] https://www.heise.de/blog/Java-Die-nicht-so-bekannten-Features-des-OpenJDK-24-10322221.html
[4] https://github.com/openjdk/jextract
[5] mailto:rme@ix.de
Copyright © 2026 Heise Medien
Michael O. Rabin
(Bild: Andrej Bauer, CC BY-SA 2.5 SI)
Im Alter von 94 Jahren ist Michael Oser Rabin gestorben. Er war der einzige Empfänger des Turing-Awards, der im Deutschen Reich geboren wurde.
Michael O. Rabin wurde als Sohn des Rabbiners Israel Rabin und der Schriftstellerin Ester Rabin am 1. September 1931 in Breslau geboren. Die Familie wanderte 1935 in das britische Mandatsgebiet für Palästina aus. Sein mathematisches Interesse wurde durch seinen Lehrer Elisha Netanyahu mit der Aufnahme in einen kleinen Kreis interessierter Schüler gefördert. Als er mit 16 Jahren 1948 im israelisch-arabischen Krieg in die Armee eingezogen werden sollte, setzte sich der berühmte Mathematiker Abraham Fraenkel für seine weitere Ausbildung an der Universität ein. 1952 schloss Rabin das Studium mit einer Masterarbeit über ein von Emmy Noether entdecktes Problem ab, was ihm ein Stipendium an der Universität Princeton einbrachte. Dort studierte er zusammen mit Dana Scott bei Alonzo Church [1], bei dem auch Alan Turing studiert hatte.
Rabin und Scott wurden im Sommer 1957 von IBM eingeladen und schrieben dort die Arbeit über „Finite Automata and Their Decision Problems“, in der sie sich mit den (heute so genannten) neuronalen Netzwerken von Warren McCulloch und Walter Pitts [2] beschäftigten. 1956 hatte der Logiker Stephen Cole Kleene mit seinem Theorem die Klasse der regulären Sprachen in die Informatik eingeführt und deshalb konnten Rabin und Scott mit ihrer Arbeit über nichtdeterministische Automaten Kleenes Annahmen bestätigen. „Wir hatten eigentlich keinen tieferen philosophischen Grund, diesen Nichtdeterminismus in Betracht zu ziehen, obwohl er, wie wir heute wissen, im Zentrum der P = NP-Frage steht – einem Problem von immenser praktischer und theoretischer Bedeutung. Für uns war das lediglich eine von mehreren Varianten“, sagte Rabin im Interview [3] über seinen Lebensweg, das er seinem Schüler Dennis Shasha gewährte. Im Jahre 1976 bekamen er und Scott für diese Arbeit den Turing Award [4], was bis heute Gegenstand von angeregten Diskussionen [5] ist.
Nach dieser Episode beschäftigte sich Rabin mit kryptographischen Problemen, angeregt über ein Problem, das ihm John McCarthy [6] gestellt hat: Wie kann ein Spion, der sein Passwort sagt, zuverlässig von einem Wächter erkannt werden, der das Passwort errechnen soll? Die Antwort war der Aufsatz „Probabilistic Algorithm for Testing Primality“ von Rabin. Der Primzahlentest, heute als Miller-Rabin-Test [7] bekannt, liefert nach sechs Tests bei langen Zahlen schnell mit einer Wahrscheinlichkeit von 99,9 Prozent die Antwort auf die Frage, ob eine Zahl eine Primzahl ist und wird deshalb in vielen kryptografischen Anwendungen eingesetzt. Mit seinem Aufsatz „Digitalized Signatures and Public-Key Functions as Intractable as Factorization“ lieferte Rabin 1979 die Grundlagen für das Rabin-Kryptosystem, das im Gegensatz zum Primzahlentest kaum genutzt wird.
Später war Rabin nach jahrelanger Forschung und Lehre an der Hebrew University, deren Rektor er zeitweilig war, ab 1982 wieder bei IBM und gehörte dort bis 1994 zum Science Advisory Committee. 1987 entwickelte er mit Richard M. Karp den Rabin-Karp-Algorithmus, der bei der Suche nach Plagiaten mit einem effizienten Hash-Verfahren aufwartet. Im Interview über seinen Lebensweg schildert er, wie wichtig die Rolle des Zufalls für seine Arbeit gewesen ist. „Das Einwirken von Zufall bei so vielen algorithmischen Problemen ist mir völlig rätselhaft. Es ist effizient, es funktioniert; aber warum und wie, ist mir ein absolutes Rätsel. Algorithmen benötigen in ihrer Reinform eine physikalische Zufallsquelle. Es handelt sich also um eine Art Zusammenarbeit zwischen uns Informatikern und der Natur als Quelle des Zufalls. Das ist einzigartig und wirft einige Fragen in der Physik und Philosophie auf.“
URL dieses Artikels:
https://www.heise.de/-11261362
Links in diesem Artikel:
[1] https://www.genealogy.math.ndsu.nodak.edu/id.php?id=8011
[2] https://www.heise.de/hintergrund/Zahlen-bitte-Von-2-AND-1-OR-0-NOT-die-wegweisende-McCulloch-Pitts-Zelle-6268289.html
[3] https://cacm.acm.org/news/an-interview-with-michael-rabin/
[4] https://amturing.acm.org/award_winners/rabin_9681074.cfm
[5] https://rjlipton.com/2023/01/19/rabin-scott-time/
[6] https://www.heise.de/news/Requiescat-in-pace-Zum-Tod-von-John-McCarthy-1366069.html
[7] https://asecuritysite.com/primes/rabintest?val=982451652
[8] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[9] mailto:mho@heise.de
Copyright © 2026 Heise Medien
Google testet in der Android Canary-Version vom April ein erweitertes Kontextmenü.
(Bild: Andreas Floemer / heise medien)
In der aktuellen Android-Canary-Version testet Google ein kompakteres, zweigeteiltes Kontextmenü für App-Icons sowie eine neue Benachrichtigungsanzeige.
Google veröffentlicht einmal pro Monat eine neue Version von Android Canary. Das ist ein hochexperimenteller Android-Build, der sich in erster Linie an Entwickler und Hardcore-Fans richtet und seit Juli 2025 die Developer-Previews ersetzt [1]. In der neuen April-Version steckt oberflächlich lediglich eine größere Veränderung, mit der das Kontextmenü von App-Icons aufgebohrt wird – und eine weitere winzige Änderung. Die Canary-Funktionen finden nicht zwingend ihren Weg in die finalen Versionen.
Die neue Canary-Version 2604 mit der Buildnummer ZP11.260320.007 steht zunächst für das Pixel 8 und neuer zum Ausprobieren bereit, ist aber nicht für den Alltagsgebrauch geeignet. Später soll der Canary-Release auch für ältere Modelle wie das Pixel 6 und weitere bereitgestellt werden, schreibt Google [2]. Das experimentelle Betriebssystem zeigt, woran Google arbeitet, beziehungsweise was der Konzern davon zeigen möchte.
Vieles – vor allem KI-Funktionen – enthüllt das Unternehmen erst dann, wenn es weitgehend fertig ist. Bestätigt hat Google, dass Android 17 und künftige Versionen mehr agentische Fähigkeiten bekommen [3] soll. Der Chef des Android-Ökosystems sagte dazu: „Wir bewegen uns weg von einem Betriebssystem hin zu einem intelligenten System, einer Plattform, die Sie wirklich versteht und für Sie arbeitet.“
In der Canary-Version backt Google kleinere Brötchen: Sie enthält ein überarbeitetes Kontextmenü für Apps, das sich durch einen Langdruck auf ein App-Icon öffnen lässt. Das Menü ist zum einen etwa kompakter gestaltet und zum anderen zweigeteilt. Nach dem Öffnen zeigt das Menü zuerst die Schnellzugriffe, ein weiterer Button öffnet eine Übersicht mit Aktionen. Die in der März-Version getestete App-Lock-Funktion, mit der man einzelne Apps mit einer Sperre versehen kann, ist in dieser Version verschwunden.
(Bild: Andreas Floemer / heise medien)
Eine weitere kleine Änderung ist die Anzeige nach dem Entfernen sämtlicher Benachrichtigungen: Hier heißt es nun „Du bist auf dem aktuellen Stand“ begleitet von einem Pokal statt „Keine Benachrichtigungen“. Die neue Anzeige orientiert sich dabei an Wear OS 6 etwa auf der Pixel Watch, sodass es über das Ökosystem hinweg einheitlicher anmutet.
(Bild: Andreas Floemer/ heise medien)
Ob das neue Kontextmenü Teil von Android 17 wird, ist zwar noch offen. Allerdings flossen einige Features, die Google erst im März im Canary-Channel [4] getestet hatte, kurz danach in die Betaversion des großen Updates ein. Dazu gehören etwa App-Bubbles, um Android eine neue Multitasking-Option zu verpassen. Außerdem sind seit der Beta 3 von Android 17 WLAN- und Mobilfunkempfang wieder getrennt. Google hatte im Jahr 2021 mit Android 12 [5] eine einzige „Internet“-Kachel für beide Konnektivitäts-Optionen in die Schnelleinstellungen integriert, sodass es umständlicher war, eine der beiden Funktionen abzuschalten.
Wer sich die Canary-Version auf einem Gerät installiert, sollte sich im Klaren darüber sein, dass es nicht sonderlich einfach ist, zur stabilen Version zurückzukehren. Um keine Canary-OTA-Updates mehr zu erhalten, muss man einen Nicht-Canary-Build flashen, was eine vollständige Löschung aller Daten nach sich zieht. Hierfür bietet Google sein Android-Flash-Tool an.
URL dieses Artikels:
https://www.heise.de/-11260688
Links in diesem Artikel:
[1] https://www.heise.de/news/Android-Canary-Channel-Google-kuendigt-neuen-Spielplatz-fuer-Entwickler-an-10483754.html
[2] https://www.reddit.com/r/android_canary/comments/1slljkt/android_canary_2604_is_now_available/
[3] https://www.heise.de/news/Gemini-fuer-Android-wird-agentisch-KI-bestellt-Essen-oder-einen-Fahrdienst-11191444.html
[4] https://www.heise.de/news/Maerz-Update-Android-Canary-Version-bringt-neue-App-Sperre-und-alte-WLAN-Kachel-11220944.html
[5] https://www.heise.de/news/Aus-fuer-Android-12-und-12L-Google-beendet-Support-fuer-Millionen-Geraete-10352204.html
[6] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[7] mailto:afl@heise.de
Copyright © 2026 Heise Medien
(Bild: software-architektur.tv)
Im Gespräch mit Eberhard Wolff räumt Industrial-AI-Experte Nikita Golovko mit dem Missverständnis auf, LLMs seien gleichbedeutend mit KI.
In der aktuellen englischsprachigen Folge des Videocasts software-architektur.tv [1] diskutiert Eberhard Wolff mit Nikita Golovko über ein verbreitetes Missverständnis: Viele setzen Large Language Models (LLM) mit künstlicher Intelligenz gleich – doch gerade in industriellen Anwendungen greift das zu kurz.
Nikita Golovko arbeitet als Principal Architect Industrial AI bei Siemens und erläutert im Gespräch, warum die Unterscheidung zwischen LLMs, generativer KI und anderen KI-Methoden entscheidend ist. Jede dieser Technologien entfalte ihren Wert an unterschiedlichen Stellen – die richtige Zuordnung von Werkzeug und Problem führe zu besseren Ergebnissen, und das nicht nur in der Fertigung.
Im Zentrum der Diskussion steht die Frage, wie sich probabilistische KI-Systeme in deterministische Umgebungen integrieren lassen. Industrielle Automatisierung verlangt Zuverlässigkeit, Präzision und Kontrolle – Eigenschaften, die KI-Modelle mit ihrem inhärent unscharfen Verhalten nicht ohne Weiteres bieten. Nikita Golovko [2] betont, dass eine sichere Architektur nötig sei, die diesen Spannungsbogen auflöst. Während generative KI etwa bei kreativen oder explorativen Aufgaben punkten kann, eignen sich andere KI-Verfahren besser für Vorhersage- oder Optimierungsszenarien in der Produktion.
Die Folge wird am Freitag, 17. April 2026, live ab 13 Uhr gestreamt. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite [4] einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger [5] und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer [6] (Socreatory) und Ralf D. Müller [7] (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.
Golovko wird auch beim TechRiders Summit [8] auftreten, der am 17. und 18. Juni 2026 auf dem Euronova Campus in Hürth bei Köln stattfindet. Die Veranstaltung steht unter der Schirmherrschaft des Bundesministeriums für Digitales und Staatsmodernisierung und versammelt nach Angaben der Organisatoren über 140 Speaker, mehr als 20 Communitys und rund 2000 Teilnehmer. Themen wie Industrial AI, Edge-Systeme und Cybersecurity stehen auf dem Programm. Interessierte können sich mit einem Rabattcode ARCH-TECHRIDER-2026 [9] kostenfrei registrieren.
URL dieses Artikels:
https://www.heise.de/-11256985
Links in diesem Artikel:
[1] https://software-architektur.tv/
[2] https://www.linkedin.com/in/dr-nikita-golovko/
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://software-architektur.tv/
[5] https://www.heise.de/developer/Continuous-Architecture-2687847.html
[6] https://www.socreatory.com/de/trainers/lisa-moritz
[7] https://techstories.dbsystel.de/blog/profiles/Ralf-D.-Mueller.html
[8] https://tech-riders.de/
[9] https://app.tech-riders.de/offers/1/book?v=ARCH-TECHRIDER-2026&pr=10
[10] mailto:map@ix.de
Copyright © 2026 Heise Medien
(Bild: heise medien)
Nginx 1.30 ist da: ECH verschlüsselt den TLS-Handshake, Backends sprechen HTTP/2, und Multipath TCP nutzt mehrere Netzwerkpfade parallel.
Nginx 1.30.0 ist als neue Stable-Version erschienen und übernimmt zahlreiche Funktionen aus der 1.29.x-Mainline. Die wichtigsten Neuerungen betreffen moderne Webprotokolle und Transportmechanismen: HTTP Early Hints (103), HTTP/2-Verbindungen zu Backends, Encrypted ClientHello (ECH), Multipath TCP und Sticky Sessions. Außerdem ändert sich ein Standardverhalten: Das Proxy-Modul nutzt für Backend-Verbindungen nun HTTP/1.1 mit Keep-Alive.
Nginx ist ein weit verbreiteter Open-Source-Webserver, Reverse Proxy und Load Balancer, der vor allem in hochskalierenden Webanwendungen und Cloud-Umgebungen zum Einsatz kommt. Die Stable-Releases übernehmen erprobte Funktionen aus der Mainline und gelten als für den Produktiveinsatz geeignet.
Mit HTTP Early Hints kann Nginx Clients schon vor der eigentlichen Antwort auf benötigte Ressourcen hinweisen. Der Server schickt dazu einen HTTP-Statuscode 103 mit Preload-Headern, sodass Browser frühzeitig CSS- oder JavaScript-Dateien laden können – etwa während das Backend noch Inhalte rendert. Das verkürzt die wahrgenommene Ladezeit.
Neu ist auch die Möglichkeit, Backend-Server über HTTP/2 anzusprechen. Bisher nutzte Nginx für diese Verbindungen typischerweise HTTP/1.1. HTTP/2 erlaubt Multiplexing, also mehrere parallele Requests über eine einzige Verbindung. Davon profitieren vor allem Microservice-Architekturen, in denen ein API-Gateway viele Backend-Endpunkte gleichzeitig anspricht.
Eine kleine, aber praxisrelevante Änderung: Das Proxy-Modul verwendet nun standardmäßig HTTP/1.1 mit Keep-Alive für Backend-Verbindungen. Bestehende Verbindungen lassen sich so wiederverwenden, was die Zahl der Verbindungsaufbauten senkt und die Performance bei vielen kurzen Requests verbessert.
Mit Encrypted ClientHello (ECH) verschlüsselt Nginx Teile des TLS-Handshakes – insbesondere die Server Name Indication (SNI). Dritte können damit beim Verbindungsaufbau nicht mehr erkennen, welche Domain ein Client anfragt. Die Integration setzt auf aktuelle OpenSSL-Schnittstellen und umfasst Anpassungen bei Logging und Fehlerbehandlung.
Ebenfalls neu: Unterstützung für Multipath TCP (MPTCP). Die Technik nutzt mehrere Netzwerkpfade gleichzeitig, etwa WLAN und Mobilfunk parallel. Verbindungen werden dadurch stabiler und können im Idealfall höhere Bandbreiten erreichen. Voraussetzung ist allerdings MPTCP-Support auf Betriebssystem- und Netzwerkebene.
Fürs Load Balancing bringt Nginx 1.30 Sticky Sessions mit. Sie leiten Anfragen eines Clients konsistent an denselben Backend-Server weiter. Das hilft bei zustandsbehafteten Anwendungen, die Session-Daten nicht zentral speichern. Das Keepalive-Modul für Upstreams ist nun standardmäßig aktiv. Zusammen mit dem geänderten Proxy-Verhalten (HTTP/1.1 mit Keep-Alive) reduziert das den Overhead bei der Verbindungsverwaltung zu Backends spürbar.
Das Release enthält zahlreiche Verbesserungen rund um HTTP/3 und QUIC – darunter Stabilitätsfixes, Anpassungen an neue OpenSSL-3.5-APIs und Optimierungen beim Verbindungsmanagement. Hinzu kommt Unterstützung für TLS-Zertifikatskompression, die den Handshake schlanker macht. Das zahlt sich vor allem bei mobilen Clients und HTTP/3-Verbindungen aus.
Im TLS-Stack gibt es neue Callback-Mechanismen bei der ClientHello-Verarbeitung, die eine flexiblere Zertifikatsauswahl ermöglichen. Gleichzeitig hat das Projekt die Kompatibilität mit OpenSSL 4.0, BoringSSL und AWS-LC erweitert.
Auf der Konfigurationsseite gibt es unter anderem eine neue max_headers-Direktive, die die Zahl der erlaubten Header begrenzt und so vor Missbrauch schützt. Auf macOS lassen sich jetzt TCP-Keepalive-Parameter konfigurieren.
Wie üblich umfasst das Release viele Bugfixes – unter anderem bei HTTP/2, HTTP/3, Proxying, gRPC und den Mail-Modulen. Die Entwickler haben dabei auch fehlerhafte Header-Verarbeitung, Integer-Überläufe und Validierungsfehler behoben.
Alle Informationen zu Nginx 1.30.0 finden sich in den Release Notes auf der GitHub-Projektseite [1].
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11258903
Links in diesem Artikel:
[1] https://github.com/nginx/nginx/releases/tag/release-1.30.0
[2] https://www.heise.de/download/product/nginx-60882?wt_mc=intern.red.download.tickermeldung.ho.link.link
[3] https://www.heise.de/ix
[4] mailto:fo@heise.de
Copyright © 2026 Heise Medien
(Bild: Alexander Supertramp / Shutterstock.com)
KI erzeugt Code schneller, als Teams ihn verstehen können. Thoughtworks fordert im Technology Radar Vol. 34 eine Rückbesinnung auf Engineering-Grundlagen.
Das Technologieberatungsunternehmen Thoughtworks hat die 34. Ausgabe seines halbjährlichen Technology Radar veröffentlicht. Zentrales Thema: sogenannte kognitive Schulden, die entstehen, wenn künstliche Intelligenz immer größere Codemengen generiert und das gemeinsame Verständnis von Softwaresystemen in Entwicklerteams schneller erodiert, als es sich erneuern lässt.
Während frühere Ausgaben des Radars die wachsenden Fähigkeiten von KI im Software-Engineering beleuchteten, verschiebt sich der Fokus dem aktuellen Report zufolge [1] nun auf die Risiken beim Skalieren und im produktiven Einsatz. Der Unterschied zu klassischen technischen Schulden ist dabei wesentlich: Technische Schulden stecken im Code selbst, kognitive Schulden dagegen in den Köpfen der Entwicklerinnen und Entwickler. Die Kluft zwischen Mensch und System wird größer, wenn KI-generierter Code schneller entsteht, als Teams ihn durchdringen können.
Thoughtworks-CTO Rachel Laycock formuliert es so: „Der Wendepunkt, an dem wir uns befinden, hat weniger mit Technologie zu tun – es geht vielmehr um die Methode“. Die KI-Fähigkeiten haben sich im vergangenen Jahr in atemberaubendem Tempo entwickelt. Doch statt den Menschen zu verdrängen, zeige sich, dass geeignete Praktiken und technische Kontrollmechanismen nötig seien, um diese Fähigkeiten sicher und effektiv einzusetzen.
Ein zentrales Konzept des Radars sind sogenannte Harnesses – technische Kontrollmechanismen für KI-gestützte Coding-Agenten. Diese unterteilen sich in zwei Kategorien: Feedforward-Kontrollen steuern vor der Ausführung, etwa durch Agent Skills oder spezifikationsgetriebene Entwicklung. Feedback-Systeme hingegen beobachten die Ergebnisse nach der Ausführung – beispielsweise durch Mutationstests – und lösen eine Selbstkorrektur aus, bevor ein Mensch eingreifen muss. Ausführlich beschreibt dieses Konzept ein Artikel zu Harness Engineering von Birgitta Böckeler [2].
Ein weiterer Schwerpunkt liegt auf der Absicherung von KI-Agenten, die zunehmend Zugriff auf private Daten und externe Systeme benötigen. Thoughtworks empfiehlt dafür Zero-Trust-Architekturen, Sandboxing und Defense-in-Depth-Strategien. Das Spannungsfeld zwischen maximalem Nutzen und Sicherheitsrisiken erfordere Prinzipien wie explizite Verifikation und minimale Rechtevergabe – Grundsätze, die auch mit Datenschutzanforderungen wie der DSGVO harmonieren.
Darüber hinaus empfiehlt der Radar eine Rückkehr zu bewährten Metriken wie den DORA-Kennzahlen (Deployment Frequency, Lead Time for Changes, Mean Time to Restore und Change Fail Percentage), um die steigende Komplexität messbar zu machen. Auch die Bewertung neuer Technologien werde durch einen Marktstau kleiner KI-Projekte und semantische Diffusion – also uneinheitliche Begriffsverwendung – zunehmend erschwert.
Die Warnung vor kognitiven Schulden fügt sich in eine breitere Debatte ein. Wie auch andere Studien [3] zeigen, beschleunigt generative KI zwar das Schreiben von Code, macht aber die Verifikation aufwendiger. Der Engpass verschiebt sich vom Erzeugen zum Verstehen und Prüfen. Genau an dieser Stelle setzt der Technology Radar an und fordert eine Rückbesinnung auf Engineering-Grundlagen, um die wachsenden Fähigkeiten von KI nachhaltig nutzen zu können.
Der interaktive Technology Radar [4] steht online zur Verfügung, ein PDF-Download ist ebenfalls möglich.
URL dieses Artikels:
https://www.heise.de/-11258863
Links in diesem Artikel:
[1] https://www.thoughtworks.com/about-us/news/2026/combat-ai-cognitive-debt-radar-v34
[2] https://martinfowler.com/articles/harness-engineering.html
[3] https://www.heise.de/news/KI-Code-Schneller-geschrieben-langsamer-getestet-11215818.html
[4] https://www.thoughtworks.com/radar
[5] mailto:map@ix.de
Copyright © 2026 Heise Medien
(Bild: Andrey Suslov / Shutterstock.com)
Das Open-Source-Framework bringt ein experimentelles Animations-Backend und lagert das Testing-Framework Jest in ein eigenes Paket aus.
Das Unternehmen Meta hat React Native 0.85 veröffentlicht. Entwicklerinnen und Entwickler können darin ein neues Animations-Backend nutzen und erhalten neue Features in den DevTools. Node.js-Versionen, die ihr End-of-Life-Datum erreicht haben, sowie Node.js-Releases vor Version 20.19.4 werden von React Native nun nicht mehr unterstützt. Mit dem Release von React Native 0.85 endet der Support für Version 0.82.
React Native ist ein quelloffenes Cross-Plattform-UI-Framework für das Erstellen nativer Apps für Android, iOS, Windows und macOS mithilfe der JavaScript-Bibliothek React. Auch React wurde einst von Meta entwickelt, ist aber seit Februar 2026 [1] unter dem Dach der Linux Foundation in einer eigenständigen Stiftung beheimatet, der React Foundation.
Das neueste Release React Native 0.85.1 [4] führt das Shared Animation Backend als experimentelles Feature ein. Diese interne Engine entstand in Zusammenarbeit mit dem Unternehmen Software Mansion. Sie steuert, wie React Native unter der Haube Animationen für die von Software Mansion entwickelte Library React Native Reanimated [5] und für die Library Animated [6] anwendet. Da die Hauptlogik für Reanimated nun im React-Native-Kern enthalten ist, profitiert die Library unter anderem von Performanceverbesserungen. In Animated lassen sich nun Layout-Eigenschaften per Native Driver animieren.
Ein Breaking Change in Version 0.85 betrifft den Umgang mit dem Testing-Framework Jest: Das React-Native-Team hat das Jest-Preset aus react-native entfernt und in das neue Paket @react-native/jest-preset ausgelagert. Dadurch reduziert sich die Größe des Core-Pakets. Die jest.config.js-Datei lässt sich wie folgt aktualisieren:
- preset: 'react-native',
+ preset: '@react-native/jest-preset',Auch in den React Native DevTools finden Entwickler einige Neuerungen. So lassen sich nun mehrere CDP-Verbindungen (Chrome DevTools Protocol) simultan aufbauen und unter macOS sind native Tabs verfügbar.
Die Upgrading-Dokumentation [7] bietet Hinweise zum Aktualisieren, und der React Native Upgrade Helper [8] zeigt die Codeänderungen zwischen den Versionen in bestehenden Projekten.
Weitere Details zum neuen Release finden sich im React-Native-Blog [9].
URL dieses Artikels:
https://www.heise.de/-11258666
Links in diesem Artikel:
[1] https://www.heise.de/news/JavaScript-React-wechselt-zu-eigener-Stiftung-bei-der-Linux-Foundation-11188525.html
[2] https://enterjs.de/?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_enterJS.empfehlung-ho.link.link
[3] https://enterjs.de/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_enterJS.empfehlung-ho.link.link
[4] https://github.com/facebook/react-native/releases/tag/v0.85.1
[5] https://docs.swmansion.com/react-native-reanimated/
[6] https://reactnative.dev/docs/animated
[7] https://reactnative.dev/docs/upgrading
[8] https://react-native-community.github.io/upgrade-helper/
[9] https://reactnative.dev/blog/2026/04/07/react-native-0.85
[10] mailto:mai@heise.de
Copyright © 2026 Heise Medien
(Bild: IM Imagery / Shutterstock.com)
Warum Firmen vor dem Aufbau einer Internal Developer Platform eine solide Automatisierungsbasis schaffen sollten, erklären Alexander Hoeft und Artem Lajko.
In der Cloud-Native-Szene erhalten Internal Developer Platforms (IDPs) viel Aufmerksamkeit. In ihrem Vortrag auf dem Cloud-Native-Festival CloudLand 2025 ordnen Alexander Hoeft und Artem Lajko ein, was hinter dem Konzept steckt, wo die Abgrenzung zu klassischen DevOps-Ansätzen liegt – und warum viele Organisationen noch nicht reif für den Aufbau einer solchen Plattform sind.
Das Grundprinzip einer IDP besteht darin, Entwicklerteams eine zentrale Plattform bereitzustellen, über die sie Infrastruktur und Services im Self-Service nutzen können. Statt sich selbst um Provisionierung, Konfiguration und Betrieb kümmern zu müssen, greifen Entwickler auf vorgefertigte, standardisierte Bausteine zurück. Das soll die kognitive Last senken und die Produktivität steigern.
Hoeft und Lajko betonen dabei einen wesentlichen Punkt, der in der Diskussion häufig untergeht: Die Rolle eines Platform Engineers unterscheidet sich grundlegend von der eines DevOps Engineers. Während DevOps Engineers typischerweise direkt in Produktteams arbeiten und dort Entwicklungs- und Betriebsaufgaben vereinen, agieren Platform Engineers als Dienstleister für die gesamte Organisation. Sie bauen und pflegen die Plattform, die andere Teams „konsumieren“ – behandeln deren Bedürfnisse also ähnlich wie ein Produktteam seine Endnutzer.
Wer allerdings glaubt, mit dem Aufbau einer IDP sofort loslegen zu können, dem erteilen die Sprecher eine klare Absage. Organisationen sollten zunächst ein belastbares Fundament an Automatisierung geschaffen haben, bevor sie eine Plattform darüber errichten. Konkret empfehlen Hoeft und Lajko, dass grundlegende Prozesse wie Infrastructure as Code, CI/CD-Pipelines und automatisierte Tests bereits etabliert und ausgereift sein müssen. Ohne diesen Reifegrad laufe man Gefahr, Komplexität nicht zu reduzieren, sondern lediglich auf eine neue Ebene zu verlagern.
Ein konkretes Werkzeug, das in der IDP-Diskussion regelmäßig auftaucht, ist das von Spotify entwickelte, heute von der CNCF betreute Open-Source-Projekt Backstage. Es dient als Developer-Portal und kann als zentrale Oberfläche für eine IDP fungieren. Hoeft und Lajko warnen jedoch vor typischen Fallstricken beim Einsatz: Backstage sei keine schlüsselfertige Lösung, sondern ein Framework, das erheblichen Anpassungs- und Pflegeaufwand erfordere. Wer es einführe, ohne genügend Ressourcen für die kontinuierliche Weiterentwicklung einzuplanen, ende schnell mit einer halbfertigen Plattform, die von den Entwicklerteams nicht angenommen werde. Zudem bestehe die Gefahr, Backstage als reinen Service-Katalog zu betreiben, ohne die dahinterliegenden Automatisierungsschichten tatsächlich aufzubauen.
Die zentrale Frage des Vortrags – ob IDPs nur ein Trend sind – beantworten die Sprecher differenziert. Das zugrundeliegende Konzept, Entwicklern Infrastruktur als Produkt anzubieten, sei keineswegs neu und habe sich in großen Technologieunternehmen bereits bewährt. Allerdings müsse jede Organisation ihren eigenen Reifegrad realistisch einschätzen. Eine IDP ist demnach kein Projekt, das man nebenbei aufsetzt, sondern eine strategische Entscheidung, die personelle Ressourcen, Organisationsstruktur und technische Voraussetzungen gleichermaßen betrifft.
Alexander Hoeft und Artem Lajko sind für das IT-Beratungsunternehmen iits-consulting tätig. Hoeft arbeitet dort in der Rolle eines Senior Platform Engineer und ist darüber hinaus als Blogger und Sprecher auf Konferenzen aktiv. Lajko ist Head of Platform Engineering bei iits und außerdem Platform Engineering Ambassador und Kubestronaut. Auch er ist Blogger, Speaker und zudem Buchautor („Implementing GitOps with Kubernetes“).
URL dieses Artikels:
https://www.heise.de/-11255407
Links in diesem Artikel:
[1] https://www.cloudland.org/de/home/
[2] https://meine.doag.org/events/cloudland/2026/agenda/#eventDay.all
[3] https://meine.doag.org/events/cloudland/2026/agenda/#agendaId.7200
[4] https://meine.doag.org/events/cloudland/shop/
[5] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[6] mailto:map@ix.de
Copyright © 2026 Heise Medien
(Bild: Cloudflare)
Cloudflare will mit cf alle Produkte über ein einziges Kommandozeilen-Tool steuerbar machen – optimiert für Entwickler und KI-Agenten.
Cloudflare hat ein neues, einheitliches Kommandozeilen-Tool vorgestellt, das alle Produkte und APIs des Anbieters abdecken soll. cf befindet sich aktuell in einer Preview und soll langfristig die bisherige Fragmentierung auflösen: Statt je nach Produkt zwischen Dashboard, Wrangler-CLI, Terraform und REST-API zu wechseln, sollen Entwickler künftig alle Dienste über ein einziges Werkzeug steuern können. Gleichzeitig richtet Cloudflare das Tool auf die Nutzung durch KI-Agenten aus. Ebenfalls neu ist der Local Explorer, der erstmals direkten Einblick in lokal simulierte Cloudflare-Ressourcen bietet.
In Cloudflares Portfolio befinden sich aktuell mehr als 100 Produkte mit rund 3.000 API-Operationen. Dazu gehören die serverlose Laufzeitumgebung Workers, die Datenbank D1, der Objektspeicher R2, der Key-Value-Store KV und Durable Objects für zustandsbehaftete Anwendungen. Bislang verwalten Entwickler diese Dienste über verschiedene Werkzeuge: die Wrangler-CLI für Workers-Deployment, Miniflare für die lokale Emulation der Laufzeitumgebung, das Web-Dashboard und Terraform. Keines dieser Tools deckt alle Produkte ab.
Genau das soll cf ändern. Es erweitert Wrangler und bildet perspektivisch die gesamte API-Oberfläche ab. Entwickler können die Preview bereits per npx cf ausprobieren oder global über npm installieren. Cloudflare plant, dass sich über das neue Tool alle Dienste nach dem Infrastructure-as-Code-Prinzip konfigurieren lassen – mit einheitlicher Syntax. Ein Beispiel wäre cf kv get statt produktabhängig variierender Befehle.
Unter der Haube steckt ein neues, TypeScript-basiertes Schema, das als zentrale Quelle für alle Schnittstellen dient. OpenAPI beschreibt nur REST-Endpunkte; das neue Schema erfasst darüber hinaus CLI-Kommandos, Konfigurationsdateien, Bindings sowie lokale Entwicklung und Tests. Daraus generiert Cloudflare automatisch SDKs, Terraform-Provider, Dokumentation und CLI-Befehle. Verbindliche Regeln auf Schema-Ebene erzwingen Konsistenz: Befehle heißen immer get, nie info; Flags wie --json stehen einheitlich zur Verfügung.
Diese Konsistenz zielt vor allem auf KI-Agenten, die Cloudflare inzwischen als „primäre Kunden“ der APIs betrachtet. Agenten sind auf vorhersagbare Schnittstellen angewiesen – weicht die Syntax eines Befehls von der erwarteten Konvention ab, rufen sie nicht existierende Kommandos auf. Ebenso wichtig: Die CLI signalisiert künftig klar, ob ein Befehl lokale oder entfernte Ressourcen betrifft. Bisher konnte es passieren, dass ein Agent eine lokale Datenbank beschrieb, während der Entwickler mit Remote-Bindings arbeitete.
Der ebenfalls vorgestellte Local Explorer ermöglicht die Inspektion und Bearbeitung lokal simulierter Cloudflare-Ressourcen. Das Werkzeug integriert sich in Wrangler und das Cloudflare-Vite-Plugin und zeigt lokal simulierte Ressourcen wie KV, R2, D1, Durable Objects und Workflows an. Bisher mussten Entwickler dafür das Zustandsverzeichnis .wrangler/state durchsuchen oder auf Drittanbieter-Tools zurückgreifen. Nun lassen sich Datenbankinhalte direkt prüfen, Testdaten einfügen oder Tabellen zurücksetzen.
Technisch stellt der Local Explorer eine lokale Spiegelung der Cloudflare-API unter /cdn-cgi/explorer/api bereit. Diese verhält sich wie die produktive API, arbeitet aber ausschließlich mit lokalen Daten. Dadurch funktionieren dieselben CLI-Befehle lokal wie remote – ein Flag wie --local lenkt die Anfrage lediglich an den lokalen Endpunkt um. Ein D1-Query adressiert dann die lokale SQLite-Instanz statt der gehosteten Datenbank, ohne dass sich die Semantik ändert. Agenten können den lokalen API-Endpunkt direkt ansprechen und finden dort eine OpenAPI-Spezifikation vor.
Die Ankündigungen fallen in Cloudflares Agents Week, in der das Unternehmen seine Plattform stärker auf KI-Agenten ausrichtet. Weitere Neuerungen umfassen unter anderem Durable Object Facets für isolierte Datenbankinstanzen in dynamisch erzeugten Anwendungen, persistente Sandbox-Umgebungen für Agenten (jetzt allgemein verfügbar) sowie eine identitätsbasierte Zugriffskontrolle für ausgehende Verbindungen aus Sandboxes.
Die neue CLI unterstützt derzeit nur einen Teil der Cloudflare-Produkte. Die vollständige API-Abdeckung und die Integration bestehender Wrangler-Funktionen plant Cloudflare für die kommenden Monate. Das Unternehmen ruft Entwickler auf [1], über den Cloudflare-Developers-Discord Feedback zur weiteren Ausgestaltung zu geben.
URL dieses Artikels:
https://www.heise.de/-11256008
Links in diesem Artikel:
[1] https://blog.cloudflare.com/cf-cli-local-explorer/
[2] https://www.heise.de/ix
[3] mailto:fo@heise.de
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
Wie wird man vom Entwickler zum Test Automation Engineer? Benjamin Bischoff über Tools, KI, Herausforderungen und Softwarequalität.
In dieser Episode spricht Richard Seidl mit Benjamin Bischoff über den spannenden Weg vom Softwareentwickler zum Test Automation Engineer. Die Episode bietet Einblicke, wie technische und methodische Fähigkeiten aus zwei Bereichen zusammenfinden. Benjamin Bischoff erklärt, wie sein Interesse für hochwertige Software ihn von der klassischen Entwicklung in die Testautomatisierung führte. Offen berichtet er, wo seine Vorteile liegen und wo er selbst noch Herausforderungen sieht, etwa beim explorativen Testen. Themen wie aktuelle Tools, der Einfluss von KI und Tipps für Quereinsteiger machen klar, dass Testautomatisierung mehr ist als bloßes Programmieren.
Nach 15 Jahren als Softwareentwickler und Trainer wechselte Benjamin Bischoff [2] 2016 in den Bereich der Testautomatisierung. Derzeit arbeitet er als Test Automation Engineer bei trivago N.V. in Düsseldorf und konzentriert sich dort hauptsächlich auf Backend- und Frontend-Testtechnologien und -Pipelines. Benjamin Bischoff ist Autor des Buches „Writing API Tests With Karate“ und betreut einige Open-Source-Projekte im Bereich Software-Testing und Reporting. Er hält regelmäßig Vorträge auf Konferenzen und schreibt auf seiner Website softwaretester.blog [3] Beiträge über Testen, Automatisierung und Software-Craftsmanship.
Bei diesem Format 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: „Vom Developer zum Test Automation Engineer – Benjamin Bischoff [4]“.
URL dieses Artikels:
https://www.heise.de/-11251576
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://www.linkedin.com/in/benjamin-bischoff/
[3] https://www.softwaretester.blog/
[4] https://www.richard-seidl.com/de/blog/vom-entwickler-zum-tester
[5] mailto:mdo@ix.de
Copyright © 2026 Heise Medien
Da war die Welt noch in Ordnung: YouTuberin und Moderatorin Justine Ezarik (von links), Apples KI-Chef John Giannandrea und Software-Chef Craig Federighi auf der Bühne im Steve-Jobs-Theater.
(Bild: Apple)
Nach dem holprigen Start von Apple Intelligence verlässt KI-Chef John Giannandrea das Unternehmen. Angekündigt wurde der Rückzug im Dezember.
Es war ein denkwürdiger Auftritt am Nachmittag des 11. Juni 2024: Apples damaliger KI-Chef John Giannandrea und Software-Chef Craig Federighi demonstrierten auf der Bühne des Steve Jobs Theater im Apple-Hauptquartier in Cupertino den großen Schulterschluss. Die von Apple-Chef Tim Cook eingeleitete Fragestunde [1] mit YouTuberin iJustine sollte die kurz zuvor vorgestellte Apple Intelligence inhaltlich vertiefen und vermutlich ein Signal der Einmütigkeit in der Apple-Chefetage ausstrahlen. Jetzt, nicht einmal zwei Jahre danach, wird Giannandrea das Unternehmen zur Monatsmitte verlassen.
Das Schicksal des früheren Google-Mitarbeiters ist eng verknüpft mit den KI-Bemühungen Apples [2]. Damals angekündigte Grundfunktionen der Apple Intelligence wie das Zusammenfassen von Texten oder maßgeschneiderte Emojis erreichten zwar binnen weniger Monate einen großen Teil der Apple-Kundschaft. Der Blick der Fachwelt richtete sich allerdings mehr auf das, was nicht kam: Siri sei kein Sprachassistent mehr, sondern ein Geräteassistent mit tieferem Verständnis dafür, was auf dem Gerät passiert, tönte Giannandrea in der damaligen Fragestunde. Zwei Jahre später gibt es immer noch nur die Ankündigung, dass Siri besser werden soll. Zuletzt verdichteten sich jedoch Berichte, wonach Apple für iOS 27 eine eigene Siri-App sowie einen Chatbot-Modus [3] plant.
Giannandrea kam im Jahr 2018 zu Apple. Bei Google war er zuvor acht Jahre lang tätig. Seine Expertise in Machine-Learning passte gut zu Apples Ambitionen, die mit der Neural Engine auch in Hardware gegossen wurden. Doch als mit ChatGPT von OpenAI Jahre später die generativen Sprachmodelle einen Hype auslösten, wirkte Apple wie auf dem falschen Fuß erwischt. Die Vorstellung der Apple Intelligence, 2024, sollte der Befreiungsschlag werden. Die „AI for the rest of us“ (KI für den Rest von uns) sollte mit dem Datenschutz-Vorrang punkten. Stattdessen machte Apple Schlagzeilen damit, dass die KI-Siri offenbar gar nicht funktionierte und das Projekt offenbar komplett zurückgesetzt werden musste. Intern gilt die Dauerbaustelle Siri bereits seit Längerem als Problemfall [4], da versprochene Funktionen immer wieder verschoben wurden.
Die diesjährige Entwicklerkonferenz WWDC am 8. Juni [5] soll nun den Trubel der vergangenen Jahre vergessen machen. Apple ist eine Kooperation mit Google eingegangen, um deren KI-Modell Gemini zu verwenden. Vor allem aber wurden erhebliche Veränderungen in der Leitung vorgenommen. Dabei gilt Federighi intern als Verfechter eines eher pragmatischen KI-Kurses mit Fokus auf Budgets [6] und Partnerschaften. Der ehemalige Vision-Pro-Chef brachte für den Umbau der Siri-Abteilung [7] zahlreiche Experten aus seinem alten Team mit. Weitere erfahrene Kräfte, die es richten sollen, sind Eddy Cue und Sabih Khan. Erneut ist ein Ex-Googler mit in der Verantwortung: Neuzugang Amar Subramanya soll als Vice President of AI aber deutlich weniger Eigenständigkeit genießen als sein Vorgänger. Er berichte an Federighi.
Giannandrea war in den vergangenen Monaten nur noch Berater für Apple. Sein Rückzug wurde im Dezember 2025 angekündigt, nachdem zuvor bereits laut geworden war, dass es zwischen den Ressortleitern bei Apple geknirscht hat. Bereits im März 2025 habe Cook Giannandrea deshalb die Leitung des Siri-Teams entzogen, hieß es in Medienberichten. Es war ein Rückzug in Raten. Sein Verbleib bis Mitte April erklärt Bloomberg-Reporter Mark Gurman [8] mit den üblichen Gepflogenheiten in börsennotierten Unternehmen, um Giannandrea noch eine letzte Aktienprämie auszahlen zu können.
Nach Apple will der frühere KI-Chef laut Bericht in verschiedenen Unternehmensvorständen mitwirken und als Berater für Start-up-Unternehmen tätig werden. Wie stark Apples stotternder KI-Motor tatsächlich mit seiner Person verknüpft war, wird sich in den nächsten Monaten zeigen. Finanziell profitiert der Konzern trotz technischer Rückstände massiv: Erwartungen zufolge wird Apple bald eine Milliarde US-Dollar durch KI-Apps [9] im App Store verdienen.
URL dieses Artikels:
https://www.heise.de/-11255446
Links in diesem Artikel:
[1] https://www.heise.de/news/Apple-Intelligence-Das-sagen-der-KI-und-der-Software-Chef-zum-Siri-Neubeginn-9757150.html
[2] https://www.heise.de/thema/Kuenstliche-Intelligenz
[3] https://www.heise.de/news/iOS-27-Apple-erwaegt-Siri-App-und-Siri-fragen-Knopf-11224654.html
[4] https://www.heise.de/news/Dauerbaustelle-Siri-Vision-Pro-Chef-soll-es-jetzt-richten-10323435.html
[5] https://www.heise.de/news/WWDC-2026-am-8-Juni-Apple-gewaehrt-ersten-Blick-auf-iOS-27-und-macOS-27-11221912.html
[6] https://www.heise.de/news/Federighi-und-Apples-KI-Ambitionen-Pragmatismus-statt-Innovation-11152262.html
[7] https://www.heise.de/news/Apple-baut-Siri-Abteilung-um-uebernimmt-Vision-Pro-Entwickler-10359675.html
[8] https://www.bloomberg.com/news/newsletters/2026-04-12/apple-ai-smart-glasses-features-styles-colors-cameras-giannandrea-leaving-mnvtz4yg
[9] https://www.heise.de/news/Apple-verdient-bald-eine-Milliarde-US-Dollar-dank-KI-im-App-Store-11221048.html
[10] https://www.heise.de/mac-and-i
[11] mailto:mki@heise.de
Copyright © 2026 Heise Medien
(Bild: lassedesignen / Shutterstock.com)
Steuererklärung, Prozesse oder Bauplanungen: Vieles lässt sich mit einer domänenspezifischen Sprache darstellen. Editoren mit LSP machen die Umsetzung leicht.
Lohnt es sich, eine eigene Programmiersprache samt Syntax-Highlighting, Code Completion anderen Features im Editor nur für ein einzelnes Projekt zu erstellen? Was sich auf den ersten Blick nach viel Arbeit anhört, ist dank Language Server Protocol (LSP) deutlich einfacher geworden. Durch die reichhaltigen Möglichkeiten zur Interaktion mit Texteditoren wie Visual Studio Code eignen sich domänenspezifische Sprachen (Domain Specific Languages, DSL) als eine vollwertige und auch unterschätzte Möglichkeit der Gestaltung einer UX.
Anwenderinnen und Anwender jenseits der Informatik nehmen Spezifikationen oft mit Formularen vor. Je komplexer die Anforderungen sind, desto komplizierter wird die Umsetzung per Formular. Ein grotesk wirkendes Beispiel zeigt Abbildung 1: Anweisungen für einen Compiler, über ein Formular zu spezifizieren.
Gleich mehrere Gründe machen diese Idee so absurd:
Eine komplexe Spezifikation ist keine Besonderheit der Informatik, auch in anderen Fachbereichen gibt es schwierige Probleme, die immer mehr mithilfe von Computern gelöst werden sollen. Das kann die Automatisierung von Workflows sein, die Planung von Bauteilen oder Gebäuden, die Dokumentation von manuellen Prozessen oder vieles mehr. Ein Erfolgsfaktor von Programmiersprachen ist sicherlich, dass Programme sowieso abstrakt sind, während sich physische Bauteile oder Gebäudepläne schon immer auch grafisch haben repräsentieren lassen. Das Beispiel von Prozessautomatisierung zeigt aber, dass in vielen Bereichen ebenfalls abstrakte Konzepte auftreten.
Innerhalb der Informatik haben sich textuelle Sprachen auch jenseits des Programmierens bewährt. Admins legen Infrastrukturen in der Cloud schon lange nicht mehr per Formular an (diese Praxis wird eher als ClickOps geschmäht), sondern in Textform per Infrastructure-as-Code. Die Gründe sind dieselben: die Spezifikation ist schlanker, verständlicher, einfacher zu versionieren und man ist damit schneller.
Einfacher zu versionieren als Formulare, sind generische Formate wie JSON oder XML. Sie sind allerdings ursprünglich nicht dafür gedacht, für Menschen lesbar zu sein, sondern für Maschinen. Da viele Anwendungen ohnehin eine maschinenlesbare Sprache benötigen, ist es bequem, diese auch als alternative Schnittstelle anzubieten.
Aber auch solche Konfigurationsdateien erreichen nicht die Prägnanz, Lesbarkeit und Effizienz einer domänenspezifischen Sprache, zumal auch Validierungstechnologien wie XML Schema oder JSON Schema nur die Struktur der Dokumente validieren, aber wenig zur fachlichen Analyse beitragen können.
Komplexe Vorgänge, die Menschen gern sehr prägnant, lesbar und versionierbar ausdrücken wollen, kann man vorteilhaft mit einer domänenspezifischen Sprache spezifizieren, mit der gleichen Editorunterstützung wie bei Programmiersprachen. Beispiele wären Reisekostenabrechnungen, Nebenkostenabrechnungen, Steuererklärungen, Umsatzabfragen, Prozessautomatisierungen oder Bauplanungen.
LLM-basierte Chatfunktionen sind dabei kein Ersatz für domänenspezifische Sprachen, umgekehrt aber können domänenspezifische Sprachen die Intention eines KI-Systems einfacher überprüfbar machen. Anstatt agentenbasierte Systeme kritische Dinge tun zu lassen (was zumindest in der EU per AI Act [1] streng reglementiert ist), kann man KI-Systeme auch eine in natürlicher Sprache vorliegende Beschreibung in eine DSL umformulieren lassen.
Die Entwicklung einer domänenspezifischen Sprache reduziert sich nicht nur auf einen Parser: Nutzerinnen und Nutzer sind den Komfort von Syntax-Highlighting, Code Completion, bequemes Springen zur Definition oder zu Referenzen gewohnt, die wesentlich für eine gute UX und gesteigerte Produktivität sind. In den letzten Jahren ist dies durch das von Microsoft entwickelte Language Server Protocol (LSP) deutlich einfacher geworden. Dieses Prinzip hat sich auf weitere Bereiche ausgeweitet, zum Beispiel auf grafische Sprachen mit dem Graphical Language Server Protocol (GLSP). LSP und GLSP erlauben es, weitgehend auf die Entwicklung von UI-Komponenten zu verzichten und sich stattdessen auf die Semantik einer Sprache zu konzentrieren.
Aus diesem Grund können Editoren wie Visual Studio Code mit beliebigen Programmiersprachen umgehen: Während sie als Frontend immer dasselbe UI verwenden (im Fall von Visual Studio Code den Monaco-Editor), liefert ein LSP-Server die sprachspezifische Editorunterstützung. Da LSP auf JSON-RPC basiert, das keine Transportschicht definiert, lässt sich LSP wahlweise über stdin/stdout oder über Websockets betreiben. Das ermöglicht viele Optionen für das Deployment: Der Client kann in einer Desktopanwendung (in Fall von Visual Studio Code via Electron) oder im Browser laufen, während der Server entweder in die IDE eingebettet oder auf einem entfernten Rechner arbeitet.
Mittlerweile gibt es für die Entwicklung von LSP-Servern mehrere Frameworks, je nachdem, mit welcher Programmiersprache man die DSL entwickeln will. Für die Beschreibung der Grammatik der DSL kommt ebenfalls eine DSL zum Einsatz. Daraus generiert das Framework Parser, Klassen für den abstrakten Syntaxbaum und die Editorunterstützung. Entwicklerinnen und Entwickler können das Ergebnis durch manuellen Code ergänzen oder überschreiben. Beispiele für entsprechende Tools sind Xtext für Java [2] (siehe auch: [1] [3]), Langium für TypeScript [4] und AnyText für .NET [5] (siehe auch [2] [6]).
Der Startpunkt für die Entwicklung einer neuen DSL ist mit allen dreien der genannten Frameworks eine Grammatik, die auch die abstrakte Syntax der Sprache ausdrückt. Die abstrakte Syntax ist hierbei die Definition der Konzepte, die die Sprache ausmachen. Für die Grammatik werden bei Xtext und Langium kontextfreie LL(k)-Grammatiken verwendet, bei AnyText Parse-Expression-Grammatiken (PEGs). Beide Klassen von Grammatiken arbeiten mit Nichtterminalen (= Platzhaltern) und Produktionsregeln, die bestimmen, wie ein Nichtterminal ersetzt werden kann. Diese Produktionsregeln lassen sich bequem über die Metasprache Erweiterte Backus-Naur-Form (EBNF) spezifizieren, die zusätzlich noch um Zuweisungen ergänzt wird, um auch die abstrakte Syntax angeben zu können.
Praktischerweise bietet Langium mit dem Playground [7] eine Möglichkeit an, mit der Entwicklung einer DSL ohne Installation einer Software direkt im Browser zu beginnen. Für Xtext [8] oder AnyText [9] bieten die Tutorials gute Einstiegspunkte.
Um beispielsweise die (hier vereinfachte) Deklaration einer Klasse in einer Programmiersprache zu spezifizieren, genügt das folgende Fragment:
Class: ‘class’ name=ID ‘{‘ members+=ClassMember* ‘}’;
Dieses Beispiel geht davon aus, dass es weitere Nichtterminale ID und ClassMember gibt, die regeln, wie ein Identifier genau aussieht und was zulässige Member einer Klasse sein können. Der Postfixoperator * erlaubt hierbei beliebig viele Member. Alternativ sind auch + oder ? möglich, um mindestens oder höchstens ein Vorkommen zu beschreiben. Der Operator | erlaubt auch Alternativen, was unterschiedliche Arten von Membern ermöglicht. Besteht eine Regel ausschließlich aus Alternativen, dann wird das in der abstrakten Syntax durch Inheritance abgebildet.
Die Zuweisung = bzw. += weist das System darüber hinaus an, das Ergebnis des Nichtterminals ID bzw. ClassMember dem abstrakten Element des Nichtterminals zuzuordnen. Das geht entweder als einwertige Eigenschaft (beispielsweise, dass das Ergebnis von ID den Namen bilden soll) oder als mehrwertige Eigenschaft, dass das Ergebnis von ClassMember zur Auflistung members hinzugefügt werden soll.
Aus diesen Zuweisungen lassen sich dann auch Klassen ableiten, um die abstrakten Elemente der Sprache im Speicher darstellen zu können. Sowohl Xtext und Langium als auch AnyText unterstützen den Operator [], mit dem sich Referenzen abbilden lassen, dass also an einer gegebenen Stelle nur eine Referenz auf ein anderes syntaktisches Element erscheinen soll.
Die Konstruktion des Parsers bleibt zwar weitestgehend vor den Entwicklern verborgen, allerdings haben manche Klassen von Grammatiken Einschränkungen, die Entwickler einer DSL berücksichtigen müssen. So sind die Produktionen bei kontextfreien Grammatiken ungeordnet, bei PEGs aber geordnet, weswegen es konstruktionsbedingt keine Mehrdeutigkeiten gibt. Gängige Parser für kontextfreie Grammatiken unterstützen keine Linksrekursionen, für PEGs aber schon.
Die Unterstützung von Linksrekursionen ist vor allem für Ausdrücke wichtig, da man damit sehr intuitiv Formeln umsetzen kann. Insbesondere sind binäre Ausdrücke selbst Ausdrücke, beginnen aber auch mit einem Ausdruck. Für PEGs haben Warth und andere [3] [10] eine Erweiterung von Packrat-Parsern entwickelt, die Linksrekursionen parsen kann, wobei das lineare Laufzeitverhalten von Packrat-Parsern erhalten bleibt.
In AnyText lässt sich daher eine einfache Expression-Grammatik wie in Listing 1 unten dargestellt implementieren. Hierbei überschreibt das Schlüsselwort returns, welche Klasse der abstrakten Syntax das Nichtterminal zurückgibt. Im Beispiel dient es dazu, nicht für jedes einzelne Nichtterminal eine Klasse einführen zu müssen. Das Schlüsselwort enum kommt zum Einsatz, um eine fixe Menge von Werten abzubilden. Ferner beschreibt das Schlüsselwort parantheses ein Nichtterminal für Klammerungen und terminal ein Terminal, dargestellt durch einen regulären Ausdruck.
grammar Expressions (exp)
root Expression
Expression:
AdditiveBinary | Multiplicative;
AdditiveBinary returns BinaryExpression:
left=Expression operator=AdditiveOperator right=Expression;
enum AdditiveOperator returns BinaryOperator:
Add => '+'
Subtract => '-';
Multiplicative returns Expression:
MultiplicativeBinary | LiteralExpression | VariableExpression | ParanthesisExpression;
MultiplicativeBinary returns BinaryExpression:
left=Multiplicative operator=MultiplicativeOperator right=Multiplicative;
enum MultiplicativeOperator returns BinaryOperator:
Multiply => '*'
Divide => '/';
LiteralExpression:
value=Number;
VariableExpression:
variable=Identifier;
parantheses ParanthesisExpression:
'(' Expression ')';
terminal Number returns nmeta.Integer:
/\d+/;
terminal Identifier:
/[a-zA-Z]\w*/;
LSP ist nicht nur auf das Parsen von Text begrenzt, sondern erlaubt auch praktische Interaktionen mit einem Text in der IDE. Programmiererinnen und Programmierern sind Features wie Code Lenses oder Code Fixes geläufig. Sie erlauben es, Analyseergebnisse wie die Anzahl der Referenzen oder Autor und Datum der letzten Änderung an einer Methode einfach in das Sichtfeld einzublenden. Interaktionen wie Refactorings lassen sich ebenfalls direkt aus dem Code heraus starten.
Zu Features dieser Art gehören:
AnyText macht die Entwicklung dieser Features besonders einfach, indem es für jede Regel in der Grammatik eine Klasse generiert, in der Entwickler meist nur eine entsprechende Methode überschreiben müssen, um das jeweilige Feature zu aktivieren. Aber auch mit Langium oder Xtext lassen sich diese Features einfach nutzen.
Domänenspezifische Sprachen haben neben Formularen oder KI-Agenten einen eigenen Platz als Möglichkeit verdient, mit der Endanwender spezifizieren, welche Probleme der Computer lösen soll. DSLs richten sich dabei vor allem an Expertinnen und Experten, die solche Spezifikationen häufiger verfassen müssen, für die also Produktivität, einfache Versionierbarkeit und Interoperabilität textueller Sprachen besonders vorteilhaft sind.
Dabei hat sich die Entwicklung neuer DSLs durch Innovationen wie das Language Server Protocol und Frameworks wie Langium, Xtext oder AnyText dramatisch vereinfacht. Wo Developer Parser früher per Hand schreiben mussten, können sie diese heute mit Editorunterstützung weitgehend aus der Spezifikation einer Grammatik ableiten, was den Aufwand stark reduziert. Daher sollten DSLs als alternative UX-Technologie durchaus in Betracht gezogen werden.
[11][1] M. Eysholdt und H. Behrens, „Xtext: implement your language faster than the quick and dirty way,“ in Proceedings of the ACM International Conference Companion on Object Oriented Programming Systems Languages and Applications Companion, Reno/Tahoe, Nevada, USA, Association for Computing Machinery, 2010, pp. 307–309.
[12][2] G. Hinkel, A. Hert, N. Hettler und K. Weinert, „AnyText: Incremental, left-recursive Parsing and Pretty-Printing from a single Grammar Definition with first-class LSP support,“ Proceedings of the 18th ACM SIGPLAN International Conference on Software Language Engineering, SLE 2025, pp. 98–111, 12–13 Juni 2025.
[13][3] A. Warth, J. R. Douglass und T. Millstein, „Packrat parsers can support left recursion,“ in Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation, San Francisco, California, USA, Association for Computing Machinery, 2008, pp. 103–110.
URL dieses Artikels:
https://www.heise.de/-11250899
Links in diesem Artikel:
[1] https://artificialintelligenceact.eu/de/high-level-summary/
[2] https://eclipse.dev/Xtext/
[3] #anchor_1
[4] https://langium.org/
[5] https://nmfcode.github.io/anytext/
[6] #anchor_2
[7] https://langium.org/playground/
[8] https://eclipse.dev/Xtext/documentation/102_domainmodelwalkthrough.html
[9] https://nmfcode.github.io/anytext/tutorials/helloWorld.html
[10] #anchor_3
[11]
[12]
[13]
[14] mailto:who@heise.de
Copyright © 2026 Heise Medien
(Bild: Natalia Klenova / Shutterstock.com)
Kleine, aber interessante Meldungshäppchen vom News-Buffet zu React Native, Perl, JavaScript, ASP .NET Core, State of Web Dev AI, PHP, Python und OpenJDK.
In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:
Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail [12].
URL dieses Artikels:
https://www.heise.de/-11251532
Links in diesem Artikel:
[1] https://devblogs.microsoft.com/react-native/%F0%9F%9A%80react-native-windows-v0-82-is-here/
[2] https://blogs.perl.org/users/petamem/2026/04/pdl-in-rust----a-native-reimplementation-of-the-perl-data-language.html
[3] https://discourse.llvm.org/t/rfc-jsir-a-high-level-ir-for-javascript/90456
[4] https://devblogs.microsoft.com/dotnet/aspnet-core-2-3-end-of-support/
[5] https://enterjs.de/ai.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_ejs_ai.empfehlung-ho.link.link&LPID=34830
[6] https://enterjs.de/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_ejs_ai.empfehlung-ho.link.link&LPID=34830#AI
[7] https://survey.devographics.com/en-US/survey/state-of-ai/2026
[8] https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-version-1-0/
[9] https://prettyphpinfo.com/
[10] https://blog.python.org/2026/04/rust-for-cpython-2026-04/
[11] https://openjdk.org/legal/ai
[12] mailto:developer@heise.de?subject=Ein%20Vorschlag%20f%C3%BCr%20die%20Developer-H%C3%A4ppchen
[13] mailto:who@heise.de
Copyright © 2026 Heise Medien
(Bild: heise medien)
Gas Town 1.0.0 orchestriert mehrstufige Entwicklungs-Workflows, härtet Agenten-Sicherheit und unterstützt erstmals Windows.
Gas Town hat Version 1.0.0 erreicht und gilt damit als produktionsreif. Nach 14 Vorabversionen (v0.5.0 bis v0.13.0) bringt das Release vor allem mehr Stabilität, bessere Sicherheit und neue Werkzeuge für die Orchestrierung komplexer Abläufe. Im Mittelpunkt stehen eine Workflow-basierte Ausführung, die direkte Anbindung an GitHub Merge Queues sowie zusätzliche Kontroll- und Schutzmechanismen für automatisierte Systeme.
Gas Town ist ein Open-Source-Projekt, das Entwicklungs- und Automatisierungsprozesse orchestriert – insbesondere mehrstufige, teils agentenbasierte Workflows. Konzepte wie „Formulas“, „Polecats“ oder „Refinery“ stehen für die Verbindung strukturierter Abläufe mit automatisierten Akteuren, die sich in bestehende Entwicklungsumgebungen wie GitHub einfügen. Entwickler arbeiten dazu nur mit einem einzigen, zentralen Agenten zusammen, dem Mayor, der die anderen Agenten selbsttätig ins Leben ruft und orchestriert.
Die wichtigste funktionale Neuerung sind Workflow-Formeln. Der neue Typ „workflow“ in gt formula run erlaubt es, mehrstufige, interaktive Abläufe zu definieren und auszuführen. Statt einzelner Befehle lassen sich damit ganze Prozessketten abbilden – etwa Codegenerierung, Testlauf und Pull-Request-Erstellung in einem Durchgang. Für Entwicklungsteams entspricht das einer leichtgewichtigen Workflow-Engine, die besonders bei KI-gestützten Prozessen nützlich ist.
Dazu passend bindet die Komponente „Refinery“ jetzt nativ GitHub Merge Queues an. Mit merge_strategy=pr reiht Gas Town Pull Requests direkt in die Warteschlange ein. GitHub führt Änderungen dann seriell und erst nach erfolgreichem CI-Lauf zusammen. In automatisierten Setups entfällt damit ein guter Teil der eigenen Merge-Logik, gleichzeitig sinkt das Risiko von Konflikten durch parallele Änderungen.
Version 1.0 bringt außerdem einen ersten Windows-Support. Gas Town implementiert dafür plattformspezifisches Signal-Handling, Prozessmanagement und die Nachverfolgung von tmux-Prozesshierarchien. Da sich diese Mechanismen unter Windows grundlegend von Unix unterscheiden, war eine eigene Umsetzung nötig. Teams mit gemischten Betriebssystemlandschaften können Gas Town damit erstmals durchgängig einsetzen.
Beim Thema Sicherheit bündelt das Release mehrere Maßnahmen. Die Entwickler haben eine SQL-Injection-Lücke in dolt_remotes geschlossen. Ein neuer „PreToolUse“-Guard blockiert kritische Systemeingriffe wie sudo-Aufrufe oder Paketinstallationen. Zusätzlich lehnt Gas Town unsignierte Binärdateien ab. Die Kombination aus Schwachstellenbehebung und Laufzeitkontrollen zielt vor allem auf agentenbasierte Szenarien, in denen automatisierte Akteure potenziell gefährliche Aktionen auslösen könnten.
Neu sind auch „Mayor Approval Gates“ als Governance-Mechanismus. Bevor ein Polecat – also ein ausführendes Modul oder ein Agent – seinen Wirkungsbereich erweitert, braucht er eine Freigabe. Das betrifft etwa den Zugriff auf zusätzliche Ressourcen oder Komponenten. Das Prinzip ähnelt Policy-Engines oder Human-in-the-Loop-Ansätzen und soll verhindern, dass automatisierte Systeme eigenmächtig ihre Berechtigungen ausweiten.
Ein neues Rate-Limit-Watchdog-Plugin rundet das Release ab. Es erkennt HTTP-429-Antworten und stoppt den betroffenen Prozess automatisch. Das verhindert, dass Workflows bei API-Überlastung in Endlosschleifen laufen oder ungewollt hohe Kosten verursachen.
Alle Details zur Version 1.0.0 finden sich in den Release Notes auf der GitHub-Projektseite von Gas Town [1].
URL dieses Artikels:
https://www.heise.de/-11252101
Links in diesem Artikel:
[1] https://github.com/gastownhall/gastown/releases/tag/v1.0.0
[2] https://www.heise.de/ix
[3] mailto:fo@heise.de
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
In einer File-based App kann man den Kestrel-Webserver auf Basis von ASP.NET Core starten.
Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps [1]. Es ist auch möglich, einen Kestrel-Webserver innerhalb einer solchen App zu starten. Unten stehendes Beispiel zeigt eine ASP.NET Core Minimal WebAPI als eigenständige C#-Datei. Das Hosting erfolgt in dem in ASP.NET Core mitgelieferten Webserver Kestrel [2].
In der File-based App wird Microsoft.NET.Sdk.Web als SDK angegeben. Als NuGet-Pakete werden Microsoft.AspNetCore.OpenApi und Humanizer verwendet. Die Ahead-of-Time-Kompilierung, die in File-based Apps Standard ist, ist hier deaktiviert, um Warnungen des JSON-Serialisierers zu vermeiden.
Folgender Code zeigt den Webserver auf Basis von ASP.NET Core mit einem Minimal-WebAPI-Endpunkt und OpenAPI-Metadaten:
#:sdk Microsoft.NET.Sdk.Web
#:package Microsoft.AspNetCore.OpenApi@10.*-*
#:package Humanizer@2.14.1
#:property Version=1.1.4
#:property PublishAot=false
using Humanizer;
using Microsoft.OpenApi;
// Webserver einrichten
var builder = WebApplication.CreateBuilder();
builder.Services.AddOpenApi();
var app = builder.Build();
app.MapOpenApi(); // http://localhost:5000/openapi/v1.json
app.MapGet("/", () =>
{
// Daten für Operation
var d = new Data
{
Version = "9.0",
Release = "2024-11-12"
};
var dotNet9Released = DateTimeOffset.Parse(d.Release);
var since = DateTimeOffset.Now - dotNet9Released;
return $"It has been {since.Humanize()} since .NET {d.Version} was released.";
});
app.MapGet("/data", () =>
{
var d = new Data
{
Version = "9.0",
Release = "2024-11-12"
};
return Results.Json(d);
});
app.Run();
class Data
{
/// <summary>
/// Version of the .NET release.
/// </summary>
public string? Version { get; set; }
/// <summary>
/// Release date of the .NET version.
/// </summary>
public string? Release { get; set; }
}
URL dieses Artikels:
https://www.heise.de/-11249251
Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-10-0-13-Kompilieren-und-Starten-einzelner-C-Dateien-11201372.html
[2] https://www.dotnet-lexikon.de/Kestrel/lex/8826
[3] mailto:rme@ix.de
Copyright © 2026 Heise Medien
(Bild: HAKINMHAN / Shutterstock.com)
Das Open-Source-IAM-System Keycloak 26.6 befördert fünf Features in den produktiven Status – darunter Federated Client Authentication und Zero-Downtime-Updates.
Das Keycloak-Projekt hat Version 26.6.0 des Open-Source-Identity-Providers veröffentlicht. Im Mittelpunkt stehen fünf Features, die den Preview-Status verlassen und nun als vollständig unterstützt gelten. Für Unternehmen, die Keycloak in Kubernetes-Umgebungen betreiben, dürften dabei vor allem die Zero-Downtime-Patch-Releases und die Federated Client Authentication relevant sein.
Die wohl praxisrelevanteste Neuerung laut Ankündigung [1]: Patch-Releases lassen sich künftig als Rolling Updates innerhalb eines Minor-Release-Streams einspielen, ohne dass der Dienst unterbrochen wird. Zusammen mit dem ebenfalls verbesserten Graceful HTTP Shutdown, der Fehlermeldungen beim Abschalten einzelner Nodes verhindert, greift das Entwicklungsteam damit eine zentrale Anforderung containerisierter Deployments auf. Um von den Zero-Downtime-Patch-Releases profitieren zu können, genügt es laut Release Notes, die Update-Strategie für den Keycloak Operator auf „Auto“ zu setzen.
Daneben hat das Projekt die Federated Client Authentication in den produktiven Status befördert. Das Feature erlaubt es Clients, vorhandene Credentials eines externen Issuers zu nutzen, sobald eine Vertrauensbeziehung besteht. Individuelle Client-Secrets in Keycloak entfallen damit. Unterstützt werden Client-Assertions externer OpenID-Connect-Identity-Provider sowie Kubernetes Service Accounts. Organisationen mit mehreren Identity-Providern reduzieren so den Verwaltungsaufwand für Secrets erheblich. Die OAuth-SPIFFE-Client-Authentication bleibt allerdings im Preview-Status, da die zugrunde liegende Spezifikation noch nicht finalisiert ist.
Mit den nun unterstützten Workflows bringt Keycloak zentrale Funktionen aus dem Bereich Identity Governance and Administration (IGA) mit. Administratoren können Realm-Aufgaben wie das Lifecycle-Management von Benutzern und Clients in YAML-Dateien definieren und anhand von Ereignissen, Bedingungen oder Zeitplänen automatisiert ausführen lassen. Das Release enthält zudem neue Built-in-Steps, einen Troubleshooting-Guide sowie diverse Verbesserungen an der Workflow-Engine.
Auch der JWT Authorization Grant nach RFC 7523 [5] gilt nun als produktionsreif. Er ermöglicht den Austausch externer JWT-Assertions gegen OAuth-2.0-Access-Token und hilft somit bei Anwendungsfällen, in denen externe Token in interne überführt werden müssen. Komplettiert wird das Quintett durch das neue Keycloak Test Framework, das den bisherigen Arquillian-basierten Ansatz ablöst.
Jenseits der fünf Haupt-Features liefert das Release weitere Neuerungen. Experimentell unterstützt Keycloak nun das OAuth Client ID Metadata Document (CIMD) – ein aufkommender Standard zur Beschreibung von OAuth-2.0-Client-Metadaten. Da das Model Context Protocol (MCP) ab Version 2025-11-25 CIMD voraussetzt, lässt sich Keycloak künftig als Authorization Server für MCP-Szenarien nutzen.
Als Preview erscheinen zudem die Identity Brokering APIs V2, die den Legacy Token Exchange V1 ablösen sollen, sowie Step-up Authentication für das SAML-Protokoll. Organisationen profitieren außerdem von isolierten Gruppenhierarchien pro Organisation, die Namenskonflikte innerhalb eines Realms vermeiden.
Auf der Infrastrukturseite unterstützt Keycloak inzwischen OpenJDK 25 [6]. Das Container-Image setzt allerdings weiterhin auf Java 21, um FIPS-Kompatibilität zu gewährleisten – für Unternehmen in regulierten Umgebungen bleibt damit alles beim Alten. Bestehende Deployments mit Java 21 sollen unverändert weiter funktionieren. Weitere Verbesserungen betreffen die automatische Truststore-Initialisierung auf Kubernetes und OpenShift, neue Client-Certificate-Lookup-Provider für Traefik und Envoy sowie überarbeitete HTTP-Access-Logs, die sensible Informationen wie Token und Cookies ausfiltern.
Vor dem Update auf Keycloak 26.6.0 [7] sollten Administratoren die Breaking Changes im Upgrading Guide [8] prüfen. JavaScript-basierte Policies erfordern nun ein aktiviertes Scripts-Feature. Client-URIs müssen HTTPS verwenden, und die Issuer-Konfiguration für JWT Authorization Grant und Client Assertions muss eindeutig einen Provider identifizieren.
URL dieses Artikels:
https://www.heise.de/-11250371
Links in diesem Artikel:
[1] https://www.keycloak.org/2026/04/keycloak-2660-released
[2] https://clc-conference.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_clc.empfehlung-ho.link.link&LPID=35283
[3] https://clc-conference.eu/cfp.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_clc.empfehlung-ho.link.link&LPID=35283
[4] https://clc-conference.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_clc.empfehlung-ho.link.link&LPID=35283
[5] https://datatracker.ietf.org/doc/html/rfc7523
[6] https://www.heise.de/blog/Java-25-Neue-Features-nicht-so-bekannt-aber-wichtig-10530723.html
[7] https://www.keycloak.org/2026/04/keycloak-2660-released
[8] https://www.keycloak.org/docs/latest/upgrading/index.html
[9] mailto:map@ix.de
Copyright © 2026 Heise Medien
(Bild: Plane)
Mit Version 1.3.0 erhält Plane viele wichtigste Updates: Gitea-Login, verbesserte Oberfläche und neue API-Endpunkte kommen für die Open-Source-Jira-Alternative.
Plane schließt in Version 1.3.0 der freien Community-Version mehrere Sicherheitslücken, bringt neue Integrationen und überarbeitet die Benutzeroberfläche umfassend. Das Release führt unter anderem eine Gitea-Authentifizierung ein, öffnet die API für externe Projektzusammenfassungen und validiert Dateiuploads sowie Projektkennungen strenger. Parallel haben die Entwickler mehrere sicherheitsrelevante Schwachstellen behoben – darunter manipulierbare Rate-Limits für API-Tokens, eine SSRF-Lücke in Webhooks und CSV-Injection beim Datenexport.
Bei Plane handelt es sich um ein quelloffenes Projektmanagement- und Issue-Tracking-System für Entwickler. Es bietet Aufgabenverwaltung, Roadmaps und API-Anbindung und ist als selbst hostbare Alternative zu Jira oder Linear gedacht.
Plane unterstützt ab Version 1.3.0 die Authentifizierung über Gitea. Teams mit selbst gehosteter Git-Infrastruktur können damit Benutzerkonten koppeln oder Single Sign-on einrichten. Neu ist außerdem eine externe Project-Summary-API, über die Drittsysteme Projektübersichten abrufen können – etwa für Dashboards oder Reporting. Webhook-Payloads lassen sich nun zudem lokalisieren.
Projektnamen und -kennungen akzeptieren keine potenziell ausführbaren Sonderzeichen mehr, was Injection-Angriffe erschwert. Im Administrationsmodus verhindert Plane außerdem, dass Admins versehentlich alle Authentifizierungsmethoden deaktivieren. Erweiterte Logs liefern detailliertere Fehlermeldungen bei Authentifizierungsproblemen und erleichtern die Fehlersuche und das Auditing.
Einen großen Teil des Releases machen Änderungen an der Oberfläche aus. Plane setzt stärker auf Design-Tokens – also zentral definierte Werte für Farben, Abstände und andere UI-Parameter –, die für ein einheitlicheres Erscheinungsbild sorgen. Die Entwickler haben unter anderem die Detailansichten von Work Items, die Sidebar, Kommentare sowie die Workspace- und Mitgliederverwaltung überarbeitet. Dropdowns verhalten sich kontextsensitiver und zeigen ausgewählte Einträge oben an. Neue Ladezustände sorgen für flüssigere Übergänge, überarbeitete Themes und Editor-Farben für mehr visuelle Konsistenz.
Attachments akzeptieren jetzt auch Markdown-Dateien. Eine Zeitzonen-Einstellung auf Workspace-Ebene sorgt dafür, dass neue Projekte automatisch die richtige Zeitzone übernehmen. Die Mention-Suche nutzt jetzt Debouncing und löst damit bei schneller Eingabe weniger API-Anfragen aus. Die Navigation zeigt eingehende Aufgaben (Intake) direkt als Zähler an.
Im Bereich Sicherheit verhindert eine serverseitige Absicherung nun, dass Angreifer Rate-Limits von API-Tokens manipulieren. Webhook-URLs durchlaufen eine strengere Validierung, um Server-Side Request Forgery (SSRF) zu unterbinden – also Angriffe, bei denen ein Server dazu gebracht wird, interne Ressourcen anzusprechen.
Beim CSV-Export bereinigt Version 1.3.0 eingebettete Formeln, die Tabellenprogramme wie Excel sonst ungefragt ausführen könnten. Zusätzlich blockiert eine neue Upload-Validierung potenziell schädliche Dateien, und der HTTP-Header X-Frame-Options schützt vor Clickjacking.
Bei der Internationalisierung kommt Ukrainisch als neue Sprache hinzu, die russische Übersetzung wurde erweitert. Zahlreiche Bugfixes betreffen den Editor, die Navigation, API-Endpunkte und E-Mail-Templates.
Alle Informationen zum Update finden sich in den Release Notes auf der Projektseite von Plane auf GitHub [1].
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11250055
Links in diesem Artikel:
[1] https://github.com/makeplane/plane/releases/tag/v1.3.0
[2] https://www.heise.de/download/product/plane-project-management?wt_mc=intern.red.download.tickermeldung.ho.link.link
[3] https://www.heise.de/ix
[4] mailto:fo@heise.de
Copyright © 2026 Heise Medien
(Bild: software-architektur.tv)
Patterns of Anarchy: Andrew Harmel-Law und Eberhard Wolff sprechen über anarchistische Ideen, die auf Softwarearchitektur treffen.
Andrew Harmel-Law, Tech Principal beim Beratungsunternehmen Thoughtworks, hat eine ungewöhnliche Verbindung zwischen anarchistischer Theorie und moderner Softwarearchitektur aufgedeckt. Ausgangspunkt ist das 1966 erschienene Buch „Patterns of Anarchy“ von Leonard I. Krimerman und Lewis Perry – eine Anthologie anarchistischer Aufsätze, die auch Christopher Alexander als Inspiration für sein einflussreiches Werk „A Pattern Language“ diente.
Harmel-Law stieß auf die Sammlung, weil Alexander sie in seinem 1977 veröffentlichten Standardwerk [1] zitierte. Alexanders Konzept der Pattern Language – 253 Entwurfsmuster für Architektur und Städtebau – hat auch die Softwarebranche nachhaltig geprägt. Die berühmten Design Patterns der sogenannten Gang of Four aus dem Jahr 1994 gehen direkt auf Alexanders Arbeit zurück.
Die Anthologie von Krimerman und Perry versammelt Texte zur anarchistischen Tradition und behandelt unter anderem alternative Gemeinschaftsmodelle und Organisationsprogramme. Besonders der Abschnitt „Constructive Anarchism: Alternative Communities and Programs“ widmet sich praktischen Aspekten dezentraler Organisationsformen – ein Thema, das in der Softwareentwicklung aktueller ist denn je. Darüber sprechen Andrew Harmel-Law und Eberhard Wolff in dieser englischsprachigen Folge des Videocasts software-architektur.tv [2].
Der auf agile Methoden und Domain-Driven Design spezialisierte Berater [4] Andrew Harmel-Law sieht deutliche Parallelen zwischen anarchistischen Organisationsideen und modernen Entwicklungspraktiken. Dezentrale, autonome Strukturen und föderale Entscheidungsprozesse, wie sie anarchistische Denker beschrieben, spiegeln sich in agilen Teams, Open-Source-Communities und selbstorganisierten Entwicklungsgruppen wider. Harmel-Law wird einige der interessantesten Erkenntnisse aus seiner Perspektive als Student des soziotechnischen Organisationsdesigns teilen. Manchmal wird er eigene Kommentare hinzufügen. Und natürlich stellt sich die Frage, inwiefern dies mit Softwareentwicklung zusammenhängt.
Die Folge wird am Freitag, 10. April 2026, live ab 13 Uhr gestreamt. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite [5] einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger [6] und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer [7] (Socreatory) und Ralf D. Müller [8] (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.
URL dieses Artikels:
https://www.heise.de/-11248682
Links in diesem Artikel:
[1] https://en.wikipedia.org/wiki/A_Pattern_Language
[2] https://software-architektur.tv/
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://andrewharmellaw.github.io
[5] https://software-architektur.tv/
[6] https://www.heise.de/developer/Continuous-Architecture-2687847.html
[7] https://www.socreatory.com/de/trainers/lisa-moritz
[8] https://techstories.dbsystel.de/blog/profiles/Ralf-D.-Mueller.html
[9] mailto:map@ix.de
Copyright © 2026 Heise Medien
(Bild: Ink)
Ink 7.0 überarbeitet das Input-Handling und bringt neue Hooks für Animation, Paste und responsive Layouts. Voraussetzung sind jetzt Node.js 22 und React 19.2.
Mit Version 7.0.0 hebt die React-basierte CLI-Bibliothek Ink ihre Mindestanforderungen deutlich an und überarbeitet das Input-Handling grundlegend. Gleichzeitig kommen neue APIs für Interaktivität, Layout und Animation hinzu. Die Maintainer setzen künftig Node.js 22 [1] und React ab Version 19.2 voraus. Die Änderungen erfordern Anpassungen in bestehenden Projekten, ermöglichen aber auch komplexere Terminal-UIs.
Mit Ink lassen sich interaktive Kommandozeilenanwendungen deklarativ mit React-Komponenten entwickeln. Statt direkt mit ANSI-Escape-Sequenzen und Low-Level-Terminal-APIs zu arbeiten, definieren Entwickler ihre CLI-Oberflächen ähnlich wie Web-UIs – mit State-Management, Komponentenstruktur und Hooks.
Intern nutzt Ink nun Reacts useEffectEvent, um zu vermeiden, dass sich Input-Handler bei jedem Render neu registrieren. Das stabilisiert das Event-Handling und reduziert Performance-Overhead.
Auch bei der Verarbeitung von Tastatureingaben gibt es Korrekturen. So unterscheidet Ink nun sauber zwischen key.backspace und key.delete. Viele Terminals senden für beide Tasten identische Byte-Sequenzen, was bislang zu Fehlinterpretationen führte. Wer bisher auf key.delete reagiert hat, um Backspace abzufangen, muss seine Logik anpassen. Außerdem setzt Ink key.meta nicht mehr beim Drücken der Escape-Taste: key.meta steht jetzt ausschließlich für Alt-/Meta-Kombinationen, key.escape wird separat ausgewiesen.
Der neue Hook usePaste behandelt eingefügten Text aus der Zwischenablage als eigenständiges Ereignis. Dafür aktiviert Ink den Bracketed-Paste-Modus des Terminals, sodass eingefügter Text als zusammenhängender String ankommt. Ohne diesen Modus würde ein Paste-Vorgang als Serie einzelner Keypress-Events erscheinen – das ist problematisch etwa bei Eingabefeldern oder REPL-artigen Interfaces.
Für responsive Layouts liefert der neue Hook useWindowSize die aktuelle Terminalgröße in Spalten und Zeilen und löst bei Änderungen automatisch ein Re-Render aus. So lassen sich etwa Tabellen oder Layouts dynamisch an unterschiedliche Terminalgrößen anpassen.
Mit useBoxMetrics ermitteln Entwickler zur Laufzeit die tatsächlichen Dimensionen von Layout-Containern – vergleichbar mit DOM-Messungen im Browser. Das führt zu präziserer Layout-Logik, wenn Inhalte abhängig von der gerenderten Größe positioniert oder gekürzt werden müssen.
Der Hook useAnimation bringt einen integrierten Animationsmechanismus mit. Er stellt einen Frame-Zähler bereit, der in konfigurierbaren Intervallen hochzählt und sich pausieren lässt. Beim Unmount räumt er automatisch auf. Typische Einsatzfälle sind Spinner, Fortschrittsanzeigen oder ASCII-Animationen.
Beim Rendering kommt ein Alternate-Screen-Modus hinzu. Aktiviert man ihn beim Aufruf von render(), nutzt die Anwendung den zweiten Bildschirmpuffer des Terminals – ein Verhalten, das von Programmen wie Vim oder less bekannt ist. Nach dem Beenden stellt das Terminal den ursprünglichen Inhalt wieder her. Ergänzend lässt sich mit der neuen Option interactive die automatische Erkennung interaktiver Umgebungen überschreiben, etwa für CI-Pipelines oder Pipe-Szenarien.
Das Layout-System erhält ebenfalls Erweiterungen. Die Komponente <Box> unterstützt jetzt aspectRatio, alignContent, position="static" sowie Positionsangaben wie top, right, bottom und left. Dazu kommen maxWidth und maxHeight. Mit borderBackgroundColor lässt sich erstmals die Hintergrundfarbe von Rahmen unabhängig vom Inhalt setzen. Für Text führt Ink die Option wrap="hard" ein: Sie füllt Zeilen strikt auf die verfügbare Breite auf und bricht dabei auch mitten im Wort um – nützlich für tabellarische oder streng ausgerichtete Monospace-Layouts.
Im Fokus-Management liefert der Hook useFocusManager nun zusätzlich die ID des aktuell fokussierten Elements. Das erleichtert die Steuerung komplexerer Interaktionen und die Fehlersuche.
Neben den funktionalen Neuerungen behebt Version 7.0.0 mehrere Stabilitätsprobleme. Dazu zählen Darstellungsfehler bei CJK-Texten und Emojis, Abstürze bei unbekannten Keycodes im Input-Handling sowie Rendering-Fehler bei abschließenden Zeilenumbrüchen und überlappenden Schreibvorgängen.
Alle Informationen zur neuen Version 7.0.0 finden sich in den Release Notes auf der GitHub-Projektseite von Ink [2].
URL dieses Artikels:
https://www.heise.de/-11249521
Links in diesem Artikel:
[1] https://www.heise.de/blog/Node-js-22-Lass-uns-Freunde-bleiben-9708771.html
[2] https://github.com/vadimdemedes/ink/releases/tag/v7.0.0
[3] https://www.heise.de/ix
[4] mailto:fo@heise.de
Copyright © 2026 Heise Medien
