On Fri, May 2, 2008 at 6:00 AM, Christian Seiler <[EMAIL PROTECTED]> wrote:
> Charles Oliver Nutter-2 wrote: > > > > - Classloader-based runtime separation; instantiating a JRuby instance > > instantiates a new classloader and all of JRuby runs under that. This > > would isolate JRuby instances and allow access to the runtime through > > getClass().getClassLoader().getRuntime() always rather than having to > > have a Ruby metaclass around. This in turn would make it possible to do > > things like normal Java serialization, instantiable Ruby types without a > > runtime passed in, and more. We need to revisit this and try to make it > > happen. > > > > Wouldn't that mean that JRuby instances can't easily share objects any > longer? I'm thinking of things like Rails instances sharing an EHCache or > Spring application contexts. This is really a sweet spot of JRuby IMO that > you can efficiently share data inside a single JVM without the need to do > any inter process communication (as long as you don't need to scale out). Actually they can, as long as shared object classes are loaded by a common parent classloader. It would work if the JRuby instances have a single common classloader (application classloader, servlet context classloader, ...) and shared object classes were loaded by this parent classloader. Charles, I'm not sure if this feature would really be positive, but I'm not so confident with JRuby internals. I can only see some of the possible drawbacks that should be considered: - It would be like a "global access" to Runtimes. Any semelhance with thread-local variables? - It would require an ugly cast to RuntimeClassLoader, as getClass().getClassLoader() doesn't have getRuntime(). Cheers, -- Fabio Kung http://www.fabiokung.com
