While the tagline of RubySpec is actually “The Standard You Trust” it might as well be “Monkeypatch with Confidence”.
Here’s the backstory:
Building TorqueBox, I ultimately wanted to be able to run a Ruby application from within a simple zip bundle of the app. And handling everything that expects to be living in a relatively-addressable filesystem. Not just require and load, but things like Dir['*.png'] and File.stat(…).
Plus, JBoss (upon which TorqueBox is built) has this cool ability to think of a jar-within-a-jar-within-a-jar (or a Russian doll nesting of zip files) as still a simple directory-based filesystem.
JRuby, though, isn’t quite as swift, in terms of paths for standard core library things such as File, or Dir, or IO.
To get this JBoss functionality (called VFS for Virtual File-System) exposed to any arbitrary Ruby code, I’m having to monkeypatch File, Dir, IO and other classes.
For the most part, the rule for how these patches jack in is “if this is a normal file/directory/io, let the normal core library handle it, otherwise, punt to VFS”.
Given this rule, with VFS turned on, all existing code that doesn’t touch these zip/jar bundles should exhibit no regressions. A great way to test that is using RubySpec. I’m approaching this problem as treating JRuby-with-VFS as a new implementation of Ruby, to be tested alongside general JRuby support. Enabling VFS should not cause JRuby to become any less compatible with the specs.
Contributors to the VFS gem can now easily run the applicable RubySpecs against JRuby both with and without VFS enabled.
Recent Comments