dynalink alternative for jdk8

Sundararajan Athijegannathan sundararajan.athijegannathan at oracle.com
Wed Nov 2 08:27:31 UTC 2016

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


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

More information about the nashorn-dev mailing list