Array update semantics and restrictions in Java-interoperable applications
In Java™, arrays are always considered objects, even
when they are arrays of Java primitive types (such as
short[], int[], long[]), so when arrays are
passed between Java methods, changes made by a called method
are always reflected in the caller method, which is the normal behavior in Java for all object arguments.
for arrays of primitive types
. For example, if a Java method passes an array of a Java primitive type to COBOL and COBOL updates the COBOL table that receives the data, those changes are
always reflected back to the Java caller. Similarly, when
COBOL calls Java and passes a table of data that is received
in the called Java method as an array object, changes to the
array data made in Java will be reflected in the COBOL table
when the Java method returns.For performance
reasons, when COBOL receives an array of java.lang.String objects or an array of
java.math.BigDecimal objects from Java, any changes to that data in COBOL will not be reflected on the Java side of the application. Similarly, when COBOL passes a table of PIC X/N/U items to Java, any changes to that data in Java is not reflected on the COBOL side of the application.Array restrictions
At present, only fixed-length tables in COBOL can receive Java arrays (no ODO tables), and the number of elements in the incoming Java array and the number of elements in the COBOL table as indicated in its
OCCURS clause must match exactly. Otherwise, a Java exception of class java.lang.IllegalArgumentException is thrown. This exception can be caught in Java code with try/catch and can be caught by a COBOL program calling a static Java method using the ON EXCEPTION phrase of the CALL statement.
because a mismatch in the number of elements of array arguments is not possible. For an array returned from Java to COBOL, however, the length must still match exactly or an exception will be thrown.