Could anyone tell me the difference between library and native library in terms of java? I found the word "native library" in the following line:
Type 1 - drivers that implement the
JDBC API as a mapping to another data
access API, such as ODBC. Drivers of
this type are generally dependent on a
native library, which limits their
portability. The JDBC-ODBC Bridge
driver is an example of a Type 1
driver.
which you can found here
"Native Library" generally means a non-Java library that's used by the system (so C/C++, etc). Think normal DLLs or libs.
Java can load these native libraries through JNI.
In the context of Java, a library is one written in Java and available in the form of Java bytecode *.class files, typically compressed into a JAR archive. By contrast, a native library is one that has been compiled to machine code and is typically written in C or C++. Native libraries are *.so, *.dylib, *.dll, *.a, or *.lib files (depending on your platform) that link against the Java Native Interface (JNI) library and expose the functionality from C or C++ to Java through the Java Native Interace mechanism.
A native library is a library that contains "native" code. That is, code that has been compiled for a specific hardware architecture or operating system such as x86 or windows.
Including such native library in your project may break the platform-independence of you application.
In this context, "library" is assumed to refer to a library written in Java (and probably distributed as a jar) whereas "native library" refers to a library written in something like C or OpenForth and compiled down to machine code.
Related
I have some Java-app and a customer with some UWP-app implemented in C#, distributed through the Windows Store etc., who wants to use some pieces of my app. Those pieces are pretty OS-independent, only parsing of some special binary file formats, applying some business logic configured using YAML files and stuff. No network, GUI, only some accesses to files etc.
We currently use IKVM to make the code of interest available to C# but ran into different problems already. Some were supporting .NET Core, some had to do with the native toolchain in Release etc. While right now things seem to work after applying some workarounds, I'm looking for alternatives to IKVM already a bit.
The only thing I currently use of IKVM is simply creating a DLL of my code using ikvmc, which can then be referenced in the UWP-project. The compiler is summarized like the following:
The ikvmc tool converts Java bytecode to .NET dll's and exe's.
That's where the support to create native Windows images of GraalVM came into my mind. Others seem to already build native binaries for Windows and according to the docs, GraalVM is able to create shared libs using "--shared". From my understanding, IKVM implements a JVM in .NET and maps things as needed and possible. That sounds pretty much like what "Substrate VM" does in case of a native image, doesn't it?
This executable includes the application, the libraries, the JDK and
does not run on the Java VM, but includes necessary components like
memory management and thread scheduling from a different virtual
machine, called “Substrate VM”. Substrate VM is the name for the
runtime components (like the deoptimizer, garbage collector, thread
scheduling etc.).
https://www.graalvm.org/docs/reference-manual/native-image/
So, is there any chance that a native image in form of a DLL can replace the DLL created by ikvmc currently? Did anyone try that already and has any experiences? Did anyone try already to create a native DLL and consume that in some other native Windows app? From my understanding UWP "only" applies additional restrictions which one might be able to work around again. Or is this approach totally impossible for some reasons?
Thanks all for your input!
I'm not very familiar with the IKVM project, so this answer is mostly about the generic question:
Can you create a native DLL/shared library and consume that in some other native Windows app?
It should be possible. You can compile Java code into a shared library. The entry points are marked with the #CEntrypoint annotation.
You can then use the generated shared library and the header files to consume your library from a native application.
This way for example GraalVM distributions use the GraalVM JIT compiler by default:
The GraalVM JIT is written in Java
Compiled as a shared library with the native-image
Used in Hotspot.
Here's a page describing how to consume those from Java through the JNI: https://www.graalvm.org/reference-manual/native-image/ImplementingNativeMethodsInJavaWithSVM/
which could be very similar to how would you use a shared library from a C# application.
GraalVM native images are not very flexible, unlike IKVM.NET images. Unless you like writing wrappers and playing with P/Invoke, you should stick to IKVM.NET.
NOTE: I am behind an IKVM.NET fork
I want to know more about libjna-jni and libjna-java libraries. What is the relationship between Java and these libraries?
libjna-jni contains native libraries (os/architecture dependent) for JNA (Java Native Access) library that allows access to native libraries without creating explicit JNI wrapper. libjna-java contains Java part of this library.
My first guess was that a *.so (unix) or *.dll (win) is a shared library. At least that is my usage writing code in C.
Now the context is developing for Android, which is done in Java->Dalvik style.
I have troubles with a perceived ambiguity of the the term shared library there. In java it seems that *.jar files or *.dex files contain the code that is somewhat both, shared and a library.
Is there a reference to tell what is meant by shared library?
A very specific problem is that Android developers aapt packaging thing is having the option --shared-lib
--shared-lib
Make a shared library resource package that can be loaded by an application at runtime to access the libraries resources. Implies
--non-constant-id.
which I have no clue what now is meant by shared library. I am aware that there is this JNI interface and some Android NDK stuff might also have *.so files which might be meant, but I am really not sure.
On Android developers code in Java, the classes he writes are compiled into Java bytecode (bundled in jar along with other classes automatically created during the building process). once created, this bytecode is translated to Dalvik bytecode (.dex) which is included in the application bundle (apk).
In addition to the Java code, application can be programmed using "native libraries" written in C code and compiled with the android-ndk for the device specific architecture, generating .so files (dynamically linked) or .a libraries (linked statically). Normally this is done for performance issues or reusing libraries written in C and avoid porting them to Java. As you said in the question, this binding is done via the JNI library.
These libraries must be included in the application bundle (apk) and loaded at runtime by the application with System.loadLibrary().
I have a device which I want to access from java. The only way to do this is using a dll library provided by the manufacturer. I have read about JNI, JNA etc. and maybe there is a tool outside which analyses the dll and generates the Java classes automatically.
Does anybody know a way of doing this?
You need something like this - JNAerator can "compile" native headers in order to generate JNA mappings, with some limited C++ support.
Finally we used jawin to generate the Java classes for accessing the the .dll. The jawin typebrowser tool was the only one that could handle the C++ .dll we were trying to access.
Unfortunately the jawin project is no longer developed. The last version is dated to early 2005.
Is there a Java library to access the native Windows API? Either with COM or JNI.
You could try these two, I have seen success with both.
http://jawinproject.sourceforge.net
The Java/Win32 integration project
(Jawin) is a free, open source
architecture for interoperation
between Java and components exposed
through Microsoft's Component Object
Model (COM) or through Win32 Dynamic
Link Libraries (DLLs).
https://github.com/twall/jna/
JNA provides Java programs easy access
to native shared libraries (DLLs on
Windows) without writing anything but
Java code—no JNI or native code is
required. This functionality is
comparable to Windows' Platform/Invoke
and Python's ctypes. Access is dynamic
at runtime without code generation.
JNA allows you to call directly into
native functions using natural Java
method invocation. The Java call looks
just like it does in native code. Most
calls require no special handling or
configuration; no boilerplate or
generated code is required.
Also read up here:
http://en.wikipedia.org/wiki/Java_Native_Interface
The Java Native Interface (JNI) is a
programming framework that allows Java
code running in a Java Virtual Machine
(JVM) to call and to be called1 by
native applications (programs specific
to a hardware and operating system
platform) and libraries written in
other languages, such as C, C++ and
assembly.
http://en.wikipedia.org/wiki/Java_Native_Access
Java Native Access provides Java
programs easy access to native shared
libraries without using the Java
Native Interface. JNA's design aims to
provide native access in a natural way
with a minimum of effort. No
boilerplate or generated glue code is
required.
JNA is pretty nice. I'm just a beginner and I found it very easy. Works not only for the Win32 API but for almost any other DLL.
Jacob is quite good on the COM side (but it's real COM - like you write in C++ - if you are familiar with true COM programming, then Jacob is a snap to use)
JNIWrapper or ConfyJ from from TeamDev.
One more option is WinRun4J. It has a native binding layer that aims to be compatible with pinvoke.net (the native binding format used in dot net). See examples for more information. Its a little early days so YMMV.
(full disclosure: i work on the project).
Yet another option is JFFI - this is used in jruby and jython to interact with native libraries.
Check out Waffle