Assertj-core: AbstractThrowableAssert#isInstanceOf() throws IllegalAccessError

[leadpony]

Summary

AbstractThrowableAssert#isInstanceOf() throws an IllegalAccessError exception
when assertj-core is used as a modular jar.

Example

Throwable thrown = new IllegalArgumentException();
assertThat(thrown).isInstanceOf(NullPointerException.class);

Building and runing this example with JDK 9 or higher:

mvn package
java -p target/modules -m example/example.Example

outputs the following error messages:

Exception in thread "main" java.lang.IllegalAccessError: class org.assertj.core.util.Closeables (in module org.assertj.core) cannot access class java.util.logging.Logger (in module java.logging) because module org.assertj.core does not read module java.logging
    at [email protected]/org.assertj.core.util.Closeables.<clinit>(Closeables.java:25)
    at [email protected]/org.assertj.core.util.Throwables.getStackTrace(Throwables.java:172)
    at [email protected]/org.assertj.core.error.ShouldBeInstance.<init>(ShouldBeInstance.java:67)
    at [email protected]/org.assertj.core.error.ShouldBeInstance.shouldBeInstance(ShouldBeInstance.java:34)
    at [email protected]/org.assertj.core.internal.Objects.assertIsInstanceOf(Objects.java:136)
    at [email protected]/org.assertj.core.api.AbstractAssert.isInstanceOf(AbstractAssert.java:382)
    at [email protected]/example.Example.main(Example.java:9)

The problem happens because org.assertj.core.util.Closeables requires java.logging module both at compile-time and at runtime.
Adding the following line to src/main/java9/module-info.java in asssertj-core repository will resolve the problem.

requires java.logging;

Please find the attached project which reproduces the problem.
assertj-example.zip

Thank you.

[joel-costigliola]

Thanks for reporting this @leadpony!

[scordio]

I am not very familiar with Java 9+ modules, but at first look it seems we don't have any module-path testing.

I would be happy to work on introducing that as it could allow us to have test cases like the one mentioned in this issue.

[joel-costigliola]

we did some manual testing with @sormuras but having a an automated test would be much better.

[leadpony]

Many open source projects compile *.java files TWICE in the release build.

1. First, compiles all *.java files including module-info.java with --release 9
2. Second, compiles all *.java files excluding module-info.java with --release 8

The final jar file contains module-info.class for Java 9 and all other *.class files for Java 8.

First compilation reports errors when module-info.java is incomplete to build all other *.java files.
I believe what compilers can do should be done by compilers.

[sormuras]

I believe what compilers can do should be done by compilers.

Exactly.

As I stumbled over another issue, namely requires java.instrument; seems to be a special snow flake, I'll try to provide either an automated integration test or a better compile strategy that chokes on missing require statements. Or both... ;-)