Hello, I noticed the lack of a proper Java-only implementation of ZSTD (I know zstd-jni is fine, but it uses native libraries and is kind of heavy too) that also supports Android
So meet the murine-aircompressor library
I noticed version 2.0 of aircompressor was exclusively Java-only and used JDK 8, the maintainer claimed Unsafe was not available for Android and therefore Android support was out of scope for it; however, that turns out not to be the case, Unsafe can be used on Android and there was only one single method and a static field which are missing on the Android implementation of Unsafe, I just made a helper method for the former, choosing the right implementation, while the static field was just a call to an existing method, and Bob's your uncle.
But not satisfied, I made a few changes, a lot of which are kanged from other forks the maintainer ignored:
- improved compression a lot (original fork that implemented this change here) - added an option to switch to the former behaviour too
- added a ring buffer mode and set as degault (also kanged from another fork, seems to improve performance over largely incompressible data)
- exposed levels for the streaming compressor
- added FAST algorithm to also support levels 1-2 on top of 3-4 which were the only supported ones in the original (level 2 is also pretty good and way faster; Claude is, however, mostly to praise [or blame] for this one)
- Improved overall performance on ARM (again, Claude is mostly to praise/blame here, but I did a lot of tests)
- added parallel compression support because fuck it
- added a wittle tar (with PAX) implementation because fuck it again, I wanted to make .tar.zst without qdding extra libraries
Using WindowSlideMode.HIGH_SPEED resets the library's (ORIGINAL) shit compression ratio for the stream, but makes it faster, I suppose; I default to HIGH_COMPRESSION which is still decently fast, and if you want it to be faster, it's much much better to use level 2 with HIGH_COMPRESSION than the default level 3 with HIGH_SPEED in my experience
Overall, the library is a little slower than zstd-jni with the (now) default parameters, but now matches its compression ratio, and may be a good compromise you'd rather want a lightweight full-java implementation than the heavy .so files in your apk
EDIT: I also noticed this may sound like I'm trashing the maintainer, I'm not lol, just stating facts, the maintainer is awesome for creating the library on the first place
submitted by /u/G3nghisKang[link] [comments]