I introduced aircompressor to support platforms and hardware architectures without native binary support in any of the usual suspects. Java-only codecs are very useful when native code integrations are not available. For that reason, it should be kept as an option as long as that is supportable. If ever aircompressor becomes nonviable I would port it’s Apache 2.0 licensed code into our compression modules directly (unless someone vetos that of course) and then maintain it directly. In fact, that exists as an option even today, although not recommended.
Apologies for missing this discussion when it happened earlier. We have native native-code codecs for lz4, snappy, brotli, and zstandard. The old but very stable Hadoop codecs can also be good options. Thanks, - Andrew > On Feb 25, 2026, at 10:55 PM, 张铎 <[email protected]> wrote: > > OK, so air compressor has released a 2.0.3 version with the CVEs fixed > and still support JDK8 > > https://github.com/airlift/aircompressor/releases/tag/2.0.3 > > We just upgrade to this version to fix the problem. > > 张铎(Duo Zhang) <[email protected]> 于2026年2月16日周一 20:24写道： >> >> Just change the compression type in table config and issue a major >> compaction to rewrite all the HFiles. >> >> Anyway, we should this in our ref guide and also in the release note >> in the removal issue. >> >> Thanks. >> >> Charles Connell via dev <[email protected]> 于2026年2月16日周一 10:29写道： >>> >>> 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.
