While testing Tika with java 9 we have hit: WARNING: Illegal reflective access by org.apache.poi.openxml4j.util.ZipSecureFile$1 (file:/E:/git/iped/target/release/iped-3.13/lib/poi-ooxml-3.16.jar) to field java.io.FilterInputStream.in WARNING: All illegal access operations will be denied in a future release
Are you able to retry with Apache POI 3.17, to see if it has been fixed with some of the more recent Java 9 testing? If not / if it still happens, what do we need to do with Tika and/or POI to trigger it?
I can confirm that this is still happening in 3.17.final.
Java 9 is just out and it looks we have a few issues (eg https://bz.apache.org/bugzilla/show_bug.cgi?id=61564) There is a plan to issue a 3.17.1 patch to fix issues when Java 9 is used.
Although I would like to fix this for 3.17.1, I think this can't be fixed without changing the java zip implementation. Maybe commons compress could help. I guess the chances are nil to get a modification into the Zip classes ?...
It's not caused in the JVM, but by the usage of reflection in ZipSecureFile.addThreshold(). I would first investigate and then discuss if there is even a fix necessary. We do cover these code-lines in our unit-tests and we do continuous testing of JDK 9 since some time. Luis, can you state if you followed the steps indicated at http://poi.apache.org/faq.html#faq-N102B0 and specified the given commandline parameters when running your application with Java 9? Also is the application crashing at that point or is this a mere output to stderr. I think this one is just a warning on stderr and thus does not hinder execution at all currently, right?
Well, I think this should definitely be fixed. It's only a warning message, and I don't expect this to have any other side effects for the time being. But if you look at the discussions that took place during Java 9 development, the message is: we decided last minute to allow this illegal access to give library/software maintainers time to fix their codebase; we will disallow this access by default in the next major release of Java. (that's not citing, it's just what I recall from memory) So not fixing this is just waiting for failure when the next release comes out. I had looked into this some days ago. The code causing the issue seems to be some kind of hotfix to prevent DOS attacks by using manipulated files (files that contain zip bombs). To do this, an an InputStream field is read and wrapped via reflective access. There's even already a comment in the code that this will break in Java 9, and an explanation on how it should be fixed. The code lies on different paths, one of which seems to be relatively easy to fix. I think the other places are somewhat harder to fix. If I had the time, I'd try to produce a fix. Currently, that's not the case. But if noone else steps up, I hope I could do it before Java 10 GA. ;-)
Sorry for the confusion, I meant mostly "releasing 3.17.1 may not be necessary/possible", fixing the warning for 4.0.0 if possible is naturally the way to go. However we still will support Java 8 as main version for some time, so that is what needs to keep working for now, not Java 9 running perfectly smooth and Java 8 not any longer.
Hi Nick, the reflective access to FilterInputStream.in from ZipSecureFile is still present in POI trunk. Hi Dominik, no, I did not add those command line parameters (--add-opens, --add-modules, so on), although I was aware of them. Part of our app and Tika are libraries, so not always we have control of command line parameters. And yes, that is just a warning from the jvm and poi works with java 9. But I think that could be improved long term to work in future versions of java.
*** Bug 62034 has been marked as a duplicate of this bug. ***
*** Bug 61991 has been marked as a duplicate of this bug. ***
*** Bug 62050 has been marked as a duplicate of this bug. ***
Fixed via #62187