In #8368 and previously #8208 we have attempted to fix the problem of classes entering JRuby from custom classloaders and getting bound into our global package namespaces simply because they were encountered first (#8156).

The changes in #8208 led to logging of interface impl hidden classes being bound and rebound:

/Users/headius/work/jruby/test/jruby/test_higher_javasupport.rb:1998: warning: already initialized constant org.jruby.gen::InterfaceImpl989326645
/Users/headius/work/jruby/test/jruby/test_higher_javasupport.rb:1998: warning: already initialized constant org.jruby.gen::InterfaceImpl989326645
/Users/headius/work/jruby/test/jruby/test_higher_javasupport.rb:1998: warning: already initialized constant org.jruby.gen::InterfaceImpl989326645
/Users/headius/work/jruby/test/jruby/test_higher_javasupport.rb:1998: warning: already initialized constant org.jruby.gen::InterfaceImpl989326645
/Users/headius/work/jruby/test/jruby/test_higher_javasupport.rb:1998: warning: already initialized constant org.jruby.gen::InterfaceImpl989326645

The work in #8368 was intended to fix that by being less aggressive about eager JI constant binding, but seems to lead to other problems:

• Without setting a constant, many imported JAva classes don't ever get a non-anonymous name.
• Some classes don't appear to be accessible when unmarshaling a stream with Java classes in it.
• Even after accessing core JDK classes like java.lang.String, the containing package does not show the constant as being set.

It seems like non-eager behavior is now to never set the constant into its package or containing class.

We need to keep eager constants enabled for the moment (temporarily done so for JRuby 10 in 8426c93 and still enabled for 9.4) and either figure out these issues or back all the way off to pre-#8208 behavior and try a fresh attempt.