Skip to content

Conversation

@arturobernalg
Copy link
Member

Make DeflatingBrotliEntityProducer and InflatingBrotliDataConsumer load brotli4j via reflection.
Removes hard dependencies and avoids linkage errors when Brotli is absent.

…#737)

Prevent EIIE when commons-compress is absent; wrap failures as IOException.
Fix runtimeAvailable() to probe CC classes; decouple from helper JARs.
@arturobernalg arturobernalg force-pushed the asyn-brotli-reflection branch 2 times, most recently from ada8f28 to 654d8bb Compare October 13, 2025 07:08
@arturobernalg arturobernalg requested a review from ok2c October 13, 2025 07:08
@arturobernalg arturobernalg force-pushed the asyn-brotli-reflection branch from c1658f3 to 7401798 Compare October 13, 2025 18:19
…ad brotli4j via reflection.

Removes hard dependencies and avoids linkage errors when Brotli is absent.
@ok2c
Copy link
Member

ok2c commented Oct 14, 2025

@arturobernalg Why are we actually doing all this? AsyncBrotli is completely unintelligible now. Moreover, the current master works absolutely correctly for me. I tested it with various combinations of having and not having optional dependencies on the classpath and everything worked for me as expected. In fact, we presently do unnecessary reflective calls in CommonsCompressCodecFactory in my opinion. It is not a problem that it directly imports org.apache.commons.compress.compressors classes at compile time. What is important is that it never gets called from ContentCodecRegistry at runtime if Commons Compress is not present.

What am i missing?

@arturobernalg
Copy link
Member Author

@arturobernalg Why are we actually doing all this? AsyncBrotli is completely unintelligible now. Moreover, the current master works absolutely correctly for me. I tested it with various combinations of having and not having optional dependencies on the classpath and everything worked for me as expected. In fact, we presently do unnecessary reflective calls in CommonsCompressCodecFactory in my opinion. It is not a problem that it directly imports org.apache.commons.compress.compressors classes at compile time. What is important is that it never gets called from ContentCodecRegistry at runtime if Commons Compress is not present.

What am i missing?

@ok2c
I assumed the goal was zero compile-time references to optional codecs and pushed everything behind reflection to avoid any potential linkage issues.

@ok2c
Copy link
Member

ok2c commented Oct 14, 2025

@arturobernalg I think it was a misunderstanding.

The problem was this bit of code that used CommonsCompressDecoderFactory#runtimeAvailable to test for availability of Brotli even if Commons Compress was not on the classpath. There is no problem linking optional dependencies at compile time.

        if (!m.containsKey(ContentCoding.BROTLI)
                && CommonsCompressDecoderFactory.runtimeAvailable(ContentCoding.BROTLI.token())) {
            m.put(ContentCoding.BROTLI,
                    Codec.decodeOnly(ent ->
                            new DecompressingEntity(ent, BrotliInputStream::new)));
        }

I once again did a poor job reviewing your changes but I will try to improve.

I fixed all these problems with 4a34b97

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants