[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1054361: ITP: jruby-jzlib



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.

Emmanuel Bourg


Reply to: