I'm seeing lots of these errors coming from multip...
# community-support
e
I'm seeing lots of these errors coming from multiple libraries after updating to Java 24. Is the correct solution to add
--enable-native-access=ALL-UNNAMED
to my jvm args until all of these libraries/tools migrate off of JNI (so probably never)?
Copy code
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by com.android.layoutlib.bridge.Bridge in an unnamed module (file:/home/eli/.gradle/caches/8.14/transforms/7ddbbeceffb506f2342ae2f7da76cf06/transformed/layoutlib-15.1.4.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled
👍 1
@ephemient just checking, is that a yes, I should add
--enable-native-access=ALL-UNNAMED
to my jvm args?
e
e
Oh and it looks like even if they migrate to FFM I would still have to explicitly enable it
It looks like that isn't propagated to workers and test executors. Is there a more "Gradle" way to do this to make sure it propagates?
v
Yeah, each of those have separate settings how to set the jvm args. You only configured it for the daemon VM. There is a non-gradle way. You can set
JAVA_TOOL_OPTIONS
environment variable as that is read by all the distributions automatically and would then be used for each and every JVM started with that enviornment variable.
e
Is there something in Gradle that plugin developers can do to make sure that their tests, tools, etc... are run using
--enable-native-access=ALL-UNNAMED
?
v
You cannot influence "all jvms created", except by using that environment variable. Besides that "all jvms created" also includes things like Kotlin compiler daemon, worker daemons, ..., so maybe better set it to those JVMs where you actually need it. 🤷‍♂️
e
The problem is I don't control all the JVMs that use it. So if there's a plugin that creates a test task that runs a tool that uses JNI, what are my options?
v
Why don't you control that JVM? Just configure that task?
Or make sure to do everything that needs something like that out-of-process. Might anyway be better if native libraries are involved as they cannot be loaded multiple times in the same JVM.
e
In case it wasn't clear, I'm speaking as the consumer of the plugin, not the developer.
v
Yes, to me that was not clear, as you asked what a plugin developer can do :-D
So I'm still not fully sure what the question is exactly :-)
e
Sorry about that 😅 To hopefully clarify things, I am trying to use Java 24 with one of my apps, however I am getting a lot of warnings related to needing
--enable-native-access=ALL-UNNAMED
. Those warnings are coming from several Gradle plugins that I use, and so I want to open issues with those projects requesting that they fix the warnings. However, I have no idea how to propose they fix it. So I'm asking if there's some Gradle API they can use when creating test tasks or workers that would let them specify
--enable-native-access=ALL-UNNAMED
.
v
Whatever they do to start a separate process like defining a
Test
task or using
javaExec
or using
exec
or using Worker API with process isolation and so on, they should always be able to specify JVM arguments.
thank you 1