Discussion:
Nashorn deprecation
(too old to reply)
yikes aroni
2018-06-07 12:31:11 UTC
Permalink
Hi i just read that Nashorn is being deprecated (JEP 335
<http://openjdk.java.net/jeps/335>). First of all, that is a drag. Two
(ish) questions:

1) So what is the last planned release of Nashorn? J9? It wasnt' clear from
the JEP.

2) Is this deprecation specifically to make room for GraalJS? That is, is
it the Oracle plan to sideline Nashorn and push forward GraalJS a
fully-supported, not-just-for-research GraalJS?

Thanks. Important stuff to know for planning for projects dependent on
Nashorn / JS support in the JVM!
João Paulo Varandas
2018-06-11 17:50:16 UTC
Permalink
Hello Yikes. Well pointed... that is a drag indeed.

Any news on those questions?


We are completely reliant to this feature in our platform, a lot of
software customization is made using ECMAScript and runs on top of
Nashorn/JDK8 currently. I was surprised and scared when I saw that.
Hopefully, Jim will bring us good news.
Post by yikes aroni
Hi i just read that Nashorn is being deprecated (JEP 335
<http://openjdk.java.net/jeps/335>). First of all, that is a drag. Two
1) So what is the last planned release of Nashorn? J9? It wasnt' clear from
the JEP.
2) Is this deprecation specifically to make room for GraalJS? That is, is
it the Oracle plan to sideline Nashorn and push forward GraalJS a
fully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent on
Nashorn / JS support in the JVM!
--
"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"
Paulo Lopes
2018-06-11 19:35:38 UTC
Permalink
Hi,
As the "core" developer of JS support for Vert.x this is quite some
shocking news as the project really relies on Nashorn for JS support.
I've been spending many hours to get GraalVM.js working and to some
extent we can run some unmodified application with it, but we're not
there yet. For example Nashorn dynalink and Multi threading support are
not there yet.
It would be nice to hear what's the ETA for the removal, will project
Detroit provide a JS script engine (ala Nashorn and will it be
available as a replacement?)...
Cheers,Paulo
Post by João Paulo Varandas
Hello Yikes. Well pointed... that is a drag indeed.
Any news on those questions?
We are completely reliant to this feature in our platform, a lot
ofsoftware customization is made using ECMAScript and runs on top
ofNashorn/JDK8 currently. I was surprised and scared when I saw
that.Hopefully, Jim will bring us good news.
Hi i just read that Nashorn is being deprecated (JEP 335<http://openj
dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
1) So what is the last planned release of Nashorn? J9? It wasnt'
clear fromthe JEP.
2) Is this deprecation specifically to make room for GraalJS? That
is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
afully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent
onNashorn / JS support in the JVM!
Attila Szegedi
2018-06-11 20:56:57 UTC
Permalink
Hey folks,

the best thing you can do is answer to this thread on jdk-dev mailing list: <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001338.html>. The JEP is a candidate, and they’re gathering feedback there. If there’s a lot of community feedback saying people use and depend on Nashorn, it’ll be taken into consideration. Lots of people have already chimed in on that thread already saying they rely on Nashorn. If you can re-post your below messages in that thread, it’d be the best. If you are not subscribed to jdk-dev, you can do so at <http://mail.openjdk.java.net/mailman/listinfo/jdk-dev>.

Paulo, your specific experience of already having tried to replace Nashorn with GraalVM.js might be particularly significant.

Best regards,
Attila.
Post by Paulo Lopes
Hi,
As the "core" developer of JS support for Vert.x this is quite some
shocking news as the project really relies on Nashorn for JS support.
I've been spending many hours to get GraalVM.js working and to some
extent we can run some unmodified application with it, but we're not
there yet. For example Nashorn dynalink and Multi threading support are
not there yet.
It would be nice to hear what's the ETA for the removal, will project
Detroit provide a JS script engine (ala Nashorn and will it be
available as a replacement?)...
Cheers,Paulo
Post by João Paulo Varandas
Hello Yikes. Well pointed... that is a drag indeed.
Any news on those questions?
We are completely reliant to this feature in our platform, a lot
ofsoftware customization is made using ECMAScript and runs on top
ofNashorn/JDK8 currently. I was surprised and scared when I saw
that.Hopefully, Jim will bring us good news.
Hi i just read that Nashorn is being deprecated (JEP 335<http://openj
dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
1) So what is the last planned release of Nashorn? J9? It wasnt'
clear fromthe JEP.
2) Is this deprecation specifically to make room for GraalJS? That
is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
afully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent
onNashorn / JS support in the JVM!
Jesus Luzon
2018-06-11 21:26:38 UTC
Permalink
Is there any way to reply to a thread before I was subscribed? I'm pretty
much a noob when it comes to this mailing list process.

As for the deprecation, we use Nashorn heavily for our Edge transformation
layers and would need to find something that's at least backwards
compatible with our use case. Our use case is actually quite simple so I
think it would be easy to get functionality again, but would rather find
something that will last more than a few years without heavy maintenance.
Post by Attila Szegedi
Hey folks,
the best thing you can do is answer to this thread on jdk-dev mailing
list: <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/
001338.html>. The JEP is a candidate, and they’re gathering feedback
there. If there’s a lot of community feedback saying people use and depend
on Nashorn, it’ll be taken into consideration. Lots of people have already
chimed in on that thread already saying they rely on Nashorn. If you can
re-post your below messages in that thread, it’d be the best. If you are
not subscribed to jdk-dev, you can do so at <http://mail.openjdk.java.net/
mailman/listinfo/jdk-dev>.
Paulo, your specific experience of already having tried to replace Nashorn
with GraalVM.js might be particularly significant.
Best regards,
Attila.
Post by Paulo Lopes
Hi,
As the "core" developer of JS support for Vert.x this is quite some
shocking news as the project really relies on Nashorn for JS support.
I've been spending many hours to get GraalVM.js working and to some
extent we can run some unmodified application with it, but we're not
there yet. For example Nashorn dynalink and Multi threading support are
not there yet.
It would be nice to hear what's the ETA for the removal, will project
Detroit provide a JS script engine (ala Nashorn and will it be
available as a replacement?)...
Cheers,Paulo
Post by João Paulo Varandas
Hello Yikes. Well pointed... that is a drag indeed.
Any news on those questions?
We are completely reliant to this feature in our platform, a lot
ofsoftware customization is made using ECMAScript and runs on top
ofNashorn/JDK8 currently. I was surprised and scared when I saw
that.Hopefully, Jim will bring us good news.
Hi i just read that Nashorn is being deprecated (JEP 335<http://openj
dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
1) So what is the last planned release of Nashorn? J9? It wasnt'
clear fromthe JEP.
2) Is this deprecation specifically to make room for GraalJS? That
is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
afully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent
onNashorn / JS support in the JVM!
Attila Szegedi
2018-06-11 21:49:41 UTC
Permalink
Subscribe first, then go to that mailing list archive link, and click on the message author link (first link on the top of the page). It’s actually a mailto: link that should open your mail client with an empty e-mail message accordingly configured as a thread response.

Attila.
Is there any way to reply to a thread before I was subscribed? I'm pretty much a noob when it comes to this mailing list process.
As for the deprecation, we use Nashorn heavily for our Edge transformation layers and would need to find something that's at least backwards compatible with our use case. Our use case is actually quite simple so I think it would be easy to get functionality again, but would rather find something that will last more than a few years without heavy maintenance.
Hey folks,
the best thing you can do is answer to this thread on jdk-dev mailing list: <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001338.html <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001338.html>>. The JEP is a candidate, and they’re gathering feedback there. If there’s a lot of community feedback saying people use and depend on Nashorn, it’ll be taken into consideration. Lots of people have already chimed in on that thread already saying they rely on Nashorn. If you can re-post your below messages in that thread, it’d be the best. If you are not subscribed to jdk-dev, you can do so at <http://mail.openjdk.java.net/mailman/listinfo/jdk-dev <http://mail.openjdk.java.net/mailman/listinfo/jdk-dev>>.
Paulo, your specific experience of already having tried to replace Nashorn with GraalVM.js might be particularly significant.
Best regards,
Attila.
Post by Paulo Lopes
Hi,
As the "core" developer of JS support for Vert.x this is quite some
shocking news as the project really relies on Nashorn for JS support.
I've been spending many hours to get GraalVM.js working and to some
extent we can run some unmodified application with it, but we're not
there yet. For example Nashorn dynalink and Multi threading support are
not there yet.
It would be nice to hear what's the ETA for the removal, will project
Detroit provide a JS script engine (ala Nashorn and will it be
available as a replacement?)...
Cheers,Paulo
Post by João Paulo Varandas
Hello Yikes. Well pointed... that is a drag indeed.
Any news on those questions?
We are completely reliant to this feature in our platform, a lot
ofsoftware customization is made using ECMAScript and runs on top
ofNashorn/JDK8 currently. I was surprised and scared when I saw
that.Hopefully, Jim will bring us good news.
Hi i just read that Nashorn is being deprecated (JEP 335<http://openj <http://openj/>
dk.java.net/jeps/335 <http://dk.java.net/jeps/335>>). First of all, that is a drag. Two(ish)
1) So what is the last planned release of Nashorn? J9? It wasnt'
clear fromthe JEP.
2) Is this deprecation specifically to make room for GraalJS? That
is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
afully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent
onNashorn / JS support in the JVM!
Tony Zakula
2018-06-15 20:28:22 UTC
Permalink
Also replied to the thread. Our entire platform is built on Nashorn.
Assumed it was the Java answer for JS on the Java runtime.
Post by Jesus Luzon
Is there any way to reply to a thread before I was subscribed? I'm pretty
much a noob when it comes to this mailing list process.
As for the deprecation, we use Nashorn heavily for our Edge transformation
layers and would need to find something that's at least backwards
compatible with our use case. Our use case is actually quite simple so I
think it would be easy to get functionality again, but would rather find
something that will last more than a few years without heavy maintenance.
Post by Attila Szegedi
Hey folks,
the best thing you can do is answer to this thread on jdk-dev mailing
list: <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/
001338.html>. The JEP is a candidate, and they’re gathering feedback
there. If there’s a lot of community feedback saying people use and
depend
Post by Attila Szegedi
on Nashorn, it’ll be taken into consideration. Lots of people have
already
Post by Attila Szegedi
chimed in on that thread already saying they rely on Nashorn. If you can
re-post your below messages in that thread, it’d be the best. If you are
not subscribed to jdk-dev, you can do so at <
http://mail.openjdk.java.net/
Post by Attila Szegedi
mailman/listinfo/jdk-dev>.
Paulo, your specific experience of already having tried to replace
Nashorn
Post by Attila Szegedi
with GraalVM.js might be particularly significant.
Best regards,
Attila.
Post by Paulo Lopes
Hi,
As the "core" developer of JS support for Vert.x this is quite some
shocking news as the project really relies on Nashorn for JS support.
I've been spending many hours to get GraalVM.js working and to some
extent we can run some unmodified application with it, but we're not
there yet. For example Nashorn dynalink and Multi threading support are
not there yet.
It would be nice to hear what's the ETA for the removal, will project
Detroit provide a JS script engine (ala Nashorn and will it be
available as a replacement?)...
Cheers,Paulo
Post by João Paulo Varandas
Hello Yikes. Well pointed... that is a drag indeed.
Any news on those questions?
We are completely reliant to this feature in our platform, a lot
ofsoftware customization is made using ECMAScript and runs on top
ofNashorn/JDK8 currently. I was surprised and scared when I saw
that.Hopefully, Jim will bring us good news.
Hi i just read that Nashorn is being deprecated (JEP 335<http://openj
dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
1) So what is the last planned release of Nashorn? J9? It wasnt'
clear fromthe JEP.
2) Is this deprecation specifically to make room for GraalJS? That
is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
afully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent
onNashorn / JS support in the JVM!
Paulo Lopes
2018-06-15 20:50:42 UTC
Permalink
Hi Tony,

By no means a solution, but at the vertx project I've managed to get a small layer that allows you to run the same script (unmodified) both on nashorn or Graal JS (not node)

https://github.com/reactiverse/es4x/pull/12
https://github.com/reactiverse/es4x/pull/16

This is what we're experimenting to smoothly allow us to run on JDK8,9,10,11 and Graal.


Cheers,
Paulo

  Original Message  
From: ***@gmail.com
Sent: June 15, 2018 22:29
To: ***@riotgames.com
Cc: ***@gmail.com; nashorn-***@openjdk.java.net
Subject: Re: Nashorn deprecation

Also replied to the thread.  Our entire platform is built on Nashorn.
Assumed it was the Java answer for JS on the Java runtime.
Post by Jesus Luzon
Is there any way to reply to a thread before I was subscribed? I'm pretty
much a noob when it comes to this mailing list process.
As for the deprecation, we use Nashorn heavily for our Edge transformation
layers and would need to find something that's at least backwards
compatible with our use case. Our use case is actually quite simple so I
think it would be easy to get functionality again, but would rather find
something that will last more than a few years without heavy maintenance.
Post by Attila Szegedi
Hey folks,
the best thing you can do is answer to this thread on jdk-dev mailing
list: <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/
001338.html>. The JEP is a candidate, and they’re gathering feedback
there. If there’s a lot of community feedback saying people use and
depend
Post by Attila Szegedi
on Nashorn, it’ll be taken into consideration. Lots of people have
already
Post by Attila Szegedi
chimed in on that thread already saying they rely on Nashorn. If you can
re-post your below messages in that thread, it’d be the best. If you are
not subscribed to jdk-dev, you can do so at <
http://mail.openjdk.java.net/
Post by Attila Szegedi
mailman/listinfo/jdk-dev>.
Paulo, your specific experience of already having tried to replace
Nashorn
Post by Attila Szegedi
with GraalVM.js might be particularly significant.
Best regards,
   Attila.
Post by Paulo Lopes
Hi,
As the "core" developer of JS support for Vert.x this is quite some
shocking news as the project really relies on Nashorn for JS support.
I've been spending many hours to get GraalVM.js working and to some
extent we can run some unmodified application with it, but we're not
there yet. For example Nashorn dynalink and Multi threading support are
not there yet.
It would be nice to hear what's the ETA for the removal, will project
Detroit provide a JS script engine (ala Nashorn and will it be
available as a replacement?)...
Cheers,Paulo
Post by João Paulo Varandas
Hello Yikes. Well pointed... that is a drag indeed.
Any news on those questions?
We are completely reliant to this feature in our platform, a lot
ofsoftware customization is made using ECMAScript and runs on top
ofNashorn/JDK8 currently. I was surprised and scared when I saw
that.Hopefully, Jim will bring us good news.
Hi i just read that Nashorn is being deprecated (JEP 335<http://openj
dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
1) So what is the last planned release of Nashorn? J9? It wasnt'
clear fromthe JEP.
2) Is this deprecation specifically to make room for GraalJS? That
is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
afully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent
onNashorn / JS su
Charles Oliver Nutter
2018-07-03 23:19:48 UTC
Permalink
I was going to start another thread, but I thought it made sense to reply here.

I see the justification for deprecating Nashorn is given as "it's too
hard to maintain". I'd like to understand if that's the real
justification or if the real truth is that the Truffle JS impl is
going to be preferred by Oracle going forward.

I am also curious, in that case, if the question is about performance.
I have been running JRuby -- a far less complex language
implementation than Nashorn -- atop Graal JIT with great results.
Numeric benchmarks are competitive with the Truffle implementation of
Ruby, and with better inlining and a bit of data structure
specialization I'd expect many more scenarios to perform well too.
Truffle goes a long way on the specialization and inlining front, but
the bulk of its gains appear to be from partial escape analysis --
gains I am seeing on JRuby without any modification.

I've just posted a blog entry about running JRuby on Graal JIT, which
shows how a mandelbrot algorithm is many times faster using
*unmodified* JRuby on Graal.

http://blog.headius.com/2018/07/running-jruby-on-graal-jit.html

This is without JRuby doing any numeric specialization of code, which
Nashorn does very aggressively.

So what's the actual reason for deprecating Nashorn? Are we
deprecating having a standard JS shipped with OpenJDK, or are we just
picking a winner? Are we sure it's the right winner?

- Charlie
Post by Paulo Lopes
Hi Tony,
By no means a solution, but at the vertx project I've managed to get a small layer that allows you to run the same script (unmodified) both on nashorn or Graal JS (not node)
https://github.com/reactiverse/es4x/pull/12
https://github.com/reactiverse/es4x/pull/16
This is what we're experimenting to smoothly allow us to run on JDK8,9,10,11 and Graal.
Cheers,
Paulo
Original Message
Sent: June 15, 2018 22:29
Subject: Re: Nashorn deprecation
Also replied to the thread. Our entire platform is built on Nashorn.
Assumed it was the Java answer for JS on the Java runtime.
Post by Jesus Luzon
Is there any way to reply to a thread before I was subscribed? I'm pretty
much a noob when it comes to this mailing list process.
As for the deprecation, we use Nashorn heavily for our Edge transformation
layers and would need to find something that's at least backwards
compatible with our use case. Our use case is actually quite simple so I
think it would be easy to get functionality again, but would rather find
something that will last more than a few years without heavy maintenance.
Post by Attila Szegedi
Hey folks,
the best thing you can do is answer to this thread on jdk-dev mailing
list: <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/
001338.html>. The JEP is a candidate, and they’re gathering feedback
there. If there’s a lot of community feedback saying people use and
depend
Post by Attila Szegedi
on Nashorn, it’ll be taken into consideration. Lots of people have
already
Post by Attila Szegedi
chimed in on that thread already saying they rely on Nashorn. If you can
re-post your below messages in that thread, it’d be the best. If you are
not subscribed to jdk-dev, you can do so at <
http://mail.openjdk.java.net/
Post by Attila Szegedi
mailman/listinfo/jdk-dev>.
Paulo, your specific experience of already having tried to replace
Nashorn
Post by Attila Szegedi
with GraalVM.js might be particularly significant.
Best regards,
Attila.
Post by Paulo Lopes
Hi,
As the "core" developer of JS support for Vert.x this is quite some
shocking news as the project really relies on Nashorn for JS support.
I've been spending many hours to get GraalVM.js working and to some
extent we can run some unmodified application with it, but we're not
there yet. For example Nashorn dynalink and Multi threading support are
not there yet.
It would be nice to hear what's the ETA for the removal, will project
Detroit provide a JS script engine (ala Nashorn and will it be
available as a replacement?)...
Cheers,Paulo
Post by João Paulo Varandas
Hello Yikes. Well pointed... that is a drag indeed.
Any news on those questions?
We are completely reliant to this feature in our platform, a lot
ofsoftware customization is made using ECMAScript and runs on top
ofNashorn/JDK8 currently. I was surprised and scared when I saw
that.Hopefully, Jim will bring us good news.
Hi i just read that Nashorn is being deprecated (JEP 335<http://openj
dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
1) So what is the last planned release of Nashorn? J9? It wasnt'
clear fromthe JEP.
2) Is this deprecation specifically to make room for GraalJS? That
is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
afully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent
onNashorn / JS support in the JVM!
Charles Oliver Nutter
2018-07-03 23:21:19 UTC
Permalink
Oh, another note about picking the Truffle JS over Nashorn: it will
mean there's no supported JS implementation that runs on non-Graal
runtimes. That doesn't seem like the future we want for JVM JS.

- Charlie

On Tue, Jul 3, 2018 at 6:19 PM, Charles Oliver Nutter
Post by Charles Oliver Nutter
I was going to start another thread, but I thought it made sense to reply here.
I see the justification for deprecating Nashorn is given as "it's too
hard to maintain". I'd like to understand if that's the real
justification or if the real truth is that the Truffle JS impl is
going to be preferred by Oracle going forward.
I am also curious, in that case, if the question is about performance.
I have been running JRuby -- a far less complex language
implementation than Nashorn -- atop Graal JIT with great results.
Numeric benchmarks are competitive with the Truffle implementation of
Ruby, and with better inlining and a bit of data structure
specialization I'd expect many more scenarios to perform well too.
Truffle goes a long way on the specialization and inlining front, but
the bulk of its gains appear to be from partial escape analysis --
gains I am seeing on JRuby without any modification.
I've just posted a blog entry about running JRuby on Graal JIT, which
shows how a mandelbrot algorithm is many times faster using
*unmodified* JRuby on Graal.
http://blog.headius.com/2018/07/running-jruby-on-graal-jit.html
This is without JRuby doing any numeric specialization of code, which
Nashorn does very aggressively.
So what's the actual reason for deprecating Nashorn? Are we
deprecating having a standard JS shipped with OpenJDK, or are we just
picking a winner? Are we sure it's the right winner?
- Charlie
Post by Paulo Lopes
Hi Tony,
By no means a solution, but at the vertx project I've managed to get a small layer that allows you to run the same script (unmodified) both on nashorn or Graal JS (not node)
https://github.com/reactiverse/es4x/pull/12
https://github.com/reactiverse/es4x/pull/16
This is what we're experimenting to smoothly allow us to run on JDK8,9,10,11 and Graal.
Cheers,
Paulo
Original Message
Sent: June 15, 2018 22:29
Subject: Re: Nashorn deprecation
Also replied to the thread. Our entire platform is built on Nashorn.
Assumed it was the Java answer for JS on the Java runtime.
Post by Jesus Luzon
Is there any way to reply to a thread before I was subscribed? I'm pretty
much a noob when it comes to this mailing list process.
As for the deprecation, we use Nashorn heavily for our Edge transformation
layers and would need to find something that's at least backwards
compatible with our use case. Our use case is actually quite simple so I
think it would be easy to get functionality again, but would rather find
something that will last more than a few years without heavy maintenance.
Post by Attila Szegedi
Hey folks,
the best thing you can do is answer to this thread on jdk-dev mailing
list: <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/
001338.html>. The JEP is a candidate, and they’re gathering feedback
there. If there’s a lot of community feedback saying people use and
depend
Post by Attila Szegedi
on Nashorn, it’ll be taken into consideration. Lots of people have
already
Post by Attila Szegedi
chimed in on that thread already saying they rely on Nashorn. If you can
re-post your below messages in that thread, it’d be the best. If you are
not subscribed to jdk-dev, you can do so at <
http://mail.openjdk.java.net/
Post by Attila Szegedi
mailman/listinfo/jdk-dev>.
Paulo, your specific experience of already having tried to replace
Nashorn
Post by Attila Szegedi
with GraalVM.js might be particularly significant.
Best regards,
Attila.
Post by Paulo Lopes
Hi,
As the "core" developer of JS support for Vert.x this is quite some
shocking news as the project really relies on Nashorn for JS support.
I've been spending many hours to get GraalVM.js working and to some
extent we can run some unmodified application with it, but we're not
there yet. For example Nashorn dynalink and Multi threading support are
not there yet.
It would be nice to hear what's the ETA for the removal, will project
Detroit provide a JS script engine (ala Nashorn and will it be
available as a replacement?)...
Cheers,Paulo
Post by João Paulo Varandas
Hello Yikes. Well pointed... that is a drag indeed.
Any news on those questions?
We are completely reliant to this feature in our platform, a lot
ofsoftware customization is made using ECMAScript and runs on top
ofNashorn/JDK8 currently. I was surprised and scared when I saw
that.Hopefully, Jim will bring us good news.
Hi i just read that Nashorn is being deprecated (JEP 335<http://openj
dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
1) So what is the last planned release of Nashorn? J9? It wasnt'
clear fromthe JEP.
2) Is this deprecation specifically to make room for GraalJS? That
is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
afully-supported, not-just-for-research GraalJS?
Thanks. Important stuff to know for planning for projects dependent
onNashorn / JS support in the JVM!
m***@oracle.com
2018-07-19 23:29:25 UTC
Permalink
Post by Charles Oliver Nutter
I was going to start another thread, but I thought it made sense to reply here.
I see the justification for deprecating Nashorn is given as "it's too
hard to maintain". I'd like to understand if that's the real
justification or if the real truth is that the Truffle JS impl is
going to be preferred by Oracle going forward.
Yes, that’s the real justification. Jim would’ve made this proposal
even if Truffle JS and Graal didn’t exist.

The simple fact is that it takes effort to maintain a body of code as
complex as Nashorn. Those who currently maintain Nashorn are these days
working on even newer features, so they’re trying to reduce the amount
of time that they spend maintaining Nashorn.
Post by Charles Oliver Nutter
So what's the actual reason for deprecating Nashorn? Are we
deprecating having a standard JS shipped with OpenJDK, or are we just
picking a winner? Are we sure it's the right winner?
This decision is not about “picking a winner.” It’s about focusing
effort. As I’ve written previously, if a set of credible developers
expresses a clear desire to maintain Nashorn after JDK 11 then all of us
who work on the JDK will find a way to make that happen. Absent that,
then at some point in the future there will no longer be a JS engine in
the JDK.

- Mark

Loading...