unsatisfied link error runnable jar referencing jssc library - java

We are creating a runnable java jar to run on a beagle bone black(running ubuntu).
We have created a runnable jar which runs fine on our mac and pc(windows) but will not run on the ubuntu system. We keep getting the following error when running:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.UnsatisfiedLinkError: /home/ubuntu/.jssc/linux/libjSSC-2.6_armhf.so: /home/ubuntu/.jssc/linux/libjSSC-2.6_armhf.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1851)
at java.lang.Runtime.load0(Runtime.java:795)
at java.lang.System.load(System.java:1062)
at jssc.SerialNativeInterface.<clinit>(SerialNativeInterface.java:172)
at jssc.SerialPort.<init>(SerialPort.java:118)
at InputBoard.<init>(InputBoard.java:33)
at InputBoard.main(InputBoard.java:22)
... 5 more
Any information would be greatly appreciated. As I said this runs fine through terminal on a mac which is unix based so it seems it should work on Ubuntu. We have no idea why it is referencing the /home/ubuntu directory. Please let us know if you need any code information on the project but I would not think it would be related.

You are missing a native runtime library. You can install this library by using apt-get to fetch the package it contains. To do this, give this command.
sudo apt-get install libc6-*

I fixed this problem when I installed the latest JDK 8 for Hard float for Arm. Previously I tried several things, I tried using versions 2.6, 2.7 and 2.8, specified LD_LIBRARY_PATH env. variable, making sure that library was in ~/.jssc/linux, etc, etc all this to no avail, only after I upgraded java, it worked flawlessly.

I had this same error even with the latest version. In my case it turned out to be that JSSC was trying to use the "soft float" version of the native libraries that it copies out of the .jar file. I ended up replacing the file with the hard float version from the .jar file and removing write access to the file. Everything started working after that.

Related

java.lang.InternalError: platform encoding not initialized when running EXE4J .exe w/ Java14 on PATH

So this error is a weird one...
I'm using EXE4J 6 to build a .exe file for my JavaFX Application. This has worked with no issues through Java version 13.0.1. I recently upgraded my environment to use Java 14.0.1 and now I get the following stacktrace whenever I try to run my application through exe:
java.lang.RuntimeException: Exception in Application start method
at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(Unknown Source)
at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.InternalError: platform encoding not initialized
at java.base/java.net.Inet6AddressImpl.getLocalHostName(Native Method)
at java.base/java.net.InetAddress.getLocalHost(Unknown Source)
at org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:54)
at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:612)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:691)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:669)
This error happens when trying to initialize my Log4J logging. however if I just made a direct call to InetAddress.getLocalHost() I can replicate this error out of .exe. Running my application directly out of my Eclipse (EE 06/2020) works just fine. After doing some debugging. I determined that removing Java from my PATH allowed the application to run. My .exe4j configuration file is set up so that the application should look for a separate Java 14 jre and not attempt to use my PATH for java.
<searchSequence>
<directory location="../java/jre64" />
</searchSequence>
The jre64 is built through ANT using the 14.0.1 jdk that I have and only importing the modules I need. Again, this all worked through 13.0.1 prior to my upgrade to 14.0.1
From research and testing on other computers, I think this boils down to an environment issue on my computer. However I've run out of places to look. Any thoughts or ideas would be much appreciated. Specifically why EXE4J would try to use the Java on my Path instead of the one in the search sequence.
Other Notes:
Running on Windows 10 Latest Updates
Path points to OpenJDK 14.0.1 (causes break) (java -version is correct in cmd)
I've confirmed that the working exe, after removing java from my Path, is still running on version 14.0.1 through the jre64
Application is built with and Eclipse Workspace/project JRE also points to same OpenJDK 14.0.1
Running on other computers with similar versions & environment works & doesn't cause this issue.
I was finally able to determine what the issue was.
I was using Exe4J 6.0 which was not compatible with Java versions 10+. I was surprised that I wasn't getting outright errors when trying to run exe4j to compile my executable, however it seems that exe4j was sucking in an older 1.8 java version from my registry and using a 1.8 jdk that I never cleaned out of my "C:/Program Files/Java" folder. When I deleted all my old JDKs, exe4j started complaining about missing a Java VM (even though 14.0.1 was set on path).
Upgrading to Exe4J 7.0 solved the issue for me.
In my case the problem was the PATH environment variable pointing to one jre directory.
I had 2 applications in different directories:
Application A had a jre directory included in the PATH environment variable and was working fine.
Application B had another jre directory NOT included in the PATH environment variable and was throwing this error.
After removing this jre directory from the PATH environment variable everything worked ok.

How to solve exceptions <WindowsNativeRunloopThread> and <JavaFX Application Thread> on build [duplicate]

I have been testing JavaFX 11 using Maven and cannot get it to work. I have Open JDK 11 installed and if adding jars to build path from downloadable .zip everything works just fine.
However when I use the recommended POM file from the javafx 11 site I get the following error.
Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError: <init>
at javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native Method)
at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
at java.base/java.lang.Thread.run(Thread.java:834)
Exception in thread "JavaFX Application Thread" java.lang.NullPointerException
at javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
at java.base/java.lang.Thread.run(Thread.java:834)
This problem seems to have cropped up once here but none of the solutions in that thread have worked.
Does anyone have suggestions on how to go about diagnosing the problem? I am running in Eclipse 4.9 and have attached a screenshot of two projects which are identical other than one uses maven and the other has jars added to the build path. Any help much appreciated.
The solution to this problem is in comments (kleopatra). For quick reference you need to add
-Djava.library.path=C:/anywhere-outside-eclipse
(I tested using -Djava.library.path=C:/) to the VM arguments. This means javafx 11 works with Maven inside eclipse.
This is not Eclipse only problem. I have exactly the same issue when running OpenJFX app in Intellij IDEA 2018.3.2. If any other Java version specified in Windows %Path% env variable then forementioned exception will be thrown.
For instance I use Java 8 as default SDK and playing with Java 11. It's not working that way. It work only if I'll delete Java 8 bin directory from %Path%.
This is rather confusing (and I believe it's a bug) because I don't see any relations to Java 8 when I launch my project in IDE:
C:\Software\Java\openjdk-11\bin\java.exe -Dmaven.multiModuleProjectDirectory=C:\Project\helloworld -Dmaven.home=C:\Software\Maven\3.6.0 -Dclassworlds.conf=C:\Software\Maven\3.6.0\bin\m2.conf "-javaagent:C:\Software\IntelliJ IDEA\CE_2018.3.2\lib\idea_rt.jar=64808:C:\Software\IntelliJ IDEA\CE_2018.3.2\bin" -Dfile.encoding=UTF-8 -classpath C:\Software\Maven\3.6.0\boot\plexus-classworlds-2.5.2.jar org.codehaus.classworlds.Launcher -Didea.version=2018.3.2 -T 2 -DskipTests=true exec:java
As suggested in the post linked to by #kleopatra, the problem is that javafx11 is loading the wrong glass.dll file.
While the workaround suggested in other answers works, the OpenJFX tutorial suggests, when possible, to instruct eclipse to use the Java 11 VM to run, so that the correct dll is loaded.
You can modify your eclipse.ini file and (supposing your jdk11 is installed in C:\Program Files\Java\jdk-11.0.2) add the following lines:
-vm
C:\Progra~1\Java\jdk-11.0.2\bin\javaw.exe
Adding the following lines in the pom.xml file have resolved this issue for me.
In the POM file for the ArtifactID -- javafx-maven-plugin add the following lines in the configuration tag section.
<options> <option>-Djava.library.path=C:\tmp</option> </options>
<executable>C:\openjdk11\jdk-11\bin\java.exe</executable>
Create the tmp folder in advance before you make the change to pom.xml file. Also ensure that java11 is present in the path mentioned above. otherwise mention the path according to the java11 path in your system.
Context: NetBeans IDE 8 and 11 on Windows 10
I had the same problem, but my context was slightly different from the above. I do a lot of work switching between various versions of Java: supporting legacy applications in Java 8 and developing new applications in Java 11.
As it turned out, I had the Java 8 entry in the PATH while trying to develop and run a Java 11 application. The builds completed successfully but at runtime it was exceptions galore. All NB console logs and other logs indicated a Java 11 environment. I removed the Java entry from the PATH and then had to restart NB 11. Everything worked fine.

Amazon Mechanical Turk (AMT) command line tools and and Java versions

I'm trying to install Amazon Mechanical Turk command line tools on Ubuntu 14.04 LTS, using this tutorial. It requires Java, so I installed OpenJDK7. However, when attempting to run the command , I get the following error, which the internet informs me indicates the wrong Java version.
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at com.amazonaws.mturk.service.axis.AWSService.<clinit>(AWSService.java:104)
at com.amazonaws.mturk.cmd.AbstractCmd.initService(AbstractCmd.java:119)
at com.amazonaws.mturk.cmd.AbstractCmd.run(AbstractCmd.java:143)
at com.amazonaws.mturk.cmd.GetBalance.main(GetBalance.java:28)
Some of the documentation for the AMT tools indicates that I need JRE 1.5 (while others say "most recent version"), so I have been trying to install that. Since it's no longer available through apt-get, I downloaded the bin file and installed it at '/home/USERNAME/', (I don't use the machine much and didn't want to deal with sticking it at the end of a long chain of folders, so all my AWS stuff is in there) then put in my AWS keys and set the environment variables:
export JAVA_HOME="/home/USERNAME/jre1.5.0_22"
export MTURK_CMD_HOME="/home/USERNAME/aws-mturk-clt-1.3.1"
Then, checking my balance to make sure everything is configured, as specified in the AWS Getting Started PDF, I still get the same error shown above.
Did I do something wrong when installing JRE 1.5? Is it still using OpenJDK7, or is JRE 1.5 also no good? I'm really at my wit's end here.
It turns out that I am an idiot and installed Java wrong.
Instructions for anyone else having this problem: http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html

Incompatible JVM in GGTS (Eclipse) and JAVA 1.8

Having some problem with running a grails application in GGTS (eclipse) due to upgrade to Java 1.8.
The stack starts with:
Mar 05, 2015 3:51:31 PM org.springsource.loaded.jvm.JVM copyMethod
SEVERE: Problems copying method. Incompatible JVM?
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springsource.loaded.jvm.JVM.copyMethod(JVM.java:134)
at org.springsource.loaded.ri.OriginalClassInvoker.createJavaMethod(OriginalClassInvoker.java:68)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlClassGetDeclaredMethods(ReflectiveInterceptor.java:151)
at org.codehaus.groovy.reflection.CachedClass$3$1.run(CachedClass.java:84)
at java.security.AccessController.doPrivileged(Native Method)
at org.codehaus.groovy.reflection.CachedClass$3.initValue(CachedClass.java:81)
...
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1270)
at org.codehaus.groovy.grails.cli.support.GrailsStarter.rootLoader(GrailsStarter.java:236)
at org.codehaus.groovy.grails.cli.support.GrailsStarter.main(GrailsStarter.java:264)
Caused by: java.lang.IllegalArgumentException: Can not copy a non-root Method
at java.lang.reflect.Method.copy(Method.java:151)
... 280 more
I used to run the same application in Java 1.7. My colleagues upgraded to 1.8 and no longer able to run it.
I tested with SUN JDK and now I am on OpenJDK again and that does not help
Current JDK openjdk version "1.8.0_40"
JAVA_HOME, JAVA_PATH and any other variable seems to point to the correct JDK installation. I have removed all the previous (JDK 1.6 & 1.7 from the OS to be sure that there is no reference to them).
For some reason GGTS still complains for a wrong JVM. I understand the error might be related to a compiler 1.7 trying to compile files in the 1.8, but I am not sure where this reference is comming from in eclipse.
My Eclipse installation information lists the following under Java:
-vm
/usr/lib64/jvm/jre-1.8.0-openjdk/bin/java
eclipse.home.location=file:/home/arb/dev/applications/ggts-3.6.3.SR1/
eclipse.launcher=/home/arb/dev/applications/ggts-3.6.3.SR1/GGTS
eclipse.launcher.name=GGTS
eclipse.p2.data.area=#config.dir/../p2
eclipse.p2.profile=DefaultProfile
eclipse.product=org.springsource.ggts.ide
eclipse.startTime=1425566898624
eclipse.stateSaveDelayInterval=30000
eclipse.vm=/usr/lib64/jvm/jre-1.8.0-openjdk/bin/java
eclipse.vmargs=-Dgrails.console.enable.interactive=false
-Dgrails.console.enable.terminal=false
-Djline.terminal=jline.UnsupportedTerminal
-Dgrails.console.class=grails.build.logging.GrailsEclipseConsole
-Dosgi.requiredJavaVersion=1.6
-Xms60m
-Xmx1024m
Version 1.8.0_40 and 1.8.0_45 has breaking updates with grails.
Spring can not copy non-Root methods.
Since the initial posting a workaround has been developed.
aclement commented on Mar 5
Here is the build:
http://repo.spring.io/libs-snapshot-local/org/springframework/springloaded/1.2.2.BUILD-SNAPSHOT/springloaded-1.2.2.BUILD-SNAPSHOT.jar
To test it under grails, what I do is go into the grails folder:
grails-2.5.0/lib/org.springframework/springloaded/jars
I then rename the spring loaded jar that is there and put in a symlink
to the jar above. It used to be that you could just modify the
startGrails script to point to the new version, but now due to the
forking I find you need to do the symlink thing. Or drop that jar into
this folder and rename it to match the expectations of grails (rename
it from springloaded-1.2.2.BUILD-SNAPSHOT.jar to
springloaded-1.2.0.RELEASE.jar)
If you want to rollback instead
Grails is natively supported in 1.8.0_25, 1.8.0_31
http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html#jdk-8u25-oth-JPR
Once you have a compatible java version clean your grails project.
Ensure that your java path variables are set to point to your expected version.
set JAVA_HOME=C:\java\jdk1.8.0_25
set PATH=%JAVA_HOME%\bin;%PATH%;
It's a problem related to jdk8u40, go back to jdku31. It works in that version.
I'm running into the same problem both in windows and linux environments.
I updated my springloaded jar to version 1.2.4.BUILD-SNAPSHOT (from 1.2.1) and that resolved the issue. (Latest version can be found in the Spring repo)
Go to your local Grails lib directory to find springloaded jar. For me that was /usr/local/Cellar/grails/2.4.4/libexec/lib/org.springframework/springloaded/jars/
remove existing 1.2.1 jars (I removed pom file, too, but not necessary)
download latest springloaded jar and place into the jars subdir:
wget http://repo.spring.io/libs-snapshot-local/org/springframework/springloaded/1.2.4.BUILD-SNAPSHOT/springloaded-1.2.4.BUILD-SNAPSHOT.jar
After doing that, everything works. (Clues used from previous answer: https://github.com/spring-projects/spring-loaded/issues/98)
Step 1 : Download this jar
step 2 : put it into the grails folder: grails-2.4.1/lib/org.springframework/springloaded/jars
should be enough , restart IDE
Root cause, work-arounds and news on fixes here: https://github.com/spring-projects/spring-loaded/issues/98
I am running Grails 2.4.3 and also had problems moving from jdk1.8.0_31 to jdk1.8.0_40 and had to go back to jdk1.8.0_31
Loading Grails 2.4.3
...
SEVERE: Problems copying method. Incompatible JVM?
java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.IllegalArgumentException: Can not copy a non-root Method
at java.lang.reflect.Method.copy(Method.java:151)
From https://github.com/spring-projects/spring-loaded/issues/98 and worked to me
wget repo.spring.io/libs-snapshot-local/org/springframework/springloaded/1.2.3.BUILD-SNAPSHOT/springloaded-1.2.3.BUILD-SNAPSHOT.jar -O ~/.gvm/grails/2.4.4/lib/org.springframework/springloaded/jars/springloaded-1.2.1.RELEASE.jar
Two Step To Make it Work
1. Download JDK Lower Version:
Install jdk1.8.0_25 from link http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html#jdk-8u25-oth-JPR. It's the lower version of JDK as grails dont support higher version. Maybe They'll include this in latest version soon.
2. Set Up Environment Variables:
Don't forget to change the Enviromental variables for jdk, you have to just edit Path Variables and JavaHome Variable from "C:\Program Files\Java\jdk1.8.0_'LatestVersion'" to "C:\Program Files\Java\jdk1.8.0_25" .
Changing the springloaded version in my pom.xml did the trick.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>springloaded</artifactId>
<version>1.2.6.RELEASE</version>
</dependency>
When I was experiencing the issue my springloaded version was 1.2.1.RELEASE
I thought I should add my two pence worth on this topic. Recently I hit the same issue trying to upgrade an ancient app to 2.4.4. The reason for my post is because all of the above instructions are a little out of date and whilst in most cases it may appear to work. The moment you introduce mysql drivers all of the above mentioned versions of spring loaded hit a new issue around incompatibility and Non-root when attempting to trigger the database.
I got ggts fully working with JDK 1.8_065. To make it work get hold of springloaded-1.2.5.RELEASE.jar Put this into grails-2.4.4/lib/org.springframework/springloaded/jars/ folder.
When you install ggts inside the ggts-bundle folder is grails-2.4.4. So put the file in the above location within the ggts-bundle folder. Unless you have changed configuration.
Re-launch GGTS
I spent ages on it and thought I should update the instructions.
Also the other thing that I hit issues around was forking under grails 2.4.4 with my uprade and ended up setting
grails.project.fork = []
In my BuildConfig.groovy

Inconsistency in ant command - CentOS 6.3

I'm in CentOS 6.3 and I'm attempting to recompile a .java file using the ant command however I'm getting these two results.
When I run ant:
Caused by: java.lang.ClassNotFoundException: org.apache.tools.ant.launch.Launcher
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: org.apache.tools.ant.launch.Launcher. Program will exit.
When I run sudo ant:
Error: JAVA_HOME is not defined correctly.
We cannot execute java
When I run *echo $JAVA_HOME*:
/usr/lib/jvm/java-1.6.0-openjdk/
Before anyone suggests that I should be using the JRE instead of the JDK, I just need to mention that my installation manual for the software I'm running - OpenGTS - specifically requests the JDK. Any ideas as to what I'm doing wrong?
Thanks in advance.
ant is script to launch a java program. It appears that script could not figure out a value for ANT_HOME. On linux the script tries to load /etc/ant.conf which reset the ANT_HOME. Your symptoms does not match, but it is worth checking.
Quote from site
The cause of this is that there is an old version of ant somewhere in
the class path or configuration.
A version of this problem may be seen on some linux systems. Some
linux systems (Fedora Core 2 for example), comes with a version of ant
pre-installed. There is a configuration file called /etc/ant.conf
which if present, the ant shell script will 'dot' include. On Fedora
Core 2, the /etc/ant.conf file resets the ANT_HOME environment
variable to /usr/share/ant. This causes the problem that an old
version of ant (1.5.x in this cause) will be used with a new version
of the ant script file.
One can check if this is the case by doing ant --noconfig -version.

Categories