This isn't a factor of being implemented in Ruby; rather, it's a factor of having access to all internals as normal objects. And although MRI doesn't provide that capability, JRuby does:
<pre> require 'java' require 'jruby'
def examine(obj) real = JRuby.reference(obj) realclass = JRuby.reference(real.meta_class) while realclass p realclass break unless realclass.super_class realclass = JRuby.reference(realclass.super_class) end end
object = Class.new { def foo; 'foo from object'; end }.new mixin = Module.new { def foo; 'foo from mixin'; end }
object.extend(mixin) examine(object) </pre>
In JRuby, as in Rubinius, all objects can be accessed as "just objects". So the same capabilities apply.
I'd strongly suggest you let the GlassFish guys know that the memory footprint is uncomfortably large. They've already started really excellent work in GlassFish V3 to make it smaller and faster and allow it to load only what you need (which in the case of JRuby on Rails wouldn't be much). And they're also keen on making JRuby on Rails a realistic option for Rails developers, so they'd love to hear from you. More input would mean more pressure to improve the GlassFish gem and to get production-ready releases of GlassFish V3 out the door.
JRuby, not jRuby. Thanks for the kind words and congratulations on a great project. I agree the future is bright for JRuby. I hope we'll have opportunities to work together...in the open...in the future.