RubyGems 2.4.5 Upgrade Triggers Bug in Java Extension Loading

[bbrowning]

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

jruby/core/src/main/java/org/jruby/runtime/load/ClassExtensionLibrary.java

Line 67 in 613673a

Class theClass = runtime.getJavaSupport().loadJavaClass(className);

ends up creating the wrong package name and thus cannot load the *Service class for the Java extension. The searchName string passed to ClassExtensionLibrary's tryFind ends up looking something like "/path/to/nokogiri/nokogiri.jar" and it converts that to the class path.to.nokogiri.NokogiriService, which obviously can't be found.

Here's a gist that demonstrates this problem against JRuby 1.7.18-SNAPSHOT - https://gist.github.com/bbrowning/cda2606bd26683ea4831

[bbrowning]

CCing @Heading and @enebo - this is the RubyGems 2.4.5 and Nokogiri issue I was working through in IRC earlier today that causes TorqueBox to be unable to run its integration tests against current JRuby 1.7.18-SNAPSHOT builds.

[headius]

@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.

[enebo]

This is still causing double loads and I reverted from 1.7.19.

[mkristian]

@enebo do you remember where/how you did see those double loads ?

[headius]

This has been fixed more betterer in recent weeks and RG 2.4.5+ seems to work well now.