Le 2023-10-24 à 11 h 02, Emmanuel Bourg a écrit :
Le 24/10/2023 à 16:28, Jérôme Charaoui a écrit :
Right, my thinking was to use the same path usj/jzlib.jar to signal
the classpath conflict. Otherwise, we can install it to
usj/jruby-jzlib.jar and not make the packages conflict, but I'm not
sure what would happen if both were installed at the same time, at the
JVM-level.
If both jars are loaded in the classpath the JVM will randomly resolve
the classes from the 2 files, that may lead to runtime errors if the two
implementations are not binary compatible.
There are some (small) code changes as well, here is a pkgdiff report:
https://paste.lib3.net/lavamind/2023-10-24-gBV6KdXXUJ4R0DlxXjjnjz0RmA9OCJ6goNYKux5c03M/changes_report.html
Looking at the changes :
* DeflaterOutputStream.java: exception message changed
* GZIPHeader.java: private 'time' variable removed
* GZIPInputStream.java: getModifiedTime method added (typo fix)
* Inflate.java: call a setter instead of setting the variable directly
* ZStream.java: comment change
The only notable change is the addition of getModifiedTime(), we can add
it to the existing package.
In addition, I believe there may be more substantive changes in the
future since there are zlib-related bugs reported against JRuby which
may lead to further changes in jruby-jzlib, see
https://github.com/jruby/jruby/issues/6613
Good point. If the code diverges significantly an independent package is
perfectly justified then.
Alright, thanks for the analysis! I'll patch GZIPInputStream.java in the
existing jzlib package to add getModifiedTime(), and I'll keep an eye on
jruby-jzlib and upload it if/when it diverges more from jzlib.
-- Jérôme
