[
https://issues.apache.org/jira/browse/SLING-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600897#comment-14600897
]
Radu Cotescu edited comment on SLING-4801 at 9/15/15 10:02 PM:
---------------------------------------------------------------
While researching how to implement this I've also worked on a Sightly
JavaScript Use Provider using the Nashorn implementation. The Sightly
performance tests only showed a 25% performance increase of running the same
JavaScript code on Nashorn instead of Rhino.
However my opinion is that we should instead try to optimise the Rhino
implementation (see SLING-913 and SLING-915) due to the multiple environment
restrictions that Nashorn currently imposes:
* run Sling on JRE > =1.8.0_45 (Nashorn had performance problems before)
* there's no way to currently provide the same JS implementation of the
Resource API
* Nashorn has to be configured specifically for Sling's use case so that all
its caching strategies are turned on; for Sling's use case - running multiple
small JavaScript scripts repeatedly - Nashorn is not necessarily the best
option due to its relatively slow warmup
For further reference I've attached a patch ([^SLING-4801.patch]) that provides
the following features:
* a new {{org.apache.sling.scripting.javascript.nashorn}} bundle that only runs
on JRE >= 1.8
* a new {{org.apache.sling.scripting.sightly.js.provider.nashorn}} bundle that
takes advantage of the Nashorn features
* it exposes the {{jdk.nashorn.api.scripting;version="0.0.0.1_008_JavaSE"}}
package for JRE 1.8
* it provides a way to test the performance improvements through the Sightly
performance tests, which is currently the most important consumer for the
JavaScript scripting engine
was (Author: radu.cotescu):
While researching how to implement this I've also worked on a Sightly
JavaScript Use Provider using the Nashorn implementation. The Sightly
performance tests only showed a 25% performance increase of running the same
JavaScript code on Nashorn instead of Rhino.
However my opinion is that we should instead try to optimise the Rhino
implementation (see SLING-913 and SLING-915) due the multiple environment
restrictions that Nashorn currently imposes:
* run Sling on JRE > =1.8.0_45 (Nashorn had performance problems before)
* there's no way to currently provide the same JS implementation of the
Resource API
* Nashorn has to be configured specifically for Sling's use case so that all
its caching strategies are turned on; for Sling's use case - running multiple
small JavaScript scripts repeatedly - Nashorn is not necessarily the best
option due to its relatively slow warmup
For further reference I've attached a patch ([^SLING-4801.patch]) that provides
the following features:
* a new {{org.apache.sling.scripting.javascript.nashorn}} bundle that only runs
on JRE >= 1.8
* a new {{org.apache.sling.scripting.sightly.js.provider.nashorn}} bundle that
takes advantage of the Nashorn features
* it exposes the {{jdk.nashorn.api.scripting;version="0.0.0.1_008_JavaSE"}}
package for JRE 1.8
* it provides a way to test the performance improvements through the Sightly
performance tests, which is currently the most important consumer for the
JavaScript scripting engine
> Add support for Nashorn in the JavaScript Scripting Engine
> ----------------------------------------------------------
>
> Key: SLING-4801
> URL: https://issues.apache.org/jira/browse/SLING-4801
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
> Affects Versions: Scripting JavaScript 2.0.16
> Reporter: Radu Cotescu
> Assignee: Radu Cotescu
> Attachments: SLING-4801.patch
>
>
> The {{org.apache.sling.scripting.javascript}} bundle should attempt to use
> Nashorn, if available on the user's platform, for running JS code.
> Alternatively it should switch to Rhino if the JRE is < 1.8.
> Requirements:
> * need to expose the
> {{jdk.nashorn.api.scripting;version="0.0.0.1_008_JavaSE"}} package on JRE >=
> 1.8 in Sling's {{launchpad/base/src/main/resources/jre-1.8.properties}}
> properties files
> * the Rhino and Nashorn implementations need to co-exist, so that customers
> still running on Java < 8 can use the Rhino implementation; the switch from
> Rhino to Nashorn should happen automatically but should also be made
> configurable in case customers really want to use a specific implementation;
> while the Nashorn implementation requires Java 8 (and this can easily be
> handled through the {{Require-Capability}} \[0\] and
> {{Bundle-RequiredExecutionEnvironment}} \[1\] manifest headers) and the
> bundle implementing Nashorn support won't start if the detected Java version
> is < 8, a non-sticky run mode / configuration should handle the switch if
> customers would still like to use the Rhino implementation on Java >= 8
> * need to find a way to inject custom properties to all instances of a class,
> similar to Rhino's host objects \[2\] (thread open on Nashorn's dev list at
> \[3\]); this is needed in order to assure JavaScript API backwards
> compatibility with the JS API exposed through the Rhino implementation
> currently available in {{org.apache.sling.scripting.javascript}}; it seems
> that Nashorn's public API only allows proxying an object, not all instances
> of a class
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
