Illegal reflective access caused by xstream

[mokun]

I use JDK 11 and have this reflective access below when using weblaf at the start of my app :

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.alee.utils.ReflectUtils (file:/C:/Users/mkhelios/.m2/repository/com/weblookandfeel/weblaf-core/1.2.13/weblaf-core-1.2.13.jar) to method sun.font.FontUtilities.fontSupportsDefaultEncoding(java.awt.Font)
WARNING: Please consider reporting this to the maintainers of com.alee.utils.ReflectUtils
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Security framework of XStream not explicitly initialized, using predefined black list on your own risk

I know this is an x-stream issue and we probably discussed this in other threads in the past.

Now one good news is that someone shared the thread below reporting that by switching to x-stream 1.4.13 (needed by launch4j-maven-plugin), the problem went away.

See x-stream/xstream#101 (comment)

Can you try if it works in weblaf as well ?

[mgarin]

This actually isn't related to XStream anyhow, that particular case is WebLaF using some proprietary stuff through Reflection to properly detect fonts for the UI. It is usually done by basic implementations of components/L&F, but since I rewritten a lot of that code - I have it on WebLaF's side and have to sometimes access proprietary stuff, not just for fonts.

A few big examples of Reflection usage:

• NativeFonts.java - the culprit of your particular warning
• ProprietaryUtils.java - a bunch of methods used across WebLaF
• ReflectUtils.java - a set of utilities for convenient Reflection usage

The warning you get is not a bug and it is expected on Java 9+. I don't think that it will be realistically possible to get rid of Reflection usage in WebLaF unless Oracle or whoever works on Open JDK would make some sweeping changes in Swing framework to cleanup it's API. Also I can't really do anything to workaround this on WebLaF's side, unfortunately.

I have a wiki article that properly explains the cause of these warnings and how you can avoid them in your app:
https://github.com/mgarin/weblaf/wiki/Java-9-and-higher

[mgarin]

As a side note - all calls to proprietary "stuff" in WebLaF are properly hidden behind Reflection so they wouldn't cause any exceptions or warnings at compile time. But the issue with Java 9+ remains as that is a runtime thing.

[mgarin]

Also the last log line -

Security framework of XStream not explicitly initialized, using predefined black list on your own risk

Is a recent XStream change that is unrelated to previous messages. I'm pretty sure I already fixed it in one of the commits for 1.2.14, but I will double-check this tomorrow.

[mokun]

https://github.com/mgarin/weblaf/wiki/Java-9-and-higher

I did follow everything in that wiki and called each one of them when running the at the start of the app.

I still get them though. Don't know why.

[mgarin]

Maybe there were some additions that aren't in the list, although I checked recently and it was up-to-date.
What is the exact message/warning you're getting? Because it should tell what is not opened up for Reflection access.

[mgarin]

Have you solved this or can you provide the exact message/warning you're getting?
Also, if you're still getting this issue, what is the exact Java version you're using?

[karelkryda]

Java 15
Latest WebLaf

[mgarin]

@karelkryda
Does that warning go away if you use JVM options as explained here:
https://github.com/mgarin/weblaf/wiki/Java-9-and-higher
or does it still appear?

There is, unfortunately, no way to avoid this due to how Reflection was changed in Java 9+. There are quite a few critical calls to proprietary APIs that have to be made in order for L&F to setup everything properly, so there is no good solution for that problem except for providing access to all required modules explicitly via JVM options. And a lot of those cannot be done on library side anyhow unfortunately.

[mgarin]

I'll be closing this issue as there is already an older one opened for JDK 12+: #525
We can continue discussion related to reflective access there to keep it in one place.
Also there were some new findings recently (for newer Java versions) that I will mention there.