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.