Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Register JNI and Reflection classes for AWT/Swing on Linux #5870

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

AlexanderScherbatiy
Copy link
Contributor

GraalVM provides tracing agent which allows to find JNI and Reflection classes used by an application and store them in configuration files. Using the tracing agent with UI application requires checking non obvious use cases to cover different application code paths: Drag & Drop, file choosers, input dialogs, key strokes, Look & Feels.

Key strokes provide the most vivid use case. AWTKeyStroke.getVKValue(String) method uses reflection to get a key code for for the requested KeyEvent.VK_* string value. It requires pressing all keys used as key strokes in the application during the tracing agent usage.

The proposed fix registers common classes used by AWT/Swing application on Linux System.

L&F UI classes are registered only for Basic and Metal L&Fs as UIManager.setLookAndFeel(String) method directly sets MetalLookAndFeel class. It is necessary to use the tracing agent when an application uses GTK, Nimbus, and other Look & Feels.

@AlexanderScherbatiy
Copy link
Contributor Author

The pull request is updated according to the #6088 [GR-40641] Dynamic linking of AWT libraries on Linux. changes.

The common classes used by AWT/Swing application are added for Windows platform as well.

Fix #6088 removed substitution for sun.awt.FontConfiguration.findFontConfigFile() method so it is necessary to provide java.home system property explicitly on Linux.

To avoid NPE in FontConfiguration.getVersion() method on Linux and Windows it needs to create a lib directory with fontconfig.bfc|fontconfig.properties.src|fontconfig.properties files. Fontconfig properties files can be copied from jdk or created manually.

For example, running the SwingSet2 native image on Linux where corresponding fontconfig properties files are placed in lib directory:

./SwingSet2 -Djava.home=.

There is also an internal system property sun.awt.fontconfig which allows to provide a fontconfig property file for debugging purposes. For example:

./SwingSet2 -Djava.home=. -Dsun.awt.fontconfig=./fontconfig.properties

For more discussions about sun.awt.fontconfig property see openjdk/jdk#11559 (comment)

@kkriske
Copy link
Contributor

kkriske commented Jul 8, 2023

I have previously set up some stuff for AWT as well, mainly focused on Windows at the time.
The draft can be found here: #3079 but seeing as it was completely ignored at the time I didn't bother cleaning it up, however I'm coincidentally working on updating the version I actually use anyway as I need Linux support on it as well.

I do think that the registration handlers should be more granular, as you've combined quite a lot of initIDs calls. They do cascade into each other but seeing as they in theory can each be the entrypoint that makes AWT reachable, it's risky to configure it in the way you did, or at least in my humble opinion.
Having separate reachability handlers for each native call makes it way easier to maintain as well, as there is a 1 to 1 mapping of calls you can look at to see if all JNI calls are covered within that specific native method.

As for the java.home system property problem for the FontConfiguration, I do have a substitution setup that works for both Linux and Windows which I'm happy to contribute once the GraalVM team is actually accepting AWT contributions.

@fniephaus fniephaus assigned fniephaus and unassigned pejovica Jan 22, 2024
@fniephaus
Copy link
Member

Hey @AlexanderScherbatiy, thanks for the PR. AWT support is of course quite requested and we've been discussing this with @kkriske and others. The problem with a contribution like this is that it adds too much maintenance work for us. The PR neither includes a test case nor is there an easy way to regenerate and validate all these configurations.

We believe a better to support AWT is through appropriate declarative, and conditional metadata in the graalvm-reachability-metadata repository. What would be nice is a set of test cases that not only validate the configuration, but can also be extended and then used to regenerate the configuration with the tracing agent. Having this in the metadata repo makes it easy for the community to maintain it. Please feel free to let me know if you like to help with something like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
native-image OCA Verified All contributors have signed the Oracle Contributor Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants