ability to inject custom properties into a JS object

A. Sundararajan sundararajan.athijegannathan at oracle.com
Thu Jun 18 15:35:36 UTC 2015


Hi,

I think you've to use one of these: POJO/bean-style property support, 
JSAdapter or JSObject.

BTW, JSObject does not have to be per object. You could accept any Java 
type value in your AbstractJSObject subclass and delegate the 
calls/property accesses to it.

For example, you could use reflection to look for specific name pattern 
in that given Java object and forward property/method access 
accordingly. Or you could have your own annotations and forward JS 
property/method access based on annotations (from your JSObject 
implementation).

Yes, this means that you've to write a bit of glue layer code.

Other thing to consider is Object.bindProperties function (another 
nashorn extension). This lets you to "bind" properties of one object to 
another object. You could write customer wrapper function that binds 
your Java object's properties and then add/remove properties.

https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Object.bindProperties

Thanks,
-Sundar

On Tuesday 16 June 2015 01:31 PM, Radu Cotescu wrote:
> Hi Sundar,
>
> Thank you for your quick reply! I did read about JSAdapter and JSObject
> before my initial email but I don't think they actually do what I want.
>
> In my use-case I need to be able to interfere with object translation (from
> Java to JavaScript) for all instances of a certain Java class, not just for
> specific objects. Is there any way I could achieve this (something similar
> to Rhino's host objects [2])?
>
> Thanks,
> Radu
>
> [2] -
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Embedding_tutorial#JavaScript_host_objects
>
> On Mon, 15 Jun 2015 at 15:23 A. Sundararajan <
> sundararajan.athijegannathan at oracle.com> wrote:
>
>> Please note that nashorn has support to handle Java objects with 'bean
>> style' property support. And you could implement Java interfaces and
>> extend Java abstract classes in script.  java.util.Map objects are
>> treated specially to provide key-value access as properties.
>> java.util.ArrayList objects are treated like arrays (indexed element
>> access, length property for size). These could be used provide
>> script-friendly access to your existing Java classes.
>>
>> But, if you want to write script "proxies" to trap property access etc.,
>> then there are two ways:
>>
>> 1) JSAdapter - you'd write JSAdapter wrapper in script.
>>
>> Example:
>>
>>
>> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JSAdapterconstructor
>>
>> 2) Implementing jdk.nashorn.api.scripting.JSObject.
>>
>>
>> https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/JSObject.html
>>
>> AbstractJSObject (
>>
>> https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/AbstractJSObject.html
>> ) provides empty/null implementation for most methods and so you can
>> extend it as well.
>>
>> In addition, any @FunctionalInterface object
>> (java.util.functions.Function etc) can be called as a script function.
>> So, your script functions could just be Java functional interface objects.
>>
>> Example:
>>
>>
>> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Plugging-inyourownJSObject
>>
>> Hope this helps,
>> -Sundar
>>
>> On Monday 15 June 2015 05:42 PM, Radu Cotescu wrote:
>>> Hello,
>>>
>>> I've recently started looking into replacing Rhino with Nashorn as the
>>> JavaScript scripting engine for Apache Sling (see SLING-4801 [0]).
>>>
>>> Once nice Rhino feature that I don't seem to be able to easily map to
>>> something from Nashorn is the ability to provide my own object wrappers,
>>> such that the resulting JS object contains some custom properties. I did
>>> notice this thread [1] but I wasn't able to reach to a conclusion
>> regarding
>>> this feature.
>>>
>>> Is there a way to easily implement this custom object translation layer
>>> without having to implement a JSObject? The problem with this approach is
>>> that Sling script developers will have to use these custom wrapper
>> classes
>>> (JSObjects) instead of the APIs directly available through the Bindings,
>>> making scripts written for the Rhino implementation incompatible.
>>>
>>> Thanks,
>>> Radu
>>>
>>> [0] - https://issues.apache.org/jira/browse/SLING-4801
>>> [1] -
>>>
>> https://www.mail-archive.com/nashorn-dev%40openjdk.java.net/msg01485.html
>>
>>



More information about the nashorn-dev mailing list