On Mar 25, 9:41 am, helge <[EMAIL PROTECTED]> wrote: > Hi, > > looking through WrapFactory.wrap(), java.lang.Class objects are not > wrapped in NativeJavaClass but in NativeJavaObject. Is this > intentional or a bug? > > It gives me some weird behaviour when a Class travels from a) JS to b) > Java back to c) JS. > In a) its still a NativeJavaClass, > in b) Context.jsToJava() aka NativeJavaObject.coerceTypeImpl() its > unwrapped to java.lang.Class > and in c) WrapFactory.wrap() its wrapped in NativeJavaObject. > The result is that static methods/props can't be invoked anymore. > > Thanks, > Helge
There are two representations of classes here: the class and the class object. A class object is "Foo.class" in Java and is a NativeJavaObject wrapping a class in Rhino's runtime. A class is "Foo" in Java and a NativeJavaObject in Rhino runtime. The first is an object that has methods of java.lang.Class, and the latter has fields and methods that are the static fields and methods of the Foo class. So the question is then what WrapFactory.wrap() should do. If we call a method "public Class bar()" the java.lang.Class should be wrapped by a NativeJavaObject so that "bar().getConstructors()" works in Rhino as it does in Java. You're right that the steps you describe above don't produce a round trip. The reason is simply that the main purpose of wrap() is to handle values returned from Java method and field accesses, and there is no way to return a class (as opposed to a class object) from these. So I think WrapFactory.wrap() does the right thing now, but I can see a missing piece of functionality in the API. How does this come up for you? What are you trying to do? --N _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
