New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine

[João Paulo Varandas]

I share the same concern with our product.

​In the past​ 3+ years we have relied upon Nashorn to build
​our
 low code development platform. People can write business logic, APIs,
intercept database logic with Triggers and render front-end content with
code written in ES.

The application is created via a no-code interface, drag'n drop components
and also dynamic database entities (based on meta-data), this is all java
abstract code. But w
hen it comes to business logic for the applications, everything runs inside
Nashorn(including multi-threading)
​ context
​via
 a ScriptEngine(per Thread) and some helpers
​ injected​
into the javax.script.bindings
​ for that execution​
​
there's a "transparent layer"
​here ​
between scripts and java code
​ so they can easily interact​
​
​
​.
We have built a "require" function to load modules (also written in
JavaScript) so developers can encapsulate code.

​Basically, the success of our product lies within the integration of
no-code (drag n drop / components part)​ and the JavaScript part, where it
doesn't matter if we update our platform, your code simply runs and that's
it. When it comes to a JDK upgrade, where Nashorn will no longer be there,
even if we have a replacement (such as GraalVM), this might bring not only
breaking changes to our product, but also to software written within our
platform, since some code "may not run seamlessly" ...



The ETA on deprecation and also a clear statement for the replacement would
be ideal
​, thus we can prepare ourselves and advise our users to not use code that
may not be supported in the long run...
​
​
Also, if
​ there's a replacement (such as GraalVM)
, what are the plans to make it more compatible with Nashorn.

​

​



​

On Mon, Jun 11, 2018 at 7:03 PM, Jesus Luzon <jluzon at riotgames.com> wrote:

> We use Nashorn heavily in our Edge at Riot for what we call our
> transformation layer, where users wanting to expose their applications can
> tranforms request and/or responses by writing JS snippets. Losing Nashorn
> without any viable replacement would destroy much of the work we've done in
> the past year and a half to make our Ecosystem highly configurable, so an
> at the very least actual ETA on deprecation and an expected replacement
> path would be ideal.
>

-- 
"Esta mensagem, incluindo seus anexos, pode conter informacoes 
confidenciais e privilegiadas. 
Se voce a recebeu por engano, solicitamos 
que a apague e avise o remetente imediatamente. 
Opinioes ou informacoes 
aqui contidas nao refletem necessariamente a posicao oficial da Plusoft."



"Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO 
AMBIENTE"