JDK-8340005 : Eliminate native access calls from javafx.swing
  • Type: Bug
  • Component: javafx
  • Sub-Component: swing
  • Affected Version: jfx24
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-09-12
  • Updated: 2024-10-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
jfx24Unresolved
Related Reports
Relates :  
Description
While implementing JDK-8339517 to eliminate native access warnings by passing "--enable-native-access" for the three JavaFX modules with native code (javafx.graphics, javafx.media, and javafx.web), I discovered that the Swing interop code in javafx.swing calls a JNI method defined in one of the native graphics libraries (prism-common) directly.

This means that even after JDK-8339517 is fixed, we still get native access warnings when running any test that uses SwingNode.

WARNING: A native method in com.sun.javafx.embed.swing.newimpl.SwingNodeInteropN has been bound
WARNING: com.sun.javafx.embed.swing.newimpl.SwingNodeInteropN::overrideNativeWindowHandle is declared in module javafx.swing (file:/Users/kcr/dev/javafx/jfx-kcr/jfx/rt/build/shims/javafx.swing/)
WARNING: Use --enable-native-access=javafx.swing to avoid a warning for native methods declared in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jfx/pull/1600 Date: 2024-10-15 03:18:09 +0000
15-10-2024

Able to see the warning with jdk24
14-10-2024

A possible fix is as follows: On the Java side: 1. Create a new static utility method somewhere in the javafx.graphics module, probably in glass (e.g., Application). That method should have the same signature as the existing overrideNativeWindowHandle method, except that the LightweightFrameWrapper argument should be changed to an opaque Object. 2. Create a private static native _overrideNativeWindowHandle method, in the same class as above with the same signature, and call that from the Java code. 3. Change the existing SwingNodeInteropN::overrideNativeWindowHandle to a Java method that calls the new <glass>::overrideNativeWindowHandle method. In native-prism/SwingInterop.c: 4. Rename Java_com_sun_javafx_embed_swing_newimpl_SwingNodeInteropN_overrideNativeWindowHandle to the appropriate name for the new glass native function. NOTE: prism-common isn't the ideal place for it, but we don't have any shared code in glass, so this is the most expedient thing to do. An alternative solution would be to implement _overrideNativeWindowHandle as an instance method that you override in the platform-dependent glass classes, but then we would need three identical copies of the native code.
12-09-2024