I don't fully grok the implications of this, but like the other responder, I'm managing a lot of individual Ruby runtimes. Some share the same ruby classes (rails, app code), some need to be independent.

I've really enjoyed being able to control the classloader I hand to the Ruby upon creation, so it's a leaf on my larger CL tree.

Would this break?

        -Bob


On Jan 6, 2010, at 10:43 AM, Thomas E Enebo wrote:

It should also be stated that if this work impacts users too much then
it will be our motivation to move to a new major version of JRuby
before putting it in.  If the impact is minimal then it makes things
so much easier for us since we won't have a maintenance branch to
support.  That said, we need users feedback to access what issues are
involved before we can schedule this for a release.

-Toim

On Wed, Jan 6, 2010 at 8:58 AM, Charles Oliver Nutter
<[email protected]> wrote:
Ok, it's time to start biting off a big change: we need to make the
JRuby runtime be classloader-global (i.e. static).

There's many reasons for this:

* You won't have to pass a Ruby instance into object construction
* Serialization will work, since it will just be able to grab the
classloader-global Ruby instance when constructing
* All core classes will be able to start inline caching calls back to
Ruby (where they do almost *no* caching right now)
* Replacing arbitrary pieces of Java code with Ruby code will be *much* easier

And the list goes on.

Perhaps the most important person I'd like to see in this discussion
would be Yoko Harada, since it may be possible to hide all this behind
RedBridge and the 223/BSF engines. But I'd like to hear from others
interested in the above features/changes, or from anyone with concerns
about how this change might affect their code.

For the record, this will almost exclusively impact only users
embedding JRuby or calling into JRuby from non-Ruby code. Users
running plain-old-Ruby probably will never see any real impact.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






--
blog: http://blog.enebo.com       twitter: tom_enebo
mail: [email protected]

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


Reply via email to