Basically, yes. The code that I showed above is code to wrap a COBOL group in a java.nio.ByteBuffer and, more specifically, a direct byte buffer (dbb.) The direct byte buffer is probably the fastest way to share COBOL data with Java.
You will need SOME C or C++ code to do this. The reason for that is: pretty much the only way to create a direct byte buffer is via JNI. (I think there might also be a private member in java.nio that our Just In Time (JIT) compiler uses to make direct byte buffers.)
Somewhere early in your program you want to INVOKE a native Java method so that it can make up the direct byte buffer for you. After that, you can use INVOKE to call other Java methods and pass in the direct byte buffer.
The native method needs two arguments: the address of the group and the length of the group. The simplest way to set these up is:
1 addressOfMyGroup usage pointer.
1 lengthOfMyGroup pic S9(9) binary.
1 dbbMyGroup Object-Reference.
Procedure Division.
set addressOfMyGroup to address of MyGroup
MOVE LENGTH OF MyGroup To lengthOfMyGroup
INVOKE myClass myNativeMethod Using BY VALUE addresOfMyGroup
BY VALUE lengthOfMyGroup
RETURNING dbbMyGroup
Now you can invoke any Java method with dbbMyGroup. On the Java side, it will be declared as a java.nio.ByteBuffer
The native method should probably be a static method. In the C++ implementation, it should probably be declared
extern "C" jobject Java_blah_myClass_blah_myNativeMethd(jint addressOfMyGroup, jint lengthOfMyGroup);
This is really horrible because we are completely thwarting the type system by telling the compiler that the address is a jint. But it will work. (Until we invent 64-bit COBOL and you migrate to 64-bit COBOL...but that is for another day.) The native method should do a couple of things:
* call the JNI function NewDirectByteBuffer
* return that result to COBOL
* I would also store the result in a static member of myClass
The reason I would store the reference to the direct byte buffer in a static member of myClass is an abundance of caution. When COBOL invokes the native method, the JVM knows you are running JNI code and objects that you create are safe from garbage collection. However, once you return to COBOL, you are now not in Java code (on your thread.) If something else is running on the JVM (say on another thread) the JVM has no way of knowing that you're storing a reference to a direct byte buffer object in a COBOL program. Thus, it could re-claim this object. Storing the reference in a static member of your class (while still in the original native method) will stop any garbage collection of the dbb object. (If you are a really thorough programmer, when you are through using the dbb in any COBOL context , you should set the static member to null.)
(Obviously, you don't need to call a native method directly from COBOL. You can call a Java method that, in turn, calls the native method to do the JNI call to NewDirectByteBuffer. The Java method can then store the reference to a static member.)
When you get to COBOL V6.1, you can call NewDirectByteBuffer directly from COBOL. (Because the JNI copybook is updated.) So, theoretically, you don't need any C. I would still consider a Java native method in that case so that the JVM does not have a chance to garbage collect the result of the NewDirectByteBuffer call.
ahkielstra