I happen to know a bit about Ruby. (A lot more than I know about Java, as it happens.) Let me pick a few nits :)

#instance_variable_get / #instance_variable_set is a thing. The (default) implementations of these methods on Object are just C code that do direct IVar reads/writes. You can thus think of #instance_variable_get and #instance_variable_set as real “field access” in Ruby. It’s just that, unlike most languages, there is sugar† for the getter/setter, and there isn’t any sugar for the “direct” field access.

† (The setter’s sugar is obvious — `a.b=x` is re-written by the lexer into a call `a.send(:"b=", x)`. The getter’s sugar is less obvious — it’s seemingly just a regular method call. But think about why Ruby makes parens optional on arity-0 method calls in the first place. To sweeten getters into something field-access-looking!)

But, well, you might say, #instance_variable_get is just a method, too! I can override it as I want! Really, it’s just another kind of getter/setter — sort of a categorical one.

Well, let’s go one level deeper — you can literally “reach into” the object to take a look at its IVars as it sees them:

    obj.instance_eval{ @foo }

“Objection! #instance_eval can be overridden! DRb proxy-objects do it!”

Well, okay, let’s get creative, and start breaking through the seemingly pure-OOP semantics of Ruby, revealing the more functional-language underpinnings:

    inst_eval_fn = Object.instance_method(:instance_eval)
    inst_eval_fn.bind(obj).call{ @foo }