How do you build the java library?

[userh...@gmail.com]

Hi,

I would love to be able to build the java library.

There clearly is code in the github repo for building a java library (with native calls), but I don't see any instruction on how to build it.  Even something simple like the what the bazel target should be.  Maybe it's obvious for bazel users, but not for someone like myself.

I assume I could pull this together and substitute more familiar build tools (gradle/maven), but it would be nice to build the jar more simply, as I would think just a command or two could do from the supplied files.

Thanks in advance.

Ben

[Evgenii Kliuchnikov]

Hello.

  Surely, will add build instructions when I have free cycles.

  Basically, with maven it is mvn clean install from java/org/brotli where the root pom file resides.

  For Bazel build it is bazel build ...:all from java/ (where WORKSPACE file resides; it marks the root of the build tree).

Best regards,

  Eugene.

[userh...@gmail.com]

Eugene, thank you very much for your quick response.

Running the mvn command as you suggest successfully builds a decoder jar, apparenty using a pure java implementation.

That is very useful of course, but my desire is to have both brotli decoding and encoding functionality with a java client.

There is additional code in the java "wrapper" package that appears to provide both encoding and decoding, through native calls that will rely on the platform-specific libraries.  

The mvn command doesn't build these, and there is no pom.xml in the wrapper directory.  

I'm sure I can set up a maven build to make a jar from the wrapper classes, but before I do, I want to ensure that it is the expectation that the wrapper java classes should work with native libraries if properly built?

I also tried the bazel build you suggested, but ran into problems, perhaps with my bazel implementation or configuration.  I am fine with skipping bazel if it is also geared to packaging only the java decoder jar.

Thanks again for any help,

Ben

[Evgenii Kliuchnikov]

Yes, JNI is a pain. It is not portable =( That is why there JNI library is not build with Maven.

Bazel is meant to build host-oriented binaries, so JNI solution is added. Ideally, all the native libraries used by Java application should be statically linked into a single shared library. And Bazel allows that.

So, if JNI wrapper is a must, I recommend to try deal with Bazel. I've seen problems with Bazel in latest CI pipelines. Will take a look soon. Please ping me if I won't do that this week.

[Evgenii Kliuchnikov]

Bazel build should be OK after https://github.com/google/brotli/pull/798 is landed.

[userh...@gmail.com]

Bazel build for java now runs!  Downloads lots of stuff and builds things :-).  And more importantly, with this I have been able to use both decoding and encoding in some java code.

Some by-hand manipulation appears to be needed post-build, I should let you know

1. The library file that the wrapper classes use for native calls is sort of buried in the generated build directories
   and hardwired with the name brotli_jni.dll even on mac and unix platforms.  However, it can be renamed to something
   more appropriate like "libbrotli.so", added to java.library.path, and then loaded in the java code with System.loadLibrary("brotli")
2. The java libraries/jar files are also buried in build directories and have the names libcommon.jar, libenc.jar, libdec.jar.  These need to be copied to the java project.

I built and ran simple encode/decode on both a mac and a centos 7 platform.

Thanks again.

Ben

[Evgenii Kliuchnikov]

".dll" extension was chosen, because windows is picky, and other OS doesn't care.

Making it OS specific would unnecessarily complicate the build file (Bazel philosophy says - artefacts are resolved on "scan" stage... so we can not freely change the name).

Overall, Bazel artifacts are not meant to be used outside of Bazel =) There is a long-standing issue/project to create an honest build for JNI libraries (https://github.com/google/brotli/projects), but no volunteers / experts to implement it...