Numerous ESAPI JUnit test failures when using JDK 9 or later

[kwwall]

When mvn test is run with JDK 9 or later, there are multiple JUnit test failures. E.g., when using OpenJDK 11, here are the failures:

[ERROR] Tests run: 19, Failures: 0, Errors: 19, Skipped: 0, Time elapsed: 1.818 s <<< FAILURE! - in org.owasp.esapi.filters.SecurityWrapperResponseTest
[ERROR] Tests run: 16, Failures: 0, Errors: 16, Skipped: 0, Time elapsed: 1.939 s <<< FAILURE! - in org.owasp.esapi.reference.DefaultValidaterDateAPITest
[ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.034 s <<< FAILURE! - in org.owasp.esapi.reference.crypto.EncryptedPropertiesUtilsTest
[ERROR] Tests run: 10, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.062 s <<< FAILURE! - in org.owasp.esapi.reference.crypto.ReferenceEncryptedPropertiesTest
[ERROR] Tests run: 18, Failures: 9, Errors: 9, Skipped: 0, Time elapsed: 2.012 s <<< FAILURE! - in org.owasp.esapi.reference.DefaultValidatorInputStringAPITest
[ERROR] Tests run: 4144, Failures: 0, Errors: 40, Skipped: 0

This problem seems to be related to Java Platform Module System (JPMS) which was first introduced in Java 9. (See the Guice GitHub issue referenced below.)

The first clue about this is the Maven error that appears for any Maven goal and looks like this (at least for Maven 3.6.0):

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
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

which @jeremiahjstacey tracked down to Google Guice issue 1133 which has been open since 2017 and is apparently related to JPMS. Maven uses Google Guice, as does Eclipse, so we need to address these issues before Oracle JDK 8 is scheduled for end-of-life (tentatively for end of December, 2020; see https://www.oracle.com/technetwork/java/java-se-support-roadmap.html for details).

[kwwall]

Note: It appears that many of the failing tests were related to Mockito and/or Power Mock which also is likely to be affected by JPMS as well. Currently all tests are passing with OpenJDK 8. At this point it is not clear if ESAPI 2.2.0.0-RC2 or later will work everywhere expected with a JavaEE application server that uses JDK 9 or later though. If you are aware of such situations, please drop us a note here and we may kick up the priority of this. Thanks.

[xeno6696]

I'm not 100% sure if I've just fixed this for JDK 1.9+ but I fixed it for JDK 1.8:

https://github.com/powermock/powermock/issues/864

Will be doing a PR soon for this issue as well as the new logic for the Referer headers.

[kwwall]

It was working for JDK 8, wasn't it? I only remember it failing for JDK 9 and later.

-kevin

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

On Sat, Aug 31, 2019, 19:48 Matt Seil [email protected] wrote:

I'm not 100% sure if I've just fixed this for JDK 1.9+ but I fixed it for JDK 1.8:

powermock/powermock#864 https://github.com/powermock/powermock/issues/864

Will be doing a PR soon for this issue as well as the new logic for the Referer headers.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ESAPI/esapi-java-legacy/issues/496?email_source=notifications&email_token=AAO6PG3727I54Y2OH4MOI73QHL7OPA5CNFSM4HSBYWTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5TXHYA#issuecomment-526873568, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO6PG2OS6HHGAQBWJVFH6LQHL7OPANCNFSM4HSBYWTA .

[xeno6696]

@kwwall @jeremiahjstacey I'm not sure how we want to proceed here. I've essentially silenced our failing tests using @PowermockIgnore, however we have a dependency for when Powermock finally fixes their library.

Do we want to leave this issue open then, since it's not technically fixed?

Also, in every version of maven I still can't get a build to complete even using Java 1.8 because it hangs on dependency check.

[kwwall]

I think there's a bug in Dependency Check. I've seen same thing. If I kill it and rerun the exact same Maven dep ck goal (with not intervening 'mvn clean' or manual file deletion), then it usually works. And once it works, I to works for a long time. If I could reproduce it or figure out a root cause, I'd report it.

-kevin

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

On Sun, Sep 1, 2019, 12:13 Matt Seil [email protected] wrote:

@kwwall https://github.com/kwwall @jeremiahjstacey https://github.com/jeremiahjstacey I'm not sure how we want to proceed here. I've essentially silenced our failing tests using @PowermockIgnore, however we have a dependency for when Powermock finally fixes their library.

Do we want to leave this issue open then, since it's not technically fixed?

Also, in every version of maven I still can't get a build to complete even using Java 1.8 because it hangs on dependency check.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESAPI/esapi-java-legacy/issues/496?email_source=notifications&email_token=AAO6PGYX257ZKE3JOOUASZTQHPS3BA5CNFSM4HSBYWTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5UFP6I#issuecomment-526931961, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO6PGYEO2YFFCPEB7RJI3TQHPS3BANCNFSM4HSBYWTA .

[noloader]

@kwwall, @xeno6696,

With PR #730, I was able to build and run the self tests on Java 8 and Java 11. All tests were successful. Java 8 was always Ok, Java 11 was the problem. And that was ESAPI 2.4.0 and 2.5.0. Also see GH #721.

I had a really bad experience with Java 17, however. Too many errors to count due to Reflection abuses.