JRuby Embed (Red Bridge) Update: configuration and global runtime

Here're recent updates of JRuby Embed (Red Bridge). Since I wrote about updates last time, Red Bridge's API has been changed a lot around configuration. Although this would directly affect to users' code, new API is easier to use and more stable. For example, setting jruby home directory has been changed from the fist to second one below:

[JRuby 1.4.0]
ScriptingContainer container = new ScriptingContainer();
container.getProvider().getRubyInstanceConfig().setJRubyHome(jrubyhome);

[JRuby 1.5.0.dev]
ScriptingContainer container = new ScriptingContainer();
container.setHomeDirectory(jrubyhome);

As you see clearly, getProvider().getRubyInstanceConfig() was gone. This is to hide JRuby's internal API so that internal API changes won't force users to adjust thier code. This also fixes the problem that current Red Bridge API exposes internal API too much and doesn't absorb internal changes well enough. To absorb internal changes is a Red Bridge's job, and by this update, more jobs have been covered. Other than get/setHomeDirectory(), we had following configuration methods in ScriptingContainer.

• get/setInput
  
• get/setOutput
  
• get/setError
  
• get/setCompileMode
  
• get/setRunRubyInProcess
  
• get/setCompatVersion
  
• get/setObjectSpaceEnabled
  
• get/setEnvironment
  
• get/setCurrentDirectory
  
• get/setHomeDirectory
  
• get/setClassCache
  
• get/setClassLoader
  
• get/setProfile
  
• get/setLoadServiceCreator
  
• get/setArgv
  
• get/setScriptFileName
  
• get/setRecordSeparator
  
• get/setKCode
  
• get/setJITLogEvery
  
• get/setJITThreshold
  
• get/setJITMax
  
• get/setJITMaxSize
  

Please go to API documantation and JRuby Options to know what are those.

The second update info is about global runtime. The "global runtime" means a static instance of Ruby runtime (org.jruby.Ruby) and, now, is used in a singleton model. The singleton model is a default local context type in JRuby 1.5.0, so unless users choose threadsafe or singlethread models explicitly, they will use static, JVM global Ruby runtime. Changing it a JVM global instance, we are supposed to get exactly the same Ruby runtime instance everywhere on a single JVM. This would be useful for some cases such as using Red Brdige for DSL. Meanwhile, we should be careful when Ruby code gets run on multi-threaded environment. Since Ruby runtime holds many states, most of them will be shared globally.

Red Bridge is still under the way to the stable API and may have more changes. However, it is surely on the way to more feasible API. Please feel free to suggest new methods or features over Red Bridge.