> > 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!
-Bill *** EXPERIMENTAL !!! *** MetaClass Registry mappings. Can map classes and/or specific values/instances. Java type => Ruby type mapping null => NilClass Boolean.TRUE => TrueClass Boolean.FALSE => FalseClass java.lang.Byte => Fixnum java.lang.Character => Fixnum (not sure if this is right) java.lang.Short => Fixnum java.lang.Integer => Fixnum java.lang.Long => Fixnum java.lang.Float => Float java.lang.Double => Float java.math.BigInteger => Bignum (may have to coerce to java.lang.Integer => Fixnum) java.lang.String (from Java) => String (minimally wrapped, not converted to ByteList unless/until necessary) java.lang.String (internal) => Symbol Also playing with this idea: java.lang.Object => Object i.e., Java::java.lang.Object == Object Also playing with this idea: <?>[] => Array (maybe wrapped, see upcoming doc for discussion) any java.util.ArrayList => Array (maybe wrapped, see upcoming doc for discussion) any java.util.Map => Hash (maybe wrapped, see upcoming doc for discussion) Looking at *all* objects implementing a java_class method. This would return an instance of java.lang.Class. No JavaXxx wrappers, possibly some helper methods added. etc. *** EXPERIMENTAL !!! ***
