@mkristian very najs find! wonder if its worth the "startup cost" to issue a gem() call that previously didn't happen. also maybe the if defined?(DidYouMean) could use some explanation where its being defined.

@kares did look a bit further and there is more then this commit to it. first I thought it is the gem() but even the require 'did_you_mean' does trigger a search through all installed gems, which needs the Gem.path to be set. a workaround all this is to Gem.clear_path inside jruby-rack. but currently you can not set gem.path inside the web.xml as it has no effect

sounds like a jruby.rack.gem.path env/web.xml setting would be necessary anyway? also this has other consequences to be considered - would anyone want "did_you_mean" to be "messing" on env.production?

let's reduce the regression to a simple example:
jruby-9.0.x.0

$ jruby -v -e "ENV['GEM_PATH']='.';p Gem.path"
jruby 9.0.5.0 (2.2.3) 2016-01-26 7bee00d Java HotSpot(TM) 64-Bit Server VM 25.72-b05 on 1.8.0_72-ea-b05 +jit [darwin-x86_64]
[".", "/Users/cmeier/.rbenv/versions/jruby-9.0.5.0/lib/ruby/gems/shared"]

and jruby-9.1.0.0-SNAPSHOT

bin/jruby -v -e "ENV['GEM_PATH']='.';p Gem.path"
jruby 9.1.0.0-SNAPSHOT (2.3.0) 2016-04-26 af9095f Java HotSpot(TM) 64-Bit Server VM 24.79-b02 on 1.7.0_79-b15 +jit [darwin-x86_64]
["/Users/cmeier/.gem/jruby/2.3.0", "/Users/cmeier/projects/active/jruby/lib/ruby/gems/shared"]

for the record the other DidYouMean part is coming from https://github.com/jruby/jruby/blob/e05ec8/core/src/main/java/org/jruby/Ruby.java#L1303-L1305 ... simply handling did-you-mean being disabled.

Tick tock gentlemen :-)

What if we just make it try to require 'did_you_mean' without activating the gem?

the problem is that when require fails that rubygems will go though
Gem.path and this is where ENV['GEM_PATH'] gets parsed and any
later changes on GEM_PATH gets ignored. so the problem is not the
gem() but the require

as @kares asked before where we need did_you_mean in production, i.e. for
the ScriptingContainer we could have a different default or something in
this direction.

Yeah that is a pain...there's no good option.

I see two paths forward:

1. We just remove it and it's not a feature of JRuby out of the box.
2. We make it a default gem so it's always requirable without going through RubyGems.

I'm going to chat with @tenderlove today about options.

We are going to punt this decision to 9.1.1.0.

@headius with commit 3dc2acf the j2ee tests are green again - we should move them back to the "not-allowed-failures" again ?!

@mkristian Seems fine to me if they're passing. It's obviously something we'll have to deal with when we do get DYM in place.

9.1.1.0 has become a quick regression-patching release, so bumped this to 9.1.2.0.

already fixed with #3892 and travis -Pj2ee is also green again.