Hi Dominik, the goal is to have no --add-opens or similar jvm arguments. In this case we get the following exception:
[junit] java.lang.reflect.InaccessibleObjectException: Unable to make public jdk.internal.ref.Cleaner java.nio.DirectByteBuffer.cleaner() accessible: module java.base does not "opens java.nio" to module org.apache.poi.poi [junit] at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:349) [junit] at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:289) [junit] at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:196) [junit] at java.base/java.lang.reflect.Method.setAccessible(Method.java:190) [junit] at org.apache.poi.poi/org.apache.poi.poifs.nio.CleanerUtil.unmapHackImpl(CleanerUtil.java:116) [junit] at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) [junit] at org.apache.poi.poi/org.apache.poi.poifs.nio.CleanerUtil.<clinit>(CleanerUtil.java:77) [junit] at org.apache.poi.poi/org.apache.poi.poifs.nio.FileBackedDataSource.unmap(FileBackedDataSource.java:189) [junit] at org.apache.poi.poi/org.apache.poi.poifs.nio.FileBackedDataSource.lambda$close$0(FileBackedDataSource.java:162) [junit] at java.base/java.util.IdentityHashMap.forEach(IdentityHashMap.java:1356) [junit] at org.apache.poi.poi/org.apache.poi.poifs.nio.FileBackedDataSource.close(FileBackedDataSource.java:162) [junit] at org.apache.poi.poi/org.apache.poi.poifs.filesystem.POIFSFileSystem.close(POIFSFileSystem.java:764) [junit] at org.apache.poi.poi/org.apache.poi.hpsf.basic.TestWrite.inPlacePOIFSWrite(TestWrite.java:539) If we use the Runnable aproach mentioned in the lucene bug, this should work again. In the meantime I had to move a few sources from ooxml to main (crypto.agile) and we need to find a way, e.g. using multi release classes, for our WorkbookFactory, as with JIgsaw the poi main module can't reflect into ooxml anymore. This was also a reason for moving the agile crypto into poi main and removing the use XmlBeans schemas there. Best wishes, Andi On 07.07.20 18:00, Dominik Stadler wrote: > Hi, > > Sorry for replying late here, not sure if you already did these changes, > but the code in CleanerUtil tries to handle this gracefully with not > cleaning on JDKs which do not support this. > > There should be no compile-time dependency on any unsafe object, during > runtime we try to get a cleaner and simply not unmap buffers cleanly if not > possible for some reason. > > Which new problem do you see with this approach when using the JDK module > system? > > Thanks... Dominik. > > On Mon, Jun 29, 2020 at 10:36 PM Andreas Beeker <[email protected]> > wrote: > >> Hi *, >> >> I'm facing the same problem as described in >> https://issues.apache.org/jira/browse/LUCENE-6989 >> >> Is it ok for you, if I get our build more or less to run with the module >> path (instead of the classpath) when running in a JDK 9+ and later try to >> fix the above Cleaner problem? >> >> I simply would like to focus on one issue now and as we a have >> multi-release jars after my commit, a JDK dependent solution shouldn't be a >> problem anymore. >> >> Andi >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
