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 <head...@headius.com> wrote: > 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 > > On Fri, Jun 15, 2018 at 3:50 PM, Paulo Lopes <pmart...@redhat.com> wrote: >> 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: tonyzak...@gmail.com >> Sent: June 15, 2018 22:29 >> To: jlu...@riotgames.com >> Cc: yikesar...@gmail.com; nashorn-dev@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. >> >> >> On Mon, Jun 11, 2018 at 8:57 PM Jesus Luzon <jlu...@riotgames.com> wrote: >> >>> 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. >>> >>> On Mon, Jun 11, 2018 at 1:56 PM, Attila Szegedi <szege...@gmail.com> >>> wrote: >>> >>> > 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. >>> > >>> > >>> > > On 2018. Jun 11., at 21:35, Paulo Lopes <pmart...@redhat.com> wrote: >>> > > >>> > > 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 >>> > > On Mon, 2018-06-11 at 14:50 -0300, João Paulo Varandas wrote: >>> > >> 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. >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> On Thu, Jun 7, 2018 at 9:31 AM, yikes aroni <yikesar...@gmail.com> >>> > >> wrote: >>> > >> 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) >>> > >> questions: >>> > >> 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! >>> > >> >>> > >> >>> > >>> > >>>
