jruby -v) and command line (flags, JRUBY_OPTS, etc)$ jruby -v
jruby 9.2.1.0-SNAPSHOT (2.5.0) 2018-07-31 cbccb8d Java HotSpot(TM) 64-Bit Server VM 25.181-b13 on 1.8.0_181-b13 [linux-x86_64]
uname -a)$ uname -a
Linux li1554-157.members.linode.com 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Other relevant info you may wish to add:
$ env |grep RUBY
JRUBY_OPTS=--dev -J-Xmx2048M
RUBY_CONFIGURE_OPTS=--disable-install-doc
Gemfile# frozen_string_literal: true
source "https://rubygems.org"
git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
gem "rails"
gem install bundler$ gem install bundler
bundle install$ bundle install
Bundle should pass.
NoMethodError: undefined method `dep' for #<Gem::Dependency:0x100c8b75>
Did you mean? dup
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/dep_proxy.rb:18:in `=='
org/jruby/ext/set/RubySet.java:639:in `add?'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/spec_set.rb:27:in `block in for'
org/jruby/RubyKernel.java:1412:in `loop'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/spec_set.rb:25:in `for'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/definition.rb:810:in `converge_locked_specs'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/definition.rb:248:in `resolve'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/definition.rb:204:in `missing_specs'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/definition.rb:209:in `missing_specs?'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/installer.rb:284:in `resolve_if_needed'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/installer.rb:83:in `block in run'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/process_lock.rb:12:in `block in lock'
org/jruby/RubyIO.java:1154:in `open'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/process_lock.rb:9:in `lock'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/installer.rb:72:in `run'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/installer.rb:25:in `install'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/cli/install.rb:65:in `run'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/cli.rb:224:in `block in install'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/settings.rb:136:in `temporary'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/cli.rb:223:in `install'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/cli.rb:27:in `dispatch'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/cli.rb:18:in `start'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/exe/bundle:30:in `block in <main>'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/home/yahonda/git/jruby/lib/ruby/gems/shared/gems/bundler-1.16.3/exe/bundle:22:in `<main>'
org/jruby/RubyKernel.java:997:in `load'
/home/yahonda/git/jruby/bin/bundle:1:in `<main>'
This issue has been triggered since https://github.com/jruby/jruby/pull/5215. Then reverting this merge commit workaround this issue.
$ git revert -m1 e483fb2251845b7bb3ff1ac99aa5760699438ffe
@yahonda Thank you for the report!
@ChrisBr Guess we still have a few kinks to work out.
Grml :cry: I will look into it @headius ...
Ok, I tracked this down now. This is a combination of two things:
1) When using the open addressing strategy, we do not cache the hash value of the keys anymore (we only do that for linear search). This means when a collision happens, we do == on the keys.
2) In bundler the DepProxy class implements == but does not check the class of the other object. This is combination with 1) causes this error.
I already submitted a fix to bundler, see https://github.com/bundler/bundler/pull/6669. However, probably we need to fix this on JRuby side as well as we don't know if bundler accepts the fix and when the will release a new version (and also we can not rely that all our users update to the new bundler version ...) :cry: So the only solution I see for now is that we always cache the hash value now.
cc @headius @enebo what do you think?
Thanks for the fix. I have confirmed this issue has been addressed by this version.
$ ruby -v
jruby 9.2.1.0-SNAPSHOT (2.5.0) 2018-07-31 067b279 Java HotSpot(TM) 64-Bit Server VM 25.181-b13 on 1.8.0_181-b13 [linux-x86_64]
Most helpful comment
Ok, I tracked this down now. This is a combination of two things:
1) When using the open addressing strategy, we do not cache the hash value of the keys anymore (we only do that for linear search). This means when a collision happens, we do
==on the keys.2) In bundler the
DepProxyclass implements==but does not check the class of theotherobject. This is combination with 1) causes this error.I already submitted a fix to bundler, see https://github.com/bundler/bundler/pull/6669. However, probably we need to fix this on JRuby side as well as we don't know if bundler accepts the fix and when the will release a new version (and also we can not rely that all our users update to the new bundler version ...) :cry: So the only solution I see for now is that we always cache the hash value now.
cc @headius @enebo what do you think?