Warnings on illegal reflective access, and tests run with Java 16 fail with java.lang.reflect.InaccessibleObjectException #32
Comments
|
@jblievremont in JVMs below 16, we get a warning for this. At this stage, I don't know of an obvious workaround, given that this library's method is to hack into what should be an immutable collection. If anyone has any good ideas for how else environment variables could be manipulated in later JVMs, then please post them here and I'll try them out. Happy to accept PRs on the subject too. |
ashleyfrieze
changed the title
|
This is the same root cause as produces: |
|
At the moment the only methodology used across various libraries that coerce environment variables into being writable is:
The outcome is that we can write environment variables at runtime, even though Java has hidden them behind a proxy object that's trying to keep them read-only. The Java module system wants to stop us doing this, but it only warns us about this in earlier versions. Our hacking into these runtime objects will need to become more powerful in the near future. |
|
@ashleyfrieze in Java17 it is no longer a warning... |
|
@McKratt - yeah - there's presently not a solution for this issue. Keep an eye on this issue. When there's a fix, we'll update it. To the best of my knowledge, all the major libraries that allow mutation of environment variables for test use the same technique. |
ashleyfrieze
added
help wanted
|
Worth noting this - stefanbirkner/system-lambda#23 (comment) |
|
This issue is now resolved. Note the new version 2.0.0 and the dependency on mockito-inline |
|
Awesome, thank you! And thanks also for the |
|
@jblievremont just waiting for the propagation to maven central. It may take a few more hours to show up on searches, but it should be downloadable with the correct version in the dependency. Read the README.md to find out what else you need to add to your Pom/build.gradle |
|
Unfortunately, this seems to trigger mockito/mockito#2522 for those using Groovy in a particular way. mockito-inline and Groovy don't seem to co-exist nicely at all right now? :-( Just a PSA, not a complaint :-) |
|
@chadlwilson - do we know if that affects ALL versions of mockito? System Stubs depends on 3.12.x, but could also accept 4.x |
|
Good question @ashleyfrieze . I think so but not 100% sure. Initially the bump of system stubs brought in mixed versions (3.12.4 of inline, 4.2.0 of core which we use and control versions of already) and my first thought was some clash. After ensuring both were 4.2.0, it definitely seems at least 4.2.0 is affected. I haven't tried a simple reprod yet, because as it turns out we need to add opens for our tests on JDK 17 anyway due to some of our own code (and old Javassist) that rely on some dodgy reflection anyway, so system stubs was not blocking us in this regard. |
|
@chadlwilson breaking the dependency on mockito would be useful in the long term. If it becomes close to being a deal breaker, please raise a separate issue (if there isn't one open by then!). |
|
FWIW, the upstream issue has been resolved now in mockito |
|
@chadlwilson - that's great news. I'll drop a note in the |
|
You may want to not bother unless someone else reports similar challenges :-) It's possible that in my case I misdiagnosed the problem due to the similarity of the issue and symptoms. Even after that upstream mockito fix I discovered that there were some method overloads that became ambiguous from mockito and Groovy's perspective once I didn't actually try going back to the various older mockito/mockito-inline versions to see whether it was only the disambiguation which was needed :-/ |
|
@chadlwilson - there's no harm in sharing your advice on mockito 4.5.0 as a known good version, though. It's in the README. Thanks for the info. |
While working on SonarSource/sonarlint-core#366, an issue triggered by Java 16's stricter rules on JDK internal access, we stumbled upon a similar issue in system-stubs - see stack trace below.
Full stack trace
A possible workaround is to pass the
--illegal-access=warnargument to the JVM, though this is not very future-proof.The text was updated successfully, but these errors were encountered: