Parsing Java and Eclipse detailed instructions for loading local libraries (. dll files) _java

The most recent work to do is to use the local method, the need to load a lot of dynamic link libraries in Java (below the Windows platform to facilitate the application of the shorthand DLL, but not limited to Windows). Just ran through the program, and hastened to write out some of the experience, mark. I also hope to help you with similar work.
first, it should be clear that there are two types of DLLs:(1) DLLs on which Java relies, and (2) DLLs on which the DLL depends. It is because of the existence of a (2) DLL that the complexity of loading DLLs in Java is greatly increased, as is many claims, but the results of my experiment show that they do not seem so complicated and will be elaborated 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 ClassLoader, except that the filename in (1) must be an absolute path , the filename in (2) can only be a DLL name and does not allow folders to be included.
In addition, Eclipse is a very powerful platform, it provides a strong bundleclassloader is a very important reason, for DLL loading also has its own set of very chic approach, worthy of our adoption.
According to the above introduction, the main problems and solutions of loading DLLs in Java are expounded in two parts.
1. Loading DLLs in a generic Java program
I did the work that needed to load the DLL 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
Direct call is a number of methods in Timage, the list of timage before all its direct or indirect dependencies, not only to all the DLL load, but also to pay attention to their dependencies, the dependent DLL must first load, Otherwise it will be an error: Unsatisfiedlinkerror. Therefore, we should first clarify the dependencies between the DLL, the list above is already processed.

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, whose default value is path content in the system environment variable. Therefore, you can set the Java.library.path property by modifying the path variable (eclipse requires a reboot after the change), and the general approach is to add the absolute path to the folder where the DLL resides in path. Another method is to set the "absolute path of the-djava.library.path=dll folder" to the parameters of the Java command (you can use; separate multiple paths). For applications on the Eclipse development environment, you can add the aforementioned parameters to the VM arguments edit box by modifying its startup parameters. For the packaged Eclipse installation package, edit the Application.ini in its startup directory (assuming its startup file is Application.exe), and add the preceding arguments after-vmargs to set the Java.library.path value. It is important to note that once the JVM has started, it is no longer possible to modify the contents of the Java.library.path, that is, by:
system.setproperty ("Java.library.path", "c:/mylib");
This is not the way to achieve the goal, because the property is read-only. Sun's forum has discussed how to modify the Java.library.path in the code, the conclusion is: Can not be modified by code! If the "java-djava.library.path=c:/mylib" such a way to write too dead, it is only through the shell programming methods such as preprocessing the path to improve its flexibility.
If your DLL is encapsulated in a jar package, you need to first unzip it to a temporary path, then add the path to the Djava.library.path, or simply unzip it to the system path.
2. Loading DLLs on the Eclipse platform
As mentioned above, the way the local library path is set up in Java is too dead, and it's my own personal experience, but thankfully our Eclipse platform offers a more flexible approach, through eclipse-provided Bundleclassloader, You can block the DLL in the plugin, no need to decompress at the time of use, no need for additional settings Java.library.path property, Bundleclassloader will find your DLL by itself to the specified directory in the relative plugin root directory: ws/win32/, os/win32/x86/, os/win32/, nl/zh/cn/, nl/zh/, See Org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader and Org.eclipse.core.runtime.internal.adaptor.EclipseClassLoadingHook.
My directory settings are:
. classpath
. cvsignore
. Project
Build.properties
Classes
Cvs
Lib
Meta-inf
Os
Plugin.xml
Src
I put all the DLLs in the Win32 directory below the OS, and can also create WS/WIN32 directories for the local libraries. After this process, you can load the local library without modifying any of the system variables.
In addition, Eclipse also provides bundle-nativecode settings in the manifest file, which is also used to load local libraries, pending further research
This article in a hurry and, I hope to be able to help themselves