The warning printed by the code in Lucene (and the fork of Hadoop in POI) informs user. Btw, there's still "Hadoop" in your code. 😁
It's interesting that JDK prints the exception to stderr. This was not happening in Java 9. Looks like a bug. Uwe Am August 7, 2020 9:58:04 PM UTC schrieb Andreas Beeker <[email protected]>: >> 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. -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de
