The C module must be able to be fetched so the HLL pre-initialization can load it. For more information, see the z/OS Language Environment Programming Reference and XL C/C++ Language Reference.
The code in Figure 4 creates the JVM. The value in the pathStr variable is the classpath for the jar file containing the Java code. You must use your own directory. The value in the cmd1Str variable contains options useful in problem determination. Because the C code is running on the native MVS side of z/OS, the literal values must be translated to ASCII by the __etoa function calls.
Once the JVM is successfully created, you get a handle to the Java class that contains the methods you want to invoke (see Figure 5). The class name must be translated. The JNI calls are fully described on the Java Website.
You get handles to the Java methods once the Java class has been found, as shown in Figure 5. The method signature is the input to the method and what it returns. You use the javap program to get method signatures; this is described later. You can learn more at http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javap.html.
The code in Figure 5 shows how the input to the Java method is created and how the method is called. The call into NewStringUTF creates a Java string object using UTF-8 encoding. The call into CallStaticObjectMethod invokes the Java method, test, identified by the variable workMethod. The call into ExceptionCheck tests to see if an exception occurred in the Java method. The call into GetStringUTFChars returns the string in UTF-8 encoding. The call into ReleaseStringUTFChars tells the JVM the string is no longer needed.
The Java Code
This is a simple class that exposes a few methods that the C module invokes. Note the static keyword on the method declarations. The C module uses the static versions of the JNI calls. There’s nothing more in the Java code that needs to be called out.
Java Class File Disassembler