Java native methods and threads considerations

You can use native methods to access functions that are not available in Java™. To better use Java with native methods, you need to understand these concepts.

• A Java thread, whether created by Java or an attached native thread, has all floating point exceptions disabled. If the thread runs a native method that reenables floating point exceptions, Java does not turn them off a second time. If the user application does not disable them before returning to run Java code, then the Java code may not behave correctly if a floating point exception occurs. When a native thread detaches from the Java virtual machine, its floating point exception mask is restored to the value that was in effect when it was attached.
• When a native thread attaches to the Java virtual machine, the Java virtual machine changes the threads priority, if necessary, to conform to the one to ten priority schemes that Java defines. When the thread detaches, the priority is restored. After attaching, the thread can change the thread priority by using a native method interface (for example, a POSIX API). Java does not change the thread priority on transitions back to the Java virtual machine.
• The Invocation API component of the Java Native Interface (JNI) permits a user to embed a Java virtual machine within their application. If an application creates a Java virtual machine and the Java virtual machine ends abnormally, the MCH74A5 "Java Virtual Machine Terminated" iSeries™ exception is signalled to the initial thread of the process if that thread was attached to the Java virtual machine when the Java virtual machine ended. The Java virtual machine could end abnormally for any of these reasons:
  • The user calls the java.lang.System.exit() method.
  • A thread that the Java virtual machine requires ends.
  • An internal error occurs in the Java virtual machine.
  This behavior differs from most other Java platforms. On most other platforms, the process that automatically creates the Java virtual machine ends abruptly as soon as the Java virtual machine ends. If the application monitors and handles a signalled MCH74A5 exception, it may continue to run. Otherwise, the process ends when the exception goes unhandled. By adding the code that deals with the iSeries server-specific MCH74A5 exception, you can make the application less portable to other platforms.

Because native methods always run in a multithreaded process, the code that they contain must be thread safe. This places these restrictions on the languages and functions that are used for native methods:

• You should not use ILE CL for native methods, because this language is not thread safe. To run thread safe CL commands, you can use the C language system() function or the java.lang.Runtime.exec() method.
  • Use the C language system() function to run thread safe CL commands from within a C or C++ native method.
  • Use the java.lang.Runtime.exec() method to run thread safe CL commands directly from Java.
• You can use ILE C, ILE C++, ILE COBOL, and ILE RPG to write a native method, but all of the functions that are called from within the native method must be thread safe.

  Note: Compile-time support for writing native methods is currently only supplied for the C, C++, and RPG languages. While possible, writing native methods in other languages may be much more complicated.

  Caution: Not all standard C, C++, COBOL, or RPG functions are thread safe.

• The C and C++ exit() and abort() functions should never be used within a native method. These functions cause the entire process that runs the Java virtual machine to stop. This includes all of the threads in the process, regardless of if they were originated by Java or not.
  Note: The exit() function referred to is the C and C++ function, and is not the same as the java.lang.Runtime.exit() method.

For more information about threads on the iSeries server, see Multithreaded applications.