From headius at headius.com Tue Jul 3 23:19:48 2018 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 3 Jul 2018 18:19:48 -0500 Subject: Nashorn deprecation In-Reply-To: References: Message-ID: 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 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: tonyzakula at gmail.com > Sent: June 15, 2018 22:29 > To: jluzon at riotgames.com > Cc: yikesaroni at gmail.com; nashorn-dev at 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 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 >> wrote: >> >> > Hey folks, >> > >> > the best thing you can do is answer to this thread on jdk-dev mailing >> > list: > > 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 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 >> > >> wrote: >> > >> Hi i just read that Nashorn is being deprecated (JEP 335> > >> 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! >> > >> >> > >> >> > >> > >> From headius at headius.com Tue Jul 3 23:21:19 2018 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 3 Jul 2018 18:21:19 -0500 Subject: Nashorn deprecation In-Reply-To: References: Message-ID: 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 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 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: tonyzakula at gmail.com >> Sent: June 15, 2018 22:29 >> To: jluzon at riotgames.com >> Cc: yikesaroni at gmail.com; nashorn-dev at 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 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 >>> wrote: >>> >>> > Hey folks, >>> > >>> > the best thing you can do is answer to this thread on jdk-dev mailing >>> > list: >> > 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 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 >>> > >> wrote: >>> > >> Hi i just read that Nashorn is being deprecated (JEP 335>> > >> 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! >>> > >> >>> > >> >>> > >>> > >>> From mark.reinhold at oracle.com Thu Jul 19 23:29:25 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Jul 2018 16:29:25 -0700 Subject: Nashorn deprecation In-Reply-To: References: Message-ID: <20180719162925.786128514@eggemoggin.niobe.net> 2018/7/3 16:19:48 -0700, 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. > 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 From krusimon at amazon.com Tue Jul 10 23:55:40 2018 From: krusimon at amazon.com (Krueger, Simon) Date: Tue, 10 Jul 2018 23:55:40 +0000 Subject: Nashorn script security permissions not working for .js Message-ID: <3A72A94E-E906-4F4A-92EB-2BDD555DB371@amazon.com> I cannot get the example at https://wiki.openjdk.java.net/display/Nashorn/Nashorn+script+security+permissions to work. Specifically, I cannot seem to get the permissions for the test.js to apply. The permissions of the .jar that loads the test.js will work. This seems to be a bug. Can anyone else verify if it is working for them or not? Simon From sundararajan.athijegannathan at oracle.com Mon Jul 23 05:24:55 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 23 Jul 2018 10:54:55 +0530 Subject: Nashorn script security permissions not working for .js In-Reply-To: <3A72A94E-E906-4F4A-92EB-2BDD555DB371@amazon.com> References: <3A72A94E-E906-4F4A-92EB-2BDD555DB371@amazon.com> Message-ID: <5B5566A7.6050402@oracle.com> Make sure that test.js is loaded via URLReader or load primitive. i.e., nashorn engine should load the script pointed via URL - if you pass FileReader or loaded content to engine.eval, Nashorn will treat it as sandboxed - i.e., script loaded from untrusted source. If it still does not work for you, please post a test case here and/or file a bug with a test. -Sundar On 11/07/18, 5:25 AM, Krueger, Simon wrote: > I cannot get the example at https://wiki.openjdk.java.net/display/Nashorn/Nashorn+script+security+permissions to work. Specifically, I cannot seem to get the permissions for the test.js to apply. The permissions of the .jar that loads the test.js will work. This seems to be a bug. Can anyone else verify if it is working for them or not? > > Simon