Start of change

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.

This behavior is preserved in the Enterprise COBOL Java interoperability model Start of changefor arrays of primitive typesEnd of change. For example, if a Java method passes an array Start of changeof a Java primitive typeEnd of change 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.
Note: Start of changeFor 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.End of change

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. Start of changeOtherwise, 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.End of change

Note: In Java, array parameters of a method are always dynamic and can receive an incoming array of any length. Therefore, calls from COBOL to static Java methods are more flexible Start of changebecause 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 thrownEnd of change.
End of change