Taro L. Saito

Since https://github.com/xerial/snappy-java/releases/tag/v1.1.10.4, the internal snappy version has upgraded to snappy 1.1.10. Until snappy-java 1.1.10.3, snappy 1.1.8 was unexpectedly used. If the original Snapy 1.1.10 has performance regression, it should be...

@whenamanlies No. The best way is to report the regression at snappy https://github.com/google/snappy and fix it there.

Consuming IOException at `flush` call inside `close` method might not be a good idea because `SnappyOutputStream` is currently designed to guarantee output the entire compressed data set before closing output...

So I guess wrapping with try-finally around flush() is ok to ensure calling the subsequent internal out.close(), but we still need to throw an exception. So anyway it will not...

I'll welcome your contribution. If you have a Solaris platform, please build native library and send a PR!

After make (or gmake in Solaris), the following folder contains newly built native libraries. https://github.com/xerial/snappy-java/tree/develop/src/main/resources/org/xerial/snappy/native I guess there exists SunOS/sparcv9 folder. Please send its contents as a pull request. Thanks...

This will be available in the next release.

Reopened since #112 doesn't work.

Currently no. HadoopCompatibleOutputStream for compressing data in Hadoop compatible format is contributed via PR. So, technically it should be possible to read the hadoop snappy format by implementing HadoopCompatibleInputStream.

@mmastrac Thanks for the report. Currently I don't have Rapsberry Pi to reproduce the problem, so I highly appreciate if you can submit a PR to fix this.