RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module

[Gerard Ziemski]

On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race <prr at openjdk.org> wrote:

> This completes the desktop module JNF removal
> 
> * remove  -framework JavaNativeFoundation from make files
> 
> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
> 
> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
> 
> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
> 
> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
> 
> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
> 
> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
> 
> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
> 
> * Remove the single usage of JNFPerformEnvBlock
> 
> * replace JNFJavaToNSNumber in single A11Y file with local replacement
> 
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
> 
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
> 
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

Changes requested by gziemski (Committer).

src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 608:

> 606:     {
> 607:         // Get string to draw and the length
> 608:         const jchar *unichars = JNFGetStringUTF16UniChars(env, str);

According to `JNFString.h`, the `JNFGetStringUTF16UniChars()` API:

/*
 * Gets UTF16 unichars from a Java string, and checks for errors and raises a JNFException if
 * the unichars cannot be obtained from Java.
 */

raises a (JNFException) if it can't get the chars, but now we simply return if `GetStringChars()` can not return the chars.

Seems like we handle this case differently in the new code now - is this change desired and correct?

src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 601:

> 599:         jchar unichars[len];
> 600:         (*env)->GetStringRegion(env, str, 0, len, unichars);
> 601:         CHECK_EXCEPTION();

Are `JNF_CHECK_AND_RETHROW_EXCEPTION` and `CHECK_EXCEPTION` equivalent?

`JNF_CHECK_AND_RETHROW_EXCEPTION` seems to throw exception, but `CHECK_EXCEPTION` does not?

src/java.desktop/macosx/native/libosxui/ScreenMenu.m line 165:

> 163:  */
> 164: static jlong NSTimeIntervalToJavaMilliseconds(NSTimeInterval interval) {
> 165:     NSTimeInterval interval1970 = interval + NSTimeIntervalSince1970;

Is it required for the APIs using the value from this function to expect the time calculated since Jan 1st 1970?

src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83:

> 81:                   stringWithFileSystemRepresentation:chs length:len];
> 82:     return result;
> 83: }

Why are we doing:

`java_string -> chars -> NSString -> chars -> [NSFileManager stringWithFileSystemRepresentation]`

?

Why not just get the raw characters form JNI and feed them directly into `[NSFileManager  stringWithFileSystemRepresentation]`, ie:

`java_string -> chars -> [NSFileManager stringWithFileSystemRepresentation]`

and skip the `JavaStringToNSString` step altogether?

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

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