Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
JNI - Java Native Interface
Dabei ist es Ziel eine zur Klasse gehörende native Lib zu verwenden. Diese MUSS bestimmte Namenskonventionen erfüllen. Eine JNI-Lib wird so erstellt :
1) Java-Klasse schreiben
2) Java-Klasse compilen
3) Header-File mit [c]javah -jni CLASSNAME[/c] erzeugen
4) native Lib implementieren (in C bzw C++)
5) native Lib compilen und linken
6) Java-Klasse ausführen
Beispiel dafür gibt es im Sun-Tut : Chapter 5: JNI Technology
JNA - Java Native Access
Hier ist das Ziel mit Hilfe der JNA-Lib (welche selbst wiederum eine JNI-Lib ist) direkten Zugriff auf bereits vorhandene Libs zu bekommen. Ob dies System-Libs oder eigene sind ist dabei eigentlich ziemlich egal. JNA-Klassen erstellt man so :
1) JNA-Lib laden https://github.com/twall/jna und in den CP legen
2) Java-Klasse mit einer speziellen nested Class erstellen
3) Java-Klasse compilen
4) Java-Klasse ausführen
Wie man JNA richtig verwendet ist in der Doc beschrieben : https://github.com/twall/jna#using-the-library
Für Zugriff auf Windows-Systeme bietet die JNA-Lib sogar eine spezielle Win32-Erweiterung.
Als JNA-Variante dürfte das mit deiner Lib dann ungefähr so aussehen :
Java:
import com.sun.jna.*;
public class ComputerName
{
public static void main(String[] args) throws Exception
{
String computerName=myLib.INSTANCE.get_ComputerName();
System.out.println(computerName);
}
public interface myLib extends Library
{
myLib INSTANCE=(myLib)Native.loadLibrary("mylib", myLib.class);
String get_ComputerName();
}
}
Testen kann ich es leider nicht da ich weder deine Lib habe noch weis ich ob das so einfach mit VB-Libs geht (müsste eigentlich da C++ auch OOP ist).
Kannst es ja mal ausprobieren.
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking up function 'get_ComputerName': Die angegebene Prozedur wurde nicht gefunden.
Zugriffsmodifier und Klassenbezeichnungen in der DLL sind nicht zu beachten?
Sehe nichts, dass die bestimmte Klasse (im Beispiel "Class1") irgendwo erwähnt wird, wo die Funktion drinsteckt.
Finde leider wieder nichts im Web, die mir bei der Fehlermeldung weiterhilft.
PS: DLL hat er gefunden, ohne DLL steht "Modul nicht gefunden".
//edit
Gilt für JNA auch die Bezeichnung in der DLL wie bei JNI mit JNIEXPORT ...... oder kann ich die DLL in VB.NET ganz normal runterschreiben ohne spezielle modifier zu verwenden?
Wie ich bereits erwähnte : ich weis nicht wie man DLLs mit VB.Net überhaupt so schreibt das diese dann normalen C-DLLs gleichen. Oder ob es dafür bestimmte Aufrufkonventionen gibt.
Das was du mit JNIEXPORT meinst ist nur für JNI wichtig (darum auch auch JNI...). Für JNA ist das eigentlich ziemlich Banane.
GooGLe brachte leider keine Erklärung wie man nun eine Funktion in einer VB.Net DLL callt die in einer Klasse ist. Das Problem dürfte sein in die Klasse selbst zu wechseln. Und da du dafür sicher eine Instanz dieser Klasse brauchst (also ein Object auf das du die Calls anwenden kannst) müsstest du eine "public function" definieren welche dir Überhaupt erstmal ein Object der VB.Net Klasse beschafft. Das ist sicher nicht anders als in Java. Auch hier kannst du nicht einfach eine Methode callen die an ein Objekt gebunden ist.
Es dürfte hier also etwas schwieriger werden.
Das einzige was man über GooGLe findet ist halt entweder das du die Lib JNI-konform schreibst oder eine zwischen-Lib die immer wieder genannt wurde : OOJNI-NET. Soweit ich in Erfahrung bringen konnte wohl eine normale C-Lib die mit JNI aufgerufen wird (und somit auch sehr umständlich mit JNA callbar wäre) und diese Calls an die .NET-Lib weiterleitet. Sollte auch mit VB.Net gehen. Aber einen direkten call wirst du wenn überhaupt nur schwer hinbekommen.
Es wird schon irgendwie mit JNA direkt möglich sein, aber wenn wir das Problem mal auf Java übertragen musst du dafür die Methode von der Instanz lösen, was man in Java mit "static" machen würde. Da es in Java NUR Klassen gibt ist es logisch das eine solche Methode auch innerhalb einer Klasse steht, aber in VB.Net müsste man doch auch eigentlich Funktionen erstellen können die sich "außerhalb" der Klassen befinden. Und genau eine solche Funktion brauchst du zum callen. So sollte das mit JNA auch machbar sein.
Diesem Post nach kann es sein das deine Methode nach außen hin garnicht als "get_ComputerName" exportiert wird sondern unter etwas wie "get_ComputerName@1234". Das kannst du so in Java natürlich nicht darstellen und desshalb findet JNA die Funktion auch nicht.
Die Lösung hierfür ist der "FunctionMapper" der Klasse StdCallLibrary welcher als Option dem load übergeben werden muss. Einfach das Code-Beispiel mal auf den Code angepasst würde also daraus :
Java:
import com.sun.jna.*;
import com.sun.jna.win32.*
import java.util.*;
public class ComputerName
{
public static void main(String[] args) throws Exception
{
String computerName=myLib.INSTANCE.get_ComputerName();
System.out.println(computerName);
}
public interface myLib extends Library
{
Map options = new HashMap();
options.put(Library.OPTION_FUNCTION_MAPPER, StdCallLibrary.FUNCTION_MAPPER);
myLib INSTANCE=(myLib)Native.loadLibrary("mylib", myLib.class, options);
String get_ComputerName();
}
}
Damit sollte Java nun die Funktion "get_ComputerName" auch wirklich finden.
Ein anderer Beitrag in der selben Mail-List hingegen behauptet das VB ähnlich wie Java ein Object braucht (wie ich erwähnte) und man entweder eine Java-VB.Net Bridge braucht (hatte ich auch angedeutet) oder schreibt sich mit C selbst eine JNI-Lib die dann die VB.Net Calls ausführt.
Also entweder gehts mit dem einfachen FunctionMapper ... oder du hast echt ein Problem.
Wenn die DLL mit .NET erzeugt wurde, ist es keine native DLL und du kannst nicht mit JNI darauf zugreifen. .Net Code benötigt, genau wie Java Code eine VM um ausgeführt zu werden.
Am einfachsten ist es, wenn du deine DLL in unmanaged C/C++ schreibst. Dann funktioniert JNI. Ansonsten google mal nach
Code:
java .net dll
, da findesst du einige Lösunge zur .NET Interoperabilität.
So komisch wie es klingt, es ist nicht möglich auf die Map zuzugreifen. Gebe ich den Namen meiner Map ein, hier "mymap", erkennt es keinerlei Funktionen die dazugehören (wie put, etc.). Dabei ist auch egal obs eine HashMap, TreeMap, sonstiges ist.
Doch dies passiert nur, wenn ich die Optionen für die Function Mapper in Variablen speichere. Dies muss ich aber tun, da es bei map.put() in der Klammer die Function Mapper nicht gibt. ???:L
Ja ECHT!
Das heißt, ich kann innerhalb des map.put() die Function Mapper nicht angeben, darum in Variablen gespeichert. Doch danach erkennt die Map keinerlei Funktionen mehr, die zu ihr gehört.
So komisch wie es klingt, es ist nicht möglich auf die Map zuzugreifen. Gebe ich den Namen meiner Map ein, hier "mymap", erkennt es keinerlei Funktionen die dazugehören (wie put, etc.). Dabei ist auch egal obs eine HashMap, TreeMap, sonstiges ist.
Doch dies passiert nur, wenn ich die Optionen für die Function Mapper in Variablen speichere. Dies muss ich aber tun, da es bei map.put() in der Klammer die Function Mapper nicht gibt. ???:L
Ja ECHT!
Das heißt, ich kann innerhalb des map.put() die Function Mapper nicht angeben, darum in Variablen gespeichert. Doch danach erkennt die Map keinerlei Funktionen mehr, die zu ihr gehört.
public interface myLib extends Library
{
myLib INSTANCE=(myLib)Native.loadLibrary("mylib", myLib.class, (Map) (new HashMap().put(Library.OPTION_FUNCTION_MAPPER, StdCallLibrary.FUNCTION_MAPPER)));
String get_ComputerName();
}
Habs nun so geschrieben und er compiliert ss.
Nun wirft er:
Java:
Exception in thread "main" java.lang.ExceptionInInitializerError
at computername.ComputerName.main(ComputerName.java:23)
Caused by: java.lang.NullPointerException
at com.sun.jna.Library$Handler.<init>(Library.java:129)
at com.sun.jna.Native.loadLibrary(Native.java:255)
at computername.ComputerName$myLib.<clinit>(ComputerName.java:32)
Die Map ist doch initialisiert, die Function-Mapper haben gültige Werte (geprüft) und die anderen Parameter sind auch gültige Werte. Die Library ist auch vorhanden.
Man sollte die API schon kennen. Map.put gibt den Wert zurück, der vorher unter dem übergebenen Key gespeichert war. Das führt logischerweiße bei einer leeren Map zu einer NPE und wenn sie nicht leer wäre würde eine ClassCastException fliegen, weil der zurückgegebene Wert eben nicht die Map selbst ist.
Eine statische Initialisierung von Collections gibt es in Java leider noch nicht, deswegen ist die einfachste Möglichkeit, die mir dazu einfällt, ein inline Konstruktor:
Java:
public interface myLib extends Library
{
static final myLib INSTANCE=(myLib)Native.loadLibrary("mylib", myLib.class, new HashMap(){{
put(Library.OPTION_FUNCTION_MAPPER, StdCallLibrary.FUNCTION_MAPPER);
}});
String get_ComputerName();
}
public class ComputerName {
public static void main(String[] args) {
String computerName = myLib.INSTANCE.get_ComputerName();
System.out.println(computerName);
}
public interface myLib extends Library {
static final myLib INSTANCE = (myLib) Native.loadLibrary("myLib", myLib.class, new HashMap() {
{
put(Library.OPTION_FUNCTION_MAPPER, StdCallLibrary.FUNCTION_MAPPER);
}
});
String get_ComputerName();
}
}
Java:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking up function 'get_ComputerName': Die angegebene Prozedur wurde nicht gefunden.
at com.sun.jna.Function.<init>(Function.java:129)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:250)
at com.sun.jna.Library$Handler.invoke(Library.java:191)
at $Proxy0.get_ComputerName(Unknown Source)
at computername.ComputerName.main(ComputerName.java:20)
Java Result: 1
Die VB.NET DLL nochmal:
Code:
Public Module Class1
Public Function get_ComputerName() As String
Return My.Computer.Name
End Function
End Module
Module wird in .NET als static verwendet. Gleiches Ergebnis erzielt auch Public Class und danach Public Shared Function.
Hat noch wer Ideen, sonst geb ich es auf und nimm C DLLs -.-
PS: Falls wer Interesse hat, dies wirklich zu lösen, stell ich die dll online.
such mal nach einem tool für c/c++ ddls das dir den header ausgibt. Wenn der mit der dll nichts anfangen kann, dann kannste dir noch alternativ über jni ne bridge basteln java -> c -> net
ja - wenn Du auf hexx in seinem Posting gehört hättest, hättest Du auch schon längst damit aufgehört. Wenn Du mit VB.NET eine DLL erstellst, dann ist das keine DLL sondern eine Assembly. Mit JNI/JNA - welches native Methoden aufrufen - wirst Du keine nicht nativen Methoden aufrufen können. ES GEHT EINFACH NICHT!
Verwende C bzw. C++ oder mach die Assembly COM-sichtbar
Hmm, das es leider so wie ich es in der Mail-List gefunden habe nicht funktioniert ist natürlich doof, war aber erlich gesagt teilweise vorrauszusehen durch den anderen Beitrag den ich erwähnte.
Das eine VB.Net DLL in dem sinne keine native Lib ist und auch eine Art VM braucht (ich nehme mal an das .NET-Framework) wusste ich nicht da ich wie gesagt weder VB noch .Net spreche und schon gar nicht die Kombination, sondern lediglich Java.
@hexx
Ich weis jetzt zwar nicht wirklich wie du auf JNI kommst aber das bis jetzt gepostete ging eigentlich fast nur um JNA. Sollte man auch alleine an meinen Posts so wie an den import-Zeilen sehen sowie daran das es keine "native" Methoden gibt. Vielleicht nächste mal etwas genauer lesen.
@TOPIC
Das ist auch das was man über GooGLe immer wieder findet : man soll eine normale C-Lib nehmen um mit Hilfe dieser dann den VB.Net Code zu callen. Dabei soll es wohl egal sein ob man diese Lib mit JNI schreibt (was von Java aus natürlich direkter wäre) oder eine "normale" Lib und auf diese dann mit JNA zugreift. Fakt ist jedenfalls das es wohl keinen direkten Weg Java <-> VB.Net gibt.
Im Netz gibt es wohl schon mehrere solcher Libs, einige davon sogar kostenpflichtig, die Frage ist eher ob sich der Aufwand lohnt oder ob es dann nicht doch einfacher ist das ganze irgendwie in C zu implementieren. Denn vor allem für alles was man direkt aus den Windows-System-DLLs ziehen kann bietet JNA bereits Implementierungen an.
Um den Computernamen herrauszubekommen kann man aus der Kernel32.dll die Funktion GetComputerNameEx() call : GetComputerNameEx function
GooGLe liefert Beispiele wie man eine JNA-Methode für sowas definiert und wie man dann an die Daten kommt (ich habe einfach mal nach "kernel32.dll jna" gesucht und einiges gefunden).
Als Beispiel kann ich dir mal folgendes posten :
Java:
import com.sun.jna.*;
import javax.swing.*;
public class AdminTest
{
public static void main(String[] args) throws Exception
{
int ver=Kernel32Lib.INSTANCE.GetVersion();
int majVer=(ver&0xFF);
int minVer=((ver>>8)&0xFF);
int build=(ver>>16);
if(majVer<6)
{
JOptionPane.showMessageDialog(null, "Windows NT "+majVer+"."+minVer+"."+build+" NOT supported !", "ERROR", JOptionPane.ERROR_MESSAGE);
System.exit(1);
}
JOptionPane.showMessageDialog(null, Shell32Lib.INSTANCE.IsUserAnAdmin(), "Admin", JOptionPane.INFORMATION_MESSAGE);
}
public interface Shell32Lib extends Library
{
Shell32Lib INSTANCE=(Shell32Lib)Native.loadLibrary("Shell32", Shell32Lib.class);
boolean IsUserAnAdmin();
}
public interface Kernel32Lib extends Library
{
Kernel32Lib INSTANCE=(Kernel32Lib)Native.loadLibrary("Kernel32", Kernel32Lib.class);
int GetVersion();
}
}
Ziel dieses Codes ist es
1) zu prüfen ob mindestens WinNT 6.x ausgeführt wird
2) zu prüfen ob der ausführende Kontext Admin-Rechte hat.
Ich verwende hier zwar nur Funktionen die einen return-Wert aber keien Übergabeparameter verwenden, aber wie man solche Funktionen nutzt findet man wie gesagt bei GooGLe.
Fazit : ob man also nun wirklich versucht eine Java <-> C <-> VB.Net Bridge zu basteln oder sich gleich mit JNA an den Windows-System-DLLs bedient ist sicher abhängig vom gewünschten Ergebnis und ob die Information die man braucht überhaupt bereits so bereitgestellt wird, aber das ganze Thema JNI/JNA ist eh ziemlich komplex und sehr plattformabhängig.
Danke nochmal an alle, die sich Gedanken dazu gemacht haben und Zeit geopfert haben.
Dies war nur ein vereinfachtes Beispiel, um ein Grundgerüst für das Importen von VB.NET DLLs zu zeigen.
Computernamen bekomm ich auch mit InetAddress.getLocalHost()).getHostName() oder sonstiges, wollte nur wie gesagt fragen, ob DLLs mit VB.NET direkt in Java eingebunden werden können.
Werde auf C/C++ umsteigen und mit den JNIEXPORT arbeiten. Schade, dass es keine direkte Möglichkeit gibt bzw. wenn, nur mit viel Aufwand.
Du könntest noch alternativ je nach komplexität, die -net sachen als eigenen process machen, und dann über die process in out streams kommunizieren (nachdem vom java das ganze übern processbuilder gestartet wurde). Evtl ist das einfacher zu machen.
Das Problem dürfte halt (wie schon erwähnt) sein das halt .NET ebenfalls in einer Art VM läuft : dem .NET-Framework. Das kann man eigentlich direkt auf Java übertragen : du kannst von außen auch nicht so einfach auf irgendwelche Java-Klassen zugreifen ohne eine VM am Laufen zu haben die diese ausführt. Nicht umsonst gehört C# im weiteren Sinn laut M$ auch zur .NET-Familie. Der Unterschied ist nur das C# am Ende durch das .NET-Framework direkt in ausführbaren Code compiled und gelinkt wird was bei "reinem" .NET eben nicht der Fall ist.
Von daher ist es halt schon notwendig entweder JNI entsprechend die Konventionen einzuhalten oder eine "normale" Lib zu schreiben und diese via JNA anzusprechen. Direkt geht halt nun mal nicht.
Nicht umsonst gehört C# im weiteren Sinn laut M$ auch zur .NET-Familie. Der Unterschied ist nur das C# am Ende durch das .NET-Framework direkt in ausführbaren Code compiled und gelinkt wird was bei "reinem" .NET eben nicht der Fall ist.
Das ist falsch. C#gehört nicht nur im weiteren Sinne zu .NET, sondern ist die Sprache, die von Microsoft extra für .NET entwickelt wurde. Und genau wie bei allen anderen Sprachen für .NET, wird der Quellcode nach CIL (äquivalent zu Java Bytecode) compiliert und dann von der CLR (Laufzeitumgebung) ausgeführt.
Von daher ist es halt schon notwendig entweder JNI entsprechend die Konventionen einzuhalten oder eine "normale" Lib zu schreiben und diese via JNA anzusprechen. Direkt geht halt nun mal nicht.
Das ist falsch. C#gehört nicht nur im weiteren Sinne zu .NET, sondern ist die Sprache, die von Microsoft extra für .NET entwickelt wurde. Und genau wie bei allen anderen Sprachen für .NET, wird der Quellcode nach CIL (äquivalent zu Java Bytecode) compiliert und dann von der CLR (Laufzeitumgebung) ausgeführt.
)
