Github user Randgalt commented on the issue:
https://github.com/apache/curator/pull/282
OK - interesting. It might make sense to develop a general purpose project
just for this. Larger projects like Curator could pull this new lib in via
shading to avoid the dependency.
---
Github user leventov commented on the issue:
https://github.com/apache/curator/pull/282
There is no peer evidence here, because we are on the optimization
forefront. See
https://github.com/apache/incubator-druid/pull/6677#discussion_r237182258 and
https://lists.apache.org/thread.html
Github user Randgalt commented on the issue:
https://github.com/apache/curator/pull/282
Can you point to other libraries that have taken the approach of re-writing
these APIs? I see you opened
https://issues.apache.org/jira/browse/COMPRESS-473. Are they taking this change
as well?
Github user leventov commented on the issue:
https://github.com/apache/curator/pull/282
Because `GZIPInputStream` and `GZIPOutputStream` are more generic
mechanisms, they are able to compress / decompress arbitrary streams of data,
of unknown length, available only byte-by-byte, etc.
Github user Randgalt commented on the issue:
https://github.com/apache/curator/pull/282
> // it still makes sense to avoid GZIPInputStream
> // and GZIPOutputStream
I don't see how it makes sense to avoid JDK library code. If what you say
is true, why wouldn't they update
Github user leventov commented on the issue:
https://github.com/apache/curator/pull/282
However, the specialized code will still be more efficient:
```java
// Even when Curator's minimum supported Java version becomes
// no less than Java 12, where finalize() methods
Github user leventov commented on the issue:
https://github.com/apache/curator/pull/282
For reference: https://bugs.openjdk.java.net/browse/JDK-8212129
---
Github user leventov commented on the issue:
https://github.com/apache/curator/pull/282
JDK authors did the right thing... in OpenJDK 12. When the minimum Curator
requirement is bumped to at least JDK 12 (realistically: JDK 17, the next LTS
version), this specialization code could be
Github user Randgalt commented on the issue:
https://github.com/apache/curator/pull/282
I came to this issue late. Are we certain merging this was the right thing
to do? Is there any additional referencing documentation of other projects
doing something similar? I'm concerned about re
Github user cammckenzie commented on the issue:
https://github.com/apache/curator/pull/282
Thanks for the PR @alexbrasetvik I will merge this shortly.
---
10 matches
Mail list logo
