Allow visible fields from inherited Java classes show up as instance variables (@foo)

Do we expose these now as attrs? Exposing as an instance var could be very tricky, since it would require hooking into (and potentially slowing down) hash-based lookup of non-field ivars.

Can't we make a reference type which we can then store in a hash? Then when we create the JI class we add one shadow/reference type per field. The cost of access would be slower for those, but I do not think it would affect anything else? To say it yet another way...the same way we hook up global vars.

I've been thinking about adding a reference type for a while now, though not in the 1.1 time-frame. My use case has been providing support for data binding and other such goodies – not directly in JRuby, probably as a gem, but with the underlying support/framework provided by JRuby. I've also been thinking about (possibly as an alternative) providing an event listener mechanism, so that code could register/listen for property events, including (but not necessarily limited to) ivar/cvar/constant events.

There will be some performance considerations with either of these approaches, but I think the impact can be minimized if done correctly.

BTW, I've also been thinking about using a reference type as part of an alternative method caching strategy, but I haven't had time to fully work this out. (Basically, a CacheSite [such as InlineCachingCallSite] would obtain a MethodReference, which would remain valid for all time [though the (volatile) referenced method might change]. The MethodReferences would be cached at the metaclasses where the methods were referenced. An event listener mechanism would be used to keep them up to date. As I said, not fully worked out.)

In general, I think we should consider building an event mechanism into JRuby 2 that will support listening for a number of internal event types. We should also consider exposing this mechanism through Ruby, via a gem or other optional module. Among other things, we could provide a superior (but non-standard and therefore necessarily optional) alternative to the rename-override-call_renamed approach of hooking events like :method_added.

Some internal code could also be refactored to use the new event mechanism.

... it strikes me that people will expect visible fields to be represented in Ruby-space as instance attributes.

I'm not sure people really expect it – there are plenty of pure-Ruby types that do not expose all their internal state through ivars. And the case you cite raises the issue of whether we should expose protected fields. Also, JIRB output could become painful to look at if inspect always dumped all internal variables. And finally, it would become difficult to distinguish "true" ivars from pseudo-ivars. Some confusion and phantom support issues might arise.

Still, it is an appealing idea, and could probably be made to work, though possibly with some flags to control some aspects of the behavior.

BTW, this will be easier to do once we've broken the RubyObject/IRubyObject stranglehold, and can simply supply an alternative vars implementation for Java classes. JRuby 2...

re:

plenty of pure-Ruby types

meant to say "core" Ruby types, i.e., implemented in C or Java

We've discussed this numerous times, but in general have decided not to expose Java fields as instance variables. They behave too differently, and the overhead of making instance-variable logic polymorphic just to support custom logic for Java classes does not seem like it's worth it. We have since provided other mechanisms for exposing fields (like field_reader, field_writer, etc), so I think exposing them as ivars is no longer necessary.