<AWT Dev> RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code [v7]

[Phil Race]

On Fri, 18 Dec 2020 21:57:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > There seems to be a pattern where we replace `JNFCallObjectMethod()` with a pair of `CallObjectMethod()` immediately followed by `CHECK_EXCEPTION()`
> > > There are places where currently in this fix, this pattern is missing the `CHECK_EXCEPTION()`
> > > Can we replace `JNFCallObjectMethod()` by a single function call (or macro) that wraps both `CallObjectMethod()` and `CHECK_EXCEPTION()` into one?
> > > This would make this change more robust and make it easier to review it.
> > 
> > 
> > Its is a reasonable idea and I thought about it but on the whole I'd prefer not to do it and insted fix missing cases.
> > Tthere are cases where we are using these macros directly in a native method and then returning to Java.
> > In those case I want to propagate the exception and this suggestion would make that difficult if not impossible.
> 
> I guess it should work already in the JNF case? The java exception should be wrapped by the NSException in the JNFCallObjectMethod/etc and unwrapped in the JNF_COCOA_ENTER before exists to the java method?

That is the pattern I know is there today and I don't think is needed.
It can be done but I don't think it needed. I'd prefer to see if we ever have such a situation and deal with it "locally"
at the call site.

> > So I believe we may end up more (theoretically) robust with my changes than we were before.
> > Perhaps they weren't a result of a JNF* call but still it seems improved.
> 
> I am not sure about that.

I am looking at JNI warnings - not just guessing.

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

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