JSObject and delegation to other java classes

[A. Sundararajan]

Will this sample of any help to you?

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/34a783929a67/samples/jsobj_example.js

PS. JSObject is meant for very lightweight script-like objects - says 
remote objects (where net latency is much more than proxying calls etc.) 
or expose database records as script-friendly objects and so on. If you 
want to mix-n-match Java objects + JSObjects, doing it scripts is better.

Thanks,
-Sundar

On Sunday 20 July 2014 09:09 PM, Marc Downie wrote:
> Dear Nashorn-dev,
>
> I'm building a JSObject-implementation-based to a fairly complex Java class
> --- in order to present a more JavaScript-flavored façade to some Java and
> I'm finding that I have to build a tremendous amount of boilerplate to call
> existing Java methods in a JSObject. You can see where this is heading in
> your own example code (
> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions):
>
> ...
> public Object getMember(String name) {
>         switch (name) {
>            case "length":
>                return buf.capacity();
>            case "buf":
>                // return a 'function' value for this property
>                return new AbstractJSObject() {
>                    @Override
>                    public Object call(Object thiz, Object... args) {
>                        return BufferArray.this.buf;
>                    }
>                    // yes, I'm a function !
>                    @Override
>                    public boolean isFunction() {
>                        return true;
>                    }
>                };
>         }
>         return null;
>      }
> ...
> Imagine this code copied and pasted out to 50-odd methods & fields.
>
> Question 1: have I missed something?
>
> My main use case is actually less general:
>
> public class ClassWithBigAPI
> {
>      .... many methods and fields ...
> }
>
> public class JSMassageLayer extends ClassWithBigAPI implements JSObject
> {
>      ...
>      public void getMember(String n)
>      {
>          // how to lookup and return all methods and fields in super?
>      }
> }
>
> Question 2: is there something better that I can return than a whole new
> AbstractJSObject? I've gotten some distance by returning
> (SomeFunctionalInterface)this::someMethod, but I can't build those
> automatically. In my case all I want is the standard method / field lookup
> that I would have gotten before I implemented JSObject if that would
> succeed. As far as I can tell, not only is this cumbersome to write and
> maintain (even building these AbstractJSObject's based on reflection of the
> class I'm delegating too), but it seems non-performant and loses
> functionality that's hard to restore (for example magic SAM conversion on
> calling). For example, is there a sane (and api-legal) way of building
> SimpleDynamicMethod/OverloadedDynamicMethod instances?
>
> Question 3: is this a real design problem? In other languages / interfaces
> to languages there's a distinction made between a "getMember" that's called
> for all member lookup and a "getMember" that's called when other, standard
> member lookups fail (for example __getattr__ / __getattribute__ in
> python/jython, groovy invokeMethod / methodMissing). Other languages /
> runtimes privilege the second case (Ruby methodMissing, Scala's
> selectDynamic). I've found Jython's functionality here, in particular,
> vital to creating Pythonic interfaces to already-existing Java things, but
> I was hoping to move my whole operation over to Nashorn.
>
> Finally, I've also tried, in JS, new JSAdaptor(new ClassWithBigAPI()){ ...
> }, but that doesn't seem to get me anywhere --- unexpectedly, __get__ is
> still called for things that are in ClassWithBigAPI. Of course, being in JS
> gives me more options, so I'm pursuing that route for now.
>
> many thanks,
>
> Marc