Re: Bug#1054361: ITP: jruby-jzlib

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