One possible consideration before removal is whether data files written with aircompressor can be read by an alternate implementation of that codec. With ZStandard, I found that the three implementations offered in HBase are not able to read some of each others' writes. Removing codec implementations could force users to stay on older HBase versions. There is no pathway offered in HBase to migrate from one codec implementation to another by reading all your HFiles with one implementation and writing them with another.
On Sat, Feb 14, 2026 at 10:37 PM Vladimir Rodionov <[email protected]> wrote: > > 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.
