Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Classloaders #2241

Closed
wants to merge 2 commits into from
Closed

Classloaders #2241

wants to merge 2 commits into from

Conversation

mkristian
Copy link
Member

@mkristian mkristian commented Nov 25, 2014

No description provided.

mkristian added 2 commits Nov 25, 2014
* 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
@mkristian
Copy link
Member Author

@mkristian mkristian commented Nov 26, 2014

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

@mkristian mkristian closed this Nov 26, 2014
@kares
Copy link
Member

@kares kares commented Nov 26, 2014

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?

@mkristian
Copy link
Member Author

@mkristian mkristian commented Nov 26, 2014

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

@kares
Copy link
Member

@kares kares commented Nov 26, 2014

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 ?

@mkristian
Copy link
Member Author

@mkristian mkristian commented Nov 26, 2014

@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.

@mkristian mkristian deleted the classloaders branch Apr 28, 2015
@headius headius added this to the Invalid or Duplicate milestone May 4, 2015
@headius headius added this to the Invalid or Duplicate milestone May 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants