On Sat, Jan 16, 2010 at 1:21 PM, Yoko Harada <[email protected]> wrote:
> Do you already have this new JRuby runtime in somewhere? If you have,
> I want to start using classloader-global runtime for emedding API.
> Current thread safe model works under a limited case. I think I should
> rethink thread safe concurrent evaluations from its design. The idea
> of classloader-global and classloder subdomain could be the answer.
> Besides, like Kevin's case (jruby -> rails -> java(embedding) ->
> ruby), we need static runtime in some cases. There might be issues to
> be solved such as states that current runtime has, but I think we'll
> be able to find the best way to manage them.
I have not answered the various replies here, and I know I owe you all
that. For the new jrubyc --java support I am using
org.jruby.Ruby.getGlobalRuntime, which just initializes a static
field. If you have isolated JRuby into separate classloaders, this is
equivalent to having a classloader-global runtime.
I'm trying to think through the implications of a classloader-global
runtime for people that currently use org.jruby.Ruby directly. It's
not altogether clear to me how best to isolate an entire set of JRuby
classes and still have it accessible for embedders. If you write code
that accesses org.jruby.Ruby, for example, you're also referencing
RubyString and friends. There needs to be some new top-level class
embedders would use (perhaps the JSR223 stuff? perhaps something new?)
that doesn't directly reference those classes and knows how to load up
a new classloader with JRuby classes, instantiate a JRuby instance,
and hand it off...
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
