I'm using LeapJava.jar to write a simple JDK program to interface with the Leap. I've roughly followed this article: Developing for the Leap Motion controller in Scala and in theory it's all very simple. However, when I try to run the program it fails with a RuntimeException when it tries to connect to the Leap device:
Native code library failed to load.
java.lang.UnsatisfiedLinkError: no LeapJava in java.library.path
java.lang.RuntimeException: Nonzero exit code: 1
at scala.sys.package$.error(package.scala:27)
I've followed the steps in the Leap documentation but since I'm using Ubuntu (and sbt) there aren't clear instructions that relate directly to this situation. I've tried various different parameters for the java.library.path argument:
pointing at the ./lib dir in the project (which contains LeapJava.jar)
using the Leap SDK's lib directory
absolute path to the Leap SDK's lib directory
the x86 dir within the LeapSDK's lib directory
symlinking the LeapJava.jar file into the x86 directory and using that
I get the same problem running it in IntelliJ (set up as described in the Leap docs linked above) or from the command line. e.g.
sbt -Djava.library.path=.:/<path to LeapSDK>/lib run
I've added the LeapJava.jar to the classpath in sbt (it's in the lib directory) and the project compiles fine.
Any advice (particularly as I'm on Linux, which is poorly documented) would be most welcome.
Copy the .dll files in the the project(your current working directory) folder since it looks for the native libraries in that particular folder.
From the Readme in the Leap Motion Linux package:
Q. ...Sample.java compiles, but when
attempting to run, I get an error about unable to load
libLeapJava.so
A. Java seems to have trouble searching for native
libraries without some guidance. Try:
LD_LIBRARY_PATH=. java -classpath .:LeapJava.jar Sample
which looks like it assumes the jar file and native libraries are in the same folder as your application.
I got things rolling in eclipse on Ubuntu by doing the following.
1)Select your project in the Package Explorer area and press a right click on it.
2) Select Build Path → Configure Build Path... option.
3) In the appearing window, select the Libraries tab.
4) Then, expand the JRE System library option and select the Native library location.
5) Click on the Edit button at the right panel
6) click external folder.
7) navigate to your download of the sdk .../LeapSDK/lib/x64
if you are on a 32 bit system use x86
You should now be able to use LeapJava.jar without error.
Related
I'm working with a Scala project and am trying to get IntelliJ to work with it. (If it makes a difference, I've gotten it to work before. But my machine died and had to be replaced, and this is the first time I've tried to use Scala since reinstalling IntelliJ on the new machine.) The machine is running Linux.
I've gotten the banner that says "No Scala SDK in module", and I selected "Setup Scala SDK"; Create; Download; Version 2.11.11; OK. But I get the message
Cannot run program "java" (in directory "/tmp/sbt-project"): error=2,
No such file or directory
Why is it looking in that directory (which does not exist on my machine)? It's possible there are some settings that got copied over from my previous machine. If so, where would I find and fix the setting?
How do I get past this problem?
Note: In a desperate attempt to work around the error, I created /tmp/sbt-project and symlinked the Java binaries into it. When I tried again, I got the same error except it said in directory "/tmp/sbt-project1". I tried creating /tmp/sbt-project1 as a symlink, and when I retried, it said in directory "/tmp/sbt-project2". What's going on?
In short: I have no idea why you and I both experienced this problem, but these steps remedied the situation for my particular case (no guarantees but maybe it will help you too)
Close Intellij
Likely in your home directory, backup and remove the .Idea* directory containing your personal settings
Open Intellij and at the welcome screen choose Do not import settings
Using the guided installation, ensure the "Featured" plugin, Scala, is installed
Reopen your project and when you setup the Scala SDK, miraculously a pre-existing version of Scala SDK should exist from the "Ivy" repository (I tested this on a fresh VM of Lubuntu)
After selecting the (likely outdated) Scala SDK, again go to Project Settings and under Global Libraries click the + symbol to add the latest Scala SDK.
Miraculously once again, you will see now both the SDK version from before and the latest version of Scala - choose that one and done!
Notes:
Before running those above steps, I tried the same things you did on the VM, possibly caching install versions I wasn't even aware of that later became available once I resetup Intellij.
The reason I suspect this worked is because I thought I would save myself time by copying the .Idea* directory from a different machine and using that - many paths were different! So likely I just disabled features with broken paths from my other machine
Even though I never needed to press the "Download" button, if I do I still get that same error! So I guess all this did was bypass manually downloading the SDK like you had to do...
My setup:
OS: Lubuntu-16.04.3-lts
Intellij Version:
IntelliJ IDEA 2018.1.4 (Community Edition)
Build #IC-181.5087.20, built on May 16, 2018
JRE: 1.8.0_152-release-1136-b39 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.13.0-43-generic
echo $PATH
/home/e/tools/jdk1.8.0_121/bin:/home/e/bin:/home/e/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
I met the same problem when installing Scala by IntelliJ.
You can choose to install Scala mannually.
For example, install Scala follow this tutorial: https://www.vultr.com/docs/how-to-install-scala-on-centos-7
Then use Browse when selecting Scala SDK. Choose your directory, e.g. /usr/share/scala/
You can use Scala in IntelliJ now.
I am writing a program which needs to use a .dll file. When my program starts up, the following code is executed:
public static void main(String[] args)
{
String dLLURL = "C:/Program Files (x86)/Location of DLL";
System.setProperty("jna.library.path", dLLURL);
System.setProperty("jna.debug_load", "true");
System.setProperty("jna.debug_load.jna", "true");
Application.launch(args);
}
I then execute
DllInterface dllinterface = (DllInterface) Native.loadLibrary( "dllName.dll", DllInterface.class);
...which loads the correct dll and allows me to use it. JNA outputs the following (this time using the actual name/path of the DLL):
Trying (via loadLibrary) jnidispatch
Looking in classpath from sun.misc.Launcher$AppClassLoader#e2f2a for /com/sun/jna/win32-x86/jnidispatch.dll
Found library resource at jar:file:/C:/Users/bengs_000/Downloads/jna.jar!/com/sun/jna/win32-x86/jnidispatch.dll
Trying C:\Users\BENGS_~1\AppData\Local\Temp\jna-792348840\jna2314341730536889248.dll
Found jnidispatch at C:\Users\BENGS_~1\AppData\Local\Temp\jna-792348840\jna2314341730536889248.dll
Looking for library 'RailDriver.dll'
Adding paths from jna.library.path: C:\Program Files (x86)\Steam\SteamApps\common\RailWorks\plugins
Trying C:\Program Files (x86)\Steam\SteamApps\common\RailWorks\plugins\RailDriver.dll
Found library 'RailDriver.dll' at C:\Program Files (x86)\Steam\SteamApps\common\RailWorks\plugins\RailDriver.dll
This is what happens when I run the program in Eclipse IDE. It works just fine!
However, when I build/run the program as a .jar, the application says the DLL cannot be found (despite looking in the correct location) and returns the following message:
Trying (via loadLibrary) jnidispatch
Looking in classpath from java.net.URLClassLoader#677327b6 for /com/sun/jna/win32-x86-64/jnidispatch.dll
Found library resource at jar:rsrc:jna.jar!/com/sun/jna/win32-x86-64/jnidispatch.dll
Trying C:\Users\BENGS_~1\AppData\Local\Temp\jna-792348840\jna8530559464473818762.dll
Found jnidispatch at C:\Users\BENGS_~1\AppData\Local\Temp\jna-792348840\jna8530559464473818762.dll
Looking for library 'RailDriver.dll'
Adding paths from jna.library.path: C:\Program Files (x86)\Steam\SteamApps\common\RailWorks\plugins
Trying C:\Program Files (x86)\Steam\SteamApps\common\RailWorks\plugins\RailDriver.dll
Adding system paths: []
Trying C:\Program Files (x86)\Steam\SteamApps\common\RailWorks\plugins\RailDriver.dll
Looking for lib- prefix
Trying libRailDriver.dll
Looking in classpath from java.net.URLClassLoader#677327b6 for RailDriver.dll
There was an error finding your raildriver.dll file
As you can see, exactly the same path is taken to find the .dll file yet it works in Eclipse and not as a compiled .jar file!
Would you please be able to help me identify the problem? One thing to note is that the .dll file is stored within the 32bit section of Program Files, and my computer is 64bit. I am using Java 32bit to compile and run the program in Eclipse. Surely it should build the .jar with Java 32bit right?
I have found a solution!
The Background
I knew that the problem was related to the .dll I wanted to use being 32bit, and my computer being 64bit. In the Eclipse IDE, I was running the app using Java 32bit (I knew I should to this to ensure compatibility).
When running the .jar file, Java was defaulting to the 64bit version; different to how I was testing it in Eclipse.
The Solution
To force the user to use Java 32bit, you need to bundle the .jar into an .exe file. I used Launch4J to do this. There's a parameter in Launch4j which allows you to specify which systems of Java to use. This is located under the JRE tab in the "Search Options" section. By changing it to "32-bit only", the .jar file is launched under Java 32-bit, thus alleviating the problem!
I hope this might help some one!
I was able to make some progress in getting Scala running on the Netbeans IDE. I am stuck with what looks like an error finding file sh.exe. I have found this file in my git directory but I have no idea where it should be in a Scala configuration. Here is the beginning of the error message, is this familiar to someone?
SBT -Completion: -Exit: exit -Help: help.
sbt-launch=C:\Users\William\AppData\Roaming\NetBeans\8.0\modules\ext\org.netbeans.libs.sbt\1\org-scala-sbt\sbt-launch.jar
[ERROR] Failed to construct terminal; falling back to unsupported
java.io.IOException: Cannot run program "sh": CreateProcess error=2,
The system cannot find the file specified at
java.lang.ProcessBuilder.start(ProcessBuilder.java:1042)
I had this problem with the newest version of NetBeans Plugin for Scala within Windows OS during use of the Scala SBT plugin. Cygwin should solve the problem (after instalation don't forget to set the path/to/cygwin/bin in the Windows path variable).
When I down load the small installation program and start the install I am presented with a large category of files without one being Scala. Do you know which packages need to be installed or a link to a document?
By continuing the install without adding any additional package and then adding the path as was suggested I was able to compile a scala project in the Netbeans 8.0.2 IDE.
I have inherited a Flash Builder 4.6 project, but cannot get the Eclipse FB to compile the project, and now my 60 days has lapsed.
I got fed up with being sent in circles by Eclipse/Fb and now I want to try and sanitise/understand the process by building manually using Flex SDK 4.6.
Trouble, is I do not know where to start. There is the MXMLC.exe and CompC.exe, there are projects within the workspace with inter-depedencies.
Simple example using ANt exists where the chap is only compiling from a single source file.
In my workspace I have a main project folder with sub-folders like src containing .as, .mxml, .png files and sub0fodlers like "assets". At the src root folder there is the main mxml which maps to the final compiled exe.
The project also has a "libs", "bin" "bin-release" folder.
The referenced projects are similar.
One of the referenced projects is "flerry".
I want a single Windows Perl/BAT scipts that will compile this for me.
Any ideas on where to look?
mxmlc.exe is used to compile the application, compc.exe is used to compile libraries. If you have code library dependencies, you'll first need to compile these and then compile your application.
The documentation on compiling is pretty good and can be found here: http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7fcc.html
I would suggest you give this a go and post specific questions if you run into issues.
I've been following the instructions shown on http://visualvm.java.net/build/build.html when attempting to build JVisualVM.
I checked out the trunk to my hard-drive, I've downloaded http://java.net/projects/visualvm/downloads/download/dev/nb73_visualvm_14012013.zip and extracted its contents to the visualvm/ directory, as asked:
To build the visualvm core tool you need the NetBeans 7.3 platform and profiler binaries available here. These binaries must be extracted into the trunk/visualvm directory. You can use ant run or ant build-zip to build or run VisualVM.
When executing ant run I got a:
compile:
[mkdir] Created dir: C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\build\classes
[nb-javac] Compiling 19 source files to C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\build\classes
[nb-javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5
[nb-javac] C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\src\com\sun\tools\visualvm\application\views\threads\ThreadMXBeanDataManager.java:117: e
rror: cannot find symbol
[nb-javac] super(dummyLong, CommonConstants.SERVER_RUNNING, CommonConstants.SERVER_PROGRESS_INDETERMINATE);
[nb-javac] ^
[nb-javac] symbol: variable SERVER_RUNNING
[nb-javac] location: interface CommonConstants
[nb-javac] C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\src\com\sun\tools\visualvm\application\views\threads\ThreadMXBeanDataManager.java:117: e
rror: cannot find symbol
[nb-javac] super(dummyLong, CommonConstants.SERVER_RUNNING, CommonConstants.SERVER_PROGRESS_INDETERMINATE);
[nb-javac] ^
[nb-javac] symbol: variable SERVER_PROGRESS_INDETERMINATE
[nb-javac] location: interface CommonConstants
[nb-javac] Note: Some input files use unchecked or unsafe operations.
[nb-javac] Note: Recompile with -Xlint:unchecked for details.
[nb-javac] 2 errors
[nb-javac] 1 warning
I've even installed Netbeans 7.3 but that didn' seem to help a bit!
I'm quite new to these matters, am I missing something?
You mentioned that you are "quite new to these matters", so may I ask if there is a reason you want to build the trunk, specifically? Most of the time, the workflow when using SVN for source control includes tagging releases under /tags. The tagged releases have generally been tested and met a minimum testing criteria to be considered suitable for release, so you will probably have an easier time building one of the tags.
There is nothing wrong with building /trunk for yourself, but it should be considered an "unstable/work in progress" build, so you should expect to encounter problems.
As you may already know, there are pre-compiled binaries available for download on the VisualVM site. If there is no binary for your operating system listed, you can probably find it with your package manager (e.g. sudo apt-get install visualvm on Ubuntu).
That said, don't let me discourage you from trying, if you want to:
In this case, the compiler is telling you that it cannot find the symbols SERVER_RUNNING and SERVER_PROGRESS_INDETERMINATE in the CommonConstants class. These are referenced on line 117 of the ThreadMXBeanDataManager class. If you take a look at that class, you will see the import org.netbeans.lib.profiler.global.CommonConstants statement, which tells us that CommonConstants comes from NetBeans. If we examine the SVN commit history for the ThreadMXBeanDataManager class, we can see that the developer made the changes intending to make VisualVM compatible with NetBeans 7.3. So, there are a few possiblities:
The developer was wrong, and was actually compiling with some other version of NetBeans (possibly a pre-release, etc). If you find that this is the case, you should file a bug report (and a patch, if possible).
You are trying to compile against the wrong version of NetBeans.
Something is wrong with the classpath/build script.
Let's examine #2 and #3. We can take binary you linked to and find out which jar(s) the CommonConstants class lives in by using JFind or a similar utility (or by Googling, etc.):
We see that the class lives in two places, so the next thing to do is check both of the class files and make sure that they have the constants. Use an unzip utility (e.g. 7-zip) to expand the jar files and use a decompiler (I like JD-GUI) to verify that the class has the constants:
The version you linked to seems OK on my machine, so unfortunately now you have to investigate further. Are either or both of these jars on the classpath in the Ant script that does the compilation? Do you have a different version of the jar on your classpath via an environment variable? There are a lot of possibilities here, so you will have to do some sleuthing. If all of this seems like a lot of work, then I suggest you go with one of the pre-compiled binaries or switch to a tag build.
It looks like you are compiling it against NetBeans 7.2. Did you opened the VisualVM project in NetBeans before you tried to compile it? If so, please check which NetBeans Platform is set for top-level VisualVM project in NetBeans. You should compile VisualVM against NetBeans platform from nb73_visualvm_14012013.zip. To check that your installation is correct, try the following:
If you have VisualVM open in NetBeans, close NetBeans
find all trunk/visualvm/*/nbproject/private directories in the VisualVM source tree and delete private directory.
use ant run from command line
If that works, open NetBeans, register trunk/visualvm/netbeans as NetBeans Platform and set is as platform for VisualVM top-level project.