Qore jni Module
1.0.1
|
The jni
module allows for Java APIs to be used in Qore as if the Java APIs were Qore APIs. The module provides a high-level binding and mapping of Java functionality in Qore as well as run-time data translations back and forth between Java and Qore data.
This module is released under the MIT license (see COPYING.MIT
in the source distribution for more information). The module is tagged as such in the module's header (meaning it can be loaded unconditionally regardless of how the Qore library was initialized).
To use the module in a Qore script, use the %requires
directive as follows:
Helper Qore classes provided by this module:
Class | Description |
JavaArray | a convenience class for using Java Arrays in Qore |
QoreInvocationHandler | a convenience class for executing Qore-language callbacks from Java |
Helper Qore functions provided by this module:
Function | Description |
get_version() | Returns the version of the JNI API |
implement_interface() | Creates a Java object that implements given interface using an invocation handler |
invoke() | Invokes a method with the given arguments |
invoke_nonvirtual() | Invokes a method with the given arguments in a non-virtual way; meaning that even if the object provided is a child class, the method given in the first argument is executed |
load_class() | Loads a Java class with given name and returns a java::lang::Class object |
new_array() | Creates a JavaArray object of the given type and size |
The JVM is initialized when the module is loaded. It is possible to disable JIT when the module is loaded, however the module is loaded an initialized before module parse commands are processed, therefore to tell the module to disable JIT, the following environment variable must be set to 1
:
QORE_JNI_DISABLE_JIT=1
To import Java APIs into the Qore program; any of the following jni-module-specific parse directives can be used, each of which also causes the jni module to be loaded and initialized:
All classes in java.lang
.* are imported implicitly. Referencing an imported class in Qore code causes a Qore class to be generated dynamically that presents the Java class. Instantiating a Qore class based on a Java class also instantiates an internal Java object that is attached to the Qore object. Calling methods on the object will cause the same Java methods to be called with any arguments provided.
The jni module also supports defining classes at parse time with the following jni-module-specific parse directives:
<name>
as the Java internal name for the class (ex: my/package/MyClassName
)define-class
directive; this should be used for inner classes and has been implemented to allow circular dependencies in such classes to be resolved; <name>
is the Java internal name for the inner class (ex: my/package/MyClassName$1
)The jni module also supports setting Java system properties at parse time with the following jni-module-specific parse directive:
This module supports the following compatibility option: "compat-types"
which, when enabled, will disable the following type conversions:
byte
[] to binary
; instead this will converted to list<int>
java.util.Map
to hash
; instead this will be converted directlyThis option can be set globally for all Program objects with set_module_option("jni", "compat-type", True)
or locally for the current Program container with the set-compat-type
module parse option like: module-cmd(jni) set-compat-type true
or module-cmd(jni) set-compat-type false
to override the global setting.
The jni
module uses reflection to automatically map Java classes to Qore classes. This class mapping and Qore class creation happens at parse time (when importing Java APIs into Qore) and also at runtime (if a new class is encountered that has not already been mapped).
There are two types of conversions:
java.lang.Object
The following table describes type conversions for Java types when the jni
module must convert a Qore value to the declared type:
Qore to Specific Java Type Conversions
Target Java Type | Source Qore Type |
boolean | any; conversions are made like with boolean() |
byte | any; conversions are made like with int() |
char | any; conversions are made like with int() |
short | any; conversions are made like with int() |
int | any; conversions are made like with int() |
long | any; conversions are made like with int() |
float | any; conversions are made like with float() |
double | any; conversions are made like with float() |
For other types, default conversions are used.
The following table describes type conversions for Java types when the jni
module must convert a Qore value to the declared type:
Qore to Java Default Type Conversions
Source Qore Type | Target Java Type |
bool | boolean |
int | int (note: precision is lost here) |
float | double |
string | java.lang.String |
date | java.time.ZonedDateTime or org.qore.jni.QoreRelativeTime |
number | java.math.BigDecimal |
binary | byte [] |
NOTHING and NULL | void |
list | java Arrays of the list type; if no list type can be found, then the Array type is java.lang.Object |
hash | java.util.LinkedHashMap , however any type implementing java.util.Map that has a constructor that takes no arguments and a compatibule put() method will be constructed / converted automatically to the desired type |
JavaArray | java.lang.Array |
object | to the Java class if the Qore object is an instantiation of java.lang.Object , otherwise org.qore.jni.QoreObject |
all jni objects | direct conversion |
long
value; use:Java to Qore Type Conversions
Source Java Type | Target Qore Type |
boolean | bool |
byte | int |
byte [] | binary (see also JNI Module Compatibility Options) |
char | int |
short | int |
int | int |
long | int |
float | float |
double | double |
java.lang.String | string |
java.time.ZonedDateTime | date (absolute date) |
org.qore.jni.QoreRelativeTime | date (relative date) |
java.math.BigDecimal | number |
java.lang.AbstractArray and arrays | list |
java.util.Map | hash (see also JNI Module Compatibility Options) |
org.qore.jni.QoreClosureMarker | code |
all other objects | direct conversion |
Arrays are mapped directly to and from Qore lists. When converting from a Qore list to a Java array, the list is scanned, and if it can be mapped to a single Java type, then an array of that type is created. Otherwise, an array of java.lang.Object
is created and the Qore values are mapped directly to Java values.
Qore lists are passed by value and Java arrays are objects (which, like Qore objects, are passed with a copy of a reference to the object). To get similar functionality in Qore, you can use the JavaArray class supplied with the jni
module, which is automatically converted to a Java array object like a list, but is also passed with a copy of a reference to the object in Qore.
When a Java method declares variable arguments, such arguments must be generally given as a single array value (so a Qore list or JavaArray object). Consider the following example:
In the above example, the java.lang.Class.getMethod()
and the java.lang.Method.invoke()
methods both take a variable number of arguments after the first argument. In the mapped Qore class, these must be given as a Qore list (as in the above example) or a JavaArray object.
If the last argument of a Java method has an array type, then the arguments in Qore can also be given in the flat argument list, and the final array argument will be created automatically for the call.
Because of this, the example above also works as follows:
The jni
module maps Java packages to Qore namespaces. Therefore in Java java.lang.String
can be referred to as java::lang::String
in Qore as in the following example:
The jni
module attempts to create Qore classes that match the source Java class as closely as possible to maximize the usefulness of Java APIs in Qore.
When creating Qore class methods from the corresponding Java source method, types are mapped according to Java to Qore Type Conversions. Because Qore has fewer types than Java, this can lead to method signature collissions in the generated Qore class.
In such cases, only the first method returned by the internal call to java.lang.Class.getDeclaredMethods()
is mapped.
To call an unmapped method, use reflection to get a java.lang.Method
object and make the call using java.lang.Method.invoke()
as in the folllowing example:
Java inner classes are mapped as Qore classes by appending "__"
to the outer class's name and then appending the name of the inner class.
For example:
The inner class would be created as "Outer__Inner"
in Qore.
When subclassing Java classes in Qore, the Qore class code is not executed by Java when dispatching method calls in Java itself. This means that overriding Java methods in Qore is only valid for code executed from Qore.
To override a Java method when called from Java, you must subclass the class in Java as well and import the child class into your Qore program.
One exception to this limitation is with interfaces; programmers can use the QoreInvocationHandler class to execute Qore-language callbacks based on Java interfaces; see the documentation for QoreInvocationHandler for more information.
Java fields are mapped to different Qore class members according to the Java type according to the following table.
Java Field to Qore Class Member Mappings
Java | Qore | Qore Example |
static | Qore class constants | MyClass::myField |
static (non-final) | Qore static class members | obj.myField |
all others | normal Qore class members | obj.myField |
For example:
memberGate()
method; updating a Java object's field value in Qore will not cause the field value to be updated in Java. To update the field's value in Java, use java::lang::reflect::Field::set()
.Java access modifiers are mapped directly to Qore access modifiers as in the following table.
Java to Qore Access Mappings
Java | Qore |
public | public |
protected | private (or private:hierarchy) |
private | private:internal |
There is a global classloader for all Java objects reachable without special classpath. For all other objects, each Qore Program container has its own custom classloader provided by the jni
module that supports a dynamic classpath.
The Qore Program-specific dynamic classpath can be set with the import
commands as documented in Importing Java APIs.
Explicit class loaders can also be used as in Java as in the following example:
If a org.qore.jni.QoreException exception is thrown, then it is mapped directly to a Qore exception.
Other Java exceptions are mapped to the Qore ExceptionInfo hash as follows:
err:
always "JNI-ERROR"
desc:
the full Java class name of the exception class; ex: "java.lang.RuntimeException"
arg:
the exception object itself as a Qore object wrappingg the Java objectException locations including call stack locations reflect the actual Java source location(s), and in such cases the lang
attribute will be "Java"
.
Java code can use the jni module and Java classes based on Qore code by calling org.qore.jni.QoreJavaApi.initQore() to initialize the Qore library and the jni module with an existing JVM session. This requires the platform-dependent qore
library to be found in a directory set in the java.library.path
or by setting the QORE_LIBRARY
environment variable to the absolute path of the qore
library.
If neither of these are set, then calling org.qore.jni.QoreJavaApi.initQore() will result in a java.lang.UnsatisfiedLinkError
exception being raised.
All Java classes for Qore support are located in the qore-jni.jar
file.
Example Java source:
Example compilation command:
javac -cp qore-jni.jar MyTest.java
Example run command:
java -Djava.library.path=/usr/local/lib -cp qore-jni.jar:. MyTest
QORE_JNI_DISABLE_JIT=1
environment variable (issue 3199)set-property
module command to allow for Java system properties to be set while initializing the module (issue 3495)