garydgregory commented on PR #666: URL: https://github.com/apache/commons-compress/pull/666#issuecomment-2821354577
> I realize that this creates an issue if `Zstd` is not on the classpath, which is why there is `ZstdUtils.isZstdCompressionAvailable()`, but I guess the issue is that if they are hard-coded, then they can change, but the methods in `Zstd` should pull the current values. > > Whatever way is chosen, could you please add support for `minCompressionLevel` and `maxCompressionLevel`? These and other constants from `Zstd` appear to be missing. > > https://github.com/luben/zstd-jni/blob/master/src/main/java/com/github/luben/zstd/Zstd.java#L1001-L1017 Hello @dwalluck I'm semi-doubtful as to the usefulness of the exceptions thrown by our high-level code that use `ZstdUtils.isZstdCompressionAvailable()`. The exception messages don't tell you how to fix the issue so a user is still left with poking around the web. In any case, I'm OK with the lower-level class _not_ trying to be clever using `ZstdUtils.isZstdCompressionAvailable()`. My initial goal with the constants was just to reflect the C-header ... but yeah, using the APIs instead of redefining values make the code better without call sites having to using what I consider internal APIs from Commons Compress' POV. Please see the latest code in this PR where I've split out the constants into a new class which will likely be used by call sites (and docs) with a future builder for the zstd input stream side of things. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
