I'm working on a new branch of code ("newji" on the kenai repository)
that has started to add the following features:* Ruby classes implementing a Java interface will actually be instance of a *real* Java class created on first instantiation. No more two-headed object and chicken/egg initialization hassles. * Ruby classes extending Java classes will *actually* extend those classes and be *real* instances of the resulting class. No more two-headed... This is part of a first effort to unify all the various class-generation schemes we have, from the standard JI (generating little stub classes and wrapping them) to ruby2java (generate real classes ahead-of-time that dynamically invoke via Ruby classes) to become_java! (generate real classes at runtime). The ultimate goal of this is to finally make Ruby's type hierarchy fit correctly into Java's type hierarchy, to bridge the remaining integration gap with languages like Scala and Groovy. This first step is already working very well for interface implementation. Check out this gist: http://gist.github.com/257634 This shows a Foo class that implements Runnable. When instantiated, the instance of Foo is actually *physically* an instance of the generated Java class. There's no wrapping layers at all, and the object can be reflectively manipulated. The extension logic is shown there as well, but its not as full-featured as the existing (extremely complex) logic. However filling in the blanks will not be particularly difficult, and that's what I'll be working on the remainder of this week. Next steps will be to work out how to get "initialize" and Java construction to cooperate nicely and adding back the features that the current class-extension logic does (like implementing abstract methods for you). Once the basic logic for those two halves of Java integration code generation are working as well as before, all the become_java! logic will be added. This will essentially merge become_java into normal Java integration, allowing you to add annotations, specify signatures, and so on. The final, and most complex step, will be to get this all to work ahead of time as well. This will require much more work and probably will not go into this upcoming release. Basically we need a way to determine statically) or through a minimal load process, like ruby2java does) what classes to generate, what classes they extend and interfaces the implement, and all their methods and annotations. It's not so much a code-generation problem as a Ruby DSL/parsing/compiler problem. But it's solvable, like all things. I'm starting to get very excited about this work. A change this major would start to warrant a JRuby 2.0, with one other 2.0 piece being the new interpreter/compiler. I'm starting to think 2010 is the year JRuby's finally going to meet all the loftiest goals we've set for it... - Charlie --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
