search

mgarin / weblaf

WebLaF is a fully open-source Look & Feel and component library written in pure Java for cross-platform desktop Swing applications.
http://weblookandfeel.com
GNU General Public License v3.0
1.13k stars 234 forks source link

Illegal reflective access caused by xstream #655

Closed mokun closed 3 years ago

mokun commented 3 years ago

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 https://github.com/x-stream/xstream/issues/101#issuecomment-702692897

Can you try if it works in weblaf as well ?

mgarin commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

image

Java 15 Latest WebLaf

mgarin commented 3 years ago

@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 commented 3 years ago

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.