Consider moving jar to Maven or eliminating entirely #580

Activity

1. headius commented on Oct 15, 2025

   

   headius

   on Oct 15, 2025

   MemberAuthor

   More actions

   See #579 for work done to remove the jar from the repository.
2. chadlwilson

   added the

   Task

   issue type on Apr 22, 2026
3. chadlwilson commented on Sep 4, 2026

   

   chadlwilson

   on Sep 4, 2026

   Contributor

   More actions

   Eliminating the extension would get the gem back to a pure-Ruby construct and allow it to be run from any compatible Ruby implementation.

   After having looked at this for a while, the extension is actually intended only as a "fast path" zip processing mechanism which redefines pure ruby methods in Java, however discovered that if you try and rely on this fallback-to-Ruby with rubyzip 3, warbler produces broken jars due to changes in rubyzip over time, which are not tested anywhere, since we only test with JRuby.

   warbler/lib/warbler/jar.rb

   Lines 306 to 337 in 06d8c82

   	def create_jar(jar_path, entries)
   	ZipSupport.create(jar_path) do |zipfile|
   	entries.keys.sort.each do |entry|
   	src = entries[entry]
   	if src.respond_to?(:read)
   	zipfile.get_output_stream(entry) { |f| f << src.read }
   	elsif src.nil? || File.directory?(src)
   	if File.symlink?(entry) && ! defined?(JRUBY_VERSION)
   	warn "directory symlinks are not followed unless using JRuby; " +
   	"#{entry.inspect} contents not in archive"
   	end
   	zipfile.mkdir(entry.dup) # in case it's frozen rubyzip 0.9.6.1 workaround
   	elsif File.symlink?(src)
   	zipfile.get_output_stream(entry) { |f| f << File.read(src) }
   	elsif File.exist?(src)
   	zipfile.add(entry, src)
   	else
   	warn "file not found; #{entry.inspect} not in archive"
   	end
   	end
   	end
   	end
   	def entry_in_jar(jar, entry)
   	ZipSupport.open(jar) do |zf|
   	zf.get_input_stream(entry) {|io| StringIO.new(io.read) }
   	end
   	end
   	# Java-boosted jar creation for JRuby; replaces #create_jar and
   	# #entry_in_jar with Java version
   	require 'warbler_jar' if defined?(JRUBY_VERSION)

   In practice, I think there are many other things that dont work properly if not executing warbler with jruby itself, because it'll start using arbitrary bundler versions which are completely different to what the target jruby version will run with. That will likely lead to absolute chaos of the sort we've been unpicking with Warbler 2.1, because bundler has changed a lot, and lockfiles written with bundler vX are not guaranteed to work with bundler vY, or to resolve the same things, which is why bundler both locks versions and is supposed to dynamically switch versions. CRuby and JRuby usually don't match bundler versions and JRuby embedded is usually stuck on some outdated version. I have also not found a way to update ones bundler version or reliably use a version other than the stdlib/embedded one, when using jruby embedded (as is implicit to jruby-rack and warbler).

   In my personal view, I'd prefer to drop usage with CRuby entirely (#649), additionally because of the reasons I outlined at #324 (comment)

   But whether the native Java extension for faster zip processing is needed is debatable, probably just needs a perf test warbling something with a large number of files (e.g git gems) to see if it can be dropped at low cost. If we dropped the extension, we could possibly just compile the JarMain and WarMain files on demand (if javac available) for placement in people's wars/jars to be able to restore use of warbler from a git-sourced gem (to make development a bit less painful).
4. chadlwilson

   added a commit that references this issue on Sep 4, 2026

   fix: disable rubyzip 3.x zip64 support for CRuby

   ...

   1027dd3