stefanbirkner
illegal reflective access update
#30 github workflows yml script uses the matrix of java versions notation add method should now no longer throw a warning about Illegal Reflective Access maven files are no longer required in repository with remote build
Java 17 does not build due to notation in javadoc for methods with
during testing the warning shows up during this phase of testing
[INFO] Running com.github.stefanbirkner.systemlambda.WithEnvironmentVariableTest [ERROR] WARNING: An illegal reflective access operation has occurred [ERROR] WARNING: Illegal reflective access by com.github.stefanbirkner.systemlambda.SystemLambda$WithEnvironmentVariables (file:/C:/Users/john/source/repos/FreedomFaighter/system-lambda/target/classes/) to field java.util.Collections$UnmodifiableMap.m [ERROR] WARNING: Please consider reporting this to the maintainers of com.github.stefanbirkner.systemlambda.SystemLambda$WithEnvironmentVariables [ERROR] WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations [ERROR] WARNING: All illegal access operations will be denied in a future release [INFO] Running com.github.stefanbirkner.systemlambda.WithEnvironmentVariableTest$environment_variables_are_the_same_as_before is from corretto openjdk
start of error message on oracle jdk
There's a workaround for this - https://www.baeldung.com/java-unit-testing-environment-variables#3-when-reflective-access-doesnt-work
this does not fix the problem but allow it to persist without warning. As stated in the compiler output it will not be allowed within the java language.
Currently it persists as a warning on all three operating systems in the pull requests build script.
@FreedomFaighter - you will find an alternative approach here - https://github.com/webcompere/system-stubs - broadly backwards compatible with System Lambda, but a new codebase/package.
That doesn't fix the immediate issue with System Lambda's warning and future disablement due to the Illegal reflective access warning message nor all the other packages that use it currently as a dependency
@FreedomFaighter at this point you have to look at your goals.
If you want @stefanbirkner to fix his library, then please ask him to steal the implementation from SystemStubs, or work with me to modularise it in such a way that he can reuse it, and then System Lambda will be free of reflective access.
If you want your build to work, then you can use a workaround, but you're right, it won't last forever, though it's lasted a long time so far.
If you want to use a library that has all the features of System Lambda, but doesn't use illegal reflective access, then you can migrate to system stubs.
I came here to share options. I'm not a maintainer of this repo. Note, I forked System Lambda as Stefan and I didn't agree on a direction - https://github.com/webcompere/system-stubs/blob/main/History.md
Hi Mr. Ashley Frieze,
I do not think it will take "stealing" open source code by which you probably mean plagerize by myself or Stefan to fix this issue. While I appreciate you chiming in this is a discussion on how to correct this problem not whether or not you've written an alternative.
As for not agreeing I can see why. Thanks for your contribution to this discussion your responses have been labeled as helping further this discussion by github.
@FreedomFaighter
Would it help you to know I'm male?
You're right, when I said "steal" I meant please copy or ask me to help share another way. Though I forked this project, I've tried to share back anything I've learned.
As for whether you think this conversation is helpful. I'll go back to my question about your goals.
If you want a working build of your project, I've laid out some options. If you want system lambda, which hasn't been maintained recently, to be further developed, and that's your only goal, then you're right, my contributions are irrelevant.
However, they're not exclusively aimed at you. I contribute to discussion threads about issues I've resolved in order to help future readers.
@ashleyfrieze
If you have nothing to contribute to this particular bug why direct the conversation to another development after being informed this development needs attention as well?
@stefanbirkner
There are other sections that need attention as well and it is hard to determine from the test portion run by maven from the pom file.
Currently the runtime environment may be prescanning for violations but the execute portion of class may be making modifications as well. Due to the warning not indicating where the problem is individual tests will be run to see where the illegal access keeps being invoked
@FreedomFaighter - the root cause of the illegal reflective access is the modification, via reflection, of the private field in UnmodifiableMap - https://github.com/stefanbirkner/system-lambda/blob/master/src/main/java/com/github/stefanbirkner/systemlambda/SystemLambda.java#L1380 - this is the core technique at the heart of how System Lambda, System Rules and also JUnit Pioneer modify environment variables at runtime.
It's explained in the opening section here. https://www.baeldung.com/java-unit-testing-environment-variables
It's an illegal technique as far as the latest Java releases are concerned, violating the protections of the module system.
To fix it, it would be necessary to do something entirely different.
If you have nothing to contribute to this particular bug
I've literally fixed it in another project and I'm offering either that project, or the solution from it to help users or the maintainers of this codebase.
Currently the runtime environment may be prescanning for violations
No, it warns at the time of breaking encapsulation via reflection
@stefanbirkner - please let me know if you want help with this and whether you're planning to maintain this project any further.
I added the following to my pom. It solves the issue for me on JDK 17.0.9:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>
--add-opens java.base/java.util=ALL-UNNAMED
--add-opens java.base/java.lang=ALL-UNNAMED
</argLine>
</configuration>
</plugin>
@fishermans
I added the following to my pom. It solves the issue for me on JDK 17.0.9:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <argLine> --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED </argLine> </configuration> </plugin>
It does - see more options in this article.
https://www.baeldung.com/java-unit-testing-environment-variables#3-when-reflective-access-doesnt-work
retroactively removed .mvn/ directory which contained the jar file and other specific settings