I know that JVM use the java.library.path property to locate the native libraries at run time. I am trying to configure Eclipse with the native dependency location.
But there are many places in Eclipse->Project Properties->Build Path I can specify the location.
The Source tab -> Native library location
The Libraries tab -> JRE System Library -> Native library location.
And for each external jars, there's a Native library location entry.
As I tried, it seems no matter where I configure it, it is always put in the java.library.path before my application starts.
Which one should I use?
If they all goes to the same destination, why so many config entries?
So far, my guess is, the designer of Eclipse hope this way can help programmers organize their native libraries more logically.
That tab within eclipse is all put onto the buildpath at runtime and is going to be organized based on the library you are putting onto the path not where in the eclipse UI you designate it.
As you mentioned it is more for a logical easier to use UI as opposed to any actual change to where it is located. Personally I prefer using the "Native Library" in the source tab but that is just out of preference.
Related
I have an Eclipse RCP application that uses some native libraries via JNI. These are shared libraries that dynamically link to each other. On Windows I put these libraries (as *.dll files) next to the RCP launcher executable (*.exe) file and load them via System.load("<absolute file path>"). This works great, as the location of the launcher seems to be added to the java.library.path so that dynamic linking between the libraries works.
On Linux, I get an UnsatisfiedLinkError. The location of the launcher is not added to the java.library.path. When I start the application from the terminal after setting the LD_LIBRARY_PATH variable it works:
export LD_LIBRARY_PATH=.
./myApp
The location . is the added to the java.library.path. Is there a better way to do this? I want the users to just double click the launcher.
Setting -Djava.library.path=. in the myApp.ini file does also not work. I see it in the installation details but I still get an UnsatisfiedLinkError.
The most reliable way to find libraries is not using java.library.path at all but finding them via Java code and load via System.load() instead of System.loadLibrary(). You can apply whatever logic you want for finding the native library (although it's probably best trying not to be too clever) and you could fall back to trying java.library.path if your mechanism fails.
This will only work of course if the library doesn't depend on other libraries that might not be found.
I am trying to communicate to Arduino with Java, so I'm using the rxtx library. I've downloaded the library and placed the respective files in my java project's folder. I put the rxtxxjar in a lib folder in the java project's folder, and I left the serial.jnlib straight into the java project's folder. I've taken the SerialTest code off of the arduino website, and I've tried to run it but I keep getting the UnsatisfiedLinkError. I've researched this question, and I've seen people saying basically the following in different ways:
Go to Project -> properties -> Java build path ->Find your .jar. Click
on + to open the JAR's properties. Select Native library location and
edit it to point to RXTX's shared library (.DLL, .so, .dylib).
However, I have no idea how to do the pointing to the shared library, especially since I don't see any .dll, .so, or .dylib file, and I cannot use the .jnlib because it is greyed out. Also on a smaller note, by my .jar is that just the project? I work in Eclipse Java EE.
You can use
System.load("Absolute path to your jni library");
This works fine on my project.
I'm trying to work out if there is a definitive, recommended, robust way to work with native libraries in Java and Maven.
I know it's possible to do this by putting libraries in the right places, configuring java.library.path and calling System.loadLibrary etc. - but I want a proper solution that works across the whole development / deployment life-cycle and doesn't involve lots of hacks.
My requirements seem fairly straightforward:
Configuration 100% via Maven
Ability to include native dependencies for different platforms / architectures (mainly Linux and Windows, others would be nice though...)
Ability to create a runnable .jar that doesn't require the user to fiddle with command line options to run it (i.e. it will unpack and load any native dependencies it needs at runtime, preferably as temp files or something like that)
The code works during development (in Eclipse)
The code works during normal Maven builds at the command line
Basically, I want natives to just work both during development and for the user at runtime.
Is this possible? If so what do I need to configure to make it happen?
It certainly is possible. A good example that I came across which solves the same problem is sqlite wrapper at https://bitbucket.org/xerial/sqlite-jdbc/overview
By following a pre defined packaging structure for each architecture, we can programmatically extract the desired native library from class path into a temp folder and can set the desired java.library.path to load the native library.
All native libraries would be packaged in the src/main/resources folder
At runtime there needs to be a bootstrap code which can determine the OS, architecture and choose the right native library to extract
the same bootstrap code can extract the native library into a temp folder and call System.loadLibrary
I have not personally tried executing the above flow but could not think of any other way.
First off I'm not a Java expert by any stretch, nor am I a regular Eclipse user. Due to personal circumstances of a member of our team I have had to step into the breach and fix some bugs in two java applications currently under development.
We have a core application (CORE) and an API which includes a reference to that CORE. What I need to do is debug the API but step into the CORE code. I have all the source code for both projects loaded into the IDE but I can't hit breakpoints in the CORE. I'm assuming it is using the jar version of the CORE included in the API as opposed to the code in the CORE.
I hope that makes sense.
Cheers
Define a breakpoint in the API by clicking on the left side column of the editor. Then, try to step into a function of CORE. Eclipse will complain that it cannot find the sources to debug. However, a button will appear that will let you define where to find these sources: either in a jar file or in an external directory.
If you were to include the sources of CORE along with the classes of CORE, normally eclipse will find it automatically as well.
Cheers
I have all the source code for both projects loaded into the IDE but I can't hit breakpoints in the CORE. I'm assuming it is using the jar version of the CORE included in the API as opposed to the code in the CORE.
Change the build path of the second project so that instead of referring to a packaged JAR of the first project, it refers to the project itself.
In the properties of the second project, go to Java Build Path, remove the JAR from the Libraries tab, and add the first project under the Projects tab.
What you need to do is remote debugging. Here is one (of several) articles covering that topic and showing how to set up a remote debugging session. (near to the end of the text)
Basically you start the application with some extra parameters while on eclipse you have a projects that contains the source code. Then you start a remote debugging session and can set breakpoint, inspect variables, etc. on the remote JVM.
You probably have the CORE java classes which are compiled by Eclipse to byte code and present in the IDE. THat means that the code invoked by the API is most likely NOT the code you think as it is probably present in jar files next to the API.
What you need to to is to attach the sources to the jar files instead in their properties. Either zip them up and attach that zipfile or attach the folder where the "com"/"org" etc package names start.
I'm trying to use an open source java library to visualize nodes and edges in a graph, but I'm completely lost.
I have a bunch of jar files in a folder. Clicking on some of the jar files makes java swing windows pop open with graphs displayed. Clicking other jar files does nothing.
If I figured that out, would I just stick the jar files in there with the other ones, or would that still not work?
And if I ever figure out how to use these files, does that mean that I have to include them if I transfer my java project to another computer? How would I go about doing that?
I believe if you put the jars in your classpath, you can import and use classes just like you would a standard library. Figuring out the classpath can be confusing, but you can just set it when you start your jvm. Your IDE may have options for it, too.
Most java problems are classpath problems.
Have you included those libraries in your classpath?
If you are using eclipse, you could
Project - > properties -> Java build path ->addJar.
And the Jar file should be placed in a directory inside your workspace (lib/ for example)
If you have to take your project to another computer, you could take these steps
Before doing anything, export your project (as a Jar file, for example).
Save it into your favorite drive (cd / usb drive/ diskette/ tape).
On "the other" computer, you can import this project into your workspace
In Eclipse, you need to add libraries to the project build path.
In general, you need to provide dependencies via the classpath mechanisms at compile time and runtime. The precise mechanisms vary, but, for example, if you used the javac compiler, you would provide your libraries on the command line:
javac -classpath C:\dir\lib1.jar;C:\dir\lib2.jar foo/MyClass.java
These dependencies would also be required to invoke the app:
java -classpath C:\dir\lib1.jar;C:\dir\lib2.jar;. foo.MyClass
This page gives some good info, though googling for the term "classpath" should provide alternative sources.
You use it by including it in the classpath of your java application, that way you can reference it from your code. Here is a starter document. The JDK 1.6 has some easier options (such as specifying multiple jar files as *.jar). It is definitely a little complicated, but it is very worth knowing.
You should have documentation for these Jars. Some sounds like examples, but one must be the core graph modelling and rendering Jar. Hopefully the examples have source included.
Just add that Jar to your project in Eclipse (e.g., in a /lib folder in your project, then add it to the build path) and use the documentation to use the code. You can also use Eclipse to look inside the Jar file.
Unless there is no alternative, it probably isn't worth using a load of third party code that isn't documented at least on the API level, and without any source examples definitely not.