Anders als in C liegen Javas mehrdimensionale Arrays nicht in einem Stück im Speicher. C kennt (intern) gar keine mehrdimensionalen Arrays, bzw. unterscheiden sich diese (intern) nicht von eindimensionalen. Und so muss man das dann auch beim Zugriff aus Java heraus nachbauen:
1
2
3
4
5
6
7
8
9
10
11
12
// pseudo-mehrdimensional
byte[]oneDimensional=newbyte[rowCount*colCount];
// ...
// Transformation in ein echtes mehrdimensionales Array:
Wer irgendwas mit zufällig generierten Token in einem Docker Container laufen lassen möchte, der sollte /dev/urandom auf /dev/random mounten, denn sonst blockiert /dev/random, bis genug Entropie vorhanden ist – die nie kommt. urandom blockiert nicht.
Spring Boot bietet ein Conditional namens ConditionalOnProperty, die die Component nur dann registriert, wenn eine gewisse System-Property entsprechend (siehe Logik unter dem Link) gesetzt ist – und ggf. auch, wenn das Property fehlt und matchIfMissing auf true gesetzt ist.
Das “auch” störte mich in einem Fall, weil ich zwar gerne gewisse Komponenten per System-Property einkonfigurieren können möchte. Aber wenn ich diese nicht habe, brauche ich Fallback-Komponenten, und dafür eine Annotation, die nur triggert, wenn das Property fehlt.
Since detecting missing properties can be problematic, and we’ve not got a direct need for this ourselves, I think your own custom condition is the best approach.
, was ich hiermit getan habe. Jeder Kommentar erwünscht (gerne auf gist, aber wer keinen Account hat, kann auch hier).
Pre-Shared Keys sind mit Spring Boot eine Geschichte voller Missverständnisse. Hier jeweils meine:
HTTP/HTTPS
In der Theorie scheint die Verwendung von https “überflüssig”, denn wenn ich eh nur vorher als “vertrauenswürdig” zertifizierte Clients zulasse, warum dann noch die Verbindung absichern. Naheliegende Antwort: Austausch von Identitäten über http ist nie gut – ⚠
Die eigentliche Idee ist jetzt: Jeder Client muss ein “trusted” Zertifikat vorweisen. Diese Zertifikate werden in einem “Trust-Store” abgelegt, den der Server bekommt. Der Client bekommt sein Zertifikat ebenfalls, dort in einem “Key-Store”, um sich auszuweisen. Andersrum analog: Das Serverzertifikat bekommt der Client in einem Trust-Store, um den https-Server zu verifizieren, der Server legt das in seinem Key-Store ab.
Die Zertifikate kann man dem Server jetzt über einen TomcatConnector bekannt machen, muss man in Spring Boot aber nicht (⚠; Danke, Nils). Stattdessen genügt Folgendes, ebenfalls in den application.properties:
ACHTUNG: Der NoopHostnameVerifier war hier nötig, da ich das Zertifikat nicht mit expliziten Hostnames erstellt habe, in Production würde man das wohl tun. ⚠
Userverwaltung
Natürlich kann man mehrere Client-Zertifikate verwenden, und natürlich kann man jedem Client separate Rechte zuweisen. In der Server-Anwendung:
Nachtrag zu neulich: JNAerator macht aus einem time_t in etwa Folgendes (schon an Java Naming Conventions angepasst):
1
2
3
4
5
6
7
8
9
publicclassMyTimeStampextendsPointerType{
publicMyTimeStamp(Pointer address){
super(address);
}
publicMyTimeStamp(){
super();
}
}
Damit kann man fast nichts anfangen; insbesondere bekommt man den Eigentlichen Timestamp nicht da raus. Das “Pointer” ist außerdem irreführend, denn C liefert an der Stelle keinen Pointer, sondern die Sekunden seit Epoch. Funktionieren tut:
Das Anstrengende Fehleranfällige an JNI ist das Mapping von (komplexen) Datentypen. Nun gibt es aber auch noch JNA,
a community-developed library that provides Java programs easy access to native shared libraries without using the Java Native Interface.
(Wikipedia), und dafür insbesondere den “JNAerator“, der komplexe Datentypen “automatisch” mappt. Die Idee liegt nahe, statt JNI(-Strukturen) JNA(-Strukturen) zu nutzen. Im Folgenden ein Versuch.
Der Aufruf allerdings schon nicht mehr so sehr (“0.13” und den Pfad zum lokalen Maven-Repo ggf. anpassen):
1
$java-jar~/.m2/repository/com/nativelibs4java/jnaerator/0.13-SNAPSHOT/jnaerator-0.13-SNAPSHOT-shaded.jar/path/to/some/HeaderFile.h-mode Directory-f-runtime JNA
Wichtig ist nämlich -runtime JNA, mit den default Einstellungen handelt man sich Abhängigkeiten zu org.bridj (laut Doku “faster runtime that supports C++”) und damit die Notwendigkeit ein, die dll darüber zu laden. Und das will man zumindest dann nicht, wenn man plain JNI möchte.
Das JNAerator Studio (hier) scheint das übrigens per default anders zu machen, aber das nur am Rande. Trotzdem für die Akten: Den Pfad zur dll würde man BridJ so bekannt machen:
Aber zurück zu den so kompilierten Klassen. -mode Directory erzeugt sie als .java-Dateien, nicht als .jar. Das ist hilfreich, denn man muss sie editieren, siehe unten. Sie enthalten (übrigens neben Kommentaren mit dem vollen Pfad der Quelldatei, im Beispiel also /some/path/to/some/HeaderFile.h, evt. will man den nicht öffentlich machen) dann alle structs in ihrer Java Version. Das eigentliche Interface, das die Methoden der Header-Datei bereitstellt, muss man trotzdem selber schreiben und wie folgt laden:
In MyInterface deklariert man die Methoden, auf die man in der dll zugreifen möchte. Primitive Übergabe-/Rückgabeparameter sind dabei ziemlich selbsterklärend (int=int, bool=boolean, etc.), Strings sind char-Arrays, Pointer bringt JNA mit (bsplw. IntByReference, IMHO ein Vorteil gegenüber JNI), structs hat man sich ja eben in Java-Klassen übersetzt. Also alles gut? Tatsächlich gibt es Probleme mit den erzeugten Klassen:
Einige sind offensichtlich, bsplw. überschreiben sie
1
protectedList<String>getFieldOrder()
mit
1
protectedList<?>getFieldOrder()
, was natürlich nicht kompiliert. Globales Suchen-und-Ersetzen, fertig.
Anderes ist schon komplexer: Structures (also die Java-Klasse jetzt) haben ein Alignment, im Konstruktor zu übergeben. Wenn ich das richtig verstehe, korrespondiert das mit der entsprechenden Compiler-Option in VS und sollte automatisch erkannt werden? Oder es hängt an der Plattform? Wie auch immer: Wenn man eine struct hat, die, sagen wir, 22 Byte belegt, dann ist es nicht hilfreich, wenn der default von 4 Byte großen Blöcken ausgeht. Entweder werden dann nämlich zwei Byte abgeschnitten, oder zwei unnötige Bytes angehängt, was zu Verschiebungen in der Folgestruktur führt!
Beispiel: In Arrays von structs beginnt der zweite Eintrag dann zwei Bytes zu spät (es fehlen zwei Bytes zu Beginn) oder zu früh (der Eintrag beginnt mit den letzten zwei Bytes aus dem ersten Eintrag). Nicht unbedingt einfach zu debuggen m( Hilfreich ist es, das System-Property jna.dump_memory auf true zu setzen, und die Ausgabe in einen Hex-Editor zu kopieren. Man sieht die beschriebenen Byte-Offsets dann wenigstens (Danke, Nils!).
Ich habe dazu eine eigene Zwischenschicht eingezogen:
Ja, JNAerator erzeugt einem Java-Klassen aus Headerdateien. Und das ist bei sehr großen Headern auch hilfreich. Aber es ist auch sehr fehleranfällig – und teilweise sogar fehlerhaft. Es kann nur eine Basis für eigenen Code sein.
Neulich musste ich eine DLL aus Java heraus ansprechen. Zur Wahl stehen JNI und JNA, wobei JNA “nur” ein Wrapper für JNI ist – und bei mir nicht funktioniert hat. In der Theorie ist JNI aber auch nicht schwer, allerdings legt Visual Studio einem mir Steine in den Weg. Ein Grund mehr, bei Java zu bleiben.
Der Java-Teil ist dann auch denkbar einfach:
1
2
3
4
5
6
7
8
9
10
publicclassDllBridge{
static{
// loads file MyDll.dll:
System.loadLibrary("MyDll");
}
// declare all functions you want to use as "native":
publicnativeStringhello(Stringinput);
// ...
}
Diese DllBridge wird dann in eine Headerdatei übersetzt:
1
2
//erzeugt DllBridge.h;Achtung:ohne.java:
$javah DllBridge
Und diese Header-Datei dann in “das” C/C++-Projekt kopiert. An “das” Projekt kommt man wie folgt:
Visual Studio installieren; ich habe Visual Studio Community 2017 mit den Standardkomponenten genommen
Neues C++/Win32-Projekt anlegen, im Dialog unter “Anwendungseinstellungen” den Anwendungstyp “DLL” wählen
Ich habe das Projekt testweise MyDll genannt, die entstehende .dll heißt später genauso
Nachdem man die DllBridge.h in das Projekt kopiert und über Rechtsklick > Include In Project eingebunden hat, kann man ihre Methoden implementieren. O.g. Code erzeugt genau eine Methode Java_DllBridge_hello, siehe DllBridge.h. Deren Implementierung in der .c-Datei:
Alleine die Importe und die korrekte Version von MessageBox herauszufinden, hat sicher eine Stunde gedauert 😡 Oh, Stichwort “Importe”: jni.h wird vom JDK mitgebracht, die entsprechenden Ordner muss man in VS bekannt machen. Das funktioniert nichtüber einen Symlink, sondern über die Projekteinstellungen, indem man unter Configuration Properties > C/C++ > General > Additional Include Directories diese drei Verzeichnisse hinzufügt (Rekursion wäre ja auch zu einfach.):
C:\Program Files (x86)\Java\jdk1.8.0_121\include\win32\bridge
PS Ja: Das ist ein 32-Bit-Java, weil ich letztlich eine 32Bit dll ansprechen will.
Das Ganze sollte jetzt bauen (Build > Build solution, oder STRG+Shift+B) und eine <Projektname>.dll erzeugen, siehe Konsolenausgabe. Der Name der .dll muss dem im initialen Java-Code entsprechen.
Ein Aufruf von
1
2
3
DllBridge dll=newDllBridge();
Strings=dll.hello("moto");
System.out.println("dll says: "+s);
öffnet dann die MessageBox:
Sowie die erwartete Ausgabe auf der Konsole. Für reine C-Anbindung könnte man hier aufhören.
Interessant wird es nun, wenn man langlebigere C++-Objekte von Java aus referenzieren möchte. Idee:
Eine Klasse auf Java-Seite, die die dll lädt, sowie die nativen Methoden bereitstellt, und eine Klasse auf C++-Seite, die diese implementiert
Die C++-Klasse wird initialisiert, ihren Pointer gibt man in Form einer long an Java zurück (bzw. jlong, vgl. hier), vermutlich ist das die Speicheradresse
Über diese long kann Java dann das Objekt referenzieren
Braucht man das C++-Objekt nicht mehr, wird es deleted.
zu ändern. setval geht allerdings per default aber beim nächsten Wert los, im Fall “1” (wenn gar keine oder nur negative IDs vorhanden sind) also bei 2. Das ist nicht direkt schlimm, aber uncool. Eine (umständliche!) Lösung ist eine Fallunterscheidung – und falls man die Migration viele viele male durchführen muss, verpackt man die Fallunterscheidung in einer FUNCTION:
FALSE sorgt dafür, dass nicht der nächste Wert genommen wird, sondern genau dieser – und “+ 1” vermeidet einen Wert von 0, der ebenfalls out of bounds wäre.
Danke an Nils für’s vereinfachen! 🙂 Die umständliche Version bleibt trotzdem online als Template für PG Functions.