Classloaders #2241
Classloaders #2241
Conversation
* only the classloader runtime.getJRubyClassLoader needs to have all the extra features. all other classloaders just needs to be able to define classes and do not need the extra overhead of loading and finding resources and adding jar files during runtime. * the OneShotClassloader is only used with runtime.getJRubyClassLoader so ensure this relation via types * the JRubyClassLoader is used at various places also as "flag via instanceof". keep this and all other uses of JRubyClassLoader as it was before * replace on use of OneShotClassloader with JRubyClassLoader to check if it possible to load byte code at runtime
|
merged manually and ensure that the API of |
|
but there's no longer a |
|
|
|
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 |
|
@kares thanx for the input. @headius had similar thoughts as you. what I could do is: rename the JRubyClassLoader to |
No description provided.