Questions regarding Nashorn Extensibility (from a Rhino Migration POV)
sundararajan.athijegannathan at oracle.com
Fri Sep 27 01:26:23 PDT 2013
* 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.
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,
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?
> 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>
More information about the nashorn-dev