Resolution:
The main difference between tibrvj.jar and tibrvnative.jar  is the thickness of the Java layer. They both use the RV C libraries but the message data is marshaled in Java when using tibrvj.jar and in C when using tibrvnative.jar.

In the native (JNI tibrvnative.jar) preferred implementations, messages occupy storage outside of the Java environment, that is, in the native C environment and also within the Java environment. When the Java garbage collector recycles the Java message object, the action triggers release of the corresponding native storage as well. However the timing of garbage collection is unpredictable, delaying the release of native storage as well. In applications where efficient management of native storage is a critical performance factor, you can use this method to explicitly free the native storage.

You can call the msg.dispose() method at the end of a message callback method to immediately free the native storage associated with the message. The Java message object is independent of the native storage and independent of this method. It remains intact until the Java garbage collector recycles it in the usual way. If you call msg.dispose() with tibrvj.jar, this method is available in the JNI compatibility implementation but it has "no-operation”. If you are running BW, refer to BW-16450 and BW-16451.

When testing an RV Java application, the memory foot print is usually greater with tibrvnative.jar than with tibrvj.jar .