Add more maintainers to `lz4-java` repo

[HTHou]

The latest lz4-java was released over two years. It still using an old version of lz4 library. See #214.

@odaira Would you like to add more maintainers to that repo? Thanks.

[petoncle]

Currently, there seems to be 2 maintainers (jpountz and odaira). One of them said they no longer have time for lz4-java, and the other has not responded to @mentions from issues and PRs in years.
It looks unlikely to me that they can actively search and vet new maintainers. They might eventually come back to lz4-java, but for now the most effective way forward I see is for someone from the community to create a fork, possibly merge some of the pending PRs and create new releases.

[thegreystone]

This is becoming a problem for the OpenJDK JMC project. Forking might be a reasonable path forward.

[thegreystone]

WDYT @viragpurnam?

[viragpurnam]

Yes, Using library which is not actively maintained is problem for JMC project. I see that master branch has been updated to latest submodule LZ4 (version 1.9.4) but it has not been published to maven central.

[8502596]

I am very interested in upgrading to the latest version 1.10.0, but due to my limited programming skills, the fork project currently only has one project that has not been upgraded and has modified the corresponding lz4 version reference. However, the corresponding. so file has not been modified. Here is a temporary method to modify the Maven repository's corresponding jar file by using compression software to rename the lz4 1.10.0 version of lz4.exe to. so file and replace the corresponding file (as shown below on Windows). After testing on my computer, there were no errors. Please test it out, everyone.

By the way, the advantage of LZ4 lies in its decompression and compression speed, so it is necessary to pursue the maximum speed of Java's LZ4 algorithm. Currently, LZ4_Java uses JNI, which is great, but it is quite difficult to maintain JNI. Other methods include JNA, Panama, etc. Currently, Panama is working on
JDK 21 and other related performance have surpassed JNI. It is recommended to use the relevant jextract tool (although I do not know how to use it yet). Currently, this project is not active, which may be partly due to the complexity of JNI. Although JNA has simplified a lot, the corresponding performance has decreased by an order of magnitude, which is unacceptable for the LZ4 algorithm.

It seems that there is another project called Apahe Commons Compressor that uses pure Java to implement LZ4, but its algorithm has not been synchronized with the LZ4 project for a long time
Its core algorithm seems to be built on version 1.5.1 or even earlier, and has been tested to be able to compress files at speeds such as Base64, but it is completely unacceptable for many other types of files.

The LZ4 algorithm requires pure Java to achieve maximum performance, but the corresponding workload will also be extremely high, and there is a problem of duplicating wheels. So, it is recommended to use jextract instead of Java 8 and use Java 21 (long-term support)

https://issues.apache.org/jira/browse/COMPRESS-649
Replacing txt files with other types of files such as JavaScript will result in an increase of 2 orders of magnitude, which is meaningless for the LZ4 algorithm