[xz-devel] XZ for Java
Dear XZ Java Community Is XZ for Java still maintained? I asked a question here a week ago and have not heard back. When I view the git log I can see it has not updated in over a year. I am looking for things like multithreaded encoding / decoding and a few updates that Brett Okken had submited (but are still waiting for merge). Should I add these things to only my local version, or is there a plan for these things in the future? -- Dennis Ens
Re: [xz-devel] XZ for Java
>> I haven't lost interest but my ability to care has been fairly limited >> mostly due to longterm mental health issues but also due to some other >> things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and >> perhaps he will have a bigger role in the future, we'll see. >> >> It's also good to keep in mind that this is an unpaid hobby project. >> >> Anyway, I assure you that I know far too well about the problem that >> not much progress has been made. The thought of finding new maintainers >> has existed for a long time too as the current situation is obviously >> bad and sad for the project. > With your current rate, I very doubt to see 5.4.0 release this year. The only > progress since april has been small changes to test code. You ignore the many > patches bit rotting away on this mailing list. Right now you choke your repo. > Why wait until 5.4.0 to change maintainer? Why delay what your repo needs? I am sorry about your mental health issues, but its important to be aware of your own limits. I get that this is a hobby project for all contributors, but the community desires more. Why not pass on maintainership for XZ for C so you can give XZ for Java more attention? Or pass on XZ for Java to someone else to focus on XZ for C? Trying to maintain both means that neither are maintained well. -- Dennis Ens
Re: [xz-devel] xz-java and newer java
> Can this be taken up again? +1 Any updates on this? -- Dennis Ens
[xz-devel] [BUG] Issue with xz-java: Unknown Filter ID
Hi all, I think I may have found a bug with xz-java. With version 1.9 (the newest, I think). While trying to decompress a file I got an error message saying "Unknown Filter ID 11". To try to solve the issue, I tried to run several of the test cases with XZDecDemo.jar. Most of them worked fine, but I noticed issues with two arm files and two riscv files. The arm files failed with "Unknown Filter ID 10" and the riscv files failed with "Unknown Filter ID 11". The files specifically were good-1-arm64-lzma2-1.xz and good-1-arm64-lzma2-2.xz and good-1-riscv-lzma2-1.xz and good-1-riscv-lzma2-2.xz. These did seem to work fine when I tried with xz, but not with xz-java. Do you think there might be a fix available for this soon? Thank you. -- Dennis Ens
Re: [xz-devel] [BUG] Issue with xz-java: Unknown Filter ID
> > The files specifically were good-1-arm64-lzma2-1.xz and > > good-1-arm64-lzma2-2.xz and good-1-riscv-lzma2-1.xz and > > good-1-riscv-lzma2-2.xz. These did seem to work fine when I tried > > with xz, but not with xz-java. Do you think there might be a fix > > available for this soon? > > > XZ for Java 1.9 doesn't have ARM64 or RISC-V filter. The master branch > has ARM64 filter. RISC-V filter will likely be there this week. > > The XZ for Java development is becoming active again but it may still > take a while until the next stable release is out. A few other things > are waiting in the queue from the past three years. Ah, I see. Thank you for the answer. Do you have a timeline of when the changes are expected? I started to use xz, and was able to decompress the files without issue. Messing around with xz and xz-java, I noticed a few other things though. First, xz-java seems much slower. I tested compressing and decompressing a ~1.2 gigabyte file, and xz-java took 17m32.345s compared to xz's 7m7.615s to compress. Decompressing was 0m21.760s to 0m6.223s. Is there anything that can be done to improve the speed of the Java version, or is c just a much more efficient programming language? Also, I noticed that the results of compressing the files were different sizes. They both worked, so I don't know if it's an issue, but it does seem strange. The xz-java one was slightly smaller than the xz one. Thanks again for the help. -- Dennis Ens
Re: [xz-devel] [BUG] Issue with xz-java: Unknown Filter ID
> I hope 1.10 could be done in a month or two but I don't want to make any > promises or serious predictions. Historically those haven't been > accurate at all. I'll hope it's on the sooner side then. Is there a reason that xz-java is so far behind its counterpart? It seems those filters have been in that version for a while, and it seems strange they aren't compatible with each other. Maybe this should be made more clear in the README? I'd be happy to help out to make them compatible. I don't see anything about contributing on the xz-java github page. What are the best practices for contributing to this project? > However, Java in general is slower. Some compressors have a Java API but > the performance-critical code is native code. For example, java.util.zip > calls into native code from zlib. XZ for Java doesn't use any native > code (for now at least). That's good to know. It seems like if it's using native code it should be possible to get the speeds pretty similar. It sounds like an interesting problem to tackle. > XZ for Java lacks threading still. Implementing it is among the most > important tasks in XZ for Java. It helps with big files like your test > file but makes compressed file a little bigger. From your numbers I'm > not certain if you used xz in threaded mode or not. The time difference > looks unusually high for single-threaded mode for both compression and > decompression. The difference for a big input file in threaded mode > looks small though (unless it had lots of trivially-compressible > sections). > XZ Utils 5.6.0 also enables threaded mode by default. That would explain a lot of the speed difference I noticed then. I was using the latest code from master, so I should have been running in threaded mode. It's great how large an improvement that can make, although I know it's always complicated to implement threading without any bugs. > The encoder implementations have some minor differences which affects > both output and speed. Different releases can in theory have different > output. XZ Utils output might change in future versions too. I see, that makes sense. I'm glad the difference is explainable and not a bug. Can you explain exactly what the differences are? Does xz-java always do a better job compressing since it resulted in a smaller file?
