Anmelden
(Bild: bombermoon/Shutterstock.com)
Rsbuild 2.0 setzt auf Rspack 2.0, modernisiert Defaults (ESM-first, Node 20) und reduziert Abhängigkeiten. Neue APIs erweitern die Kommunikation.
Rsbuild 2.0 ist da: Das Major-Release des Build-Tools setzt auf Rspack 2.0, modernisiert zahlreiche Defaults – unter anderem in Richtung ESM-first und Node 20 – und reduziert die Zahl der Abhängigkeiten deutlich. Neue APIs erweitern die Kommunikation zwischen Dev-Server und Client. Gleichzeitig bricht die Version mit mehreren Altlasten: CommonJS-Builds und ein paar Webpack-Abhängigkeiten fallen weg.
Rsbuild ist ein Build-Tooling-Layer auf Basis des Rust-basierten Bundlers Rspack und Teil des Rstack-Ökosystems. Zu diesem gehören unter anderem Rspress, Rslib und Rstest, die sich eine gemeinsame Build- und Plugin-Architektur teilen.
Im Zentrum von Rsbuild 2.0 steht das Upgrade auf Rspack 2.0 [1]. Projekte profitieren damit von schnellerem Bundling und neuen Optimierungsmöglichkeiten. Rspack verfolgt einen webpack-kompatiblen Ansatz, arbeitet durch seine Rust-Implementierung aber deutlich schneller.
Parallel dazu modernisiert Rsbuild seine technische Basis. Das Core-Paket erscheint nur noch als ES-Modul, ein CommonJS-Build entfällt. Die Zielplattformen steigen: Für Node.js gilt nun Version 20 [2] als Standard, die Browser-Targets orientieren sich an einem Baseline-Stand von Mai 2025. Das verringert den Bedarf an Transpiling und Polyfills und führt zu kleineren Bundles. Für Node-Ziele erzeugt Rsbuild außerdem standardmäßig unminifizierte ES-Module – Stacktraces bleiben so besser lesbar.
Neu ist ein experimenteller Support für React Server Components (RSC). Das Plugin rsbuild-plugin-rsc integriert serverseitig gerenderte Komponenten, die Datenabruf und Rendering kombinieren und so weniger JavaScript an den Client schicken. Es baut auf nativer Rspack-Unterstützung auf und nutzt die Environments-API von Rsbuild, um Client- und Server-Kontext gemeinsam zu verwalten. Das Modern.js-Framework setzt das Plugin bereits ein; eine Integration mit TanStack Start ist geplant.
Im Zuge dieser Arbeiten erweitert Rsbuild die Kommunikation zwischen Dev-Server und Browser. Über den bestehenden HMR-Kanal lassen sich jetzt gezielt Nachrichten austauschen: Der Server schickt per hot.send ein Event, das der Client über import.meta.webpackHot.on empfängt. So kann etwa ein serverseitiger Prozess den Client zu einem gezielten Update veranlassen, ohne die gesamte Seite neu zu laden. Ein zusätzlicher WebSocket ist dafür nicht nötig.
Auch die Server-Konfiguration gewinnt an Flexibilität. Die neue Option server.setup erlaubt es, Initialisierungslogik, Middleware oder eigene Endpunkte direkt in der Rsbuild-Konfiguration zu definieren – sowohl für den Dev- als auch den Preview-Server. Das bisherige setupMiddlewares bleibt vorerst erhalten, gilt aber als veraltet.
Beim Code-Splitting führt Rsbuild ein neues splitChunks-Modell ein, das die bisherige Option performance.chunkSplit ergänzt und perspektivisch ersetzen soll. Die Konfiguration orientiert sich nun direkt an Rspack und bietet vordefinierte Presets, etwa um jedes npm-Paket in einen eigenen Chunk aufzuteilen.
Bei den Sicherheits-Defaults ändert sich ebenfalls einiges: Der Dev-Server lauscht standardmäßig nur noch auf localhost statt auf allen Interfaces. Das verhindert, dass Entwicklungsserver unbeabsichtigt im lokalen Netzwerk erreichbar sind. Außerdem steigt die Proxy-Middleware auf eine neue Version um, die HTTP/2 unterstützt und bekannte Sicherheitslücken schließt.
Die Abhängigkeiten schrumpfen deutlich. Pakete wie core-js für Polyfills oder das Module-Federation-Runtime gehören nicht mehr zur Standardinstallation. Die Zahl der mitgelieferten Dependencies sinkt laut Projekt von 13 auf 4.
Darüber hinaus unterstützt Rsbuild jetzt benutzerdefinierte Logger pro Instanz. Damit lassen sich Log-Level und Ausgabeformate feiner steuern, ohne den globalen Logger zu verändern. Auch die Projekt-Templates wurden überarbeitet: Neue Projekte können optional den React Compiler nutzen, und ein auf TypeScript-Go basierender Linter steht experimentell bereit. Vorlagen für React 18 und Vue 2 in create-rsbuild hat das Team entfernt.
Mit Version 2.0 gehen mehrere Breaking Changes einher. Neben dem Wegfall von Node 18 und CommonJS entfernt das Projekt sämtliche Webpack-spezifischen Komponenten und ändert diverse Defaults. Für die Migration stellt das Team eine Anleitung bereit; viele Anpassungen lassen sich nach eigenen Angaben automatisieren.
Alle Informationen zur neuen Rsbuild-Version finden sich in den Release Notes auf der GitHub-Projektseite [3] und in der Ankündigung der Entwickler [4].
URL dieses Artikels:
https://www.heise.de/-11267704
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Stockinq / Shutterstock.com)
Anthropic experimentiert mit dem Umfang seines Pro-Tarifs: Bei einigen Neukunden fehlt die für Entwickler wichtige Claude-Code-Komponente.
Bei Anthropic gibt es teilweise Änderungen für neue Kunden: Das KI-Unternehmen hat testweise auf einigen Webseiten Claude Code aus dem Pro-Tarif genommen. Außerdem berichtet ein Neukunde, dass er sich mit Persona identifizieren musste, einem US-Unternehmen, das Ausweisdaten und Gesicht von Personen kontrolliert.
Eine Reihe von Nutzern haben in Blogs [1] oder bei Reddit [2] mitgeteilt, dass auf der Preisübersicht von Claude zum Pro-Tarif die Code-Komponente fehlt. Diese ist gerade für Entwicklerinnen und Entwickler interessant. Ein Anthropic-Manager beschwichtigt bei X [3], dass es sich nur um einen Test gehandelt habe, der zwei Prozent aller Neuanmeldungen betroffen habe. Ob diese zwei Prozent dennoch Zugriff auf Claude Code erhalten oder wie es insgesamt mit den Tarifen weitergeht, sagt er nicht. Eine Antwort auf eine Anfrage von heise developer steht noch aus.
Viele LLM-Coding-Firmen haben den Umfang ihres Angebots in letzter Zeit begrenzt, da gerade Agenten wie OpenClaw die Kapazitäten offensichtlich an den Rand bringen: Anthropic selbst hat die Nutzung von externen Tools wie OpenClaw [4] eingeschränkt, ähnlich wie Google für Gemini CLI [5]. Microsoft stoppte die Neuanmeldung für GitHub Copilot Pro komplett [6] und nahm alle rechenaufwendigen Opus-Modelle aus den Tarifen für Endanwender. Opus liefert allgemein die besten Ergebnisse zum Coden und Entwickler sind nun gezwungen, in Business-Tarife zu wechseln, was für Einzelentwickler schwierig ist.
Ein einzelner Bericht eines X-Accounts [7] legt nahe, dass Anthropic bei ihm eine Identifizierung per US-Dienstleister Persona verlangt hat. Persona fordert ein Ausweisdokument und ein Live-Foto zur Identifizierung. Der Dienst ist durchaus umstritten [8]; Anbieter wie Discord haben sich wieder von ihm getrennt.
In den aktuellen, heute gesichteten Datenschutzrichtlinien von Anthropic [9] findet sich kein Hinweis auf Persona. Zu diesem Thema läuft ebenfalls eine Anfrage von heise developer bei Anthropic.
Auch Sicherheitsforscher, deren Experimente Anthropic standardmäßig zunächst blockiert, müssen sich seit Neuestem registrieren, um weiterarbeiten zu können. Persona ist hierbei zwar nicht vorgesehen, aber ein Business-Zugang mit Organisations-ID [10]. Auch hier werden Einzelentwickler ausgeschlossen.
URL dieses Artikels:
https://www.heise.de/-11267811
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: MP_P / Shutterstock.com)
Die neue Version der Programmiersprache mit Go-Unterbau soll oft zehnmal schneller sein als der Vorgänger, der noch die JavaScript-Codebasis verwendete.
Microsoft hat die Beta-Version von TypeScript 7.0 veröffentlicht. Damit rückt das erste Release mit in Go geschriebenem Compiler und Language Service immer näher. Trotz Beta-Label soll TypeScript 7.0 bereits so weit sein, dass Entwicklerinnen und Entwickler es mitunter in ihrer täglichen Arbeit einsetzen können. Es soll deutliche Geschwindigkeitsvorteile gegenüber früheren TypeScript-Versionen bringen, die eine JavaScript-Basis nutzten.
Seit über einem Jahr arbeiten interne Microsoft-Teams gemeinsam mit Teams anderer Unternehmen – darunter Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Slack, Vanta, Vercel und VoidZero – am Wechsel zur Go-Codebasis für TypeScript, mit antizipierten hohen Geschwindigkeitsvorteilen [1]. Durch die Änderung soll TypeScript 7.0 oftmals rund zehnmal schneller laufen als TypeScript 6.0, wie Microsoft in der aktuellen Ankündigung erneut bestätigt [2]. Erst vor knapp einem Monat ist TypeScript 6.0 erschienen [3], um eine Brücke zwischen der alten und der neuen Codebasis zu schlagen.
TypeScript 7.0 lässt sich parallel zu TypeScript 6.0 installieren. Die neue Version ist darauf ausgelegt, mit dem Type-Checking- und Kommandozeilenverhalten von TypeScript 6.0 kompatibel zu sein. Jeglicher TypeScript-Code, der mit Version 6.0 sauber kompiliert wird (mit aktiviertem stableTypeOrdering-Flag und ohne das ignoreDeprecations-Flag), sollte laut Microsoft in Version 7.0 identisch kompiliert werden – nur schneller.
Dabei bringt TypeScript 7.0 die gleichen neuen Standardeinstellungen (Defaults), die seit Version 6.0 gelten. Wie der Hersteller zu bedenken gibt, ist auch Version 6.0 noch recht neu, und viele Projekte dürften sich noch darauf einstellen müssen. Beispielsweise ist nun strict standardmäßig auf true gesetzt und module verwendet im Standard esnext. Einige Deprecations, also als veraltet markierte Funktionen, geben jetzt schwerwiegende Fehler aus. Beispielsweise wird target: es5 nicht mehr unterstützt.
TypeScript 7.0 Beta lässt sich via npm installieren:
FreshRSS npm install -D @typescript/native-preview@betaWer die neue Version auf seiner Codebasis direkt ausprobieren möchte, kann auch zur Visual-Studio-Code-Erweiterung „TypeScript (Native Preview) [6]“ greifen.
Weitere Informationen zum Einsatz von TypeScript 7.0 Beta bietet der Microsoft-Entwicklerblog [7].
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11267409
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Andrey_Popov / Shutterstock.com)
Im neuen Release bringt die Versionsverwaltung den experimentellen Befehl git history, um beispielsweise Fehler zu korrigieren oder einen Commit aufzuteilen.
Das verteilte Versionsverwaltungssystem Git 2.54 ist erschienen. Ein experimenteller git history-Befehl und ein veränderter Umgang mit Hooks zählen zu den wichtigsten Neuerungen in dem Release, an dem 137 Personen mitgewirkt haben.
Wie GitHub in einem Blogeintrag ausführt [1], bot Git bisher bereits Möglichkeiten, die Historie eines Projekts zu verändern. So lassen sich mit git rebase -i Commits anders anordnen, editieren oder verwerfen. Das ändert jedoch auch Working Tree und Index, was weitreichende Aktionen nach sich ziehen kann.
Für einfache Fälle steht daher nun der experimentelle Befehl git history bereit, der unter der Haube auf der Funktionsweise von git replay basiert. git history unterstützt die beiden Vorgänge reword und split. Mit git history reword <commit> können Entwicklerinnen und Entwickler eine Commit-Nachricht im Editor öffnen und anpassen, um zum Beispiel einen Tippfehler zu berichtigen. Das aktualisiert ebenfalls Branches, die aus diesem Commit hervorgehen. Im Gegensatz zu git rebase verändern sich Working Tree und Index hierbei jedoch nicht. Die zweite mögliche Aktion, git history split <commit>, erlaubt das Aufteilen eines Commits in zwei verschiedene Commits.
Zu den bewussten Einschränkungen des history-Befehls zählt, dass er weder mit Historien umgehen kann, die Merge Commits enthalten, noch Vorgänge durchführt, die Merge-Konflikte auslösen würden.
Eine weitere bedeutende Neuerung betrifft den Umgang mit Git-Hooks [2]. Diese ließen sich bisher nur als ausführbare Skripte definieren, die sich in einem spezifischen Verzeichnis [3] befanden – standardmäßig im Unterverzeichnis hooks des .git-Verzeichnisses. Das brachte einige Schwierigkeiten mit sich, wie GitHub erläutert [4]: Wollten Entwickler beispielsweise vor jedem Commit auf allen Repositories einen Linter laufen lassen, so mussten sie das entsprechende Skript in jedes Repository kopieren, was zu Arbeitsaufwand und Fehleranfälligkeit führte.
Diese Probleme soll Git 2.54 lösen, denn Hooks lassen sich nun in den Konfigurationsdateien definieren. Statt ein Skript in .git/hooks/pre-commit zu platzieren, ist nun diese Alternative möglich:
[hook "linter"]
event = pre-commit
command = ~/bin/linter --cpp20Auf diese Weise lassen sich Hooks zentral definieren und auf alle Repos anwenden. Eine solche Konfiguration kann sich User-basiert in ~/.gitconfig befinden, systemweit in /etc/gitconfig oder in einer lokalen Konfigurationsdatei eines Repositories. Entwicklerinnen und Entwickler können zudem mehrere Hooks für ein bestimmtes Event definieren oder Hooks wahlweise in einem Repository deaktivieren.
Weitere Informationen zu diesen und anderen Neuerungen in Git 2.54 finden sich in den Release Notes [5].
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11265560
Links in diesem Artikel:
[1] https://github.blog/open-source/git/highlights-from-git-2-54/
[2] https://git-scm.com/docs/githooks
[3] https://git-scm.com/docs/git-config/2.54.0#Documentation/git-config.txt-corehooksPath
[4] https://github.blog/open-source/git/highlights-from-git-2-54/
[5] https://lore.kernel.org/git/xmqqa4uxsjrs.fsf@gitster.g/T/#u
[6] https://www.heise.de/download/product/git-57506?wt_mc=intern.red.download.tickermeldung.ho.link.link
[7] mailto:mai@heise.de
Copyright © 2026 Heise Medien
(Bild: Sundry Photography/Shutterstock.com)
Kunden verwenden GitHub Copilot stärker als geplant. Jetzt zieht Microsoft die Reißleine und schränkt die Nutzung ein.
Microsoft [1] hat die Registrierung bei GitHub Copilot pausiert. Neukunden können sich somit nicht mehr für die Tarife Pro, Pro+ und Student anmelden. Gleichzeitig verschärfte das US-Unternehmen Tokenlimits und kündigte die Entfernung von Claude Opus 4.5 und 4.6 aus dem Pro+-Tarif an. Opus 4.7 [2] bleibt im Pro+-Tarif hingegen verfügbar. Aus dem Pro-Tarif wurden alle Opus-Modelle sofort entfernt. Die kostenfreie Stufe und Enterprise-Abonnements sind von den Änderungen derzeit nicht betroffen.
Hintergrund der Änderungen sei ein unerwartet hoher Bedarf an Rechenleistung. „Lang andauernde, parallelisierte Sitzungen beanspruchen regelmäßig weitaus mehr Ressourcen als geplant. Die ursprünglichen Strukturen waren dafür nicht ausgelegt“, schreibt Joe Binder, VP of Product, im GitHub-Blog [3]. Inzwischen übernähmen KI-Agenten mehr Aufgaben und Kunden stießen an ihre Nutzungsgrenzen. Ohne Einschränkungen verschlechtere sich die Servicequalität für Bestandskunden.
Die Nutzungsgrenzen des Pro+-Abonnements sind mehr als fünfmal so hoch wie im Pro-Tarif. Dieses Limit ist von der Anzahl der Premiumanfragen unabhängig. Stattdessen handelt es sich um tokenbasierte Beschränkungen innerhalb eines festgelegten Zeitfensters. Somit können Kunden noch über ungenutzte Premiumanfragen verfügen, aber bereits die Nutzungsgrenzen erreicht haben.
Microsoft unterscheidet bei den Nutzungslimits von GitHub Copilot zwischen zwei Zeitfenstern, die sich nach dem Tokenverbrauch und einem Multiplikator richten, der bei rechenintensiven Modellen entsprechend höher ist. Das erste Zeitfenster bezieht sich auf die jeweilige Session. Reizen Kunden ihr Limit aus, müssen sie warten, bis sich das Nutzungsfenster zurücksetzt, um Copilot wieder verwenden zu können.
Das zweite Zeitfenster ist das wöchentliche Limit, das eine Obergrenze für die nutzbaren Token darstellt. Damit will Microsoft parallelisierte Anfragen beschränken, die oft lange laufen und hohe Kosten verursachen. Künftig wolle das Unternehmen die Limits anpassen, um ein Gleichgewicht zwischen Zuverlässigkeit und Nachfrage zu erzielen, schreibt Binder. Ihren aktuellen Verbrauch können Kunden in Visual Studio Code oder dem Kommandozeilentool von GitHub Copilot einsehen.
Microsoft empfiehlt Kunden, die sich ihrem Nutzungslimit nähern, auf kleinere Modelle umzusteigen, weniger parallele Workflows zu verwenden oder den Plan-Mode zu nutzen. Alternativ verweist das Unternehmen seine Pro-Kunden auf den Pro+-Tarif.
GitHub Copilot kostet im Pro-Tarif monatlich 10 US-Dollar, Pro+-Nutzer zahlen 39 US-Dollar. Kunden der Pro- und Pro+-Tarife können ihr Abonnement jederzeit kündigen und sich die Gebühren für April über eine Supportanfrage bis zum 20. Mai 2026 zurückerstatten lassen. Zuletzt versuchte Microsoft, nicht nur mit Abonnement-Gebühren an GitHub Copilot zu verdienen, sondern blendete Werbung in Pull Requests [4] ein. Nach Nutzerbeschwerden ruderte das Unternehmen zurück.
URL dieses Artikels:
https://www.heise.de/-11265219
Links in diesem Artikel:
[1] https://www.heise.de/thema/Microsoft
[2] https://www.heise.de/news/Befolgt-Anweisungen-substanziell-besser-Anthropic-gibt-Opus-4-7-frei-11261267.html
[3] https://github.blog/news-insights/company-news/changes-to-github-copilot-individual-plans/
[4] https://www.heise.de/news/Werbung-oder-Hinweis-GitHub-Copilot-erweiterte-Pull-Requests-um-Produkttipps-11240850.html
[5] https://www.heise.de/ix
[6] mailto:sfe@ix.de
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
Wie wird IEC 62443-4-1 im Alltag wirksam? Holger Santelmann über praktische Umsetzung, Trainings, Tests und bessere Zusammenarbeit für sichere Software.
In dieser Episode spricht Richard Seidl mit Holger Santelmann über IT-Sicherheit in Entwicklungsprozessen und über die internationale Norm IEC 62443-4-1, die festlegt, wie sichere Entwicklungsprozesse für industrielle Software und Systeme gestaltet werden sollen. Im Zentrum steht die Frage, wie Normen praktisch umgesetzt werden können, ohne dass sie nur lästige Pflicht bleiben. Holger Santelmann erzählt, wie sein Unternehmen diese Norm eingeführt und zum echten Werkzeug für bessere Softwarequalität gemacht hat. Es geht um konkrete Herausforderungen: von Trainings und unabhängigen Testern bis hin zu interner Reflexion und Zusammenarbeit im Team.
Holger Santelmann [2] ist Dipl.-Medieninformatiker (FH) und verfügt über mehr als 20 Jahre Erfahrung in der Softwareentwicklung. Er hat als Senior Software Developer bei der Firma M&M Software GmbH angefangen und sich in den letzten Jahren immer mehr auf das Thema Release- bzw. Testmanagement spezialisiert. Als Leiter des Competence Centers Quality Engineering treibt er das Thema Qualitätssicherung innerhalb der Firma M&M Software GmbH weiter voran und unterstützt den Softwareentwicklungsprozess.
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: „Praxisnah sicher entwickeln mit IEC 62443-4-1 – Holger Santelmann [3]“.
URL dieses Artikels:
https://www.heise.de/-11251604
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://www.linkedin.com/in/holger-santelmann-01266974/
[3] https://www.richard-seidl.com/de/blog/iec-62443-4-1-it-sicherheit
[4] mailto:mdo@ix.de
Copyright © 2026 Heise Medien
(Bild: Schager / Shutterstock.com)
Google formiert laut einem Bericht ein „Strike Team“, um die Coding-Fähigkeiten seiner KI-Modelle zu steigern und den Rückstand auf Anthropic aufzuholen.
Google soll intern ein Sonderteam aus Forschern und Ingenieuren zusammengestellt haben, um seine KI-Modelle für die Softwareentwicklung zu verbessern. Auslöser ist laut einem Bericht von The Information die wachsende Überzeugung innerhalb von Google DeepMind, dass Anthropics Coding-Tools den eigenen Gemini-Modellen derzeit überlegen sind. Während Anthropic nach eigenen Angaben nahezu seinen gesamten Code KI-gestützt schreibt, liegt der Anteil bei Google laut Finanzchefin Anat Ashkenazi bei rund 50 Prozent. Der Rückstand soll nun aufgeholt werden – und zwar nicht nur aus Wettbewerbsgründen: Googles Mitgründer Sergey Brin sieht verbesserte Coding-Fähigkeiten als Zwischenschritt auf dem Weg zu einer KI, die sich irgendwann selbst weiterentwickeln kann.
Mit seinem „Strike Team“ verschärft damit auch Google die Gangart in dem zurzeit meist umkämpften Teilbereich der Künstlichen Intelligenz [1]. Anthropic hatte sich mit seinem Coding-Tool Claude Code frühzeitig auf den Bereich Coding spezialisiert. OpenAI hat sein Engagement rund um das KI-Tool Codex massiv erweitert [2], woraufhin Anthropic auch ein Design-Tool namens Claude Design vorstellte [3].
Bei Google geht es aktuell erst einmal auch darum, den internen Einsatz von KI stärker voranzubringen, wie das US-Magazin The Information unter Berufung auf namentlich nicht genannte Quellen im Unternehmen berichtet [4]. Bislang habe sich Google bei seinen Modellen vor allem auf die Bedürfnisse externer Kunden konzentriert. Ähnliches gilt für Apple: Auch dort werden Entwickler gerade im Umgang mit KI-Coding-Tools für die Softwareentwicklung [5] geschult, um den internen Einsatz zu modernisieren. Solche internen Modelle, welche die Eigenheiten des Google-Codes besser abbilden als öffentliche Modelle, wolle man zwar wegen der darin enthaltenen Geschäftsgeheimnisse nicht nach außen geben. Sie können aber eine wichtige Zwischenstufe sein, um bessere öffentliche Modelle zu erschaffen.
Teamleiter sei Sebastian Borgeaud, ehemaliger Pre-Training-Lead für Gemini bei Google DeepMind. Der Fokus liege auf komplexen Langzeit-Coding-Aufgaben. Dazu zähle das Verständnis von Codebases und das Schreiben kompletter Software. Google-Mitgründer Sergey Brin und DeepMind-CTO Koray Kavukcuoglu sollen persönlich in das Strike Team eingebunden sein. Brin habe die Mitarbeiter angehalten, verpflichtend interne Agenten für mehrstufige Aufgaben zu nutzen. Ein Fernziel sei der sogenannte „AI Takeoff“, also eine KI, die sich selbst verbessern kann. Die Nutzung der Coding-Tools werde intern mit einem Leaderboard nachgehalten.
Dabei treffen Googles Ambitionen auf eine Branche, die KI-Tools bereits weit verbreitet einsetzt. Das Entwicklerportal Stack Overflow fand in seiner jährlichen Befragung [6] mit 49.000 Teilnehmern heraus, dass 84 Prozent der Entwickler entsprechende Tools schon nutzen oder zumindest deren Einsatz planen. Sie versprechen sich damit vor allem eine Zeitersparnis. Bislang, so ergeben Befragungen, sei diese Hoffnung aber nicht immer erfüllt worden. 46 Prozent der Entwickler misstrauen der Genauigkeit von KI-Tools.
URL dieses Artikels:
https://www.heise.de/-11264675
Links in diesem Artikel:
[1] https://www.heise.de/thema/Kuenstliche-Intelligenz
[2] https://www.heise.de/news/OpenAI-kontert-Anthropic-mit-grossem-Codex-Update-11262364.html
[3] https://www.heise.de/news/Anthropic-stellt-Claude-Design-vor-KI-Werkzeug-fuer-Prototypen-und-Webseiten-11262940.html
[4] https://www.theinformation.com/articles/google-creates-strike-team-improve-coding-models
[5] https://www.heise.de/news/Apple-schickt-Siri-Entwickler-ins-KI-Bootcamp-11261019.html
[6] https://survey.stackoverflow.co/2025
[7] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[8] mailto:mki@heise.de
Copyright © 2026 Heise Medien
(Bild: Cloudflare)
Cloudflare will mit Agent Memory dem Kontextverfall bei langen Prompts in KI-Agenten verbeugen. Entwickler können so auch Kosten sparen.
Cloudflare hat mit Agent Memory einen Dienst vorgestellt, der KI-Agenten ein dauerhaftes Gedächtnis verleihen soll. Anstatt alle nötigen Informationen immer wieder als Kontext mitzugeben – was einen hohen Tokenverbrauch verursacht –, sollen KI-Agenten mit Agent Memory eigenständig relevante Informationen auswählen und in ihren Prompts an die Sprachmodelle verwenden. Der Dienst steht zunächst nur in einer geschlossenen Beta-Version zur Verfügung.
Neben den potenziellen Kosteneinsparungen für Entwickler, die aus dem geringeren Tokenverbrauch folgen, will der US-Anbieter mit Agent Memory auch dem sogenannten Kontextverfall entgegenwirken. Lange Prompts verschlechtern zunehmend die Geschwindigkeit und Zuverlässigkeit von Antworten eines KI-Modells. Dabei gehen Informationen vom Anfang einer Konversation verloren, die nicht mehr in das Kontextfenster des jeweiligen Modells passen.
Laut einem Post im Cloudflare-Blog [1] soll sich Agent Memory als persistente Speicherebene für lokal und in der Cloud gehostete KI-Agenten einsetzen lassen. Zudem können Entwickler den Dienst in Koordinations-Frameworks für mehrere Agenten einbinden, um den darin enthaltenen Agenten einen dauerhaften Speicher über Sessions und Neustarts hinweg zu bieten. Ebenfalls lassen sich Speicherprofile gemeinsam verwenden, sodass Informationen nur einmal an einen KI-Agenten übermittelt werden müssen und sich danach von mehreren Agenten nutzen und erweitern lassen.
Als möglichen Einsatzzweck für Agent Memory nennt Cloudflare die Einbindung in Coding-Agenten eines Entwicklungsteams. Initial können Entwickler grundlegende Informationen eingeben, die für alle Agenten wichtig sind, beispielsweise interne Konventionen oder Architekturentscheidungen. Danach nutzen und erweitern alle angebundenen Agenten diese Informationen.
Außerdem lässt sich der Dienst zur agentischen Code-Review einsetzen – er soll sich merken können, was die Entwickler zurückweisen. Mit diesen Informationen soll der KI-Agent sein Feedback zum Programmcode anpassen und relevantere Hinweise geben können. Auch in einfachen Chatbots lässt sich Agent Memory einbinden, um den Nachrichtenverlauf zu speichern und bei Nachfrage darauf zurückgreifen zu können.
Agent Memory unterscheidet bei den Informationen zwischen unveränderlichen Fakten, Events früherer Zeitpunkte, aktuellen Aufgaben und Anweisungen wie Arbeitsabläufen oder Runbooks. Der Dienst aktualisiert eigenständig veraltete Informationen und löscht Duplikate. Zugriffe auf die Informationen erfolgen über eine Anbindung an Cloudflare Workers oder eine REST-API.
Die Schnittstelle bietet fünf Kernoperationen: ingest für die Massenverarbeitung von Konversationen, remember für explizites Speichern, recall für synthetisierte Abfragen sowie list und forget für Verwaltung und Löschung. Um die gesamte API-Oberfläche abzubilden, veröffentlichte Cloudflare zuletzt mit cf ein einheitliches Kommandozeilen-Tool [2]. Mit ihm sollen Entwickler alle Dienste des Anbieters über ein zentrales Werkzeug steuern und von KI-Agenten nutzen lassen können.
Eine Anmeldung zur geschlossenen Beta von Agent Memory ist aktuell nicht möglich, eine Warteliste steht aber bereit. Der Zeitpunkt für die allgemeine Verfügbarkeit ist bislang nicht bekannt.
URL dieses Artikels:
https://www.heise.de/-11263627
Links in diesem Artikel:
[1] https://blog.cloudflare.com/introducing-agent-memory/
[2] https://www.heise.de/news/Cloudflare-Ein-CLI-Tool-fuer-alles-11256008.html
[3] https://www.heise.de/ix
[4] mailto:sfe@ix.de
Copyright © 2026 Heise Medien
(Bild: amgun / Shutterstock.com)
Interne Vercel-Systeme und damit auch Kundendaten wurden in einem Security-Vorfall kompromittiert. Ein externes KI-Tool diente als Einfallstor.
Das Softwareunternehmen Vercel hat bekannt gegeben, dass es derzeit einen Sicherheitsangriff untersucht. Ein Angreifer erhielt unbefugten Zugriff auf interne Systeme und Vercel-Kundendaten. Nach Angaben des Unternehmens hat der Vorfall seinen Ursprung bei einem Vercel-Mitarbeitenden, der das KI-Tool Context.ai verwendete. Durch dessen Vercel-Google-Workspace-Account erhielt der Angreifer Zugriff auf Vercel-Umgebungen.
Guillermo Rauch, CEO und Gründer von Vercel, hat auf X Neuigkeiten zu dem Angriff gepostet [1]. Demnach handelt es sich anscheinend um eine „sehr raffinierte Angreifergruppe“, die seiner Vermutung nach künstliche Intelligenz einsetzt und „mit überraschender Geschwindigkeit und tiefgehendem Verständnis von Vercel“ vorging.
Next.js, Turbopack und weitere Open-Source-Projekte des Unternehmens sind nach Angaben von Rauch nicht betroffen: „Wir haben unsere Supply Chain analysiert und sichergestellt, dass Next.js, Turbopack und unsere vielen Open-Source-Projekte für die Community sicher bleiben.“
Laut dem entsprechenden Vercel-Security-Bulletin-Eintrag [4] ist eine begrenzte Zahl an Vercel-Kundinnen und -Kunden von dem Angriff betroffen. Diese seien bereits informiert und zu einer unverzüglichen Rotation ihrer Credentials aufgefordert worden.
Vercel hat zudem einen Indicator of Compromise (IOC) veröffentlicht. Ausgangspunkt des Angriffs war eine Google-Workspace-OAuth-App. Google-Workspace-Admins und Google-Account-Besitzer sollen daher unverzüglich prüfen, ob diese App verwendet wird:
Wie The Hacker News berichtet [5], übernehmen Angreifer unter dem Namen ShinyHunters die Verantwortung für diesen Vorfall – und bieten laut Screenshots auf X [6] offenbar gestohlene Daten für zwei Millionen US-Dollar an. Die Gruppe ShinyHunters hat bereits kürzlich Daten aus einem Cyberangriff auf Rockstar Games [7] veröffentlicht. Ob diese für den Angriff auf Vercel tatsächlich verantwortlich ist, hat das Unternehmen bisher nicht bestätigt.
Vercel untersucht den Angriff derzeit noch aktiv und hat Incident-Response-Experten – darunter Googles Cybersicherheitstochter Mandiant – sowie die Behörden eingeschaltet. Über weitere Neuigkeiten wird das Unternehmen auf seinem Security Bulletin informieren [8].
URL dieses Artikels:
https://www.heise.de/-11263669
Links in diesem Artikel:
[1] https://x.com/rauchg/status/2045995362499076169
[2] https://enterjs.de/ai.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_ejs_ai.empfehlung-ho.link.link&LPID=34830
[3] https://enterjs.de/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_ejs_ai.empfehlung-ho.link.link&LPID=34830#AI
[4] https://vercel.com/kb/bulletin/vercel-april-2026-security-incident#indicators-of-compromise-iocs
[5] https://thehackernews.com/2026/04/vercel-breach-tied-to-context-ai-hack.html
[6] https://x.com/DiffeKey/status/2045813085408051670
[7] https://www.heise.de/news/Rockstar-Games-Kriminelle-Gang-veroeffentlicht-Daten-11255795.html
[8] https://vercel.com/kb/bulletin/vercel-april-2026-security-incident
[9] mailto:mai@heise.de
Copyright © 2026 Heise Medien
(Bild: Natalia Klenova / Shutterstock.com)
Kleine, aber interessante Meldungshäppchen vom News-Buffet zu Azure MCP Server, Angular, nbgitpuller, MantisBT, ESLint, Servo, NiFi, Symfony und GitLab.
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:
meta.languages Support für an Sprachen orientierte Regeln: Autorinnen und Autoren von Regeln können damit explizit festlegen, für welchen Sprachen eine Regel gültig ist. Sollte sie für eine nicht unterstützte Sprache aktiviert werden, gibt ESLint einen Laufzeitfehler aus.Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail [12].
URL dieses Artikels:
https://www.heise.de/-11255598
Links in diesem Artikel:
[1] https://devblogs.microsoft.com/azure-sdk/announcing-azure-mcp-server-2-0-stable-release/
[2] https://voidzero.dev/posts/oxc-angular-compiler
[3] https://blog.jupyter.org/better-sharing-ux-with-nbgitpuller-and-contextual-error-handling-18eb5c83dc1b
[4] https://mantisbt.org/blog/archives/mantisbt/827
[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://eslint.org/blog/2026/04/eslint-v10.2.0-released/
[8] https://servo.org/blog/2026/04/13/servo-0.1.0-release/
[9] https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version2.9.0
[10] https://symfony.com/blog/symfony-ux-3-0-0-released
[11] https://about.gitlab.com/de-de/blog/gitlab-and-vertex-ai-on-google-cloud/
[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
Anthropic hat Claude Design als Research Preview veröffentlicht.
(Bild: Screenshot / heise Medien)
Mit Claude Design präsentiert Anthropic ein experimentelles Werkzeug für Webdesign und Prototyping, das auf dem neuen Modell Claude Opus 4.7 basiert.
Anthropic hat mit Claude Design ein neues KI-Werkzeug [1] für die Gestaltung von Designs, Prototypen, Präsentationen und Webseiten vorgestellt. Das experimentelle Tool, das als Research Preview von Anthropic Labs veröffentlicht wurde, basiert auf dem neuen Modell KI-Modell Claude Opus 4.7 [2]. Es ist für Abonnenten der Abo-Pläne Pro, Max, Team und Enterprise ohne Zusatzkosten verfügbar. Für Enterprise-Organisationen ist Claude Design allerdings standardmäßig deaktiviert und muss von Administratoren in den Organisationseinstellungen erst freigeschaltet werden.
Wenn es um Designfragen ging, war Anthropic bislang zurückhaltend. Die Text-KI beantwortete zwar Fragen zu Bildern. Grafiken oder gar Bilder suchten Nutzer aber vergeblich. Mit den Artefakten bot Anthropic zuletzt immerhin interaktive Komponenten und Diagramme [3] im Chat an.
Das ändert sich nun, wobei Anthropic seinem Fokus auf Entwickler treu bleibt [4], aber durchaus auch für Nicht-Entwickler interessant bleibt. In Beispielvideos ist zu sehen, wie zum Beispiel eine Website mit Hintergrundanimation erzeugt wird. Auch bei der Gestaltung von Apps soll die KI behilflich sein. Nutzer können nach einem anfänglichen Prompt mit dem Modell in Interaktion treten und etwa Kommentare in den Rückmeldungen einpflegen, per Chat über das Design diskutieren oder mit KI-generierten Schiebereglern Einfluss auf Abstände, Farben und Layout nehmen.
Wer nicht bei null anfangen möchte, kann vorhandene Designdateien und Programmierprojekte einlesen. Auf diese Weise können bereits favorisierte Farben, Typografie und Komponenten berücksichtigt werden. Auch Bilder, Dokumente aus Word, Excel und PowerPoint oder Code können importiert werden. Per Capture-Tool können zudem Elemente einer vorhandenen Website integriert werden.
Claude Design erinnert ein wenig an Google Stitch [5], das auf der Entwicklerkonferenz Google I/O im Jahr 2025 vorgestellt wurde. Allerdings ist das Tool von Anthropic breiter aufgestellt. Und es ermöglicht sogar, erstellte Designs direkt in Claude Code [6] weiterzuverarbeiten. Canva, das ebenfalls KI-Tools für Design im Angebot hat, wurde als erster Export-Partner integriert. Auch Figma ermöglicht inzwischen die Integration externer KI-Modelle für Design-Workflows [7] und kann Designs aus Claude Design weiterverarbeiten.
Mit Claude Design holt Anthropic zum Doppelschlag aus: Zum einen ist es eine Kampfansage gegen Google, das sich im Duell zwischen OpenAI und Anthropic als lachender Dritter zu positionieren schien. Zum anderen trifft es OpenAI an einer Schwachstelle: OpenAI hat zwar eine sehr gute Bild-KI, aber kein vergleichbares Design-Tool. Gerade erst hat OpenAI mit einem großen Codex-Update [8] zum Gegenschlag gegen Claude Code ausgeholt. Es steht zu erwarten, dass OpenAI diese Veröffentlichung nicht lange unbeantwortet lässt.
URL dieses Artikels:
https://www.heise.de/-11262940
Links in diesem Artikel:
[1] https://www.heise.de/thema/Kuenstliche-Intelligenz
[2] https://www.heise.de/news/Befolgt-Anweisungen-substanziell-besser-Anthropic-gibt-Opus-4-7-frei-11261267.html
[3] https://www.heise.de/news/Claude-Anthropic-fuehrt-interaktive-Diagramme-und-Visualisierungen-ein-11210565.html
[4] https://www.anthropic.com/news/claude-design-anthropic-labs
[5] https://www.heise.de/news/Kommt-jetzt-Vibe-Design-11224124.html
[6] https://www.heise.de/news/Claudes-Computer-Use-kommt-in-Cowork-und-Code-11222192.html
[7] https://www.heise.de/news/Figma-oeffnet-seine-Designplattform-fuer-externe-KI-Modelle-11222763.html
[8] https://www.heise.de/news/OpenAI-kontert-Anthropic-mit-grossem-Codex-Update-11262364.html
[9] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[10] mailto:mki@heise.de
Copyright © 2026 Heise Medien
Android 17 ist fast fertig.
(Bild: Google)
Die Entwicklung von Android 17 befindet sich auf der Zielgeraden: Die nun erschienene Beta 4 ist die letzte Testversion vor dem finalen Release.
Etwa drei Wochen nach der Android 17 Beta 3 [1] schiebt Google die Beta 4 heraus. Es ist laut der Entwickler die letzte geplante Betaversion, in den nächsten Wochen könnten noch Patches und Bugfixes erscheinen. Die neue Beta enthält neben wenigen Neuerungen eine lange Liste an Fehlerbehebungen – und das Easter-Egg.
Nach der Beta 3, die allerhand neue nutzergerichtete Funktionen mit sich brachte, wie etwa die App-Bubbles, sind die Neuerungen in der Beta 4 überschaubar. Lediglich die schon in der April-Version von Android Canary [2] gesichtete neue Nachricht nach dem Entfernen sämtlicher Benachrichtigungen: „Du bist auf dem aktuellen Stand“, begleitet von einem Pokal, ist neu. Die neue Anzeige orientiert sich dabei an Wear OS 6 etwa auf der Pixel Watch, sodass sie über das Ökosystem hinweg einheitlicher anmutet.
(Bild: Andreas Floemer / heise medien)
Zudem hat die letzte Beta das traditionelle Android-Easter-Egg an Bord: Begibt man sich in die Einstellungen „Über das Smartphone“, tippt auf die Android-Versionsnummer und anschließend dreimal schnell erneut auf die Android-Version, erscheint das Easter-Egg. Hier füllt man mit dem Finger den Kreis vollständig und hält das dann erscheinende Android-17-Logo gedrückt. Nun erscheint das seit einigen Android-Generationen integrierte kleine Space-Game, in dem man ein kleines Raumschiff durchs All manövriert.
(Bild: Andreas Floemer / heise medien)
Für Entwickler wichtig: Google führt mit Android 17 Beta 4 Speicherbegrenzungen für Apps ein, „die sich nach dem gesamten RAM-Speicher des Geräts richten, um eine stabilere und deterministische Umgebung für Ihre Anwendungen und Android-Nutzer zu schaffen“, schreibt Google [3]. In der neuen Android-Version seien die Grenzwerte konservativ festgelegt, um Systembasiswerte zu etablieren. „Damit sollen extreme Speicherlecks und andere Ausreißer bekämpft werden, bevor sie systemweite Instabilität auslösen, die zu Rucklern in der Bedienoberfläche, erhöhtem Akkuverbrauch und dem Beenden von Apps führt“, erklärt der Konzern weiter.
Google empfiehlt Entwicklern, bewährte Verfahren für den Speicherumgang zu befolgen und Speicherlecks zu beheben. Um Entwicklern bei der Suche nach Speicherlecks zu helfen, bietet Android Studio Panda eine „LeakCanary-Integration“ direkt im Android Studio Profiler als eigene Aufgabe an.
(Bild: Google)
Überdies unterstützt der Android-Keystore nun den nach NIST-Standard entwickelten ML-DSA (Module-Lattice-Based Digital Signature Algorithm). Auf unterstützten Geräten können Entwickler ML-DSA-Schlüssel generieren und diese zur Erstellung quantensicherer Signaturen nutzen. Den Schutz vor Angriffen durch Quantencomputer für Android 17 [4] hatte Google Ende März angekündigt.
Behobene Fehler der Beta von Android 17 hat Google in einem umfangreichen Reddit-Beitrag dokumentiert [5]. Unter anderem fixt Google ein Problem, das dazu führte, dass die Ladegeschwindigkeit von Geräten deutlich abnahm, sobald die 80-Prozent-Marke der Akkuladung erreicht wurde. Dieser Bug steckt auch in Android 16 QPR3 [6].
Wagemutige und Entwickler können die Beta auf kompatiblen Pixel-Geräten installieren. Zu diesen gehören alle Modelle ab dem Pixel 6 und neuer als auch das Pixel Tablet sowie Googles Foldables. Um die Beta zu erhalten, müssen Nutzerinnen und Nutzer ihr Gerät im Android-Betaprogramm [7] registrieren, anschließend wird die Software als Over-the-Air-Update angeboten.
Weitere Neuerungen von Android 17 dürfte Google im Zuge der Entwicklerkonferenz I/O 2026 verraten, die am 19. und 20. Mai stattfindet. Als gesichert gilt, dass Google seinem mobilen Betriebssystem agentische Fähigkeiten verleihen wird [8], die Nutzern mehrstufige Aufgaben abnehmen sollen. Der Chef des Android-Ökosystems Sameer Samat 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.“ Die finale Version von Android 17, zunächst für Pixel-Geräte, wird im Juni erwartet.
URL dieses Artikels:
https://www.heise.de/-11261781
Links in diesem Artikel:
[1] https://www.heise.de/news/Android-17-Beta-3-App-Bubbles-getrennte-WLAN-Kacheln-und-mehr-11226957.html
[2] https://www.heise.de/news/Android-Canary-Google-testet-ueberarbeitetes-Kontextmenue-fuer-App-Icons-11260688.html
[3] https://android-developers.googleblog.com/2026/04/the-fourth-beta-of-android-17.html
[4] https://www.heise.de/news/Android-17-Google-sichert-sein-OS-gegen-Quantencomputer-ab-11225969.html
[5] https://www.reddit.com/r/android_beta/comments/1snf5ry/android_17_beta_4_now_available/
[6] https://www.heise.de/news/Pixel-Google-drosselt-Laden-bei-80-Prozent-Limit-massiv-11206802.html
[7] https://www.google.com/android/beta?hl=de
[8] https://www.heise.de/news/Gemini-fuer-Android-wird-agentisch-KI-bestellt-Essen-oder-einen-Fahrdienst-11191444.html
[9] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[10] mailto:afl@heise.de
Copyright © 2026 Heise Medien
(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:
#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
