Hi Charlie, On Wed, Jan 6, 2010 at 9: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.
Basically, I agree with these ideas. Embedding API's getRuntime() method exposes internal API too much, so it should be hidden. But, I have a concern when embedding API is used to web applications. I'm hoping my knowledge is obsolete and current Java web servers don't have this problem since I haven't written a web application for long time. Java based web applications such as Tomcat can have multiple web applications (multiple wars) on a single web server instance. When one of the web applications, I mean one of the wars, instantiates Ruby runtime, other web applications activated later are unable to use Ruby runtime because of custom classloader of the web servers. Before, Apache Velocity (web presentation layer tool) container had this problem. The classloader subdomin of Groovy model, which Charlie talked at IRC, might be the answer, but I don't have any knowledge about it right now. I'll go Groovy to see what it is. I have one more concern about global variables. Once Ruby runtime becomes static, global variables will be VM wide variables. Is my understanding correct? If so, I'm worrying whether users, all users, are using global variables as globally referenced, VM wide ones. I'm hoping I mind this too much, but it may cause a web application vulnerability. I think global variables are better to be managed by somewhere else other than the Ruby runtime instance. > 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. Indeed, especially, people who have used Ruby runtime directly. For example, Ruby#evalScriptlet() will be deprecated? -Yoko > > - Charlie > > --------------------------------------------------------------------- > 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
