RFR: Checking for JNI Exceptions in jni_util.c
Please review these cleanups to check for JNI pending exceptions in jni_util.c. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ Thanks, Roger
Looks good to me Roger. -Chris. On 02/04/2014 02:33 PM, roger riggs wrote:
Please review these cleanups to check for JNI pending exceptions in jni_util.c.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/
Thanks, Roger
On 04/02/2014 14:33, roger riggs wrote:
Please review these cleanups to check for JNI pending exceptions in jni_util.c.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ This mostly looks okay, I just wonder about the jclass declarations at L686 and 690 as I assume these are declaration-after-use warnings with some compilers.
Also there is JNU_ClassString use at L760 that I assume should be replaced with strClazz. -Alan.
Hi Alan, Thanks for the review and suggestions; the webrev has been updated with the recommendations. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ Thanks, Roger On 2/4/2014 10:12 AM, Alan Bateman wrote:
On 04/02/2014 14:33, roger riggs wrote:
Please review these cleanups to check for JNI pending exceptions in jni_util.c.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ This mostly looks okay, I just wonder about the jclass declarations at L686 and 690 as I assume these are declaration-after-use warnings with some compilers.
Also there is JNU_ClassString use at L760 that I assume should be replaced with strClazz.
-Alan.
On 04/02/2014 18:11, roger riggs wrote:
Hi Alan,
Thanks for the review and suggestions; the webrev has been updated with the recommendations.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ The updated webrev looks okay. I note in the JNU_ClassXXX functions that the return from NewGlobalRef is not checked but I believe it's safe to call DeleteLocalRef even if there is a pending exception.
One minor comment is that in initializeEncoding it now assumes that the reference returned by JNU_ClassString is a global ref (because it obtains the reference before expanding the space for local refs). An alternative (which might be clearer for future readers) is to do the EnsureLocalCapacity first. -Alan
Hi, Updated the webrev with the recommendations. On 2/4/2014 3:36 PM, Alan Bateman wrote:
On 04/02/2014 18:11, roger riggs wrote:
Hi Alan,
Thanks for the review and suggestions; the webrev has been updated with the recommendations.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ The updated webrev looks okay. I note in the JNU_ClassXXX functions that the return from NewGlobalRef is not checked but I believe it's safe to call DeleteLocalRef even if there is a pending exception.
One minor comment is that in initializeEncoding it now assumes that the reference returned by JNU_ClassString is a global ref (because it obtains the reference before expanding the space for local refs). An alternative (which might be clearer for future readers) is to do the EnsureLocalCapacity first. Corrected; but I note in reading the jni specification for EnsureLocalCapacity that the VM ensures that there is capacity for 16 local references before calling the native method so checking for smaller numbers is a noop.
Roger
-Alan
On 04/02/2014 21:05, roger riggs wrote:
Corrected; but I note in reading the jni specification for EnsureLocalCapacity that the VM ensures that there is capacity for 16 local references before calling the native method so checking for smaller numbers is a noop. Yes, and my comment was just to point out that it just looked a bit odd to get a reference before EnsureLocalCapacity.
I've looked through the latest webrev and it looks good to me. -Alan.
participants (3)
-
Alan Bateman
-
Chris Hegarty
-
roger riggs