On Mar 26, 3:50 pm, Norris Boyd <[EMAIL PROTECTED]> wrote: > You're right that it's unfortunate that jsToJava and javaToJS don't > roundtrip. The fundamental problem is that there are two namespaces,
Yes. Actually your NativeJavaClass is more like a shortcut to a 'someclass.__statics__' trampoline. In Java itself there is only one namespace at runtime. But this is nitpicking ;-) Hm, too late to change the API that way, but maybe the __prototype__ of a Java Class object on the JS side should have been a ClassStatics object (or the other way around). This way class.getConstructor would work, and class.myStatic too. The latter would do class.__prototype__.myStatic. If java.lang.Class object would shadow a static function/variable, you could still access it using explicitly __prototype__ (but in practice this would be sounds quite unlikely?). > So you're proposing unifying the class object and the static class > namespaces? That definitely wouldn't work as far as its impact on > backwards compatibility Thats certainly an issue. Maybe the behavior could be only fixed ;-) when a certain flag is set, like with dynamic scopes? Context.FEATURE_AWESOME_CLASS_SCOPE > and it would seem counterintuitive to have, > for example, java.lang.String.valueOf(...) and > java.lang.String.getConstructors() both be valid. Don't know. Its counterintuitive from a JS/Java perspective, but its what all other reasonable languages do ;-) > Your change to your custom WrapFactory doesn't seem like it would work > if you had a class object in the map as it would be mapped to a class. It basically eliminates the possibility to access the java.lang.Class methods on the JS side, thats right. Should be OK for my requirements. I don't really expect the user to do reflection on Java in JavaScript :-) On the Java side everything is always OK because a Class in Java is always an instanceof Class object (whether you plan to dynamically access statics or reflection). Other Java code can't deal with NativeJavaClass anyways. > What if you just used the scope's storage rather than creating your > own map, or if you stored the values from the scope in your map > without calling jsToJava? I would still need to do the conversion when the Java side gets/puts values into the scope. It doesn't really change the core problem. Well, it would be marginally better because the Java side is less likely to write Class value slots (this is mostly importPackage in my setup). Anyways, so far I'm happy with my solutions, though I think that my __prototype__ is quite awesome ;-) Thanks, Helge PS: the other thing I find most annoying in Rhino :-), is that Scriptable, especially NativeJavaArray, is not a java.util.List/Map. And there seems to be no way to hack around this w/o touching the source :-/ _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
