Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6364623

JNI specification may need to be corrected.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 6
    • Fix Version/s: 6
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      The JNI spec. seems to be inaccuratate and is leading to some confusion in the field.
      JNI spec.....
      http://java.sun.com/j2se/1.3/docs/guide/jni/spec/design.doc.html#770
      "Exception Handling
      There are two ways to handle an exception in native code:

          * The native method can choose to return immediately, causing the exception to be thrown in the Java code that initiated the native method call.
          * The native code can clear the exception by calling ExceptionClear(), and then execute its own exception-handling code.

      After an exception has been raised, the native code must first clear the exception before making other JNI calls. When there is a pending exception, the only JNI functions that are safe to call are ExceptionOccurred(), ExceptionDescribe(), and ExceptionClear(). The ExceptionDescribe() function prints a debugging message about the pending exception."

      There has been discussions about this matter, and depends on the VM implementation, but we
      should follow the JNI spec.
      *** (#3 of 5): 2005-12-14 15:26:07 PST ###@###.###

      Please see http://java.sun.com/docs/books/jni/html/design.html#2193. The spec quoted in the previous evaluation comment is incorrect and should be fixed. The attached files Test7.java and Test7.c illustrate why. For example, in Test7.c

              for (i = 0; i < n; ++i) {
                      (*env)->CallVoidMethod(env, obj, jm, s, i);
                      if ((*env)->ExceptionCheck(env)) {
                          (*env)->MonitorExit(env, jc);
                          return;
                      }
              }

      failing to call MonitorExit in the exception case hangs the application; the second thread in Test7.java never gets to run. However, including the MonitorExit call thwarts the exception handler of the first thread in Test7.java.
      *** (#4 of 5): 2005-12-14 17:08:01 PST ###@###.###

      See test case Test7.* in CR: 6361259

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              ksrini Kumar Srinivasan
              Reporter:
              ksrini Kumar Srinivasan
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: