reply below.
- since the project is Apache licensed we could fork / adopt for our needs?
> I’m not familiar enough with the hurdles we’d have to surmount around the
> licensing but at least it’s a compatible license. Maybe Mick knows more
> about what would be required for this route?
>
It's "C
Rei used to be semi-active on the Cassandra lists. He took over lz4-java a few
years ago. Wonder if he’d be willing to pass the torch if he no longer has
time? CC’ing him in case he’s following email.
> On Aug 6, 2024, at 8:47 AM, Jordan West wrote:
>
> Oof this is a tough one. I agree wi
Oof this is a tough one. I agree with both of you on the concerns. I don’t
have good answers but I do see a few options:
- upgrade to 1.10.0 (optionally and w rigorous testing ofc) and then start
to think of a deprecation plan for LZ4 in project. That would be
unfortunate but we could probably do
Indeed, I also want to add that I tried to checkout 1.10.0 submodule of lz4
in lz4-java git repository and I built it and all tests of lz4-java just
passed fine. That is nice to know but that does not change the fact that
there is nobody behind it to drive the releases, do the bug fixes and
similar
I just want to note that lz4 is used for network compression, either
between nodes or more importantly for clients, so interoperability is
key and we need to be careful about changing things here.
Kind Regards,
Brandon
On Fri, Aug 2, 2024 at 3:05 AM Štefan Miklošovič wrote:
>
> I just want to ra
I just want to raise awareness about lz4-java library we use for LZ4
compressor. We are using the version 1.8.0, there is already version 1.10.0
of the underlying lz4 project which lz4-java integrates.
We can see from NEWS (1) that after 1.8.0 there are a lot of performance
improvements and in 1.1
