Baptiste Mathus I think that before https://github.com/jenkinsci/jenkins/pull/3135, you would get this error just from starting Jenkins, whereas now you would only get it if methods are actively called that use particular methods inside of PosixAPI#jnr, but I'm not sure what those methods are or whether they are called in normal Jenkins usage and so still a problem. Once we know the answer to that, I think we could close this issue and open new ones as needed.
I don't think there is any way for the jnr-posix library to become fully compliant with reflective access without changes to Java APIs, see https://github.com/jnr/jnr-posix/issues/110 as an example, so I think the long-term approach would be to detach the library and rewrite places that need it to use pure Java APIs where possible to reduce our dependency on jnr-posix. See
JENKINS-46725 (which I think should be reopened)/https://github.com/jenkinsci/jenkins/pull/3511 for more info. IIRC the majority of uses are just to get the current Process ID, which was added in Java 9 to the java.lang.Process API, so with some kind of new API/multi-release JAR to use the Process API on Java 9+ with a fallback on older versions of Java we might be able to get rid of most of the uses. Part of the issue here is that we expose the jnr-posix API directly in Jenkins core, so plugins can use anything it provides.
With backwards compatibility in mind, we probably need to investigate all usages of PosixAPI in plugins to understand what would need to be switched. We should also check which APIs that we currently use throw reflective access exceptions, since if they aren't thrown for any of the calls in core or major plugins than detaching the library is not as urgent.