Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
None
-
None
-
None
-
None
Description
One file in our Common Crawl stash demonstrates a Bouncy Castle version conflict...incompatible binaries with Jackcess and our current version of Bouncy Castle.
java.lang.NoSuchMethodError: org.bouncycastle.crypto.StreamCipher.processBytes([BII[BI)V
at com.healthmarketscience.jackcess.impl.BaseCryptCodecHandler.streamDecrypt(BaseCryptCodecHandler.java:91)
at com.healthmarketscience.jackcess.impl.BaseJetCryptCodecHandler.decodePage(BaseJetCryptCodecHandler.java:62)
at com.healthmarketscience.jackcess.impl.PageChannel.readPage(PageChannel.java:224)
at com.healthmarketscience.jackcess.impl.UsageMap.read(UsageMap.java:130)
at com.healthmarketscience.jackcess.impl.PageChannel.initialize(PageChannel.java:117)
at com.healthmarketscience.jackcess.impl.DatabaseImpl.<init>(DatabaseImpl.java:516)
at com.healthmarketscience.jackcess.impl.DatabaseImpl.open(DatabaseImpl.java:389)
at com.healthmarketscience.jackcess.DatabaseBuilder.open(DatabaseBuilder.java:248)
at TestIt.testIt(TestIt.java:19)
A full description and test file are attached here.
There was an API change in 1.51 that causes this problem. 1.50 works with the one test file, and 1.51 does not work. We're currently using 1.52.
It looks like POI is using 1.51 in trunk, now. According to PDFBox trunk's build.xml, they're using 1.50, but their pom.xml has 1.51.
Two options that I see:
1) close our eyes and hope it doesn't affect too many people before Jackcess Encrypt upgrades... perhaps add a try/catch for this one version conflict? Is there any shade magic we can do on our end ... or (I'm assuming) would that have to be done by Jackcess (or an upgrade, of course)?
2) downgrade our bc-prov to 1.50 (from 1.52).
Other options?