Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
RubyGems 2.4.5 Upgrade Triggers Bug in Java Extension Loading #2336
RubyGems 2.4.5 has some new logic that sometimes (but not always - depends on what's already loaded or not) expands require statements to absolute paths before passing them on to the original require.
Depending on the state of things, it's possible for a require statement to hit this line of code in RubyGems - https://github.com/rubygems/rubygems/blob/v2.4.5/lib/rubygems/core_ext/kernel_require.rb#L69. That code expands the thing being required to an absolute path before handing it off to the original require logic.
So, when a .jar is required via an absolute path, the logic in ClassExtensionLibrary at
Here's a gist that demonstrates this problem against JRuby 1.7.18-SNAPSHOT - https://gist.github.com/bbrowning/cda2606bd26683ea4831
@drbrain So here's the situation: in JRuby, extensions have traditionally been a jar with a specially-named class file inside based on the jar's relative path. For example, require 'foo/myext' looks for foo/myext.jar and then for foo.MyextService class within that jar.
The logic above in kernel_require seems to be causing some of those requires to become a full path. So requiring nokogiri's ext through that logic causes the ext to see a non-relative require line and it doesn't load the *Service class.
We have intended to replace the ext mechanism some day, but this is the current situation. It's not quite clear to me why the ext require would end up going through that logic...maybe you can help us understand how that could happen if a library simply requires 'nokogiri' after the gem has been activated.
We're contemplating fixes for this, but in the short term it could be a serious problem.