Connect with us

Entwicklung & Code

Model-Schau: Coding, OCR und chinesisches Neujahr


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Seit der letzten Model-Schau Ende Januar hat sich einiges bei den Sprachmodellen getan. Eine große Rolle scheint dabei das chinesische Neujahr zu spielen, vor dem die Anbieter nochmal viele Modelle veröffentlicht haben. Doch der Reihe nach!

Weiterlesen nach der Anzeige




Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.

Schon im September 2025 hat Qwen Modelle mit einer neuen, hybriden Architektur angekündigt. Das einzige verfügbare Modell war Qwen3-Next-80B-A3B-Instruct, das aber mehr als Experiment zu betrachten war. Allerdings hat Qwen die vorgestellte Architektur in das Modell Qwen3 Coder-Next übernommen. Auch die Anzahl der (aktiven) Parameter stimmt genau überein. Hervorzuheben sind die hybriden Attention-Layer, die einen sehr langen Kontext von 262.144 Token erlauben, dabei nicht sehr viel Speicher benötigen und damit auch die Rechengeschwindigkeit kaum reduzieren.

Dadurch ist Qwen3-Coder-Next auf eigener Hardware schnell ablauffähig, wenn ausreichend Speicher zur Verfügung steht, was vor allem bei leistungsfähigen Macs mit Apple Silicon der Fall sein dürfte. So hat sich das Modell bei einigen Developern zu einem Lieblingsmodell für den lokalen Betrieb gemausert. Einige sind davon sogar so begeistert, dass sie es auch abseits vom Coding einsetzen.


Chatbot umringt von Laptops

Chatbot umringt von Laptops

(Bild: Golden Sikorka/Shutterstock)

Die Online-Konferenz LLMs im Unternehmen zeigt am 19. März, wie KI-Agenten Arbeitsprozesse übernehmen können, wie LLMs beim Extrahieren der Daten helfen und wie man Modelle effizient im eigenen Rechenzentrum betreibt.

OpenAI musste nachlegen und hat das Modell GPT-5.3-Codex veröffentlicht. Laut eigener Beschreibung ist es deutlich schneller als das Vorgängermodell und besser für agentische Aufgaben geeignet. Das neue Modell kann Code Reviews durchführen und OpenAI hat es inzwischen durch das kleinere Modell GPT-5.3-Codex-Spark ergänzt. Damit soll es sich auch für Realtime-Coding eignen. Sicher spürt OpenAI allerdings auch den Preisdruck, der durch die offenen Modelle entsteht. Coding-Modelle produzieren (insbesondere wenn sie Reasoning verwenden) notorisch viele Token, was sich in sehr hohen Kosten manifestieren kann.

Auch Coding-Primus Anthropic hat mit Claude Opus 4.6 ein neues Modell geschaffen, das sich hervorragend für Coding-Aufgaben eignet. Zusätzlich kann Opus 4.6 Finanzanalysen durchführen, Präsentationen erstellen und viele Aufgaben des täglichen Lebens übernehmen. Nicht zuletzt deswegen nutzen es viele auch für OpenClaw, was aber schnell zu unabsehbaren Kosten führen kann. Sowohl im Bereich Text als auch beim Coding ist Opus 4.6 unangefochtener Sieger bei den Arena-Leaderboards.

Weiterlesen nach der Anzeige

Wie man Coding-Modelle wirklich effizient nutzt und was man damit alles erreichen kann, hat Steve Yegge mit seinem viel beachteten Gas Town erklärt und das entsprechende Tooling gleich mit implementiert. Yegge spart dabei nicht mit Warnungen, dass man das System nur dann nutzen sollte, wenn man über die notwendigen Erfahrungen verfügt und sich auf dieses neue Paradigma auch wirklich einlassen möchte. Teilweise sind die Vorschläge extrem, aber es könnte dennoch einen Ausblick darauf bieten, wie sich agentisches Coding mit LLMs in Zukunft weiterentwickeln kann. Vorsicht ist allerdings geboten, weil Gas Town Token „verbrennt“ – die Kosten können geradezu explodieren, wenn man ein teures Modell verwendet.

Durch die Vision-Language-Modelle ist OCR mehr und mehr zu einer Domäne der großen Sprachmodelle geworden. Nachdem es einige Monate in diesem Bereich ziemlich ruhig war, erschienen nun gleich mehrere neue Modelle.

Sehr beliebt ist das neue GLM-OCR-Modell von Z.ai. Obwohl der Anbieter ein Newcomer bei OCR-Modellen ist, stellt das Modell zumindest nach den Benchmarks die ebenfalls neuen DeepSeek-OCR-2 und PaddleOCR-VL-1.5 in den Schatten. Eine in früheren Tests verwendete iX-Seite kann das Modell nicht ganz fehlerfrei in Text wandeln, kommt aber mit den Spalten bestens zurecht – das Ergebnis liegt nur als Text vor, ist aber gut verwendbar.

Tabellen und Formeln kann GLM-OCR auch interpretieren, die Wandlung von Grafiken in Daten ist aber bisher nicht möglich.

Aber auch DeepSeek-OCR-2 hat sich gegenüber seinem Vorgänger deutlich weiterentwickelt und nutzt nun ein – interessanterweise altes – Qwen-VL-Modell als Encoder. Die iX-Seite wird dabei perfekt erkannt:


OCR-Ergebnis einer gescannten iX-Seite

OCR-Ergebnis einer gescannten iX-Seite

DeepSeek-OCR2 erkennt die iX-Seite sehr gut (Abb. 1).

Auch das konvertierte Markdown sieht gut aus.

PaddleOCR-VL-1.5 nutzt einige neue Ansätze wie Text Spotting und kann auch Textboxen erkennen, die nicht rechteckig sind. Ein Fokus liegt außerdem auf Tabellen, die es auch über mehrere Seiten zusammensetzen kann. Als einziges der genannten Systeme kann PaddleOCR-VL-1.5 Daten aus Diagrammen extrahieren. Die iX-Seite verarbeitet es gut und benötigt dabei zwar wenig Speicher, rechnet aber äußerst lange.

Es wäre spannend zu erfahren, ob die Anbieter die aus PDF extrahierten Texte auch als Trainingsdaten für ihre großen Sprachmodelle nutzen. Dazu schweigen sich jedoch alle aus.

Die stets aktiven Anbieter aus China haben sich in den vergangenen Wochen selbst übertroffen. Angeblich soll das am chinesischen Neujahr liegen, das traditionell mit Urlaub verbunden ist.

Kimi K2.5 wird von vielen als das aktuell stärkste Modell mit offenen Gewichten wahrgenommen. Moonshot hat das Modell zwar schon vor einer Weile veröffentlicht, die technischen Informationen waren aber nur spärlich. Das hat sich nun geändert, weil der zugehörige technische Bericht jetzt bereitsteht. Das Dokument berichtet ausführlich über das Training und die Evaluation des Modells. Besonders das Training hat es dabei in sich, denn Moonshot hat sowohl im Pre-Training als auch beim Reinforcement Learning multimodale Daten verwendet. Das erklärt möglicherweise auch, warum Kimi K2.5 so weit oben in der Vision-Rangliste bei arena.ai steht. Eine weitere Besonderheit stellt Agent Swarm dar: Das Modell kann Agentenaufrufe parallel durchführen, was die Geschwindigkeit bei komplexen Aufgaben stark erhöht. Diese Anforderungen berücksichtigt Moonshot bereits beim Training. Die Autoren beschreiben auch Details des Trainingsprozesses, verschweigen aber die benötigte Rechenzeit. Im Vergleich zu DeepSeek geht der Bericht weniger in die Tiefe, aber viele Details sind dennoch sehr interessant.

Mit Step-3.5-Flash betritt ein weiterer, bisher weitgehend unbekannter Player die Bühne der großen (chinesischen) Sprachmodelle. Im Vergleich zu Kimi K2.5 ist das Modell regelrecht klein, auch wenn es über 196 Milliarden Parameter verfügt (von denen elf Milliarden aktiv sind). Diese Größe ermöglicht es aber, das Modell auch auf leistungsfähiger (Mac-) Hardware in einer quantisierten Version zu betreiben. Für ein derart kleines Modell produziert es sehr ansehnliche Ergebnisse, ist aber in ersten Tests auch sehr stark chinesisch indoktriniert. Bei der Frage nach dem Heise Verlag liegt es mit dem Gründungsjahr und dem Gründer falsch. Bei politisch sensiblen Fragen verweigert sich das Modell.

Das trifft in diesem Maße nicht auf GLM 5.0 zu. Z.ai ist ein in der Zwischenzeit etablierter Anbieter offener Sprachmodelle, der auch sehr bereitwillig Auskunft über politisch heikle Themen gibt. Die Community hat diesem Modell entgegengefiebert und wurde nicht enttäuscht. Gar nicht lange nach GLM 4.7 liefert Z.ai ein extrem starkes Modell, das es insbesondere beim Coding mit fast allen kommerziellen Modellen aufnehmen kann. Auch sonst hat GLM 5.0 eine starke Performance, aber im Vergleich zum Vorgänger die Anzahl der Parameter auf 744 Milliarden Parameter (davon 40 Milliarden aktiv) mehr als verdoppelt. Es benötigte bei einer geeigneten Quantisierung auf einem Mac Studio stolze 512 GByte RAM, wenn man sich nicht in noch höhere Kosten für GPUs stürzen möchte. In den Arena-Benchmarks schneidet das Modell hervorragend ab. In unseren Tests konnte es (als eines der wenigen Modelle) das Gründungsjahr und den Gründer des Heise Verlags korrekt nennen.

Da konnte MiniMax nicht zurückstehen und hat auch noch ein neues Modell veröffentlicht. MiniMax 2.5 ist mit 230 Milliarden Parametern (davon zehn Milliarden aktiv) deutlich kleiner und kann in einer geeigneten Quantisierung auch mit 128 GByte RAM auf der CPU laufen. Noch ist es nicht in vielen Benchmarks vertreten, aber die ersten Resultate sehen gut aus. In ersten Tests gibt auch MiniMax 2.5 falsche Antworten zum Heise Verlag. Bei Fragen zu politisch heiklen Themen in China bleibt es neutral, aber sehr kurz angebunden.

Weniger stark beachtet, aber dennoch interessant ist das Modell Nanbeige4.1-3B. Es handelt sich um ein „kleines“ Reasoning-Modell mit lediglich drei Milliarden Parametern, das aber in bestimmten Benchmarks die viel größeren Qwen3-Modelle mit bis zu 32 Milliarden Parametern schlägt. Als erstes kleines Sprachmodell beherrscht es auch Deep Search und kann in bis zu 500 Runden Tools aufrufen. Es wird spannend, ob andere Modelle nachziehen können, beziehungsweise welche Fähigkeiten die großen Modelle erlangen, wenn sie ähnliche Mechanismen einsetzen.

Lange erwartet und vor ganz kurzem erschienen ist nun auch Qwen3.5. Das Modell steht in unterschiedlichen Größen zur Verfügung, allerdings fehlen aktuell noch die kleineren Modelle. Schon jetzt zeigt sich allerdings, dass Qwen3.5 sehr leistungsfähig ist und gegenüber der vorherigen Version sehr viel Boden gutgemacht hat. Die großen Qwen3.5-Modelle (wie 122B) spielen dabei fast schon in der gleichen Liga wie (das viel größere) Stepfun. Eine genauere Analyse folgt im nächsten Artikel.

Als Interoperabilitätsstandard hat sich die OpenAI-API etabliert. Fast immer wird dabei die completions-Ressource angefragt, obwohl der Name eigentlich nicht mehr zeitgemäß ist. Auch die Übergabe weiterer Parameter ist eher historisch gewachsen als inhaltlich motiviert. Verschlüsselung beherrscht das Interface in dieser Form gar nicht.

All diesen Problemen hat sich ursprünglich OpenAI angenommen und dafür die Responses-API geschaffen, deren Weiterentwicklung unter dem Namen Open Responses die Community übernommen hat. Auch den Umgang mit Agenten beherrscht das neue Format besser und kann somit Reasoning-Zyklen umgehen. Dabei legt das Protokoll unter anderem fest, wie viele Tools maximal aufgerufen werden dürfen.

Viele Werkzeuge unterstützen die neue API bereits. Eine Standardisierung ist nicht nur sinnvoll, sondern wichtig, weil durch die agentische Interaktion eine immer bessere Konfigurierbarkeit der Schnittstellen dringend notwendig wird.

Die Geschwindigkeit, mit der die Anbieter neue Modelle vorstellen, hat sich in den letzten Monaten eher noch einmal erhöht. Ob das so weitergehen kann, sei dahingestellt. OpenAI stellt jedenfalls schon weniger neues Personal ein. Bei den chinesischen Anbietern ist es wesentlich intransparenter, wie lange sie sich das leisten können. Insbesondere fehlt es dort auch an Umsatz, der sich mit den offenen Modellen deutlich schwerer (und vor allem extrem schwer außerhalb Chinas) erzielen lässt.

Hinzu kommt der Hype um OpenClaw als Agent. Dessen Betrieb ist mit offenen Modellen sogar autark möglich, allerdings sind auch dann die Sicherheitsprobleme erheblich. Wenn man die Berichte darüber liest, fragt man sich, ob die Technologie wirklich schon reif genug ist, sie so „von der Leine“ zu lassen. Die Diskussionen über die Guardrails bekommen so eine ganze neue Dimension. Das trifft nicht für alle Anwender zu: Das amerikanische Verteidigungsministerium wollte Anthropic dazu zwingen, genau diese Guardrails in den von ihnen genutzten Modellen abzuschalten. Anthropic blieb standhaft. Zwar sind sie nun ihren Auftrag los, haben aber ChatGPT in den Popularitätswerten überholt.


(rme)



Source link

Entwicklung & Code

Neu in .NET 10.0 [19]: Umwandeln von File-based Apps in C#-Projekte


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps. Wenn die Anforderungen höher werden, sind File-based Apps keine Sackgasse.

Weiterlesen nach der Anzeige


Der Dotnet-Doktor – Holger Schwichtenberg

Der Dotnet-Doktor – Holger Schwichtenberg

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

Entwicklerinnen und Entwickler können per Kommandozeilenbefehl aus einer File-based App ein C#-Projekt mit .csproj-Projektdatei machen:

dotnet project convert .\Dateiname.cs


Screenshot

Screenshot

Umwandeln einer eigenständigen C#-Skriptdatei in ein C#-Projekt (Abb. 1)

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.

Weiterlesen nach der Anzeige


Screenshot

Screenshot

Aus der einzelnen C#-Datei entsteht ein C#-Projekt (Abb. 2).


(rme)



Source link

Weiterlesen

Entwicklung & Code

Android 17 Beta 4: Letzte Testversion vor dem finalen Release


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Etwa drei Wochen nach der Android 17 Beta 3 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.

Weiterlesen nach der Anzeige

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 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.


Screenshots: Info zu abgearbeiteten Benarchrichtigungn in Android 17 Beta 4 und Android 16 QPR3

Screenshots: Info zu abgearbeiteten Benarchrichtigungn in Android 17 Beta 4 und Android 16 QPR3

Kleine Änderung: Statt bisher „Keine Benachrichtigungen“ heißt es in Android 17 künftig „Du bist auf dem aktuellen Stand“.

(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.


Screencast Android 17 Easter Egg

Screencast Android 17 Easter Egg

Das Easter-Egg in der neuen Android-Version.

(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. 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.

Weiterlesen nach der Anzeige

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.


Screenshot LeakCanary-Funktion in Android Studio

Screenshot LeakCanary-Funktion in Android Studio

Google führt mit Android 17 „App memory limits“ ein.

(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 hatte Google Ende März angekündigt.

Behobene Fehler der Beta von Android 17 hat Google in einem umfangreichen Reddit-Beitrag dokumentiert. 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.

Lesen Sie auch

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 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, 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.


(afl)



Source link

Weiterlesen

Entwicklung & Code

C-Libraries in Java nutzen 1: Grundlagen der Foreign Function & Memory API


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

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.

Weiterlesen nach der Anzeige




Rudolf Ziegaus ist Software-Entwickler, Java-Trainer und Geschäftsführer der IO Software GmbH. Seine Lieblingsthemen sind PKi, Kryptographie und systemnahe Programmierung.

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 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. 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 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.

Weiterlesen nach der Anzeige

Um die FFM-API zu nutzen, gelten folgende Voraussetzungen:

  • Ein JDK ab Version 24 muss installiert sein.
  • Das Betriebssystem muss Windows oder Linux auf x64-Basis sein. Die Demo-App sollte auch unter macOS funktionieren, wozu ich aber keine Tests durchgeführt habe.
  • Eine Windows-DLL oder eine Shared Library für Linux in 64-Bit-Version muss vorhanden sein.
  • Die DLL beziehungsweise Shared Library muss in einer Sprache geschrieben sein, die die C-ABI (Application Binary Interface) unterstützt. Dazu gehören neben C und C++ (mit passend deklarierten Funktionen) auch weitere Sprachen wie Rust und Go.
  • Beim Zugriff auf die Shared Library muss man den Native Access erlauben. Das ist aktuell noch ohne Einschränkungen möglich, was sich in einer späteren Java-Version ändern könnte.

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 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.



Source link

Weiterlesen

Beliebt