merged manually and ensure that the API of runtime.getJRubyClassLoader remains the same.

but there's no longer a tearDown method on JRubyClassLoader ?
... also if it's only master I'll look at removing the org.jruby.util.JDBCDriverUnloader and related method
would instead prefer the ability to manually register "tear-down" runnables, do you have any notes on that?

runtime.getJRubyClassLoader still exists. how do you call the
tearDown method

well, I recall seen it called "normally" from Java code somewhere around ... personally I've been just calling it from Ruby during some re-deploy hacks. I guess I can expect that do still work, so it shall not matter.

I see there some reasoning behind the refactoring, although on first look it seems that changes such as these might turn out difficult for some "advanced" JRuby users interacting with the API ( asssuming there are some - tooling such as opus migth have used some of the JCL internals) to migrate to 9k - as more is not always "better" :) ... just my 2 cents for a late review.

I was more interested on whether it's completely unnecessary to be able to register un-load hooks (I needed it previously but in the end come up with a different work-around) ... kind of like at_exit but directly on the CL (Java side) similar to the JDBCDriverUnloader or is there another way somewhere already, do you happen to know ?

@kares thanx for the input. @headius had similar thoughts as you.

what I could do is: rename the JRubyClassLoader to
ClassDefiningJRubyClassLoader and the new DynamicJRubyClassLoader
to JRubyClassLoader. which does not break the direct usage of the
JRubyClassLoader which might be around in the wild but replaces all the
internal usage of ClassDefiningJRubyClassLoader to the thin version of the
ClassLoader.