I would like to know if there is any alternative to load a library more than System.LoadLibrary or System.load.
Due to the circustances I cant use them. Is there anyway in Java to specify the address where the dll has to be loaded?
thanks!
Related
I am developing an app on Android using JNI.
My native code mylib.so depends on a.so.
When I use System.loadlibrary() I want to know do I need to load a.so too?
Thanks.
YL
I think this example on github that I had written way back for loading static linked library and its dependencies will give you some more idea. In general, you only have to specify the main lib [in my case it was curl lib] and the System.loadlibrary will take care of loading dependencies.
I wonder how java.* libraries implement the java native interface?
To be more specific I am investigating the java.awt.Robot and come across native method calls. As I am in windows - does that mean there is a .cpp file laying around somewhere (inside the java.awt.* package?) - that the java.awt.Robot uses?
Whenever you call native code, you have to go via JNI. Typically, you need to build shared library. Calling schema follows (note that you don't call C file - it's just visualization of which method will be called):
So, in a sense, there is a file that contains source code of the library that you call.
In case of Windows, shared libraries are DLL files in case of Linux they are typically so files and in macOS dylib. If you want to make them "visible" to your Java code, you have few options here. You can put location (directory where library is) in:
PATH (windows)
LD_LIBRARY_PATH (macOS/Linux)
-Djava.library.path - work for all systems, it's just a jvm's argument.
I have two dlls, C:\foo\x.dll and C:\bar\y.dll, where x.dll depends on y.dll (i.e. the implementation of functions in x will call functions in y).
In a Java application, when I load x.dll using JNA what do I need to set up to ensure that I don't get a UnsatisfiedLinkException?
I'm currently setting up jna.library.path to C:\foo, but it seems that it is not enough. Including both C:\foo and C:\bar in java.library.path also doesn't help.
You can usually call System.load("/name.dll") with the path to your dependent library prior to making the JNA call to load the primary.
System.loadLibrary("name") will work if the library is on java.library.path and conforms to expected naming conventions.
I was wondering if there is a Java method for injecting code into a process during runtime.
The key term; in Java. I have found alot of references to this (the most useful being at this website). The problem is that that all the references I've found do not use Java, and hence are unfavorable for my current situation.
Could anyone help me out, and perhaps point me in the right direction?
You can use Java Native Interface to bind CreateRemoteThread() API to Java.
The closest I know of is System.loadLibrary. That method will load a library by name in a system dependent way.
One way would be to load the non java library you found using Java Native Access. I don't really see a way you will be able to do this without calling native code so unless a some other java developer has already created a JNI or JNA wrapper you will probably have to do it yourself.
I'm attempting to use the CreateObject function within ColdFusion to access functionality within a DLL through JNI. I've managed to get ColdFusion to load the DLL OK using the java.lang.System.load function, but am not sure how to then access the functions contained within this method.
My current code:
<cfset CreateObject("java","java.lang.System").load("C://Path//To//JniDll.dll")>
<cfset JniObject = CreateObject("java","Organisation.product.package")>
Which fails on line 2 with the error
Object Instantiation Exception.
Class not found Organisation.product.package
It's possible I'm accessing these methods incorrectly, but haven't been able to find any information about using JNI in ColdFusion on the web.
Thanks for your help,
Tom
You won't get access to the methods in that DLL just by registering it AFAIK. Either you get supplied a Java wrapper (probably as a JAR) which will then use the DLL, or you have to see what COM interfaces the DLL exposes and call them via createobject(type="COM"), as others have suggested.
From the looks of your code and error, you're expecting a Java class Organisation.product.package to be present and CF can't see it, so I'd take a look in the CF administrator and see which paths are in your classpath. Drop the JAR I assume you have into CF's lib folder and restart CF and see if that makes a difference.
I would suggest you make it work in java first. After that you place the generated jar file in the correct coldfusion lib directory and load (the java class) using CreateObject. The java class should be responsible for the dll binding.