Resolve the details of loading the local library of. DLL file in Java and Eclipse
- 2020-04-01 01:58:04
- OfStack
The work I've been doing recently involves using native methods and loading a number of dynamic link libraries into Java (for convenience, I'll stick with the simplified DLL for Windows, but not just Windows). I just ran the program through, so let's get some ideas out there, mark. I hope it will be helpful for your similar work
First, it should be clear that there are two types of DLLS: (1) the DLL that Java depends on and (2) the DLL that DLL depends on. It is the existence of the (2) type of DLL that causes the complexity of loading DLLS in Java to increase greatly. Many statements are true, but the results of my experiments do not seem that complicated, which will be explained in more detail later.
Second, there are two ways to load DLLS in Java :(1) by calling system.loadlibrary (String filename) and (2) by calling the system.load (String filename) method. The bottom layer is implemented by using the loadLibrary(Class fromClass, String name, Boolean isAbsolute) method in the ClassLoader, except that the filename in (1) must be an absolute path, and the filename in (2) must be a DLL name and is not allowed to contain folders.
Furthermore, Eclipse is a fairly powerful platform, and the power of the BundleClassLoader it provides is an important reason, for DLL loading also has its own set of very unique practices, worth adopting.
According to the above introduction, the main problems and solutions of loading DLLS in Java are described in two parts.
1. Load DLLS in regular Java programs
For the work I have done, the DLL needs to be loaded as follows:
DigitDll. Dll
DsivsAcct. DLL
DsivsComm. DLL
DsivsTrans. DLL
JBPack. DLL
XCodeDll. DLL
ImageDllCtrl. DLL
Yhfiche. DLL
Yhocr. DLL
Yhbill. DLL
TSealSvrDll. DLL
TImg. DLL
TImage. Dll
Directly call a number of methods in TImage, the list of TImage before all its direct or indirect dependence, not only to put all the DLL load, but also to pay attention to the dependency between them, the dependent DLL must be loaded first, otherwise it will report an error: UnsatisfiedLinkError. Therefore, the first step is to clarify the dependencies between the DLLS, as the above list has already been dealt with.
The next step is to set the JVM's search path so that it can find your DLL. The search path for the JVM is determined by the java.library.path system property, which defaults to the path content in the system environment variable. Therefore, you can set the java.library.path property by modifying the PATH variable (Eclipse needs to be restarted after the change) by adding the absolute PATH to the PATH of the DLL's folder. Another option is to add "-djava.library.path = the absolute path to the DLL" to the Java command. Separate multiple paths. For applications on the Eclipse development environment, you can add the preceding parameters to the VM arguments edit box by modifying their startup parameters. For the packaged Eclipse installation package, you can edit the application.ini in its launch directory (assuming its launch file is application.exe) and add the preceding parameter after -vmargs to set the value of the java.library.path. Note that once the JVM is started, the contents of the java.library.path cannot be modified, that is, by:
System. SetProperty (Java. Library. "path", "c: / mylib");
This approach does not serve the purpose because the property is read-only. The Sun forum discussed how to modify the java.library.path in your code, and concluded that you can't! If "java-djava.library.path =c:/mylib" is too hard to write, you can only preprocess the path through shell programming methods to improve its flexibility.
If your DLL is packaged in a jar, you need to unzip it to a temporary path, then add it to the djava.library.path, or unzip it to the system path.
Load the DLL on the Eclipse platform
Mentioned above, this basement in Java path set way of doing too dead, this is my own experience, but it is comforting to our Eclipse platform provides a more flexible approach, through the Eclipse provides BundleClassLoader, you can use the DLL in the plugin, does not need to unpack when using, also do not need an additional set of Java. If the path attribute, The BundleClassLoader will go to the specified directory relative to the plugin root to find your DLL. These directories are: Ws/win32 / OS/win32 / x86 /, OS/win32 / nl/useful/CN/nl/useful /, see org. Eclipse osgi. Internal. Baseadaptor. DefaultClassLoader and org., eclipse. The core runtime. Internal. Adaptor. EclipseClassLoadingHook.
My directory Settings are:
The classpath
. Cvsignore
.project
Build. The properties
classes
CVS
The lib
meta-inf
OS
XML plugins.
The SRC
I put all the DLLS in the win32 directory under the OS, and I can also set up a ws/win32 directory for local libraries. After doing this, the local libraries can be loaded without any further changes to the system variables.
In addition, Eclipse also provides a setup item for the bundle-nativecode in the MANIFEST file, which is also used to load local libraries, which needs further study
This article in a hurry, I hope to help you all
First, it should be clear that there are two types of DLLS: (1) the DLL that Java depends on and (2) the DLL that DLL depends on. It is the existence of the (2) type of DLL that causes the complexity of loading DLLS in Java to increase greatly. Many statements are true, but the results of my experiments do not seem that complicated, which will be explained in more detail later.
Second, there are two ways to load DLLS in Java :(1) by calling system.loadlibrary (String filename) and (2) by calling the system.load (String filename) method. The bottom layer is implemented by using the loadLibrary(Class fromClass, String name, Boolean isAbsolute) method in the ClassLoader, except that the filename in (1) must be an absolute path, and the filename in (2) must be a DLL name and is not allowed to contain folders.
Furthermore, Eclipse is a fairly powerful platform, and the power of the BundleClassLoader it provides is an important reason, for DLL loading also has its own set of very unique practices, worth adopting.
According to the above introduction, the main problems and solutions of loading DLLS in Java are described in two parts.
1. Load DLLS in regular Java programs
For the work I have done, the DLL needs to be loaded as follows:
DigitDll. Dll
DsivsAcct. DLL
DsivsComm. DLL
DsivsTrans. DLL
JBPack. DLL
XCodeDll. DLL
ImageDllCtrl. DLL
Yhfiche. DLL
Yhocr. DLL
Yhbill. DLL
TSealSvrDll. DLL
TImg. DLL
TImage. Dll
Directly call a number of methods in TImage, the list of TImage before all its direct or indirect dependence, not only to put all the DLL load, but also to pay attention to the dependency between them, the dependent DLL must be loaded first, otherwise it will report an error: UnsatisfiedLinkError. Therefore, the first step is to clarify the dependencies between the DLLS, as the above list has already been dealt with.
The next step is to set the JVM's search path so that it can find your DLL. The search path for the JVM is determined by the java.library.path system property, which defaults to the path content in the system environment variable. Therefore, you can set the java.library.path property by modifying the PATH variable (Eclipse needs to be restarted after the change) by adding the absolute PATH to the PATH of the DLL's folder. Another option is to add "-djava.library.path = the absolute path to the DLL" to the Java command. Separate multiple paths. For applications on the Eclipse development environment, you can add the preceding parameters to the VM arguments edit box by modifying their startup parameters. For the packaged Eclipse installation package, you can edit the application.ini in its launch directory (assuming its launch file is application.exe) and add the preceding parameter after -vmargs to set the value of the java.library.path. Note that once the JVM is started, the contents of the java.library.path cannot be modified, that is, by:
System. SetProperty (Java. Library. "path", "c: / mylib");
This approach does not serve the purpose because the property is read-only. The Sun forum discussed how to modify the java.library.path in your code, and concluded that you can't! If "java-djava.library.path =c:/mylib" is too hard to write, you can only preprocess the path through shell programming methods to improve its flexibility.
If your DLL is packaged in a jar, you need to unzip it to a temporary path, then add it to the djava.library.path, or unzip it to the system path.
Load the DLL on the Eclipse platform
Mentioned above, this basement in Java path set way of doing too dead, this is my own experience, but it is comforting to our Eclipse platform provides a more flexible approach, through the Eclipse provides BundleClassLoader, you can use the DLL in the plugin, does not need to unpack when using, also do not need an additional set of Java. If the path attribute, The BundleClassLoader will go to the specified directory relative to the plugin root to find your DLL. These directories are: Ws/win32 / OS/win32 / x86 /, OS/win32 / nl/useful/CN/nl/useful /, see org. Eclipse osgi. Internal. Baseadaptor. DefaultClassLoader and org., eclipse. The core runtime. Internal. Adaptor. EclipseClassLoadingHook.
My directory Settings are:
The classpath
. Cvsignore
.project
Build. The properties
classes
CVS
The lib
meta-inf
OS
XML plugins.
The SRC
I put all the DLLS in the win32 directory under the OS, and I can also set up a ws/win32 directory for local libraries. After doing this, the local libraries can be loaded without any further changes to the system variables.
In addition, Eclipse also provides a setup item for the bundle-nativecode in the MANIFEST file, which is also used to load local libraries, which needs further study
This article in a hurry, I hope to help you all