As a follow-up to Tom's undesired side-effect, would you expect this to work:
include_class 'java.util.ArrayList' a = ArrayList.new include_class 'java.util.List' class List def something end end a.something I had hoped perhaps we would only have to "proxy" superclasses/interfaces that had already been loaded into Ruby-world, but that would not allow the above to work since ArrayList would already have been loaded and instantiated; basically, the "List" class created when ArrayList is loaded ends up being different from the "List" class loaded and proxied later. It would be nice to avoid the initial hit of proxying all superclasses/interfaces (especially considering some classes that have many superclasses and interfaces) but perhaps it's not easily achieved. - Charlie On 2/8/06, Thomas E Enebo <[EMAIL PROTECTED]> wrote: > Yeah this seems to be a bug to me and I will enter it as such. I think > this fits into the general Ruby way of looking at things (the class > definition should always be open and inherited classes should still see > the changes). To fix this we need to make loaded Java classes in turn > load their inherited classes/interfaces as proxies (right now we just > wrap the class as a single proxy and ask java if we can invoke methods on > it). > > I do have a work-around and I just realized our workaround has some > undesired behavior in it: -- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Jruby-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jruby-devel
