> The problem was only the missing import of the unsupported module which is > required for unmapping. I think, I should also add the information about the permissions to a FAQ entry: https://stackoverflow.com/a/54046774/2066598
> I still wonder where the exception came from. Have a look at AccessibleObject:349 which prints the stacktrace to System.Err > I would recommend to put the module-info.class into the multi release part Of course it will be eventually put into meta-inf/versions/9 ... but my goal was to release with Java 8, so I need to save the .class file when compiling with Java 9+ before. Andi On 07.08.20 23:07, Uwe Schindler wrote: > CleanerUtil dies not need to be multireleased. Just leave as is. > > The problem was only the missing import of the unsupported module which is > required for unmapping. If you are in module mode at runtime (module path) > and the unsupported module is not there, the exception handler falls through > to the Java 8 code. After that it complains that nothing works. > > I still wonder where the exception came from. The code catches all of them > and converts to a message which should get logged. So this is why I asked how > you got the exception! > > I would recommend to put the module-info.class into the multi release part of > the jar (below meta-inf/versions/9). > > Uwe > > Am August 7, 2020 8:18:48 PM UTC schrieb Andreas Beeker > <[email protected]>: >> 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
