Bill Dortch wrote:
What breaks is the ability to go to lower-level Java support, get a JavaMethod object directly, and invoke it to get the original wrapped JavaObject. Largely this capability was used in the old JI code to implement the normal Java integration features; with most of those "higher" Java support features now in 100% Java code, this may not be necessary anymore.So I think Bill and I are going to need to get together to determine how this is all supposed to fit together in the future. I'm not comfortable just breaking lower-level Java support across the board without knowing if I'm breaking something higher first. But the split between lower and higher and the overhead of wrapping so many objects is probably going to have to go.I foresee pretty much all of the JavaXxx classes (JavaObject, JavaMethod, etc.) going away, which will certainly break some code. I've been working on a JI model doc and some (currently non-functional, very experimental) code in the bdortch-bnw branch (not yet uploaded to SVN). Among other things, I've been looking at implementing most Java types (and their corresponding Ruby types where there's a direct mapping, see table below) as lightweights ( i.e., not wrapped at all) -- the model includes a metaclass Registry, among other things -- so coercion (except for primitive -> object) mostly goes away. I'll get some of the code uploaded over the weekend, and will post the doc somewhere for review and discussion. Again, very experimental stuff, so don't be too alarmed (yet :) ). Do feel free to comment in advance of the doc, all input welcome!
Yeah, now you're starting to talk about what Tom and I have been wanting for a while, true lightweight support. We've talked in most discussions about globally doing lightweights, but in my experiments it would be very difficult to move to a full-on Groovy-like "detached metaclass" model without paying some performance penalty in the core types. But the detached metaclass module would work superbly for non-Ruby Java objects, so this is absolutely appropriate to look into.
We need to give a little thought to timeframes here. If it's possible to break lower Java support in the interim while getting a substantial performance improvement it would probably be worth it. In the simple example I've been posting we see a 6x perf improvement just by making return-value coercion work better for a Fixnum-like type. So if we can make a reasonable case for breaking the public APIs of lower Java support, we could get a nice perf boost while waiting for the "lightweight" rework.
Bill: do keep very close communications and try to find ways the rest of us can help make this happen faster. That will also ensure we understand the new way and will be able to help maintain and evolve it.
- Charlie --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
