Hi Uwe, I currently try to understand, how to call the Cleaner in Java 14 (or 9+) without adding the --add-opens JVM options. As you've worked on this in LUCENE-6989, you might have a few hints for me.
I've checked the Lucene implementation, but that code is similar to POIs current implementation. [1] As I don't see the Runable interface, I might look at the wrong branch. Any ideas? Best wishes, Andi [1] https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java#L338 vs. https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/poifs/nio/CleanerUtil.java?view=markup#l91 On 09.07.20 00:34, Andreas Beeker wrote: > 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] >
signature.asc
Description: OpenPGP digital signature
