Changes

The normalization steps are skipped if the URI is prefixed with {{Code|java:}}. The path to the standard package {{Code|java.lang.}} can be omitted:

Java constructors, functions and variables can be referenced and evaluated by the existing XQuery function syntax:

* The middle dot character <code>[https://www.fileformat.info/info/unicode/char/b7/index.htm ·]</code> (<code>&amp;#xB7;</code>, a valid character in XQuery names, but not in Java) can be used to append exact Java parameter types to the function name. Class types must be referenced by their full path. Since {{Version|9.6}}, three Three adjacent dots can be used to address an array argument.

| <code>Q{java.lang.Integer}MIN_VALUE()</code>

| <code>Q{java.lang.Object}hash-code($object)</code>

| <code>Q{java.lang.String}split·java.lang.String·intsplit·String·int($string, ';', xs:int(3))</code>

| Function Constructor with array argument| <code>Q{java.lang.String}new·byte...(xs:hexBinary('414243'))</code>

In the following example, Java’s the Java {{Code|Math}} class is referenced. When executed, the query returns the cosine of an angle by calling the static method {{Code|cos()}}, and the value of π by addressing the static variable via {{Code|PI()}}:

With the [[XQuery 3.0#Expanded QNames|Expanded QName]] notation of XQuery 3.0,the namespace can directly be embedded in the function call:

declare namespace fw = "'java:java.io.FileWriter"';

declare namespace br = 'java:java.io.BufferedReader';declare namespace fr = 'java:java.io.FileReader';

A Java classes class can also be instantiated by ''importing'' them as a module: A new instance of the addressed class will be constructed, which can then be referenced in the query body.

By default, Java values with the most common types (as shown in the second and third column of the table) are converted to XQuery values. All other values are returned as ''Java items'', which are function items with an embedded a wrapped Java value. The results of constructor calls are always returned as Java items.

The conversion of the embedded wrapped Java value to XQuery is enforced by invoking the function item: Values in {{Code|Iterator}} and {{Code|Iterable}} instances (Lists, Sets and Collections) are converted to items, and maps are converted to XQuery maps:

If no conversion is defined, a string is returned, resulting from the string representation {{Code|toString()}} method of the Java value is returnedobject. In contrast to other function items, it This method is legal to retrieve also called if the string value representation of a Java itemis requested:

(: returns the string representation representations of the Java object a HashMap and an ArrayList instance :)

The implicit conversion can be further controlled with the {{Option|WRAPJAVA}} option. The following values exist:

| The default: The Java values of the most common types are converted, others are wrapped into Java items.

| The All Java values are converted. If no conversion is enforceddefined, a string is returned, and no Java values will be wrappedresulting from the {{Code|toString()}} method.

| All Java values are wrapped into Java items (excluding those inheriting the internal type {{Code|org.basex.query.value.Value}}) are returned as .|- valign="top"| {{Code|instance}}| If the method of a class instance was called, the Java value is ignored and the instance is wrapped into a Java itemsitem. This Otherwise, the Java value is helpful if returned.|- valign="top"| {{Code|void}}| Java function calls values are chainedignored, and if no intermediate conversion an empty sequence is required or desiredreturned instead.

In the following example, the result of the first function – a char array – is wrapped and passed on to a {{Code|CharBuffer}} function. Without the option, the single-value array would be converted to an {{Code|xs:unsignedShort}} item and the second function call would fail:

Q{java.lang.Character}toChars(xs:int(33))

Without The next example demonstrates a use case for the {{Code|instance}} option: <syntaxhighlight lang="xquery">(: Thanks to the pragma, the singlefunction calls can be chained :) declare namespace set = 'java:java.util.HashSet';let $set := (# db:wrapjava instance #) { set:new() => set:add('1') => set:add('2')}return $set()</syntaxhighlight> The {{Code|void}} option is helpful if side-value array effecting methods return values that do not contribute to the final result: <syntaxhighlight lang="xquery">(: Without the pragma, 100 booleans would be converted returned by the FLWOR expression :) declare namespace set = 'java:java.util.HashSet';let $set := set:new()return ( (# db:wrapjava void #) { for $i in 1 to an 100 return set:add($set, $i) }, $set())</syntaxhighlight> The irrelevant results could also be swallowed with {{CodeFunction|Profiling|xsprof:unsignedShortvoid}} item and the second function call would fail.

* Updated: Java Bindings revised (new mappings, Java functiom items, {{AnchorOption|Data TypesWRAPJAVA}}: {{Code|array(*option)}} type added; {{Code|xs:integer}} are converted to {{Code|long}} values.