Connect with us

Entwicklung & Code

30 Jahre Java – Interview mit Community-Vertretern (Teil 5)


In den vergangenen 30 Jahren hat sich eine rege Community im Java-Umfeld gebildet. Ich habe einige deutschsprachige Vertreter zu ihren Erfahrungen befragt. Die Resonanz war überwältigend. Vielen Dank an alle, die mitgemacht haben. In diesem fünften und letzten Teil kommen Sandra Warmbrunn (Co-Organisatorin JUG Ostfalen), Michael Paus (Board-Mitglied JUG Stuttgart und Organisator des Java Forum Stuttgart), Stefan Hildebrandt (Co-Organisator JUG Bremen/Oldenburg), Thomas Ruhroth (Mitorganisator JavaLand4Kids) und Gerrit Meier (Co-Organisator JUG Ostfalen) zu Wort.

Weiterlesen nach der Anzeige


Neuigkeiten von der Insel - Falk Sippach

Neuigkeiten von der Insel - Falk Sippach

Falk Sippach ist bei der embarc Software Consulting GmbH als Softwarearchitekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen. Falk twittert unter @sippsack.

Java prägt viele Entwicklerinnen und Entwickler seit ihren ersten Schritten in der IT – und hat in dieser Zeit Höhen, Tiefen und mehrere Neuerfindungen erlebt. Die folgenden Antworten spiegeln persönliche Anfänge, prägende Erlebnisse, kritische Momente und eine Einordnung von Javas Rolle in der heutigen Softwareentwicklung wider. Abschließend wagen sie einen Blick nach vorn: mit Tipps für die eigene Weiterentwicklung und Erwartungen an Java in den kommenden Jahren.

  • Alexander Culum , Birgit Kratz, Simon Martinelli , Dierk König, Christian Stein

  • Bernd Müller, Heinz Kabutz, Patrick Baumgartner, Wolfgang Weigend, Gernot Starke

  • Jens Schauder, Richard Fichtner, Cay Horstmann, Ralf D. Müller, Mark Paluch 

  • Michael Simons, Stefan Zörner, Markus Eisele, Dirk Weil und Michael Vitz

  • Sandra Warmbrunn, Michael Paus, Stefan Hildebrandt, Thomas Ruhroth und Gerrit Meier

Wann und mit welcher Version bist du erstmals mit Java in Berührung gekommen?

Sandra Warmbrunn: Ich bin 1998 im Studium das erste Mal mit Java 1.1 in Berührung gekommen.

Michael Paus: Das muss etwa 1997 mit Java 1.1 oder evtl. auch noch 1.0 gewesen sein.

Stefan Hildebrandt: Gegen Ende meiner Schulzeit habe ich 1997 meine ersten Gehversuche mit Linux gemacht und habe dort auch weiterhin Desktop-Anwendungen programmieren wollen. Durch Zufall bin ich auf ein Java-Buch gestoßen, und der Ansatz, die Anwendungen unter Linux und Windows laufen zu lassen, hat mir gefallen, auch wenn die eine oder andere Hürde vorhanden war.

Weiterlesen nach der Anzeige

Thomas Ruhroth: Ich bin während meiner Ausbildung zum mathematisch-technischen Assistenten auf Java gestoßen. Ich hatte gerade Smalltalk (ja, das ist eine OO-Programmiersprache) gelernt, und da kam das Thema auf, dass Java auch OO und schneller sei. Das war die Version Java 1.1. Naja, so schnell war Java dann auch nicht, aber unter den Runtime-Sprachen, war es die schnellste.

Gerrit Meier: Das ist eine sehr gute Einstiegsfrage. Da musste ich doch wirklich gerade mal mit javap in meinen alten Uniunterlagen von 2003 schauen. Obwohl das Tool 1.2 für die ersten Übungen ausgibt, würde ich offiziell das Statement abgeben wollen, dass es wohl Version 1.4 war, die mich die meiste Zeit in der Uni begleitet hat. Somit kam ich eigentlich eher aus der Pflicht zu Java, anstatt es zu finden. Zum Ende des Studiums jedoch war es schon ein fester Bestandteil für Tools (Visualisierung) rund um meine Diplomarbeit, die im Kern C++ war.




(Bild: DOAG)

Vom 10. bis 12. März 2026 findet die JavaLand-Konferenz statt. In diesem Jahr zieht die Community-Konferenz in den größten deutschen Freizeitpark, den Europa-Park Rust. Das Programm bietet knapp 130 Vorträge in 13 Themenbereichen.

Was war rückblickend dein schönstes Erlebnis mit der Sprache oder dem Ökosystem Java?

Sandra Warmbrunn: Rückblickend, da es schon so viele Jahre sind, kann ich gar nicht genau sagen, welches wirklich mein schönstes Erlebnis war. Es sind ein paar, die ich toll fand. Meine bestandene Prüfung zum Certified Java Programmer 1.5 war schon sehr schön. Außerdem die Möglichkeit, auf der JVM andere Programmiersprachen benutzen zu können. Groovy hat mir geholfen, funktionale Programmiertechniken zu lernen.

Michael Paus: Mein schönstes Erlebnis war, als ich nach Jahren der Beschäftigung mit Java in einem eher kleineren Rahmen endlich bei Airbus in ein sehr interessantes und großes Java-Projekt mit JavaFX einsteigen durfte.

Stefan Hildebrandt: Die Mächtigkeit des Ökosystems, die sich bei mehreren Migrationen von anderen Plattformen zu Java gezeigt hat: Allen Unkenrufen zum Trotz waren die Systeme danach deutlich leistungsfähiger, was an der JVM und an optimierten Komponenten wie Connection-Pools lag.

Thomas Ruhroth: Ich habe mich sehr über Streams und Lambdas gefreut. Das hat schöne Dinge, die ich von anderen Sprachen kannte, möglich gemacht. Die letzte schöne Sache war vor ein paar Jahren ArchUnit. Damit ist jetzt eine gut lesbare, leicht verwendbare Erweiterung zur Sicherstellung von Architektur-Eigenschaften vorhanden.

Gerrit Meier: Da gibt es einige und für mich ist es schwer, das Schönste rauszupicken. Eines der Ersten war jedenfalls ein Poor Man’s Remote Desktop beim Kunden aus der Not und die erste Erkenntnis: Das kann man mit Java machen! Danach ging es gerade in den 2010ern featuretechnisch Schlag auf Schlag. Vor allem Java 8 war, meines Erachtens nach, ein sehr revitalisierendes Release und hat dafür gesorgt, dass sich Java wieder modern anfühlte. Auch wenn ich kaum Desktop-UIs entworfen habe, hat mir auch die JavaFX-Phase sehr gefallen und mich mindestens privat mal wieder dazu eingeladen, mich damit zu beschäftigen. Am Ende war es ein etwas kürzeres Gastspiel von JavaFX im JDK als damals angenommen, aber trotzdem würde ich es nicht als Misserfolg werten wollen. Vor allem beginnend mit Java 8 und seinem reichhaltigen Feature-Set (und natürlich auch 9, 10, 11) war auch wieder mehr Core-Java in Vorträgen zu erleben und zu lernen, was mich zum nächsten Punkt bringt. Wenn wir natürlich das Ökosystem breiter fassen und die Technologie als gemeinsame Basis sehen, dann sind es die Menschen, die einem über den Weg laufen und – ob nun Java User Group, Konferenzen oder auf der Arbeit – einem das Gefühl geben, dass wir uns mit unserer Community sehr glücklich schätzen können. Platt gesagt: Ohne Java wäre mein Freundeskreis ab 30 wohl nicht mehr so stark angewachsen.

Aber es ist nicht alles Gold, was glänzt. Was hat dich negativ beeinflusst beziehungsweise war ein unschöner Moment im Java-Umfeld?

Sandra Warmbrunn: Der unschöne Moment war, von Groovy (schöne klare Schreibweisen) zu Java und dem ganzen Boilerplate-Code zurückzukommen (was allerdings natürlich historisch begründet ist).

Michael Paus: Dies war kein einzelner Moment, sondern eher ein kontinuierlicher Prozess. Ich habe es als sehr enttäuschend und frustrierend erlebt, wie konsequent stiefmütterlich das Thema Frontend im Java-Umfeld behandelt wurde und wird. Es wurde vieles begonnen, aber nie richtig zu Ende gedacht, geschweige denn richtig vermarktet und beworben.

Stefan Hildebrandt: Der Umstieg von JSF 1.x auf 2 war nur als Big Bang möglich, wenn man weiter eine einheitliche UI haben wollte. Das war sehr hinderlich und hat viele Anwendungen technologisch veralten lassen. Nach diesem Debakel wurden auch Updates im Java-Enterprise-Umfeld mit der Zeit einfacher zu handhaben.

Thomas Ruhroth: Ich fand es schade, dass aus der Idee der Java-Prozessoren nichts wurde. Es gab ja mal die Idee, Java-Bytecode direkt auf einem speziellen Prozessor ausführbar zu machen. Das war während meiner Ausbildung eines der Themen, von denen wir geglaubt haben, dass sie die ganze Computerwelt revolutionieren würden und es bald nur noch Java-Prozessoren gibt.

Gerrit Meier: Disclaimer: Ich hoffe, dass sich hier keine Personen negativ angesprochen fühlen. Gerade im Laufe der oben erwähnten 2010er kam es durch Oracle zu einer starken Erschütterung in der Entwicklergemeinschaft (oder nur bei mir, falls ihr es nicht so empfunden habt) bezüglich Lizenzierung, beispielsweise Android, Abwendung von Java EE und grundsätzlich das Gefühl, dass Java für das Unternehmen als Lizenzierungsgrundlage wichtiger ist als die Technologie als solche. Das hat bei mir eine gewisse Unsicherheit bezüglich der Zukunft der Sprache gebracht. Am Ende war es für mich persönlich wahrscheinlich die einzige unschöne Erfahrung. Auf der anderen Seite war es zum Beispiel für Java EE ein notwendiger Bruch. Mit der Überführung in die Eclipse Foundation und breitem Firmensupport (zu dem auch Oracle gehört) ist es meiner Meinung nach am Ende doch gut ausgegangen.

Glaubst du, dass Java auch nach 30 Jahren noch relevant ist? Welche Rolle spielt Java deiner Meinung nach in der modernen Softwareentwicklung, insbesondere im Vergleich zu anderen Sprachen und Technologien?

Sandra Warmbrunn: Ich glaube, dass Java weiterhin eine große Rolle im Bereich Softwareentwicklung spielen wird, ich kenne kein Ökosystem, das so eine große Community hat und so viele Tools, Frameworks und Möglichkeiten bietet.

Michael Paus: Java hat nach wie vor eine große Bedeutung. Das zeigen allein schon die Zahlen und das Ranking in den diversen Metriken. Java ist keine Hype-Sprache mehr, sondern hat mehr den Charakter eines stabilen Fundaments, auf dem man auch große Projekte erfolgreich aufbauen kann.

Stefan Hildebrandt: Im KI-Umfeld spielt Python eine größere Rolle und kommt darüber auch im Unternehmensumfeld stärker zum Einsatz. Der Umweg über einen anderen Einsatzbereich war schon bei JavaScript/TypeScript zu beobachten, die über SPAs auch auf dem Server gelandet sind. Auf der JVM ist der Trend hin zu Kotlin ein wenig abgeflaut, auch wenn Kotlin sich in vielen Bereichen etabliert hat.

Thomas Ruhroth: Ja, ich glaube, dass Java noch eine lange Geschichte haben wird. Sprachen, die viele Connections zu Open-Source-Communitys haben, werden nicht so schnell sterben – da steckt so viel Liebe und Arbeit von vielen drin.

Gerrit Meier: In der „modernen Softwareentwicklung“ würde ich Java ohne jeglichen Zweifel gesetzt sehen. Vor allem durch Technologien wie Spring als alternativer Vorreiter, der nicht müde wird, mit dem Stand der Technik mitzuhalten, und Quarkus als Standard (JakartaEE) Framework, haben wir eigentlich fast schon die Qual der Wahl. Und das vom Hobbyprojekt bis zu großen Enterprise-Deployments. Ich möchte Java gar nicht so direkt mit anderen Sprachen vergleichen. Gerade heutzutage sind syntaxtechnisch relativ viele ähnliche Konzepte zu finden – klammern wir hier mal Haskell, Elixir und Freunde aus, bei denen sich sinnvolle Neuerungen in einer Sprache relativ schnell auch in andere Sprachen verteilen. Natürlich sollten wir unterscheiden, wo das kompilierte Programm zur Ausführung gebracht wird. Java auf dem Mikrocontroller mag ein schönes Bastelprojekt sein, aber da sollten wir C/Rust doch den Vortritt lassen, wenn wir in Richtung Signalverarbeitung schauen. Wir dürfen auch nie vergessen, dass die JVM ein Biest ist, das immer mehr leisten kann und wird. Und eventuell werden wir irgendwann Programmiersprache X dort laufen lassen und das J in JVM ist das Einzige, das uns dann noch an Java erinnert.



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