New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine (original) (raw)

João Paulo Varandas joaovarandas at inpaas.com
Mon Jun 11 22:27:37 UTC 2018

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"

More information about the jdk-dev mailing list