Gzip file input failing again in Logstash 8.4

[freddyh (Freddy Heppell)]

There's a few discussion posts (1, 2) and a github issue about a similar issue in the past, but previously it was reported to happen with unsupported Java versions, but I'm now getting this with version 8.4 of the official docker container.

Pipeline:

input {
   file {
        check_archive_validity => true
        path => ["/ingest/**/*.gz"]
        mode => "read"
   }
}

Error:

[2022-08-30T12:03:45,044][ERROR][logstash.javapipeline    ][ingest][9c22338b3618aabae907ad9662e74ebe23b5188078b49a4258766e7fa192f4c8] A plugin had an unrecoverable error. Will restart this plugin.
  Pipeline_id:ingest
  Plugin: <LogStash::Inputs::File mode=>"read", path=>["/ingest/**/*.gz"], check_archive_validity=>true, id=>"9c22338b3618aabae907ad9662e74ebe23b5188078b49a4258766e7fa192f4c8", enable_metric=>true, codec=><LogStash::Codecs::Plain id=>"plain_7b14fde8-cb1a-4932-ab59-322030ae1d92", enable_metric=>true, charset=>"UTF-8">, stat_interval=>1.0, discover_interval=>15, sincedb_write_interval=>15.0, start_position=>"end", delimiter=>"\n", close_older=>3600.0, file_completed_action=>"delete", sincedb_clean_after=>1209600.0, file_chunk_size=>32768, file_chunk_count=>140737488355327, file_sort_by=>"last_modified", file_sort_direction=>"asc", exit_after_read=>false>
  Error: wrong number of arguments (given 1, expected 2)
  Exception: ArgumentError
  Stack: /usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/read_mode/handlers/read_zip_file.rb:32:in `handle_specifically'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/read_mode/handlers/base.rb:26:in `handle'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/read_mode/processor.rb:25:in `read_zip_file'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/read_mode/processor.rb:88:in `block in process_active'
org/jruby/RubyArray.java:1865:in `each'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/read_mode/processor.rb:73:in `process_active'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/read_mode/processor.rb:31:in `process_all_states'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/watch.rb:70:in `iterate_on_state'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/watch.rb:44:in `subscribe'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/filewatch/observing_read.rb:12:in `subscribe'
/usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-input-file-4.4.3/lib/logstash/inputs/file.rb:370:in `run'
/usr/share/logstash/logstash-core/lib/logstash/java_pipeline.rb:410:in `inputworker'
/usr/share/logstash/logstash-core/lib/logstash/java_pipeline.rb:401:in `block in start_input'

This trace refers to the same line as before, but is now saying (given 1, expected 2) instead of (given 1, expected 0). This is a bit strange because, as far as I can tell, the readLine method still expects 0 arguments in Java 17?

This is with the container docker.elastic.co/logstash/logstash:8.4.0, the version information that gets logged is:
Starting Logstash {"logstash.version"=>"8.4.0", "jruby.version"=>"jruby 9.3.6.0 (2.6.8) 2022-06-27 7a2cbcd376 OpenJDK 64-Bit Server VM 17.0.4+8 on 17.0.4+8 +indy +jit [aarch64-linux]"}

[Badger]

This is very likely related to the most recent PR for filewatch, which is "Package private methods mustn't be called also if JRuby permit us.
In JDK 11 readLine() invokes readLine(false)m in JDK 17 the package private readLine(boolean, boolean[]) takes one more parameter and this breaks the tests.
This commit made use of the public API."