Java encoder

[RehanSaeed]

I'm investigating Brotli for use in Java Android apps. I'm not aware of any project which provides this capability (if you are, I'd like to know), so I would like to build an interceptor for Android's OkHttp that compresses/decompresses using Brotli. Would someone be kind enough to point me to the correct release of the Brotli native library that would work on Android devices?

Related: https://github.com/square/retrofit/issues/1957

[eustas]

Internally we use SWIG and JNI wrappers for brotli library. We plan publish them closer to Brotli 1.0.0 release. Also we have pure-java brotli decoder. And, again, it will published a little bit later. Sorry.

[RehanSaeed]

I had assumed that as Brotli was now a standard, that the library would be complete. If this is not the case, is there somewhere I can read about what's missing, what's planned and look at a the roadmap?

A pure Java implementation would be great, are there any other languages planned as part of 1.0?

[eustas]

There is third-party port to JavaScript and Rust. Not sure, may be even to Go. v1.0.0 is not about format, it is about API. We need to make a final clean-ups (remove deprecated API) and make sure that API is portable and easy to use. So, I believe, we are almost here. So, when v1.0.0 is released, API is considered stable -> it is good time to write wrappers to different languages...

[RehanSaeed]

Cool. Do you have any rough (probably very rough) estimates (or guess-timates) of when v1.0.0 may happen? I'm interested in a Java and C# port and would be willing to help with the C# version if required.

[charliermarsh]

Chiming in to say that I'm also very interested in this and have been tracking this issue for a while. Very excited to see that the Java port is starting to make it into the codebase (e.g., with 5025365d0fe5a5ca874574b952ef53cfa98ca5c1). Is the current Java version in the repo 'safe' to start using externally?

[eustas]

Hi. Java decoder seems to be ready for usage. We've fuzzed it and tested on a large corpora. Soon maven artifact will be published as well. Encoder port is not even planned...

[paked]

@eustas: Any update on the Maven artefact being published?

[thomasjungblut]

@eustas I'm also interested in the mvn artifact. Any news?

[eustas]

org.brotli.dec:0.1.1 has been recently released

[markehammons]

I'm also interested in a java port/jni bindings for brotli

[eustas]

JNI bindings are already here, see java/org/brotli/wrapper Unfortunately, JNI is a headache for portable projects. There is no convenient way to use it out of the box. Currently only Bazel builds JNI artifacts...

[garydgregory]

Wow, almost two years since this issue was created. Are there ANY plans for a Java BrotliOutputStream?

[eustas]

Yes, two years seems to be a very long period... But still we have no time for that =(

[re-thc]

If JNI is a headache would moving to JavaCPP or JNA be a better option? Anything that can be done to move this forward?

[eustas]

There are JNI wrappers for brotli. Just there is no CMake/make/premake build files for them. Bazel compiles and tests JNI library.

I believe JNA does not work well with "in/out" parameters. Going to look at JavaCPP.

[eustas]

JavaCPP looks like a no-go - it requires both JDK and compiler installed...

[hmaclean82]

https://mvnrepository.com/artifact/org.apache.commons/commons-compress/1.5

[CAFxX]

@hmaclean82 commons-compress only includes a decoder. This issue is for the encoder.

[stokito]

IMHO this should be added on JVM level like GZip stream. Brotli can be used even for jar files instead of zip. But here is a good competitor like ZStd which is even added on linux kernel level.

[Jeff11]

https://github.com/square/okhttp/tree/master/okhttp-brotli

[stokito]

@Jeff11 the interceptor just uses the official brotli encoder https://github.com/google/brotli/tree/master/java