Re: RFR: 8260462: Missing in Modality.html
On Fri, 29 Jan 2021 13:36:40 GMT, Alexey Ivanov wrote: > The first row in The Standard Blocking Matrix table in The AWT Modality > (`Modality.html`) is a header row and it should be inside `` element. Marked as reviewed by psadhukhan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2314
Re: RFR: 8197825: [Test] Intermittent timeout with javax/swing JColorChooser Test [v4]
On Fri, 29 Jan 2021 23:46:14 GMT, Sergey Bylokhov wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h line 478: >> >>> 476: BOOL m_breakOnError; >>> 477: >>> 478: volatile BOOL m_breakMessageLoop; >> >> Does this volatile modifier resolve the now-removed infinite loop in `while >> (!tk.IsDisposed())` in `WToolkit_shutdown`? > >> Does this volatile modifier resolve the now-removed infinite loop in `while >> (!tk.IsDisposed())` in `WToolkit_shutdown`? > > The loop should not be removed. Unfortunately, volatile modifier has no effect if infinite loop is reinstated.. - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermittent timeout with javax/swing JColorChooser Test [v4]
On Fri, 29 Jan 2021 20:19:43 GMT, Alexey Ivanov wrote: > Does this volatile modifier resolve the now-removed infinite loop in `while > (!tk.IsDisposed())` in `WToolkit_shutdown`? The loop should not be removed. - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8260462: Missing in Modality.html
On Fri, 29 Jan 2021 13:36:40 GMT, Alexey Ivanov wrote: > The first row in The Standard Blocking Matrix table in The AWT Modality > (`Modality.html`) is a header row and it should be inside `` element. Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2314
Re: RFR: 8197825: [Test] Intermittent timeout with javax/swing JColorChooser Test [v4]
On Fri, 29 Jan 2021 18:05:07 GMT, Prasanta Sadhukhan wrote: >> This test was failing in our nightly mach5 testing. Appropriate stability >> code in form of waitForIdle and delay is added. >> mach5 job running for several iterations on all platforms is ok. Link in JBS. > > Prasanta Sadhukhan has updated the pull request incrementally with one > additional commit since the last revision: > > Declare m_breakMessageLoop volatile src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h line 478: > 476: BOOL m_breakOnError; > 477: > 478: volatile BOOL m_breakMessageLoop; Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`? - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2]
On Fri, 29 Jan 2021 16:23:20 GMT, Gerard Ziemski wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> 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?
JNF_CHECK_AND_RETHROW_EXCEPTION is this
// JNF_CHECK_AND_RETHROW_EXCEPTION - rethrows exceptions from Java
//
// Takes an exception thrown from Java, and transforms it into an
// NSException. The NSException should bubble up to the upper-most
// JNF_COCOA_ENTER/JNF_COCOA_EXIT pair, and then be re-thrown as
// a Java exception when returning from JNI. This check should be
// done after raw JNI operations which could cause a Java exception
// to be be thrown. The JNF{Get/Set/Call} macros below do this
// check automatically.
#define JNF_CHECK_AND_RETHROW_EXCEPTION(env)
\
{
\
jthrowable _exception = (*env)->ExceptionOccurred(env);
\
if (_exception) [JNFException raise:env throwable:_exception]; \
}
So what it actually does is clear the exception, raise an NSException and when
the code reaches JNF_COCOA_EXIT - which then has to be there - it clears the
NSException
and re-throws the Java exception.
So the name of the macro is misleading since this does NOT itself rethrow the
exception,
it relies on other code to do that.
CHECK_EXCEPTION will amount to the same - it throws an NSException if there is
a Java exception pending.
And it will clear the NSException before exiting back to Java.
The difference is that it doesn't clear the Java Exception and later rethrow it
since there is no need
There is one exception to this in CHECK_EXCEPTION - if this is the main (ie
appkit) thread the java exception is cleared since there's no one to return it
to ...
> 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?
You are correct, but I decided that here it is fine.
If GetStringChars fails it will return NULL (it does not raise any excptions
itself).
I added a check for NULL if NULL we then return from the JNI method to Java.
In the old case it also would return but would additionally propagate that
raised exception to Java which JNF
decided to throw into the mix when there's already a standard way of testing
failure.
And since we already know str != NULL we are in the realms of something went
badly wrong inside the VM for
this to fail. So I decided this was all fine.
> 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?
I tried to explain the odd-ness of this in the comments preceding the function
definition.
Near as I could figure out that intermediate call is needed to do the
decomposition since the NSFileManager won't do that.
But this is not exactly my area of expertise and there may be a better way. Who
is an expert on the intricacies of the macOS file system naming ?
-
PR: https://git.openjdk.java.net/jdk/pull/2305
Re: RFR: 8197825: [Test] Intermittent timeout with javax/swing JColorChooser Test [v4]
> This test was failing in our nightly mach5 testing. Appropriate stability > code in form of waitForIdle and delay is added. > mach5 job running for several iterations on all platforms is ok. Link in JBS. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Declare m_breakMessageLoop volatile - Changes: - all: https://git.openjdk.java.net/jdk/pull/2220/files - new: https://git.openjdk.java.net/jdk/pull/2220/files/6fdcc0d7..d7dc2a52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2220&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2220&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2220.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2220/head:pull/2220 PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2]
> This completes the desktop module JNF removal > > * remove -framework JavaNativeFoundation from make files > > * remove #import 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) Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8260616: Removing remaining JNF dependencies in the java.desktop modul - Changes: - all: https://git.openjdk.java.net/jdk/pull/2305/files - new: https://git.openjdk.java.net/jdk/pull/2305/files/1951d6d8..efab1de5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305 PR: https://git.openjdk.java.net/jdk/pull/2305
Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2]
On Fri, 29 Jan 2021 17:02:30 GMT, Gerard Ziemski wrote: >> Changes requested by gziemski (Committer). > > Lots of small changes you had to handle here. Thank you for doing it! I pushed a commit with the remaining -lframework ... removals in the desktop makefiles that I had somehow missed ... - PR: https://git.openjdk.java.net/jdk/pull/2305
Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module
On Fri, 29 Jan 2021 16:57:09 GMT, Gerard Ziemski wrote: >> This completes the desktop module JNF removal >> >> * remove -framework JavaNativeFoundation from make files >> >> * remove #import 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). Lots of small changes you had to handle here. Thank you for doing it! - PR: https://git.openjdk.java.net/jdk/pull/2305
Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module
On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote:
> This completes the desktop module JNF removal
>
> * remove -framework JavaNativeFoundation from make files
>
> * remove #import 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
Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module
On Fri, 29 Jan 2021 10:53:42 GMT, Magnus Ihse Bursie wrote: >> This completes the desktop module JNF removal >> >> * remove -framework JavaNativeFoundation from make files >> >> * remove #import 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) > > I mostly have questions about what is missing from this PR. :-) (If this is > supposed to remove the final remnants of JNF) > > - There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, > referring to JavaNativeFoundation. It can presumably be removed. If it > triggers individually instead, the warning should be disabled on a > per-library basis. > > - In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to > JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from > JNF as well. Also, the comments indicate that the exception for STATIC_BUILD > can be removed. (You can verify this with `configure --enable-static-build`) > > - In `make/modules/java.desktop/Lib.gmk`, line 129, and > `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems > like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be > removed. If these are fixed in any of the other issues for the umbrella > JDK-8257852, I apologize. I could not figure that out. > > - There is also a test dependency that I have seen being addressed, in > `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`. Right, this is the desktop module as per the first line of the comment. java.base needs to be removed by the other PR as Erik said. I had not spotted it, but I don't see why the make/test /JtregNativeJdk.gmk case needs to link this framework. I don't see it being used by the test in question. But we can just remove it and prove it - but probably a separate PR since it is nothing to do with the desktop module and the autoconf code needs to be updated once everything else is in. - PR: https://git.openjdk.java.net/jdk/pull/2305
Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module
On 2021-01-29 02:56, Magnus Ihse Bursie wrote: On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote: This completes the desktop module JNF removal * remove -framework JavaNativeFoundation from make files * remove #import 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) I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF) - There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis. - In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`) libosxsecurity is being worked on separately, see https://github.com/openjdk/jdk/pull/1845 That said, we may need a separate bug for build to remove the any lingering global stuff after each component has been fixed. /Erik - In `make/modules/java.desktop/Lib.gmk`, line 129, and `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out. - There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`. - PR: https://git.openjdk.java.net/jdk/pull/2305
RFR: 8260462: Missing in Modality.html
The first row in The Standard Blocking Matrix table in The AWT Modality (`Modality.html`) is a header row and it should be inside `` element. - Commit messages: - 8260462: Missing in Modality.html Changes: https://git.openjdk.java.net/jdk/pull/2314/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2314&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260462 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2314.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2314/head:pull/2314 PR: https://git.openjdk.java.net/jdk/pull/2314
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
On Mon, 25 Jan 2021 15:09:35 GMT, Alexey Ivanov wrote: > Yet I suggest fixing the typo in the bug synopsis: Intermiitent → Intermittent I've edited the JBS synopsis. Please also update the PR subject. - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
On Fri, 29 Jan 2021 04:03:29 GMT, Prasanta Sadhukhan wrote: > It seems "m_breakMessageLoop" is never true for unsuccessful run even though > AwtToolkit::QuitMessageLoop finish execution (where m_breakMessageLoop is set > to true), > so AwtToolkit::MessageLoop never ends and shutdown hook gets called where > tk.isDisposed() loop start spinning. seems to be some timing issue. Then this does look like a synchronisation problem. One thread changes the value of `m_breakMessageLoop` but another doesn't see it's changed. Should `m_breakMessageLoop` be declared as `volatile`? - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module
On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote: > This completes the desktop module JNF removal > > * remove -framework JavaNativeFoundation from make files > > * remove #import 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) I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF) - There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis. - In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`) - In `make/modules/java.desktop/Lib.gmk`, line 129, and `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out. - There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`. - PR: https://git.openjdk.java.net/jdk/pull/2305
