Compiling JD2XX for Raspberry Pi - java

For Openhab2 there is a binding add-on called RFXCOM. The problem however is that this add-on uses JD2XX which is not compatible with the ARM architecture of the Raspberry Pi.
I have found a Github repository with the source that you can use to compile a *.so file: https://github.com/0x6a77/JD2XX
A little change to the Makefile to use the correct Java path (zulu-8-armhf-embedded instead of (oracle-7).
Running sudo make jni creates a *.so file which I copied to /usr/lib (inside the java library path). However I still get the error that the Raspberry Pi can't open the shared library due to it being 32-bit. How can you compile a shared library that works for ARM with the source provided by the Github repository.
Error message:
java.lang.UnsatisfiedLinkError:
/var/lib/openhab2/tmp/libjd2xx5892592723514582617.so:
/var/lib/openhab2/tmp/libjd2xx5892592723514582617.so: cannot open shared object file:
No such file or directory (Possible cause: can't load IA 32-bit .so on a ARM-bit platform)
The Raspberry Pi has a fresh installation of Openhabian.
Link to the issue on Github: https://github.com/openhab/openhab2-addons/issues/2316#issuecomment-304795652
EDIT:
11:00:52.291 [ERROR] [rnal.discovery.RFXComBridgeDiscovery] - Error occurred during discovery
java.io.IOException: device not found (2)
at jd2xx.JD2XX.listDevices(Native Method)
at jd2xx.JD2XX.listDevicesByDescription(JD2XX.java:785)
at org.openhab.binding.rfxcom.internal.discovery.RFXComBridgeDiscovery.discoverRfxcom(RFXComBridgeDiscovery.java:89)
at org.openhab.binding.rfxcom.internal.discovery.RFXComBridgeDiscovery.startScan(RFXComBridgeDiscovery.java:66)
at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:199)
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:382)
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:358)
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:216)
at org.eclipse.smarthome.io.rest.core.discovery.DiscoveryResource.scan(DiscoveryResource.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_121]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_121]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_121]
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)[158:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76)[10:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)[81:org.eclipse.jetty.servlet:9.2.19.v20160908]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[81:org.eclipse.jetty.servlet:9.2.19.v20160908]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)[172:org.ops4j.pax.web.pax-web-jetty:4.3.0]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[79:org.eclipse.jetty.security:9.2.19.v20160908]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:287)[172:org.ops4j.pax.web.pax-web-jetty:4.3.0]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[81:org.eclipse.jetty.servlet:9.2.19.v20160908]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)[172:org.ops4j.pax.web.pax-web-jetty:4.3.0]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.Server.handle(Server.java:499)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[80:org.eclipse.jetty.server:9.2.19.v20160908]
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[72:org.eclipse.jetty.io:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[83:org.eclipse.jetty.util:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[83:org.eclipse.jetty.util:9.2.19.v20160908]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
11:01:02.868 [WARN ] [e.sshd.server.channel.ChannelSession] - Unknown pty opcode value: 42

In the JD2XX.java file, you can see the mechanism how to load a dll, so or some other type of library depending on OS.
static {
String dataModel = System.getProperty("sun.arch.data.model");
String osName = System.getProperty("os.name").toLowerCase();;
StringBuilder lib = new StringBuilder("/jni/");
if (osName.contains("win"))
lib.append("win/");
else if (osName.contains("linux"))
lib.append("linux/");
else if (osName.contains("mac"))
lib.append("mac/");
else
throw new UnsatisfiedLinkError("Loading JD2XX JNI: Unsupported operating system ("+osName+")");
if (dataModel.equals("32"))
lib.append("x86_32/");
else if (dataModel.equals("64"))
lib.append("x86_64/");
else
throw new UnsatisfiedLinkError("Loading JD2XX JNI: Unknown runtime data model ("+dataModel+")");
if (osName.contains("win"))
lib.append("jd2xx.dll");
else if (osName.contains("linux"))
lib.append("libjd2xx.so");
else if (osName.contains("mac"))
lib.append("libjd2xx.jnilib");
try {
NativeUtils.loadLibraryFromJar(lib.toString());
} catch (IOException e) {
throw new UnsatisfiedLinkError(e.getMessage());
}
}
The loadLibraryFromJar method from NativeUtils creates temp directory and copy the right library for OS to temp directory then call the System.load method eventually.
So, I think you should modify this part of source code like the code as follows, if possible.
static
{
System.load("/var/lib/openhab2/tmp/libjd2xx5892592723514582617.so");
}
or
static
{
System.load("/usr/lib/libjd2xx5892592723514582617.so");
}
There are several ways to make this job work re-setting the 'java.library.path' order to indicate the /usr/lib directory first then use the code below.
Or you can rename the library name, libjd2xx5892592723514582617.so to libjd2xx.so in the /usr/lib which is usually in the 'LD_LIBRARY_PATH' variable.
then, our code in the JD2XX.java can be used instead,
static
{
System.loadLibrary("jd2xx");
}
I think it works..

Related

Read the jar version for a class

For a webservice client I'd like to use Implementation-Title and Implementation-Version from the jar file as user-agent string. The question is how to read the jar's manifest.
This question has been asked multiple times, however the answer seems not applicable for me. (e.g. Reading my own Jar's Manifest)
The problem is that simply reading /META-INF/MANIFEST.MF almost always gives wrong results. In my case, it would almost always refer to JBoss.
The solution proposed in https://stackoverflow.com/a/1273196/4222206
is problematic for me as you'd have to hardcode the library name to stop the iteration, and then still it may mean two versions of the same library are on the classpath and you just return the first - not necessarily the right - hit.
The solution in https://stackoverflow.com/a/1273432/4222206
seems to work with jar:// urls only which completely fails within JBoss where the application classloader produces vfs:// urls.
Is there a way for code in a class to find it's own manifest?
I tried the abovementioned items which seem to run well in small applications run from the java command line but then I'd like to have a portable solution as I cannot predict where my library would be used later.
public static Manifest getManifest() {
log.debug("getManifest()");
synchronized(Version.class) {
if(manifest==null) {
try {
// this works wrongly in JBoss
//ClassLoader cl = Version.class.getProtectionDomain().getClassLoader();
//log.debug("found classloader={}", cl);
//URL manifesturl = cl.getResource("/META-INF/MANIFEST.MF");
URL jar = Version.class.getProtectionDomain().getCodeSource().getLocation();
log.debug("Class loaded from {}", jar);
URL manifesturl = null;
switch(jar.getProtocol()) {
case "file":
manifesturl = new URL(jar.toString()+"META-INF/MANIFEST.MF");
break;
default:
manifesturl = new URL(jar.toString()+"!/META-INF/MANIFEST.MF");
}
log.debug("Expecting manifest at {}", manifesturl);
manifest = new Manifest(manifesturl.openStream());
}
catch(Exception e) {
log.info("Could not read version", e);
}
}
}
The code will detect the correct jar path. I assumed by modifying the url to point to the manifest would give the required result however I get this:
Class loaded from vfs:/C:/Users/user/Documents/JavaLibs/wildfly-18.0.0.Final/bin/content/webapp.war/WEB-INF/lib/library-1.0-18.jar
Expecting manifest at vfs:/C:/Users/user/Documents/JavaLibs/wildfly-18.0.0.Final/bin/content/webapp.war/WEB-INF/lib/library-1.0-18.jar!/META-INF/MANIFEST.MF
Could not read version: java.io.FileNotFoundException: C:\Users\hiran\Documents\JavaLibs\wildfly-18.0.0.Final\standalone\tmp\vfs\temp\tempfc75b13f07296e98\content-e4d5ca96cbe6b35e\WEB-INF\lib\library-1.0-18.jar!\META-INF\MANIFEST.MF (The system cannot find the path specified)
I checked that path and it seems even the first URL to the jar (obtained via Version.class.getProtectionDomain().getCodeSource().getLocation() ) was wrong already. It should have been C:\Users\user\Documents\JavaLibs\wildfly-18.0.0.Final\standalone\tmp\vfs\temp\tempfc75b13f07296e98\content-e4d5ca96cbe6b35e\WEB-INF\lib\library-1.0.18.jar.
So this could even point to a problem in Wildfly?
It seems I found some suitable solution here:
https://stackoverflow.com/a/37325538/4222206
So in the end this code can display the correct version of the jar (at least) in JBoss:
this.getClass().getPackage().getImplementationTitle();
this.getClass().getPackage().getImplementationVersion();
Hopefully I will find this answer when I search next time...

Ecplise Java JNI, java.lang.UnsatisfiedLinkError loading dll

I'm having a problem with loading printer dll. I have a dll file from the printer manufacturer (JniPrinterStatusLib.dll). I wrote code like printer manufacturer suggested. The code is:
package com.printer.test
public class JniPrinterStatus {
static{
System.loadLibrary("JniPrinterStatusLib");
}
public native int GetStatus(String printer);
}
package com.printer.test
public class TestSample {
public static void main(String[] args) {
int status;
String printer = "MY PRINTER";
JniPrinterStatus jps = new JniPrinterStatus();
System.out.println("PRINTER NAME = " + printer);
status = jps.GetStatus(printer);
if (status == -1) {
System.out.println("status = -1");
}
else if (status == 0) {
System.out.println("status = NORMAL");
}
else if ((status & 0x00000080) != 0) {
System.out.println("status = PRINTER_STATUS_OFFLINE");
}
else if ((status & 0x00400000) != 0) {
System.out.println("status = PRINTER_STATUS_DOOR_OPEN");
}
else if ((status & 0x00000010) != 0) {
System.out.println("status = PRINTER_STATUS_PAPER_OUT");
}
else if ((status & 0x00000800) != 0) {
System.out.println("status = PRINTER_STATUS_OUTPUT_BIN_FULL");
}
else if ((status & 0x00000040) != 0) {
System.out.println("status = PRINTER_STATUS_PAPER_PROBLEM");
}
}
}
I used Eclipse to run the code, i put the dll library in the folder project and the error is
PRINTER NAME = MY PRINTER
Exception in thread "main" java.lang.UnsatisfiedLinkError: com.printer.test.JniPrinterStatus.GetStatus(Ljava/lang/String;)I
at com.printer.test.JniPrinterStatus.GetStatus(Native Method)
at com.printer.test.TestSample.main(TestSample.java:10)
If i move the source from the package "com.printer.test" to default package the code works and show:
PRINTER NAME = MY PRINTER
status = -1
I don't know how it's possible. If i compile and run the code from command prompt without package it works.
Where is the problem?
Thank you
From the javadoc for class UnsatisfiedLinkError...
Thrown if the Java Virtual Machine cannot find an appropriate
native-language definition of a method declared native.
That means that function Java_com_printer_test_JniPrinterStatus_GetStatus is not found.
Method loadLibrary in class java.lang.System usually searches the directories listed in the [System] property "java.library.path". For Windows machines, the value of this property is generally the value of the PATH environment variable.
So I suggest printing out the value of that property in your code to see whether it includes the directory containing your DLL. If it doesn't then you need to fix that, either by relocating the DLL or changing the PATH environment variable or launching your java program with the -Djava.library.path=... option. After that you need to check the signature of the native method. Dependency Walker is a tool I use at my work to accomplish this.
EDIT
Having re-read your question, I feel I did not accurately address your question, so let me add...
The default behaviour of Eclipse is to copy resource files, like DLLs, to the output folder. So if you put your DLL in folder src\com\printer\test, it will get copie to folder bin\com\printer\test. My guess is that the current, working directory, i.e. . is in your "java.library.path" which is why it works when your java code is in the default package.
Sorry, actually I wanted to write a comment, but as I'm still low on reputation, I have to try and guess an answer.
There should be no need to recompile the dll - it's just some native code to be invoked.
The java package of the class loading the dll should not make a difference, either.
You have to take care about your system architecture: A 64-bit dll file will fail in a 32-bit JRE and vice versa. Make sure, your JRE architecture matches the dll architecture.
Another thing to take into account is your working directory. Eclipse may use a working directory different from what you used when you ran you program from console.
Last but not least, please have a look at your java.library.path variable.
This page might also help: https://www.chilkatsoft.com/java-loadLibrary-Windows.asp
I covers all the details.
The expected package of the Java classes is hard-coded in the JNI library. In your case, it's the default package.
Let me expand on that. When one implements a native method in a JNI library, one has to create a public C function with a name in the following format:
Java_com_mypackage_MyClass_MyMethod
In other words, the JNI library can't provide methods for the classes in arbitrary packages - only for classes in packages that the JNI library authors had in mind.
In your case, it's the default one. The C function goes Java_JniPrinterStatus_GetStatus. If you call your class MyPrinterStatus, or place it into package com.foobar, the JNI run-time won't be able to associate the C function with the declared Java native method. That's just how JNI was designed.

Java OCR program using tesseract in Windows

I just started trying to write a simple java code to do some simple OCR, using the code and advice found here.
I have installed libraries, and the project in the IDE (NetBeans) looks like the picture I have attached.
I'm getting these errors:
10:47:30.099 [main] WARN net.sourceforge.tess4j.util.LoadLibs - Source 'C:\Users\Simon%20Bothner\Documents\NetBeansProjects\OCRTest\build\classes\win32-x86-64' does not exist
java.io.FileNotFoundException: Source
'C:\Users\Simon%20Bothner\Documents\NetBeansProjects\OCRTest\build\classes\win32-x86-64' does not exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:1074)
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:1038)
at net.sourceforge.tess4j.util.LoadLibs.copyResources(LoadLibs.java:138)
at net.sourceforge.tess4j.util.LoadLibs.extractTessResources(LoadLibs.java:105)
at net.sourceforge.tess4j.util.LoadLibs.<clinit>(LoadLibs.java:59)
at net.sourceforge.tess4j.TessAPI.<clinit>(TessAPI.java:42)
at net.sourceforge.tess4j.Tesseract.init(Tesseract.java:367)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:280)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:212)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:196)
at Main.main(Main.java:15)
Exception in thread "main" java.lang.UnsatisfiedLinkError: The specified module could not be found.
at com.sun.jna.Native.open(Native Method)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:263)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:403)
at com.sun.jna.Library$Handler.<init>(Library.java:147)
at com.sun.jna.Native.loadLibrary(Native.java:502)
at com.sun.jna.Native.loadLibrary(Native.java:481)
at net.sourceforge.tess4j.util.LoadLibs.getTessAPIInstance(LoadLibs.java:77)
at net.sourceforge.tess4j.TessAPI.<clinit>(TessAPI.java:42)
at net.sourceforge.tess4j.Tesseract.init(Tesseract.java:367)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:280)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:212)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:196)
at Main.main(Main.java:15)
C:\Users\Simon Bothner\AppData\Local\NetBeans\Cache\8.1\executor-snippets\run.xml:53: Java returned: 1
BUILD FAILED (total time: 0 seconds)
I tried to use this tutorial, but I seemed to be missing a .dll, the liblept168.dll...
Can someone help me with this? I'm quite new at this and can't seem to get this to work...
Thanks a lot! :)
Step 1: http://tphangout.com/how-to-use-the-tesseract-api-to-perform-ocr-in-your-java-code/
Open the link above and see how to install Tesseract in Java properly.
Step 2: After reading it, if you still get the error like "library not open", download Microsoft Visual Studio >12.0, and also update your JDK version (I also get the same error).
Step 3:
public class tesserct
{
public static void main(String[] args)
{
//System.setProperty("jna.library.path", "64".equals(System.getProperty("sun.arch.data.model")) ? "lib/win32-x86" : "lib/win32-x86-64");
System.setProperty("jna.library.path", "32".equals(System.getProperty("sun.arch.data.model")) ? "lib/win32-x86" : "lib/win32-x86-64");
File imageFile = new File("F:\\Wallpaper & photo\\wallpaper\\holi wollpepar\\happy-holi-2013-hd-wallpaper1.jpg");
ITesseract instance = new Tesseract(); // JNA Interface Mapping
// ITesseract instance = new Tesseract1(); // JNA Direct Mapping
File tessDataFolder = LoadLibs.extractTessResources("tessdata"); // Maven build bundles English data
instance.setDatapath(tessDataFolder.getParent());
try {
String result = instance.doOCR(imageFile);
System.out.println(result);
} catch (TesseractException e) {
System.err.println(e.getMessage());
}
}
run the code above on your NetBeans, and try it.

How to use kyotocabinet(JNI) in playframework?

I'm tackling to use kyotocabinet in Playframework.
and following error occurred.
I'm using Eclipse and playframework-1.2.3.
and kyotocabinet is native library so I'm using its Java-Binding.
the reproduce code is simple.
in controller:
public static void somePage() {
DB db = new DB();//error occurred
render();
}
Internal Server Error (500) for request GET /
Execution exception (In /app/controllers/TestApp.java around line 45)
NoClassDefFoundError occured : Could not initialize class kyotocabinet.DB
play.exceptions.JavaExecutionException: Could not initialize class kyotocabinet.DB
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:229)
at Invocation.HTTP Request(Play!)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class kyotocabinet.DB
at controllers.TestApp.somePage(TestApp.java:45)
at play.mvc.ActionInvoker.invokeWithContinuation(ActionInvoker.java:546)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:500)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:476)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:471)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:159)
... 1 more
build in Eclipse was completed but error occured at runtime.
I guess it is because kyotocabinet.dll is missing.(only jkyotocabinet.jar was found)
I configured the location of kyotocabinet.dll to Java Build Path > Source > Native Library Location of my playframework project.
and it was good in other projects.
How to use native library in playframework?
any example or tutorial?
Play.getFile and System.load didn't work.
package controllers;
import play.Play;
import play.jobs.*;
#OnApplicationStart
public class Bootstrap extends Job {
public void doJob() {
String path = "D:/MyProject/lib/jkyotocabinet.dll";
Play.getFile(path);
//System.load(path); if this was enabled, following error occurred: "Native Library D:\MyProject\lib\jkyotocabinet.dll already loaded in another classloader". so I guess the dll was loaded.
System.out.println("bootstrap loaded");//this is displayed.
}
}
UnsatisfiedLinkError occured : no jkyotocabinet in java.library.path
this Japanese blog tells Play!Framework cannot load native library.
http://d.hatena.ne.jp/hjym_u/20110702/1309609277
I already tried these: Absolute path, Relative path, System.load, System.loadLibrary, Play.getFile.
as conclusive approach, I put jkyotocabinet.dll to current directory(D:/MyProejct/), and wrote this code.
public static void somePage(){
File f = Play.getFile("jkyotocabinet.dll");
if(f != null && f.isFile() && f.canRead() && f.canExecute()){//true
DB db = new DB();//error occured. it reached here.
}
render();
}
Execution exception
NoClassDefFoundError occured : Could not initialize class kyotocabinet.DB
Play.getFile found the path "jkyotocabinet.dll" so jkyotocabinet.dll is in current directory so jvm should find it automatically.
anyone can use JNI in playframework?
finally, I could use kyotocabinet as PROD mode but not DEV mode.
Project/conf/application.conf
#application.mode=dev
application.mode=prod
I assume you just need to load the dll into Java via System.load
If you place the ddl on your project, you may load it via Play.getFile inside your #OnApplicationStart controller. This should make it available to your application while the JVM is alive.
EDIT:
#KenichiYamamoto Play.getFile gets files from the application path. You are trying to use a full path in there.
Read this about loading the file in a container. It may be that (due to Play compile-reload system) you are hitting the "already loaded" error. Try to follow the example by adding the System.load inside a static block in your #OnApplicationStart
Do as pere says but use the relative path from your application root. Not the absolute path. I.e. Play.getFile("lib\myfile.dll")

Working with libpath with java reflection

I'm dynamically loading a class and calling a method on it. This class does JNI. When I call the class, java attempts to load the library. This causes an error because the library is not on the libpath. I'm calling from instead a jar so I can't easily change the libpath (especially since the library is not in the same directory or a sub directory of the jar). I do know the path of the library, but how can I load it before I load the class.
Current code:
public Class<?> loadClass(String name) throws ClassNotFoundException {
if(!CLASS_NAME.equals(name))
return super.loadClass(name);
try {
URL myUrl = new URL(classFileUrl);
URLConnection connection = myUrl.openConnection();
InputStream input = connection.getInputStream();
byte[] classData = readConnectionToArray(input);
return defineClass(CLASS_NAME,
classData, 0, classData.length);
} catch (MalformedURLException e) {
throw new UndeclaredThrowableException(e);
} catch (IOException e) {
throw new UndeclaredThrowableException(e);
}
}
Exception:
Can't find library libvcommon.so
java.lang.UnsatisfiedLinkError: vcommon (A file or directory in the path name does not exist.)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:998)
at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:962)
at java.lang.System.loadLibrary(System.java:465)
at vcommon.(vcommon.java:103)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at com.fortune500.fin.v.vunit.reflection.ReflectionvProcessor.calculateV(ReflectionvProcessor.java:36)
at com.fortune500.fin.v.vunit.UTLTestCase.execute(UTLTestCase.java:42)
at com.fortune500.fin.v.vunit.TestSuite.execute(TestSuite.java:15)
at com.fortune500.fin.v.vunit.batch.Testvendor.execute(Testvendor.java:101)
at com.fortune500.fin.v.vunit.batch.Testvendor.main(Testvendor.java:58)
Edit: I'm having a 64bit vs 32bit issue right now. I'll come back to this when I've sorted that out.
Related: Dynamic loading a class in java with a different package name
If you know the path to the library, you could add the path to the java.library.path environment variable in your custom class loader. A simpler approach is to compute the path and use it in your call to Runtime.loadLibrary.
The code below outlines two approaches, using loadLibrary and setting the java.library.path system property.
if(CLASS_NAME.equals(name)) {
// two ways of doing this - either load the library explicitly from the full path
if (useFullPath) {
Runtime.getRuntime().loadLibrary("/full/path/to/mylibrary");
}
else { // or tweaking the library path
System.setProperty("java.library.path",
System.getProperty("java.library.path")
+ System.getProperty("file.separator")
+ "/path/to/lib");
}
}
return super.loadClass(name);
You mention your code is being called from a jar - using a custom class loader is going to be difficult if the ClassLoader is part of the jar as well. Have you verified that your class loader is indeed being used?
A simpler approach is to change the current call to loadLibrary in your native class to use the full path. E.g. fetch from system properties, or compute it, if you know in advance where to find it. This is only an option of course if you have the source to the native class. If you can't modify the native class, then use the loadLibrary call in the classloader.
It's my understanding that calls to load library with the same library name (regardless of path) load the same library. (At least, that's the behaviour on Windows - I haven't verified on Linux.) So, even though the classloader loads the library using the full path, and the native class loads the library using it's simple name, both should resolve to the same library.
(Just for completeness, resolving equivalent libraries happens in the kernel, again, speaking from Win32 experience. Each library internally has a name, and windows only loads one instance of the library with the same internal name per process.)

Categories

Resources