Thank you Uwe. The "jdk.unsupported" module hint did the trick - at least the build is now getting over that error.
So our build uses classpath mode when run under Java 8 and modulepath for Java 9+ - actually everything except of the module-info is compiled in classpath mode and the module-info is then patched into the classes. To release under Java 8, I compile/update the module-info.class to the source when compiling under Java 9+ - so this development noise is a bit of a drawback which we might solve by using timestamp checks in the build. I thought about providing a multi-release version of the CleanerUtil, so we have only the Java 8 or the Java 9+ code active. But then I'm puzzled how the JRE reacts, if you use classpath mode in Java 9+. I guess it ignores the module-info modules and the patched multi-release class, effectively running the Java 8 code. So we need both versions with that fallback mechanism. TL;DR: don't change CleanerUtil. On 07.08.20 18:24, Uwe Schindler wrote: >> Sorry for not understanding the whole problem (module system usage instaed >> of classpath). Your code is perfectly valid and works with Java 9, it's just >> broken > ...with module system as its not fully declared all imports. The compile > won't find the issue, as it's in dynamic linking code. >
signature.asc
Description: OpenPGP digital signature
