> 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?
