Calling static Java methods from COBOL

In the same way that Java™ applications can make calls to COBOL and have the arguments be automatically converted between Java and COBOL data formats, COBOL can make calls to Java and have the same automatic conversions performed. Only calls to static Java methods are supported.

You can make a call to Java using a CALL statement. The call target should be a literal in the following form:

'Java.java-class-name.java-static-method-name'

where java-class-name is a Java class name that is fully-qualified with its package name if it is part of a package, and where java-static-method-name is the name of the static method being called.

If the method is part of a group of nested classes, each nested class name must be introduced with a $ character in the literal.

For example, to call a method myMethod() that exists in nested class Util in outer class TestApp as part of package com.acme, use the following CALL statement:

CALL 'Java.com.acme.TestApp$Util.myMethod' USING ...

Note: The 'Java.' prefix of the literal is not case-sensitive, that is, 'JAVA.' and 'jAvA.' would both be accepted, but the remaining portion of the literal is case-sensitive and must match the names as they are declared in Java.

Example

The following example consists of Java class TestApp with static method MyMethod having the indicated signature:


identification division.
program-id. COBPROG.
data division.
:
package com.acme;
import java.math.*;

public class TestApp
{
  public static void myMethod(float f1, long l1, BigDecimal[] bdarr) {
    :
  }
}

The method can be called from COBOL as follows:


working-storage section.
01 f1 comp-1.
01 l1 pic s9(18) comp-5.
01 bdarr.
   03 pd pic s9(9)v9(2) comp-3 occurs 3 times.
Procedure division.
:
CALL 'Java.come.acme.TestApp.myMethod' USING f1 l1 bdarr

To build the DLL for this COBOL application that calls Java, if the stub files generated by the compiler are located in the current directory which does not contain stub files for any other application(s), and you accept the current directory for all the output paths for cjbuild (which is the default and which we do here for simplicity but is not recommended in production), then cjbuild can be invoked as follows:

cjbuild -v app1

which tells cjbuild to include all the stub files in the current directory into the DLL it builds. The string "app1" is used to construct the name of the resulting DLL. For a DLL written to a z/OS UNIX path, the DLL will be called libapp1.so. If the DLL is output to an MVS data set, the DLL will appear as a member in that data set with the name LIBAPP1. See the -d option of cjbuild utility for details. End of change

Alternatively, if you are mixing stub files for multiple interoperable applications in the same directory you can create a file in your current z/OS UNIX directory called "programs" that contains the name COBPROG, which is the only program that is part of this current application, and then you can invoke cjbuild as follows:

cjbuild -v programs app1

As a further alternative, if you are mixing stub files for multiple interoperable applications in the same directory, you can use the -i/--progid option of cjbuild to indicate that COBPROG is the only COBOL program in the current application, and then you can invoke cjbuild as:

cjbuild -v -i COBPROG app1

Start of change Programming tip: Using a program file or specifying one or more -i\--progid options is supported so that if you want to place the stub files for all your COBOL programs in a single z/OS UNIX directory, you can specify which subset of them you care about for a particular interoperable application you are building. However, if you use one directory of stub files per interoperable application, which is one possible approach to organizing your code, then you can simply omit those options and arguments, and cjbuild will process all stub files in the artifact directory as indicated by the -c/--coboldir option, and this can simplify your build process and is recommended. End of change