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
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
a ScriptEngine(per Thread) and some helpers
into the javax.script.bindings
for that execution
there's a "transparent layer"
between scripts and java code
so they can easily interact
We have built a "require" function to load modules (also written in
Basically, the success of our product lies within the integration of
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
, thus we can prepare ourselves and advise our users to not use code that
may not be supported in the long run...
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
More information about the jdk-dev