If your java_type_object.someMethod method's signature is something like:
void someMethod(JSObject obj) { }
then from nashorn side, you can pass script objects and your java code
would receive it as JSObject.
java_type_object.someMethod({k: 1});
should work fine in that case. To operate smoothly on
JsonObject/JsonArray on script object is somewhat involved. You may have
to use JSAdapter or JSObject wrapper over your Java object for script
friendliness...
Regards,
-Sundar
On 10/28/2016 7:35 PM, Paulo Lopes wrote:
> Hi everyone,
>
> I'm working with eclipse vert.x project javascript support and one
> thing we would like to achieve was to simplify our bindings code by
> having what could be done with dynalink to provide "automatic"
> conversion between:
>
> JSObject <--> io.vertx.core.json.JsonObject
>
> We do not want to introduce helper functions to the end user like:
>
> var java_type_object = Java.type(...);
>
> java_type_object.someMethod(to_native({k: 1}));
>
> but we would like to have:
>
> java_type_object.someMethod({k: 1});
>
>
> Currently we have a code generator that writes a full wrapper for the
> vert.x API that will do this translation, but this has several
> limitations, we must force a very restricted set of types to be used in
> public APIs, there's a build step for each module, introduces potential
> bugs if the generated code is not correct.
>
> After reading the Dynalink API and examples from JDK9 it seems that
> this could be done with it since one could write a linker from JSObject
> properties to JsonObject and vice-versa but this is not present on
> JDK8.
>
> Even though dynalink was present on JDK8 the service loader is not
> present or at least should not be used.
>
> So my question is, what alternatives/suggestions do you have to achieve
> this?
>
> I'm thinking of something like groovy metaprogramming but that would
> also require dynalink, or not?
>
> For the sake of completeness I must say that JsonObject/JsonArray do
> not implement java.util.Map/java.util.List interfaces so one cannot
> rely on the fact that nashorn would internally handle those for us.
>
> Best regards,
> Paulo
