Questions regarding Nashorn Extensibility (from a Rhino Migration POV)

[A. Sundararajan]

Hi,

* Nashorn uses wrapperless Java objects - Java objects are exposed "as 
is". Security filtering is automatic - no ClassShutter. If you want, 
you've to override Packages and Java objects in global scope.

* No precompiling to bytecodes supported yet. The compiled .classes 
can't be saved and re-loaded in later process.

* There is no context concept exposed to user code. Preferred way to use 
nashorn is to use javax.script API. You can use 'load' and 
'loadWithNewGlobal' APIs to load new script from file/URL/string/object 
in the same caller global or in a new fresh global instance. New 
"context" use cases of rhino may be served by this. Also, in jsr223 API, 
you can create new Global via ScriptEngine.createBindings() as well.

* There is API in jdk.nashorn.api.scripting package - to access script 
objects- property access, function call access, 'new script object' etc. 
are provided.

That said, you will have some porting effort with your java code that 
uses Rhino. In the interim, you can continue to drop Rhino jar and use 
it (i.e., till you migrate your code to nashorn)\.

Hope this helps,
-Sundar

On Friday 27 September 2013 12:30 AM, Rick Bullotta wrote:
> Hi, Nashorn team.
>
> I was wondering if there were any documents or other content regarding how to migrate from Rhino to Nashorn.  In this context, we are moving from "pure Rhino", not the Rhino that is embedded in the JVM.  We heavily leverage capabilities in Rhino such as wrap factories, precompiling and context cloning.   Any insights on the Nashorn analog to these various capabilities?
>
> Thanks,
>
> Rick
>
> _______________________________________________________________
> ThingWorx
> Powering the Connected World(tm)
>
> Rick Bullotta, CTO & Co-Founder
> M: +1 610 220 3183 | S: rick.bullotta.thingworx
> rick.bullotta at thingworx.com<mailto:rick.bullotta at thingworx.com> | @rickbullotta | www.thingworx.com<http://www.thingworx.com>
>