Taro L. Saito

@richardstartin Thanks for the PR. I'm OK with adding this functionality, but this change will require re-compilation of all native libraries, including linux/ppc64, AIX, s390x. The other native libraries can...

@richardstartin I think so. For now compress(ByteBuffer, ByteBuffer) and uncompress(ByteBuffer, ByteBuffer) should be the only target to minimize the change. Internally, we need to distinguish two types of buffers: heap...

@richardstartin Usually the PR review of this change size will need a couple of days (so expect one week after submitting PR), and releasing a preview version (e.g., snappy-java-1.1.8-p1 with...

@richardstartin Let me take a look again once the conflict is resolved.

Another idea is adding a fallback to pure-java Snappy (like aircompressor) if no native library is found.

Added a fallback to pure-java snappy implementation in #244 and this is available since snappy-java 1.1.76

It's not a bug, rather big-endian architecture is not supported in the pure-java fallback version. To use zOS, s390x we need to add a native library for this. If https://github.com/dockcross/dockcross...

Personally I don't have time for working on big-endian support by checking every detail of the compressor/decompressor implementation (e.g., where byte order matters). If there is a docker image of...

libsnappy.so won't work as snappy-java needs its own extension (libsnappyjava.so). Running `make native` is the basic step to create snappy-java that should work at your target machine. https://github.com/xerial/snappy-java/blob/master/Makefile#L143

I guess the data is not compressed with snappy compatible format. See also https://github.com/xerial/snappy-java#compatibility-notes