RFR: 8181571: printing to CUPS fails on mac sandbox app [v5]

[Phil Race]

On Tue, 24 Aug 2021 15:57:40 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 244:
>> 
>>> 242:         DPRINTF("CUPSfuncs::bad alloc new array\n", "")
>>> 243:         (*env)->ExceptionClear(env);
>>> 244:         JNU_ThrowOutOfMemoryError(env, "OutOfMemoryError");
>> 
>> I find this weird. What is the ExceptionClear for ? The only possible exception here is for
>> an OOME which might be thrown by NewObjectArray. So you clear that and then re-create it ?
>> And who do will catch this ? What's the point ? Maybe just clear and return null.
>
> The array creation error handling is implemented in the similar way as it is done in the getMedia() function.
> The ExceptionClear() has been added to the getMedia() by `8031001: [Parfait] warnings from b121 for jdk/src/solaris/native/sun/awt: JNI-related warnings`
> I would prefer to have unified error handling in these methods. If ExceptionClear is not suitable in this place it would be better to recheck JDK-8031001 and update all places accordingly in a separate fix.

I can't agree with the apparent reasoning that "well that thing over there is wrong, so it's ok for me to add something here that's wrong too".

And the getMedia(..) case is different.  It doesn't re-create the same exception.
It wants to create an OOME which is not actually thrown by GetStringUTFChars() since it needs to throw some exception and with an appropriate string reason.
And the clear there is just prudence since it is creating a new one and can't be 100% sure there isn't one pending.

In your case the JNI spec documents OOME 
https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#newobjectarray

So in your case it is pointless. Please just remote the Clear()

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861