While trying to fix JDK-8252739 we added a workaround and subclassed java.util.zip.Deflater, so we can work around the offset != 0 bug.

Because of this the Elasticseach CI builds were failing as soon as this new workaround was used by their code. Elasticsearch by default runs with a security manager enabled that prohibits everything and carefully selects which permissions are give.

The permission java.lang.RuntimePermission("accessDeclaredMembers") is not granted to general Elasticsearch code.

Unfortunately the fix in JDK-8185582 causes the constructor of Deflater and Inflater to check without AccessController#doPrivileged, if the class was subclassed and the end() method was overriden, falling back to legacy finalization. As this uses Class#getDeclaredMethod(), the permission must be given. Because no AccessController is used in JDK code, the top-level code somehow calling indirectly the subclassed Deflater deep in the code will trigger a SecurityException.

The problematic code is here: http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/zip/Deflater.java#l991
And here: http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/zip/Inflater.java#l806

In both cases the whole method should be wrapped with AccessController#doPrivileged()

This bug does not happen anymore with JDK 12 as the problematic code was removed there: https://github.com/openjdk/jdk/commit/a655e6b52b3819092c0e874d95e39c124d681381

Thanks to Ignacio Vera (Apache Lucene / Elastic) forbringing this bug to my attention.

The workaround is to not subclass Deflater/Inflater to fix the bug in JDK-8252739.