Ok, I see the problem here. Currently, here's the rough order in which we search for libraries in response to a require call:

1. Search for a "builtin" with .rb extension
2. Search as a jar: or file: URL with .rb extension
3. Search load path with .rb extension
4. Search for a "builtin" with .so extension
5. Search as a jar: or file: URL with .so extension
6. Search load path with .so extension
7. Search classloader resources with .rb and .so extensions

And this continues through a few other phases. The problem is that while the thread.rb file is available through the classloader (in jruby-complete.jar) we find the built-in thread.so library sooner, which causes us to skip loading the thread.rb where Thread.exclusive is defined. We don't want to move the classloader searching further up the chain since it's a little slow and most resources will be on command line anyway. But this does underscore the need for us to formalize the load process better than it exists currently, and possible always try JRuby's parent classloader for the resource so jruby-complete.jar works like you would expect.

Marking for 1.2.

I was unable to come up with a good non-invasive fix for this in 1.2 timeframe, so we're going to punt to 1.3. I think another round of cleanup for LoadService is in order, but this may simply be a case where no solution is perfect.

Still not sure the best way to fix this. The simplest one I can think of would be to move the remaining thread.rb stuff into Java so it loads all at once with Thread.exclusive defined...