From hannes.wallnoefer at oracle.com Mon Jun 4 16:42:29 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 4 Jun 2018 18:42:29 +0200 Subject: RFR: 8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails Message-ID: <0C34A568-ADDF-44A5-A9BD-2B9D77C52CBC@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8204288 Webrev: http://cr.openjdk.java.net/~hannesw/8204288/webrev/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Tue Jun 5 09:19:52 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 05 Jun 2018 14:49:52 +0530 Subject: RFR: 8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails Message-ID: <5B1655B8.30201@oracle.com> Looks good. PS. Reply to http://mail.openjdk.java.net/pipermail/nashorn-dev/2018-June/007393.html -Sundar From hannes.wallnoefer at oracle.com Tue Jun 5 12:44:17 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 5 Jun 2018 14:44:17 +0200 Subject: RFR: 8204290: Add check to limit number of capture groups Message-ID: Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8204290 Webrev: http://cr.openjdk.java.net/~hannesw/8204290/webrev/ This (like the previous RFR) is another backport from jruby/joni. Thanks, Hannes From sundararajan.athijegannathan at oracle.com Tue Jun 5 14:48:03 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 05 Jun 2018 20:18:03 +0530 Subject: RFR: 8204290: Add check to limit number of capture groups In-Reply-To: References: Message-ID: <5B16A2A3.6010803@oracle.com> Looks good -Sundar On 05/06/18, 6:14 PM, Hannes Walln?fer wrote: > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204290 > Webrev: http://cr.openjdk.java.net/~hannesw/8204290/webrev/ > > This (like the previous RFR) is another backport from jruby/joni. > > Thanks, > Hannes From yikesaroni at gmail.com Thu Jun 7 12:31:11 2018 From: yikesaroni at gmail.com (yikes aroni) Date: Thu, 7 Jun 2018 08:31:11 -0400 Subject: Nashorn deprecation Message-ID: Hi i just read that Nashorn is being deprecated (JEP 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! From james.laskey at oracle.com Thu Jun 7 18:48:10 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 7 Jun 2018 15:48:10 -0300 Subject: RFR: 8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails In-Reply-To: <0C34A568-ADDF-44A5-A9BD-2B9D77C52CBC@oracle.com> References: <0C34A568-ADDF-44A5-A9BD-2B9D77C52CBC@oracle.com> Message-ID: <1A0AF23E-73F6-44EE-AE3F-00CE309ED1B8@oracle.com> +1 > On Jun 4, 2018, at 1:42 PM, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204288 > Webrev: http://cr.openjdk.java.net/~hannesw/8204288/webrev/ > > Thanks, > Hannes > From james.laskey at oracle.com Thu Jun 7 18:49:37 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 7 Jun 2018 15:49:37 -0300 Subject: RFR: 8204290: Add check to limit number of capture groups In-Reply-To: References: Message-ID: <077804BC-F5A4-4779-A86A-028A324B2478@oracle.com> +1 > On Jun 5, 2018, at 9:44 AM, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204290 > Webrev: http://cr.openjdk.java.net/~hannesw/8204290/webrev/ > > This (like the previous RFR) is another backport from jruby/joni. > > Thanks, > Hannes From joaovarandas at inpaas.com Mon Jun 11 17:50:16 2018 From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=) Date: Mon, 11 Jun 2018 14:50:16 -0300 Subject: Nashorn deprecation In-Reply-To: References: Message-ID: 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. On Thu, Jun 7, 2018 at 9:31 AM, yikes aroni wrote: > Hi i just read that Nashorn is being deprecated (JEP 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! > -- "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" From pmartins at redhat.com Mon Jun 11 19:35:38 2018 From: pmartins at redhat.com (Paulo Lopes) Date: Mon, 11 Jun 2018 21:35:38 +0200 Subject: Nashorn deprecation In-Reply-To: References: Message-ID: <8c72e9e781570f61935a3bc121d37390633d8ede.camel@redhat.com> 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 szegedia at gmail.com Mon Jun 11 20:56:57 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 11 Jun 2018 22:56:57 +0200 Subject: Nashorn deprecation In-Reply-To: <8c72e9e781570f61935a3bc121d37390633d8ede.camel@redhat.com> References: <8c72e9e781570f61935a3bc121d37390633d8ede.camel@redhat.com> Message-ID: <33FAED34-B57B-44A9-A0DF-A14AB67B09FC@gmail.com> Hey folks, the best thing you can do is answer to this thread on jdk-dev mailing list: . 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 . 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 jluzon at riotgames.com Mon Jun 11 21:26:38 2018 From: jluzon at riotgames.com (Jesus Luzon) Date: Mon, 11 Jun 2018 14:26:38 -0700 Subject: Nashorn deprecation In-Reply-To: <33FAED34-B57B-44A9-A0DF-A14AB67B09FC@gmail.com> References: <8c72e9e781570f61935a3bc121d37390633d8ede.camel@redhat.com> <33FAED34-B57B-44A9-A0DF-A14AB67B09FC@gmail.com> Message-ID: 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 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 szegedia at gmail.com Mon Jun 11 21:49:41 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 11 Jun 2018 23:49:41 +0200 Subject: Nashorn deprecation In-Reply-To: References: <8c72e9e781570f61935a3bc121d37390633d8ede.camel@redhat.com> <33FAED34-B57B-44A9-A0DF-A14AB67B09FC@gmail.com> Message-ID: <7617EAEB-71AA-4D0F-8301-C8818CC41BCF@gmail.com> 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. > On 2018. Jun 11., at 23:26, 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: >. 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 >. > > 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 jan.lahoda at oracle.com Fri Jun 15 13:47:58 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 15 Jun 2018 15:47:58 +0200 Subject: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError() Message-ID: <5B23C38E.9060402@oracle.com> Hi, The Nashorn APIs have been enhanced in JDK 8 updates. The proposal here is to update the historical data for --release 8 to JDK 8u40. Note this includes removal of: jdk.nashorn.api.scripting.NashornException.ENGINE_SCRIPT_SOURCE_NAME and: jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(...) and a change of: jdk.nashorn.api.scripting.ScriptUtils.wrap(...) Bug: https://bugs.openjdk.java.net/browse/JDK-8203814 Webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.00/ How does this look? Thanks, Jan From hannes.wallnoefer at oracle.com Fri Jun 15 14:52:08 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 15 Jun 2018 16:52:08 +0200 Subject: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError() In-Reply-To: <5B23C38E.9060402@oracle.com> References: <5B23C38E.9060402@oracle.com> Message-ID: <319CCAE9-FF1F-450B-A61F-A14F57E30DE2@oracle.com> Thanks for helping out with this, Jan. Unfortunately I found another change that was backported to 8u102 that changes the signatures of ScriptUtils makeSynchronizedFunction(?) and wrap(?) methods (again). https://bugs.openjdk.java.net/browse/JDK-8148379 I?m sorry about this, I should have checked when you first asked me about it. Otherwise the patch looks good to me. Hannes > Am 15.06.2018 um 15:47 schrieb Jan Lahoda : > > Hi, > > The Nashorn APIs have been enhanced in JDK 8 updates. The proposal here is to update the historical data for --release 8 to JDK 8u40. > > Note this includes removal of: > jdk.nashorn.api.scripting.NashornException.ENGINE_SCRIPT_SOURCE_NAME > and: > jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(...) > and a change of: > jdk.nashorn.api.scripting.ScriptUtils.wrap(...) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203814 > Webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.00/ > > How does this look? > > Thanks, > Jan From tonyzakula at gmail.com Fri Jun 15 20:28:22 2018 From: tonyzakula at gmail.com (Tony Zakula) Date: Fri, 15 Jun 2018 16:28:22 -0400 Subject: Nashorn deprecation In-Reply-To: References: <8c72e9e781570f61935a3bc121d37390633d8ede.camel@redhat.com> <33FAED34-B57B-44A9-A0DF-A14AB67B09FC@gmail.com> Message-ID: 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 pmartins at redhat.com Fri Jun 15 20:50:42 2018 From: pmartins at redhat.com (Paulo Lopes) Date: Fri, 15 Jun 2018 22:50:42 +0200 Subject: Nashorn deprecation In-Reply-To: Message-ID: 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 jan.lahoda at oracle.com Tue Jun 19 11:14:33 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 19 Jun 2018 13:14:33 +0200 Subject: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError() In-Reply-To: <319CCAE9-FF1F-450B-A61F-A14F57E30DE2@oracle.com> References: <5B23C38E.9060402@oracle.com> <319CCAE9-FF1F-450B-A61F-A14F57E30DE2@oracle.com> Message-ID: <5B28E599.7000107@oracle.com> Hi Hannes, Thanks for the comment, updated webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.01/ (It also includes a few more tweaks that turned out to be needed.) Jan On 15.6.2018 16:52, Hannes Walln?fer wrote: > Thanks for helping out with this, Jan. > > Unfortunately I found another change that was backported to 8u102 that changes the signatures of ScriptUtils makeSynchronizedFunction(?) and wrap(?) methods (again). > > https://bugs.openjdk.java.net/browse/JDK-8148379 > > I?m sorry about this, I should have checked when you first asked me about it. > > Otherwise the patch looks good to me. > > Hannes > > >> Am 15.06.2018 um 15:47 schrieb Jan Lahoda : >> >> Hi, >> >> The Nashorn APIs have been enhanced in JDK 8 updates. The proposal here is to update the historical data for --release 8 to JDK 8u40. >> >> Note this includes removal of: >> jdk.nashorn.api.scripting.NashornException.ENGINE_SCRIPT_SOURCE_NAME >> and: >> jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(...) >> and a change of: >> jdk.nashorn.api.scripting.ScriptUtils.wrap(...) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203814 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan > From hannes.wallnoefer at oracle.com Tue Jun 19 13:14:16 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 19 Jun 2018 15:14:16 +0200 Subject: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError() In-Reply-To: <5B28E599.7000107@oracle.com> References: <5B23C38E.9060402@oracle.com> <319CCAE9-FF1F-450B-A61F-A14F57E30DE2@oracle.com> <5B28E599.7000107@oracle.com> Message-ID: Hi Jan, The changes for Nashorn symbols all look good to me. Thanks, Hannes > Am 19.06.2018 um 13:14 schrieb Jan Lahoda : > > Hi Hannes, > > Thanks for the comment, updated webrev: > http://cr.openjdk.java.net/~jlahoda/8203814/webrev.01/ > > (It also includes a few more tweaks that turned out to be needed.) > > Jan > > On 15.6.2018 16:52, Hannes Walln?fer wrote: >> Thanks for helping out with this, Jan. >> >> Unfortunately I found another change that was backported to 8u102 that changes the signatures of ScriptUtils makeSynchronizedFunction(?) and wrap(?) methods (again). >> >> https://bugs.openjdk.java.net/browse/JDK-8148379 >> >> I?m sorry about this, I should have checked when you first asked me about it. >> >> Otherwise the patch looks good to me. >> >> Hannes >> >> >>> Am 15.06.2018 um 15:47 schrieb Jan Lahoda : >>> >>> Hi, >>> >>> The Nashorn APIs have been enhanced in JDK 8 updates. The proposal here is to update the historical data for --release 8 to JDK 8u40. >>> >>> Note this includes removal of: >>> jdk.nashorn.api.scripting.NashornException.ENGINE_SCRIPT_SOURCE_NAME >>> and: >>> jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(...) >>> and a change of: >>> jdk.nashorn.api.scripting.ScriptUtils.wrap(...) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203814 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8203814/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan >> From sundararajan.athijegannathan at oracle.com Mon Jun 25 15:16:46 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 25 Jun 2018 20:46:46 +0530 Subject: CSR - JDK-8205594 - Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs Message-ID: <5B31075E.9060304@oracle.com> Please review: https://bugs.openjdk.java.net/browse/JDK-8205594 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Wed Jun 27 04:16:11 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 27 Jun 2018 09:46:11 +0530 Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs Message-ID: <5B330F8B.1050509@oracle.com> Please review. Bug https://bugs.openjdk.java.net/browse/JDK-8204492 Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 Related: JEP http://openjdk.java.net/jeps/335 CSR https://bugs.openjdk.java.net/browse/JDK-8205594 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Wed Jun 27 04:19:33 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 27 Jun 2018 09:49:33 +0530 Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs In-Reply-To: <5B330F8B.1050509@oracle.com> References: <5B330F8B.1050509@oracle.com> Message-ID: <5B331055.4060305@oracle.com> Forgot to CC build-dev for makefile changes. -Sundar On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote: > Please review. > > Bug https://bugs.openjdk.java.net/browse/JDK-8204492 > Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 > > Related: > > JEP http://openjdk.java.net/jeps/335 > CSR https://bugs.openjdk.java.net/browse/JDK-8205594 > > Thanks, > -Sundar > From hannes.wallnoefer at oracle.com Wed Jun 27 09:42:10 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 27 Jun 2018 11:42:10 +0200 Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs In-Reply-To: <5B331055.4060305@oracle.com> References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com> Message-ID: <5B235217-1C30-4017-99FE-766DCDA67C23@oracle.com> Looks good. Hannes > Am 27.06.2018 um 06:19 schrieb Sundararajan Athijegannathan : > > Forgot to CC build-dev for makefile changes. > > -Sundar > > On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug https://bugs.openjdk.java.net/browse/JDK-8204492 >> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 >> >> Related: >> >> JEP http://openjdk.java.net/jeps/335 >> CSR https://bugs.openjdk.java.net/browse/JDK-8205594 >> >> Thanks, >> -Sundar >> From james.laskey at oracle.com Wed Jun 27 11:58:50 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 27 Jun 2018 08:58:50 -0300 Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs In-Reply-To: <5B330F8B.1050509@oracle.com> References: <5B330F8B.1050509@oracle.com> Message-ID: +1 > On Jun 27, 2018, at 1:16 AM, Sundararajan Athijegannathan wrote: > > Please review. > > Bug https://bugs.openjdk.java.net/browse/JDK-8204492 > Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 > > Related: > > JEP http://openjdk.java.net/jeps/335 > CSR https://bugs.openjdk.java.net/browse/JDK-8205594 > > Thanks, > -Sundar > From erik.joelsson at oracle.com Wed Jun 27 15:41:45 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Jun 2018 08:41:45 -0700 Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs In-Reply-To: <5B331055.4060305@oracle.com> References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com> Message-ID: <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com> Hello Sundar, Adding $(DISABLE_WARNINGS) disables a lot of warnings. Isn't jdk.scripting.nashorn pretty much warning frree now? What warnings do you really need to disable? /Erik On 2018-06-26 21:19, Sundararajan Athijegannathan wrote: > Forgot to CC build-dev for makefile changes. > > -Sundar > > On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug https://bugs.openjdk.java.net/browse/JDK-8204492 >> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 >> >> Related: >> >> JEP http://openjdk.java.net/jeps/335 >> CSR https://bugs.openjdk.java.net/browse/JDK-8205594 >> >> Thanks, >> -Sundar >> From sundararajan.athijegannathan at oracle.com Wed Jun 27 15:59:02 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 27 Jun 2018 21:29:02 +0530 Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs In-Reply-To: <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com> References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com> <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com> Message-ID: <5B33B446.40109@oracle.com> Hi Erik, Yes, nashorn is warning free afaik. Besides nashorn is being deprecated. No further development expected other than perhaps occasional bug fixes. We need to disable javac deprecation warnings. Without this javac deprecation warnings cause build failure. -Sundar On 27/06/18, 9:11 PM, Erik Joelsson wrote: > Hello Sundar, > > Adding $(DISABLE_WARNINGS) disables a lot of warnings. Isn't > jdk.scripting.nashorn pretty much warning frree now? What warnings do > you really need to disable? > > /Erik > > > On 2018-06-26 21:19, Sundararajan Athijegannathan wrote: >> Forgot to CC build-dev for makefile changes. >> >> -Sundar >> >> On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote: >>> Please review. >>> >>> Bug https://bugs.openjdk.java.net/browse/JDK-8204492 >>> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 >>> >>> Related: >>> >>> JEP http://openjdk.java.net/jeps/335 >>> CSR https://bugs.openjdk.java.net/browse/JDK-8205594 >>> >>> Thanks, >>> -Sundar >>> > From erik.joelsson at oracle.com Wed Jun 27 15:59:53 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Jun 2018 08:59:53 -0700 Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs In-Reply-To: <5B33B446.40109@oracle.com> References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com> <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com> <5B33B446.40109@oracle.com> Message-ID: <70af42e4-4db2-320f-acf3-9940e61d9bd6@oracle.com> If it's just deprecation you want to remove, then -Xlint:all,-deprecation should be enough to add. The current argument for jdk.scripting.nashorn is -Xlint:all (if I'm not mistaken). /Erik On 2018-06-27 08:59, Sundararajan Athijegannathan wrote: > Hi Erik, > > Yes, nashorn is warning free afaik. Besides nashorn is being > deprecated. No further development expected other than perhaps > occasional bug fixes. > > We need to disable javac deprecation warnings. Without this javac > deprecation warnings cause build failure. > > -Sundar > > On 27/06/18, 9:11 PM, Erik Joelsson wrote: >> Hello Sundar, >> >> Adding $(DISABLE_WARNINGS) disables a lot of warnings. Isn't >> jdk.scripting.nashorn pretty much warning frree now? What warnings do >> you really need to disable? >> >> /Erik >> >> >> On 2018-06-26 21:19, Sundararajan Athijegannathan wrote: >>> Forgot to CC build-dev for makefile changes. >>> >>> -Sundar >>> >>> On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote: >>>> Please review. >>>> >>>> Bug https://bugs.openjdk.java.net/browse/JDK-8204492 >>>> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 >>>> >>>> Related: >>>> >>>> JEP http://openjdk.java.net/jeps/335 >>>> CSR https://bugs.openjdk.java.net/browse/JDK-8205594 >>>> >>>> Thanks, >>>> -Sundar >>>> >> From sundararajan.athijegannathan at oracle.com Thu Jun 28 04:53:22 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 28 Jun 2018 10:23:22 +0530 Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs In-Reply-To: <70af42e4-4db2-320f-acf3-9940e61d9bd6@oracle.com> References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com> <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com> <5B33B446.40109@oracle.com> <70af42e4-4db2-320f-acf3-9940e61d9bd6@oracle.com> Message-ID: <5B3469C2.6070003@oracle.com> Only -deprecation still results in build failure :( I'll go with what I've now to push the change before the deadline -- and we can revisit better makefile option in a future patch. Thanks, -Sundar On 27/06/18, 9:29 PM, Erik Joelsson wrote: > If it's just deprecation you want to remove, then > -Xlint:all,-deprecation should be enough to add. The current argument > for jdk.scripting.nashorn is -Xlint:all (if I'm not mistaken). > > /Erik > > > On 2018-06-27 08:59, Sundararajan Athijegannathan wrote: >> Hi Erik, >> >> Yes, nashorn is warning free afaik. Besides nashorn is being >> deprecated. No further development expected other than perhaps >> occasional bug fixes. >> >> We need to disable javac deprecation warnings. Without this javac >> deprecation warnings cause build failure. >> >> -Sundar >> >> On 27/06/18, 9:11 PM, Erik Joelsson wrote: >>> Hello Sundar, >>> >>> Adding $(DISABLE_WARNINGS) disables a lot of warnings. Isn't >>> jdk.scripting.nashorn pretty much warning frree now? What warnings >>> do you really need to disable? >>> >>> /Erik >>> >>> >>> On 2018-06-26 21:19, Sundararajan Athijegannathan wrote: >>>> Forgot to CC build-dev for makefile changes. >>>> >>>> -Sundar >>>> >>>> On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote: >>>>> Please review. >>>>> >>>>> Bug https://bugs.openjdk.java.net/browse/JDK-8204492 >>>>> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 >>>>> >>>>> Related: >>>>> >>>>> JEP http://openjdk.java.net/jeps/335 >>>>> CSR https://bugs.openjdk.java.net/browse/JDK-8205594 >>>>> >>>>> Thanks, >>>>> -Sundar >>>>> >>> >