Hadoop already provides broad native support for the commonly used codecs, and those implementations are well-tested and widely deployed. >From that standpoint, I’m trying to better understand what specific value Aircompressor adds for HBase. Reducing dependency surface area generally helps with long-term maintenance and operational consistency. That said, I’m open to hear the pro-arguments. If there are concrete performance, portability, or stability benefits that justify keeping it, it would be helpful to outline them so the trade-offs are clear. In light of the JDK 22+ requirement, I think dropping it is a reasonable decision.
On Fri, Feb 13, 2026 at 7:45 PM 张铎(Duo Zhang) <[email protected]> wrote: > > There is a CVE which considers high risk for air compressor > > https://nvd.nist.gov/vuln/detail/CVE-2025-67721 > > And the fix version is 3.4. > > I downloaded the 3.4 jar from maven central and checked its byte code > version, the result is > > public interface io.airlift.compress.v3.Compressor > minor version: 0 > major version: 66 > > Which indicates that it requires at least JDK22 to run. > > Since we still need to support JDK8 on 2.x, I propose we just remove > the air compression support in HBase, as for most cases, we could use > the native snappy or zstd compression. > > Thoughts? > > Thanks.
