Hello This is my code :
if (isWindows()) {
//System.setProperty("jna.library.path", getClass().getResource("/resources/win32-x86").getPath());//netbeans WinOs
System.setProperty("jna.library.path", System.getProperty("user.dir").toString()+File.separator+"Desktop");//compiler WinOs
} else if (isMac()) {
//System.setProperty("jna.library.path", getClass().getResource("/resources").getPath());//netbeans MacOs
System.setProperty("jna.library.path", System.getProperty("user.dir").toString()+File.separator+"Desktop");//compiler MacOs
} else {
System.out.println("Your OS is not support!!");
}
Why I have 2 PATH (don't understand because for add an image i have only one Path) by OS, one for use with IDE and another for use with .JAR ?
I just realized, that when I'm use windows and I run the project (from netbeans) the "Library" load and I get the information, but when I compile and I launch my .jar I get error :
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: %1 is not a valid Win32 application.
My Structure
It is correct?
On mac only work with this command : java -jar "/System/Volumes/Data/Users/hugoclo/NetBeansProjects/Prezauto/dist/Prezauto.jar"since Terminal. If click on jar i have message error : Not Found .....
Sorry about my English,
There can be two reasons for the "why". While Java is cross-platform, JNA (which relies on some native code) must necessarily behave differently on different operating systems. Particularly in the case of loading DLLs (Windows) or dynamic libraries (OSX), you don't want to mix and match. Because it might be possible to have a dll with the same name compiled for different operating systems, JNA's Getting Started page identifies standard locations for these libraries:
Make your target library available to your Java program. There are several ways to do this:
The preferred method is to set the jna.library.path system property to the path to your target library. This property is similar to java.library.path, but only applies to libraries loaded by JNA.
Change the appropriate library access environment variable before launching the VM. This is PATH on Windows, LD_LIBRARY_PATH on Linux, and DYLD_LIBRARY_PATH on OSX.
Make your native library available on your classpath, under the path {OS}-{ARCH}/{LIBRARY}, where {OS}-{ARCH} is JNA's canonical prefix for native libraries (e.g. win32-x86, linux-amd64, or darwin). If the resource is within a jar file it will be automatically extracted when loaded.
In your code, you appear to be trying to do the first option (setting the jna.library.path) to include the user's desktop. That's fine for testing, not good for production, and likely the reason your compiled jar can't find it. Furthermore, by setting this variable, you are overwriting any previous (default) location for it. If you want to go this route, you should copy the saved location and then append your own additional path to it.
However, for code you'll distribute to users, you don't want to have to rely on an absolute file path. It's far better to put the library in a standard relative path location: a resources path (src/main/resources if using Maven) that will be available on your (or any user's) classpath when executing. This seems to align with the commented-out Windows branch of your code, which will look in the win32-x86 subdirectory of your resources folder.
You may have told your IDE to add something to the classpath (so it works there) but if it's not in a standard location, it may fail in a jar.
I'm not sure why the macOS branch of your code does not put the resources in the darwin subdirectory but it probably should.
Related
I currently wrote a simple GUI in Eclipse which runs as intended. I was hoping to export it so I can share it with my friend (who doesn't need to install eclipse and the java libraries). I tried all 3 library handling method Eclipse provides and none of them works. I read a little online and saw something about a manifest file, but wasn't quite sure what to do with it. Is it going to help?
This is where I placed the folder that comes with the .dll file.
This is the result. Am I doing something wrong?
As indicated by the error messages in the first screenshot, what you are missing here is the native library - the software library written and compiled to native code specific to the operating system. What you will need to do is provide the libraries specific to the operating system on which your software will run, eg. dlls for 32 or 64 bit Windows. The manifest does not provide the capability to include those libraries.
When the program is run on Windows, Java will look for native libraries in the following locations:
The current directory
The directories in the PATH environment variable
The directories in java.library.path (if it's specified)
It may be easiest to simply put all files in the one directory. If you do this, you should be able to run the program in the same way as you do now.
The java.library.path option is only needed if you want to put your native library files in a directory separate to the one in which you run your program and not on your PATH. It is only in this case that you will need to add java.library.path, eg. by adding -Djava.library.path=c:\path\to\your\lib after java. Also note that you may use a relative path, ie. a path that is relative to the directory you are in when you execute the command.
I also see from your later error messages that you have another dependency, but on a java library LeapJava.jar. As running a jar with -jar will only work if you have a single jar, but because you have more than one (your own program plus the dependency), you'll instead need to use the -classpath (or -cp for short) argument and add your main class. The classpath argument is a semicolon-separated list of classpath locations, while the main class is the one containing your public static void main method, eg. your.package.name.YourMainClass. So assuming your UI.jar is still in C:\Users\Ian\Desktop\Leap Data UI, you should be able to navigate to that directory and execute with:
java -cp UI.jar;UI_lib\LeapJava.jar -Djava.library.path="UI_lib\x64" your.package.name.YourMainClass
We have an app that sometimes is installed with an associated app. Both may be installed separately, at different times, and neither is usually in the OS Path environment setting.
IF both apps are installed, the one I'm working on needs to use a JNI library from the other app. This library uses a dozen or so other native libs. While I can FIND the JNI lib, I can't seem to find a way to use it without requiring the user to change their system setup.
I've found the (hacky) technique to add the JNI lib to the java.library.path, I've been unable to find any way of updating the native Path so the JNI lib can find it's associated libs.
The only things that have worked so far are to:
Add the folder that the JNI and associated files are in to the OS path before launching our app.
Launch our app so the Current Working Directory is the JNI lib folder.
Neither of which makes for a hassle-free user experience.
So, is there any way for a Java app to modify it's own environment Path so the JNI lib can find it's associated native libs? (currently testing on Win7, will also need to support OS/X)
This can not be done with an unknown location at run time. According to jni documentation
"To load your shared native library module in Java, simply use Java's System.loadLibrary method in a Java class:"
as well as
"Another common reason for the native library not loading is because it is not in your path. On Windows make sure the path environment variable contains the path to the native library. On Unix make sure that your LD_LIBRARY_PATH contains the path to the native library. Adding paths to LD_LIBRARY_PATH can slow down other programs on your system so you may want to consider alternative approaches. For example you could recompile your native library with extra path information using -rpath if you're using GNU, see the GNU linker documentation (ld man page). You could use a command such as ldconfig (Linux) or crle (Solaris) to add additional search paths to the default system configuration (this requires root access and you will need to read the man pages)."
So thus you need to know the location and must be in a path to be able to load the file. If the location is not known it can not be done due to how jni works and the jvm works.
One way to load a JNI lib with dependent libraries is to load each of the dependents then load the JNI library.
For example, if bar.so is dependent on foo.so and both libraries exist in /some/dir, do the following:
System.load("/some/dir/foo.so");
System.load("/some/dir/bar.so");
Use System.load() instead of System.loadLibrary() so you can specify the absolute path to the library.
You'll have to load all dependents of all loaded libraries unless they can be found in the java.library.path path.
Hope this helps.
I'm a little confused by this error. I'm new to Java and the error seems pretty self explanatory, but I've checked my paths (even defined my own) and it still fails to find this library. Is there something I'm doing wrong? See directory screenshot and error screenshot below:
UPDATE
UPDATE 2
If I create a new NetBeans project this works fine. Same code and everything. If I create new IntelliJ project I get this error above. I must be missing something in IntelliJ
UPDATE 3
Found the solution. Adding dependencies is a bit different in IntelliJ. Thanks all for the help.
http://www.jetbrains.com/idea/webhelp/configuring-module-dependencies-and-libraries.html
Obidisc4j is a .jar file. You just dont see its extension in the explorer.
Regular jar files are not loaded by System.loadLibrary. They are automatically loaded by the JVM's classLoader.
You are using a native library. It doen't matter if that library is in the classpath. There are 4 ways you can make the Java runtime load your shared library at runtime:
Call System.load to load the .so from an explicitly specified absolute path.
Copy the shared library to one of the paths already listed in java.library.path
Modify the LD_LIBRARY_PATH environment variable to include the directory where the shared library is located.
Specify the java.library.path on the command line by using the -D option.
Seems like your application is trying to find out a obidisc4j.dll (for Windows) or obidisc4j.so (for Linux). The file must be present on the PATH (but not the classpath). If you are not sure what PATH is your Java application searching in, you can write the following statement, before the point where the exception takes place, to find out the PATH.
System.out.println(System.getProperty("java.library.path"));
This will tell you about the paths where your DLL or SO file should be placed. You just need to place the file in ONE of those N-paths.
I am using Jacob jar file in my java application.
This Jacob jar file comes with a .dll file. I have added Jacob jar file to my classpath. But when I execute my application a runtime error occurs as
"couldn't load jacob-1.15-M3-x86.dll file"
How can I load this .dll file?
Edited:=================================================================================
I had set the "path" environment varaible to the dir that contains my .dll file and loading that .dll file as follows
static {
System.loadLibrary("jacob-1.15-M3-x86.dll");
}
but the following error occured
java.lang.UnsatisfiedLinkError: no jacob-1.15-M3-x86.dll in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1734)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at TemplateClass.TemplateClass.<clinit>(TemplateClass.java:14)
The 'jacob-1.15-M3-x86.dll' needs to be in a place where your the operating system can find it. You have a few options here:
You can place the .dll file in the directory you started your application from. If you have a batch script to start your application, it would be that directory. If you are starting in some sort of application server, it would typically be the 'bin' directory.
You can place the .dll file somewhere in the %PATH% environment variable. I may be easier to just update your PATH environment variable to include the directory that contains your .dll file.
Another option is to place your .dll into the %SystemRoot%\system32 directory. Usually this is 'C:\Windows\system32'. This option is not usually recommended unless it is a shared library like the MSCVRT runtime.
One other possible issue you might have. If the .dll is compiled as 32-bit, then you must be running in the 32-bit Java runtime. Likewise, if it is a 64-bit .dll it needs to be run in a 64-bit JRE.
Ah, that's not a compilation error but a runtime error.
My guess would be that your DLL needs to be on the PATH. Not CLASSPATH, but PATH, because that's where Windows looks for DLLs. Try either extending your PATH to include the location of your DLL, or do what many other people do: Dump the DLL into \Winnt\System\System32 or whatever the system directory is called on your box. Wherever all the other DLLs are, in other words.
Update
The error message you post, thankfully, is pointing out the exact problem. You can solve it by putting the directory containing your DLL into java.library.path This Sun forum thread shows a nice example: http://forums.sun.com/thread.jspa?threadID=627890
Actually, that's a lot less clean than it should be; this seems to be one of the "shadier" areas in Java. The thread wanders around a lot, I do advise you to read all the way through to see some problems and solutions. I think you'll be able to succeed with a little trial and error.
Other options :
set the property java.library.path to the directory containing the dll. Example :
java -Djava.library.path="path/to/directory/containing/the/dll" -jar appli.jar
in the code, load the dll explicitly, with System.load.
You need to set LD_LIBRARY_PATH. This will give you all the right steps to follow.
When you use System.loadLibrary() don't include the .dll at the end.
Also, if you are not setting java.library.path to point to the folder containing the DLL then the DLL should be in the directory where you launch your Java application from.
I had the same problem.
I see that the question is not "answered", so maybe none of the options above worked.
One of my last hypothesis was that the Jacob.dll is missing its dependency.
What I did was to get depend and check if all the dependence, used by Jacob are loaded.
Of course this works for Windows.
Cheers!
I got a native library that needs to be added to java.library.path. With JVM argument -Djava.library.path=path... I can set the path as I want.
My problem is that my other library (pentaho reporting) searches fonts based on the default java.library.path (including system directories etc) and the manual setting overrides the default path..
So : how can I add a path entry to the default java.library.path instead of overriding it (which seems to be done with -Djava.library.path)? (I wouldn't want to add the default path by hand, which wouldn't be nice for the sake of deployment)
EDIT: Sorry for missing details; I'm working with Eclipse. (The deployment is done with JNLP and there I can use nativelib under resources)
Had forgotten this issue... I was actually asking with Eclipse, sorry for not stating that originally.
And the answer seems to be too simple (at least with 3.5; probably with older versions also):
Java run configuration's Arguments : VM arguments:
-Djava.library.path="${workspace_loc:project}\lib;${env_var:PATH}"
Must not forget the quotation marks, otherwise there are problems with spaces in PATH.
If you want to add a native library without interfering with java.library.path at development time in Eclipse (to avoid including absolute paths and having to add parameters to your launch configuration), you can supply the path to the native libraries location for each Jar in the Java Build Path dialog under Native library location. Note that the native library file name has to correspond to the Jar file name. See also this detailed description.
SWT puts the necessary native DLLs into a JAR. Search for "org.eclipse.swt.win32.win32.x86_3.4.1.v3449c.jar" for an example.
The DLLs must be in the root of the JAR, the JAR must be signed and the DLL must appear with checksum in the META-INF/MANIFEST.MF for the VM to pick them up.
In Windows, like this:
-Djava.library.path="C:/MyLibPath;%PATH%"
%PATH% is your old -Djava.library.path
Can you get round this by calling System.load() programmatically to load your native library? This method (unlike System.loadLibrary()) allows you to specify an absolute path.
In UNIX systems, you can append to the LD_LIBRARY_PATH environment variable. On Windows, the JVM automatically sets the system property, java.library.path, to PATH; so if the dll is on your PATH, then you're set.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=102239 states that there is no substitution mechanics implemented in Eclipse's launcher, at least no up to release Juno.
Thus it is (almost) impossible to append or prepend another library folder to java.library.path when launching Eclipse without prior knowledge of the default setting.
I wrote almost, cause it should be possible to let Eclipse startup, dump the content of java.library.path and stop Eclipse in one command. The dump would the be parsed and then taken as the input for launching Eclipse, i.e.
#!/bin/bash
# get default value of java.library.path (somehow)
default_lib_path=$( start_dump_stop_eclipse_somehow )
# now launch Eclipse
eclipse --launcher.appendVmargs \
-vmargs \
-Djava.library.path="/my/native/lib/folder:${default_lib_path}"
On Windows: Add the path to the library to the PATH environment variable.
On Linux: Add the path to the library to the LD_LIBRARY_PATH environment variable.
On Mac: Add the path to the library to the DYLD_LIBRARY_PATH environment variable.
java.library.path is initilized with the values of the variables above on its corresponding platform.
This should work on any IDE.
You can test if the value is what you expect by calling java -XshowSettings:properties
The solution offered by Rob Elsner in one of the comments above works perfectly (OSX 10.9, Eclipse Kepler). One has to append their additional paths to that separated by ":".
You could also use ${system_property:java.library.path} – Rob Elsner Nov 22 '10 at 23:01
Window->Preferences->Java->Installed JREs.
Choose your current
JRE(JDK) and click Edit.
Fill Default VM Arguments:
-Djava.library.path=/usr/local/xuggler/lib.
The native library file name has to correspond to the Jar file name. This is very very important.
Please make sure that jar name and dll name are same.
Also,please see the post from Fabian Steeg
My download for jawin was containing different names for dll and jar.
It was jawin.jar and jawind.dll, note extra 'd' in dll file name.
I simply renamed it to jawin.dll and set it as a native library in eclipse as mentioned in post
"http://www.eclipsezone.com/eclipse/forums/t49342.html"
For some reason I couldn't get multiple folders to work (well it did for a while but as soon as I needed more dlls and added more folders, none with white spaces in the path). I then copied all needed dlls to one folder and had that as my java.library.path and it worked. I don't have an explanation - if anyone does, it would be great.
Many of the existing answers assume you want to set this for a particular project, but I needed to set it for Eclipse itself in order to support integrated authentication for the SQL Server JDBC driver.
To do this, I followed these instructions for launching Eclipse from the Java commandline instead of its normal launcher. Then I just modified that script to add my -Djava.library.path argument to the Java commandline.
On Windows, I have found that the important thing is to start Eclipse from the command line rather than from the Start Menu or a shortcut, provided that the native DLL is in a directory in your PATH. Apparently, this ensures that the proper directory is on the path.