Re: Nashorn Standalone 15.3 engine returned is null

Can you check if this is specific to 15.3, or does it also not work with e.g. 15.2? Attila. > On 2021. Jul 15., at 12:49, Andreas Mueller wrote: > > Tested it again with listing the engine right befor getByName: > > List factories = manager.getEngineFactories(); > for (int i = 0; i <

Re: Nashorn Standalone 15.3 engine returned is null

Tested it again with listing the engine right befor getByName: List factories = manager.getEngineFactories(); for (int i = 0; i < factories.size(); i++) {     ctx.logSwiftlet.logInformation(ctx.streamsSwiftlet.getName(), "name=" + factories.get(i).getEngineName() +             ", version=" +

Re: Nashorn Standalone 15.3 engine returned is null

Here are the jar files I use: am@Mac-mini scripts % ll ../nashorn total 4968 -rwxr-xr-x  1 am  staff   121836 Jul 11 14:31 asm-7.3.1.jar -rwxr-xr-x  1 am  staff    33446 Jul 11 14:31 asm-analysis-7.3.1.jar -rwxr-xr-x  1 am  staff    71548 Jul 11 14:31 asm-commons-7.3.1.jar -rwxr-xr-x  1 am  staff

Re: Nashorn Standalone 15.3 engine returned is null

Hi Attila, thanks but didn’t work in my environment.  Tried every combination (using “nashorn”, “JavaScript” as name, using class path, using module path).  Fact is, it lists the Nashorn engine correctly: ScriptEngineManager manager = new ScriptEngineManager(); List factories =

Re: Nashorn Standalone 15.3 engine returned is null

I’m honestly not sure. I have this very small test program: import javax.script.*; public class X { public static void main(String[] args) throws ScriptException { ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine engine =

Re: Nashorn 15.3 is out

On 01.07.2021 13:32, Attila Szegedi wrote: > Hey all, > > I just released Nashorn 15.3[0]. Check the change log[1] to easily see what’s > new. > > The most notable change is that Nashorn now works with JDK 17. > > Attila. > > [0] >

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

> From: "Attila Szegedi" > To: "Remi Forax" > Cc: "nashorn-dev" > Sent: Mardi 29 Juin 2021 00:37:56 > Subject: Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17? >> On 2021. Jun 28., at 19:30, Remi Forax < [ mai

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

> On 2021. Jun 28., at 19:30, Remi Forax wrote: > > > In the meantime, I think you can use Lookup.defineClass() or do you rely on > the weird security model of the anonymous classes ? Thankfully, no. Nashorn regenerates code for the same function sometimes so it was convenient having old

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

- Original Message - > From: "Attila Szegedi" > To: "nashorn-dev" > Cc: "Greg Watts" > Sent: Lundi 28 Juin 2021 19:07:38 > Subject: Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17? > Hi Gre

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

Hi Greg, that’s a consequence of Java 17 removing the Unsafe.defineAnonymousClass method. Unfortunately, we don’t have an ideal replacement for it yet. MethodHandles.Lookup.defineHiddenClass is supposed to be a publicly supported replacement, but it hides the generated classes from stack

Re: JDK Dynalink only works with unconditionally exported packages

On 2021. May 11., at 1:51, Thiago Henrique Hupner wrote: > > Hi all. > > I've been testing the JDK Dynalink recently and > I think I've found a bug. > > The class jdk.dynalink.beans.CheckRestrictedPackage checks > if a package is restricted. > > So, I have a class that has some static

Re: ECMAScript 6 through the ScriptEngineManager

I’ve also been considering this idea. FWIW, there are some incompatibilities between ES5 and ES6. Most people wouldn’t ever encounter these as they typically make some things work in ES6 that wouldn’t work in ES6 For example, there’s a bunch of methods on Object prototype that in ES5 throw a

Re: ECMAScript 6 through the ScriptEngineManager

Hi Attila, On 29.03.2021 19:29, Attila Szegedi wrote: > today the most used ECMAScript version is 6 (ES6); Nashorn OTOH implements > the full ECMAScript 5.1 (ES5) specification and also a subset[0] of 6. > Mostly for compatibility purposes though, it defaults to ES5 and ES6 features > aren’t

Ad "Re: Run servlets on Nashorn written in server-side JavaScript" ...

As this may be interesting for the Nashorn community as well FYI: Forwarded Message Subject:Re: Run servlets on Nashorn written in server-side JavaScript Date: Sun, 28 Feb 2021 17:33:22 +0100 From: Rony G. Flatscher Reply-To: Tomcat Users

Re: Terminate running script thread

- Mail original - > De: "Attila Szegedi" > À: "Viktor Remennik" > Cc: "nashorn-dev" > Envoyé: Samedi 27 Février 2021 18:07:55 > Objet: Re: Terminate running script thread Hi, > No, there’s no support for that. Nashorn comp

Re: Terminate running script thread

Thanks, by all means report back with what you found :-) Attila. > On 2021. Feb 27., at 18:59, Viktor Remennik wrote: > > I didn’t checked it yet, just wanted to ask first. It is implemented in > graal, will look there to check how. The first idea i thought, was to inject > some global var

Re: Terminate running script thread

I didn’t checked it yet, just wanted to ask first. It is implemented in graal, will look there to check how. The first idea i thought, was to inject some global var checking in loops, but i am not a big specialist in that area yet. Will study it further then, thank you! Kind regards, Viktor >

Re: Terminate running script thread

No, there’s no support for that. Nashorn compiles all scripts to JVM bytecode and runs them as such. There’s no more of a way to stop that code than any Java code. Even if there was some other way, I don’t see how would stopping a thread be materially better than what Thread#stop provides. I’m

Re: Question ad "arguments" and ScriptEngine.ARGV

Keep forgetting, that adding boldness breaks the text. Here the JSP text without any styling (hence without those injected asterisks): <%@ page session="false" pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %> <%@ taglib uri="/WEB-INF/script-jsr223.tld" prefix="s" %>

Re: Lowering minimum runtime requirement to Java 11

On 09.02.2021 21:03, Attila Szegedi wrote: There’s one minor point to consider: should it be compiled with Java 15 compiler, but targeting 11, or should it simply be compiled with Java 11 compiler? Is there any advantage in using javac from 15 targeting 11? I think it's usually better to

Re: Fix for NashornScriptEngineFactory.getOutputStatement(toDisplay) (Re: Standalone Nashorn is coming for Java 15+

Hi, thanks for reporting this. I filed a JBS issue[0] and I have a PR[0] to fix it put up. It’ll go into the next Nashorn release. Thanks, Attila. [0] https://bugs.openjdk.java.net/browse/JDK-8258787 [1] https://github.com/openjdk/nashorn/pull/11 > On 2020. Nov 23., at 17:20, Rony G.

Re: Some Nashorn PRs need review love

Thank you! I have since added testing for non-modular Nashorn (details on the PR.) > On 2020. Dec 17., at 7:36, sundararajan.athijegannat...@oracle.com wrote: > > Hi, > > Approved 4 out of 5. Clarification sought for 1 > > Thanks, > > -Sundar > > On 17/12/20 2:40 am, Attila Szegedi wrote:

Re: Some Nashorn PRs need review love

Hi, Approved 4 out of 5. Clarification sought for 1 Thanks, -Sundar On 17/12/20 2:40 am, Attila Szegedi wrote: I have several Nashorn PRs up for review; I started working my way through the JBS bug tracker. If anyone with OpenJDK reviewer privileges feels like helping, you can contribute a

Re: RFC: enable demodularized operation?

> On 2020. Dec 16., at 11:58, Ben Evans wrote: > > Hi Attila, > > This might be being pedantic - but for folks that want to use > standalone Nashorn it is emphatically not the case that they "have not > adopted JPMS": If they're using a Java 9+ runtime then they *have* > adopted JPMS -

Re: RFC: enable demodularized operation?

Hi Attila, This might be being pedantic - but for folks that want to use standalone Nashorn it is emphatically not the case that they "have not adopted JPMS": If they're using a Java 9+ runtime then they *have* adopted JPMS - they're just using a nasty compatibility mode of it to dump their

RE: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

Wednesday, October 30, 2019 1:31 PM To: Nashorn-Dev Subject: Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared Thanks for the report! https://bugs.openjdk.java.net/browse/JDK-8233195 The provided patch looks reasonable so the chances to get this fixed are

Re: RFC: enable demodularized operation?

Hi Ben, funnily enough since I posted this I found this newly submitted issue: The reporter there argues that lots of folks might still be using Nashorn in non-modular applications. I think all module handling is restricted to three source

Re: RFC: enable demodularized operation?

Hi Attila, I'd like to put forward a counterargument: Why would this be a good use of time? Nashorn SO requires at least Java 15, so it will never need to run on a pre-modular runtime. Rather than spending effort on making it run as a non-modular JAR, I would argue that getting to the bottom of

RE: RFC: enable demodularized operation?

Dear Attila, Nice to meet you. I'm working for Yokogawa, and we're using JDK11 and Nashorn in one of our products. Our code has not adopted the java module system. They probably do that for next release (I'm not sure). We're not using spring-boot. We're using the script engine as part of

Re: Nashorn + Spring Boot; help appreciated

Thanks Remi, although I don’t think that’s it. To wit, if I write a minimal executable example: --- import javax.script.*; public class X { public static void main(String[] args) throws ScriptException { ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine

Re: Nashorn + Spring Boot; help appreciated

Hi Attila, for compatibility, you have to both use the new module-info descriptor and the old META-INFO/services when you declare a service. It's a shame that jar doesn't do that by itself, it was something we (module/jigsaw EG) discussed but it was never implemented. regards, Rémi - Mail

Re: Standalone Nashorn 15.0 is out!

Congrats Attila! -Sundar On 28/11/20 12:06 am, Attila Szegedi wrote: Hey everyone, I’m happy to announce that the first standalone version of Nashorn, 15.0 is now available on Maven Central[0]! This version of Nashorn requires minimum of Java 15 to run. If you want to use Nashorn on older

Re: Standalone Nashorn 15.0 is out!

Congrats and Thank you! On Fri, Nov 27, 2020 at 4:28 PM Jamie Mansfield wrote: > Hey Attila, > > Congrats to you and team, fab news to see Nashorn back! Great effort > from you to get us here, and you have my thanks for that :) > > Best regards, > Jamie > > >

Re: Standalone Nashorn 15.0 is out!

Hey Attila, Congrats to you and team, fab news to see Nashorn back! Great effort from you to get us here, and you have my thanks for that :) Best regards, Jamie

Re: Standalone Nashorn 15.0 is out!

Congrats!  On Fri, Nov 27, 2020 at 12:36 PM Attila Szegedi wrote: > Hey everyone, > > I’m happy to announce that the first standalone version of Nashorn, 15.0 > is now available on Maven Central[0]! > > This version of Nashorn requires minimum of Java 15 to run. If you want to > use Nashorn

Re: Standalone Nashorn bound to specific JVM flavors?

i > Sent: Monday, November 23, 2020 11:59 AM > To: BURRIS Thomas > Cc: nashorn-dev@openjdk.java.net > Subject: Re: Standalone Nashorn bound to specific JVM flavors? > > EXTERNAL EMAIL : The sender of this email is external to 3DS. Be wary of the > content and do not open unexpect

Re: Standalone Nashorn bound to specific JVM flavors?

- Mail original - > De: "BURRIS Thomas" > À: "Attila Szegedi" > Cc: "nashorn-dev" > Envoyé: Lundi 23 Novembre 2020 18:32:37 > Objet: RE: Standalone Nashorn bound to specific JVM flavors? > Hi Attila -- Just to clarify to make

RE: Standalone Nashorn bound to specific JVM flavors?

...@3ds.com http://www.3ds.com/enovia ––– DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States -Original Message- From: Attila Szegedi Sent: Monday, November 23, 2020 11:59 AM To: BURRIS Thomas Cc: nashorn-dev@openjdk.java.net Subject: Re: Standalone

Re: Standalone Nashorn bound to specific JVM flavors?

It has exactly one dependency on sun.misc.Unsafe - a call to defineAnonymousClass. I’m not aware if that’s available on other JVMs or not, but that might be the only issue I’m aware of. FWIW, Nashorn can be used with --anonymous-classes=false to turn this feature off (it’s a bit of an

Fix for NashornScriptEngineFactory.getOutputStatement(toDisplay) (Re: Standalone Nashorn is coming for Java 15+

Hi there, the NashornScriptEngineFactory.getOutputStatement() does not create a valid String from the toDisplay argument. As a result it is not possible to create correct Javascript statements that output strings created with that method (Nashorn creates an exception when running a statement

Re: Standalone Nashorn is coming for Java 15+

Hey ;) > I don’t know how does Gradle stack up against Maven when it comes to > signing and publishing artifacts. Gradle includes a 'signing' plugin [1] and a 'maven-publish' plugin [2] that can be combined [3] to provide sufficient metadata for the Central repository. While I'm no expert, I'm

Re: Standalone Nashorn is coming for Java 15+

Thanks Ben, FWIW, I just gave up on using Ivy in the PR; the behavior between 2.4.0 and 2.5.0 changed significantly and I decided the added value of Ivy is not proportional to the newly arisen headaches. I absolutely want to move away from Ant; once 15.0 is out I’d like to switch to either

Re: Standalone Nashorn is coming for Java 15+

Thanks Isaiah - I totally missed that point in the thread. I'll hit up some Ivy folks I know and see if they're interested in helping with this. Ben On Tue, 17 Nov 2020 at 12:50, Isaiah Peng wrote: > > FYI, the reason for using Any is specified in the thread: > > > I still need to figure out

Re: Standalone Nashorn is coming for Java 15+

FYI, the reason for using Any is specified in the thread: > I still need to figure out the minimal descriptive pom.xml (dependencies etc., no build information) in order to be able to produce Maven artifacts. Right now, Nashorn’s build and test process is highly customized set of Ant build.xml

Re: Standalone Nashorn is coming for Java 15+

Thanks for all the work you've done on this, Attila. Quick question: The project still seems to be using Ant. Is there a reason for that? Would you merge a PR that ported the build system to Maven or Gradle instead? (and if so, do you have a preference for either one?) IME, Ant is rather

Re: Standalone Nashorn is coming for Java 15+

For anyone who doesn’t want to build this from sources themselves, but want to try it, I put a preliminary prebuilt version in my Dropbox at Attila. > On 2020. Nov 15., at 18:25, Attila Szegedi wrote: > > Hi y’all, > >

Re: Standalone Nashorn is coming for Java 15+

Hi y’all, openjdk/nashorn repo is up and its main branch is populated with the initial copy of Nashorn as it existed in JDK 14. I added a fix for wrong/missing licenses for two files (agreed with Oracle) and an initial project README on top of it. An even better news is that I have the

Re: Standalone Nashorn is coming for Java 15+

+1 On Sun, Oct 25, 2020 at 5:18 PM Peter Ansell wrote: > Hi Atilla, > > Nashorn-15 seems intuitive to me. > > Thanks for the regular updates! > > Peter > > On Mon, 26 Oct 2020 at 04:08, Attila Szegedi wrote: > > > > Hi y’all, > > > > trying to get into the habit of making these weekly updates

Re: Standalone Nashorn is coming for Java 15+

Hi Atilla, Nashorn-15 seems intuitive to me. Thanks for the regular updates! Peter On Mon, 26 Oct 2020 at 04:08, Attila Szegedi wrote: > > Hi y’all, > > trying to get into the habit of making these weekly updates until I have > something else to show. > > * With Remi’s, Sundar’s and Mandy’s

Re: Standalone Nashorn is coming for Java 15+

Hi y’all, trying to get into the habit of making these weekly updates until I have something else to show. * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. We’ll be using the sun.misc.Unsafe for now, with hope to transition to Lookup.defineHiddenClass somewhere down

Re: Standalone Nashorn is coming for Java 15+

fr wrote: - Mail original - De: "Attila Szegedi" À: "nashorn-dev" Envoyé: Lundi 19 Octobre 2020 17:16:55 Objet: Re: Standalone Nashorn is coming for Java 15+ Hi y’all, Hi Attila, a quick update with regard of what’s been happening since the last post. * I’m talki

Re: Standalone Nashorn is coming for Java 15+

On 10/19/20 11:44 AM, Remi Forax wrote: Hi Attila, * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has a feature called “anonymous code loading”

Re: Standalone Nashorn is coming for Java 15+

> De: "Attila Szegedi" > À: "remi forax" > Cc: "nashorn-dev" , "mandy chung" > > Envoyé: Lundi 19 Octobre 2020 20:28:53 > Objet: Re: Standalone Nashorn is coming for Java 15+ >> On 2020. Oct 19., at 18:06, Remi Forax < [ mailto

Re: Standalone Nashorn is coming for Java 15+

> On 2020. Oct 19., at 18:06, Remi Forax wrote: > > - Mail original - >> De: "Attila Szegedi" mailto:szege...@gmail.com>> >> À: "nashorn-dev" > <mailto:nashorn-dev@openjdk.java.net>> >> Envoyé: Lundi 19 Octobre 202

Re: Standalone Nashorn is coming for Java 15+

- Mail original - > De: "Attila Szegedi" > À: "nashorn-dev" > Envoyé: Lundi 19 Octobre 2020 17:16:55 > Objet: Re: Standalone Nashorn is coming for Java 15+ > Hi y’all, Hi Attila, > > a quick update with regard of what’s been happening since th

Re: Standalone Nashorn is coming for Java 15+

Hi y’all, a quick update with regard of what’s been happening since the last post. * I’m talking with folks at Oracle about setting up the openjdk/nashorn repo. We’re hashing out what the initial content of the repo should be. * The licensing for the standalone Nashorn is confirmed to be

Re: Stand-alone Nashorn licensing

I am not considering moving Nashorn to Apache. As to the why: I believe OpenJDK is a very robust open source organization with a good governance model. Nashorn already exists as a project in OpenJDK, and it was a natural choice to continue its development within its existing organization.

Re: Stand-alone Nashorn licensing

Not sure what you mean by “derailed probe.” Are you saying in the past you tried to move Nashorn to the Apache Software Foundation? Or you tried to get Nashorn to be licensed under the Apache license? In any case, I’m not aware of any such past efforts. Attila. > On 2020. Oct 14., at 15:49,

Re: Stand-alone Nashorn licensing

I’m talking with folks within Oracle about this topic. My assumption is that the code being lifted out of the jdk project doesn’t change its licensing, so it should continue to be GPL Version 2 with Classpath exception. A past example of a project similarly spun off from jdk was JavaFX and that

Re: Standalone Nashorn is coming for Java 15+

Thank you for working on Nashorn Attila. We use it extensively. Not sure what exactly we can contribute, but willing to help if we can. Thanks, Tony On Mon, Oct 12, 2020 at 9:05 AM Attila Szegedi wrote: > Hi Anamitra, > > yes, that is the exact intent of this initial standalone Nashorn

Re: Standalone Nashorn is coming for Java 15+

ing an explicit addition of Nashorn internal packages to access-checked >> list. I’ve been trying to figure out what to do about that. > > To be clear, the failing tests are just these four: > > https://github.com/sqreen/nashorn/tree/master/test/nashorn/script/failing-s

Re: Standalone Nashorn is coming for Java 15+

On Mon, Oct 12, 2020 at 5:54 PM Attila Szegedi wrote: > > On 2020. Oct 12., at 18:41, Gustavo Lopes wrote: > > > > * Half a dozen sandboxing tests don't pass because they require that > > nashorn be loaded on the platform classloader. More precisly, when running > > with a security manager and

Re: Standalone Nashorn is coming for Java 15+

> On 2020. Oct 12., at 18:41, Gustavo Lopes wrote: > > I had to change to the Unsafe in sun.misc rather than the internal one Yeah, forgot to address this one… So that is used for “anonymous code loading” which is an optional feature and I think for the first cut, I might just disable it.

Re: Standalone Nashorn is coming for Java 15+

Hi Gustavo! On 2020. Oct 12., at 18:41, Gustavo Lopes wrote: > > I've incidentally been working on this lately. > > The results of my efforts are here: https://github.com/sqreen/nashorn Yeah, Sqreen was one of the businesses that indicated they’d need this. > The tests that don't require

Re: Standalone Nashorn is coming for Java 15+

I've incidentally been working on this lately. The results of my efforts are here: https://github.com/sqreen/nashorn The tests that don't require external js libraries all pass, with some exceptions: * I couldn't get the tests requiring jemmy to pass. IIRC, the original ant files pointed to

Re: Standalone Nashorn is coming for Java 15+

Hi Anamitra, yes, that is the exact intent of this initial standalone Nashorn release work. A minor point though where you mention “java application path": Nashorn used to be a JDK module, and it only works properly when put on the module path. But as long as you put it in the --module-path,

Re: New Nashorn Project Lead: Attila Szegedi

+100 from me as well. Thank you, Attilla, for picking up the torch. > On 12 Oct 2020, at 11:46, sundararajan.athijegannat...@oracle.com wrote: > > +100 :) Congrats Attila! > > -Sundar > > On 12/10/20 3:10 pm, Hannes Wallnoefer wrote: >> Excellent news, Attila! >> >> I couldn’t think of a

Re: New Nashorn Project Lead: Attila Szegedi

+100 :) Congrats Attila! -Sundar On 12/10/20 3:10 pm, Hannes Wallnoefer wrote: Excellent news, Attila! I couldn’t think of a better person for this task than you. I’m glad there is a future for Nashorn, and I hope I’ll be able to contribute something to the project somewhere down the road.

Re: New Nashorn Project Lead: Attila Szegedi

Excellent news, Attila! I couldn’t think of a better person for this task than you. I’m glad there is a future for Nashorn, and I hope I’ll be able to contribute something to the project somewhere down the road. Hannes > Am 11.10.2020 um 09:26 schrieb Attila Szegedi : > > Thank you,

Re: New Nashorn Project Lead: Attila Szegedi

Thank you, Vladimir! I accept the nomination[1]. Attila. [1] I read the Bylaws and they do not seem to require the candidate to declare whether they accept – or even agree with – the nomination. While I wouldn’t think anyone would ever nominate a candidate without their consent, I still

Re: Resigning as OpenJDK Nashorn Project Lead

Thank you Jim for creating Nashorn and shepherding it through the years. I remember when I joined the project that I was impressed with the quality of the original code I found there, as well as your eagerness to always help us get up to speed on it. Thanks in big part to you, it was very easy

Re: Resigning as OpenJDK Nashorn Project Lead

Could you elaborate? I worked on both Rhino and Nashorn and have been a project admin for Rhino for a while. So did Hannes. And yet us having worked on both is the only relation between the two I can see. They certainly don’t share code and I don’t think Rhino is in any form an “original” of

Re: Resigning as OpenJDK Nashorn Project Lead

On 10/5/20 10:17 PM, sundararajan.athijegannat...@oracle.com wrote: Nashorn is not related to Rhino project at all. Nashorn is a different implementation of ES 5.1 and select few features of ES6 . Although the second sentence is true, the first is not. -- Colby Russell

Re: Resigning as OpenJDK Nashorn Project Lead

Just a clarification. You said "the original Rhino project" - which seems to suggest that Nashorn is related to Rhino. Nashorn is not related to Rhino project at all. Nashorn is a different implementation of ES 5.1 and select few features of ES6 . -Sundar On 05/10/20 11:50 pm,

Re: Resigning as OpenJDK Nashorn Project Lead

On 10/5/20 1:11 PM, Jim Laskey wrote: Nashorn was deprecated in JDK 11 [5] was removed from the OpenJDK in JDK 15 [6]. Moving forward, it is hoped that Nashorn may continue on as a standalone library in maven central. Any chance Nashorn ownership would be transferred to either the Apache

Re: RFR 8246113: re-visit javax/script test that still requires jdk.scripting.nashorn module

+1 > On Jul 15, 2020, at 12:58 PM, sundararajan.athijegannat...@oracle.com wrote: > > Hi, > > Please review - removing these tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246113 > > Webrev: http://cr.openjdk.java.net/~sundar/8246113/webrev.00/ > > Thanks > > -Sundar >

RFR 8246113: re-visit javax/script test that still requires jdk.scripting.nashorn module

Hi, Please review - removing these tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8246113 Webrev: http://cr.openjdk.java.net/~sundar/8246113/webrev.00/ Thanks -Sundar

Re: RFR jdk15 8247956: remove scripts under bin/nashorn and doc/nashorn/source

On 2020-06-23 08:32, sundararajan.athijegannat...@oracle.com wrote: Please review Bug: https://bugs.openjdk.java.net/browse/JDK-8247956 Webrev: http://cr.openjdk.java.net/~sundar/8247956/webrev.00/ Looks good to me. Thank you for cleaning out these remnants. /Magnus Thanks -Sundar

Re: RFR jdk15 8247956: remove scripts under bin/nashorn and doc/nashorn/source

+1  > On Jun 23, 2020, at 3:37 AM, sundararajan.athijegannat...@oracle.com wrote: > > Please review > > Bug: https://bugs.openjdk.java.net/browse/JDK-8247956 > > Webrev: http://cr.openjdk.java.net/~sundar/8247956/webrev.00/ > > Thanks > > -Sundar >

Re: JDK-8229011: Workaround?

Not sure if it will help but you could try the "--optimistic-types=false" option. > On Jun 9, 2020, at 6:22 AM, STAMPF Lukas wrote: > > Hello, > > I wanted to ask if there is any workaround for the memory leak described in > https://bugs.openjdk.java.net/browse/JDK-8229011 > > Unfortunatly

Re: Questions about nashorn

Hello, Answers inline below. > Am 18.05.2020 um 05:40 schrieb 阮智 <1655362...@qq.com>: > > Hello, I have some questions about using nashorn in the project > > The first question: what is the usage scenario of > nashorn.option.class.cache.size, and what benefits can be brought by > modifying

Re: RFR 8241749

On Mon, Apr 20, 2020 at 1:35 PM Abhay Kulkarni wrote: > Hi, > > I don't know if this question was asked earlier. Is there any other > javascript engine which can be used instead of nashorn in JDK 11? Also, > exactly in which version/release of openJDK 11 is this removal taking > effect? > >

Re: RFR 8241749

Hi, I don't know if this question was asked earlier. Is there any other javascript engine which can be used instead of nashorn in JDK 11? Also, exactly in which version/release of openJDK 11 is this removal taking effect? Also, to reiterate others' concerns, this breaks backward compatibility

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

Thanks Mandy. I'll add bug id next to @ignore before push. Thanks, -Sundar On 16/04/20 2:50 am, Mandy Chung wrote: This looks okay to me. Can you add the bug ID next to @ignore that will make it easier to find the JBS issue?   These test bugs are filed with P4 but I think they should be

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

Thanks for spotting this Magnus! I'll fix this before push. Thanks. -Sundar On 15/04/20 10:44 pm, Magnus Ihse Bursie wrote: On 2020-04-15 17:56, sundararajan.athijegannat...@oracle.com wrote: Please review. Nashorn script engine modules (jdk.scripting.nashorn, jdk.scripting.nashorn.shell)

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

This looks okay to me. Can you add the bug ID next to @ignore that will make it easier to find the JBS issue?   These test bugs are filed with P4 but I think they should be fixed in 15. Mandy On 4/15/20 8:56 AM, sundararajan.athijegannat...@oracle.com wrote: Please review. Nashorn script

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

On 2020-04-15 17:56, sundararajan.athijegannat...@oracle.com wrote: Please review. Nashorn script engine modules (jdk.scripting.nashorn, jdk.scripting.nashorn.shell) and jjs tool are removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8241749 JEP: https://openjdk.java.net/jeps/372 CSR:

Re: Nashorn future

On 9/14/19 4:29 AM, eric.vergnaud at wanadoo.fr (Eric Vergnaud) wrote: I was wondering if some options had been considered: There is, of course, the familiar path of transferring it to the Apache Foundation, which would require a license change (from GPL to Apache 2.0). So long as a license

Re: Bug in NashornScriptEngineFactory.getOutputStatement(...) with a possible fix (Re: Nashorn's javax.script.ScriptEngineFactory produces wrong code

Hmm, the formatting of the offered fix was mangled (had used a format which was obviously not o.k.). So here another attempt to present the code in a way that makes it hopefully easy to copy and paste (in a fixed pitch the ".replace(...)" invocations are aligned to the same column): - code

Bug in NashornScriptEngineFactory.getOutputStatement(...) with a possible fix (Re: Nashorn's javax.script.ScriptEngineFactory produces wrong code

Almost two years ago I brought up a bug in NashornScriptEngineFactory.getOutputStatement(String). Further attention obviously stopped with the question where an appropriate place would be to file a bug. The bug is caused by not quoting and escaping the passed string such that a proper

Re: Bug report: can't call static methods on a Java class instance

Hey guys, How I can un-subscribe from this mailing list Thx, On Wed, Oct 30, 2019 at 9:33 AM tibetty wrote: > t works and many thanks for your timely response, Joao! However, > personally > I think it's problematic for Nashorn not to support the static method > invocation from an extended

Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

Hey guys, How I can un-subscribe from this mailing list Thx, On Wed, Oct 30, 2019 at 6:33 AM Hannes Wallnöfer < hannes.wallnoe...@oracle.com> wrote: > Thanks for the report! > > https://bugs.openjdk.java.net/browse/JDK-8233195 > > The provided patch looks reasonable so the chances to get this

Re: Bug report: can't call static methods on a Java class instance

It works and many thanks for your timely response, Joao! However, personally I think it's problematic for Nashorn not to support the static method invocation from an extended class. Any design consideration under the hood? On Wed, Oct 30, 2019 at 8:27 PM João Paulo Varandas wrote: > Call

Re: Bug report: can't call static methods on a Java class instance

Call parseObject directly from the class that contains the static method, not from the extended one. var jso = Java.type('com.alibaba.fastjson.JSON').parseObject(json); https://github.com/alibaba/fastjson/blob/master/src/main/java/com/alibaba/fastjson/JSON.java On Wed, Oct 30, 2019 at 9:22

Re: Bug report: can't call static methods on a Java class instance

I used your method, but it stills failed calling a static method of a 3rd party class (com.alibaba.fastjson.JSONObject): Nashorn (JS) code: var jso = Java.type('com.alibaba.fastjson.JSONObject').parseObject(json); Error Message: Exception in thread "main" javax.script.ScriptException: TypeError:

Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

Obviously, this wasn't intended for the list. To clarify, since Nashorn is being deprecated, we are taking input such as this and recording it as a bug in case someone adopts Nashorn in future. Cheers, -- Jim > On Oct 28, 2019, at 12:36 PM, Jim Laskey wrote: > > You want to take this on?

Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

You want to take this on? File a bug and put the e-mail (change set) in it, then tell the user Nashorn is deprecated. > On Oct 28, 2019, at 12:21 PM, Anton Mitrofanov wrote: > > Hi. > > We have encountered another bug in Nashorn. It can be reproduced by > evaluation of this script with "jjs

Re: JDK 14 RFR of JDK-8231557: Suppress warnings on non-serializable instance fields in jdk.scripting.nashorn module

+1 > On Sep 26, 2019, at 7:45 PM, Joe Darcy wrote: > > Hello, > > Another part of an on-going cleanup of library serialization usage ahead of > augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance > fields of serializable types in the jdk.scripting.nashorn module

Re: RFR: 8230709: Array index out of bounds in ES6 mode

Am 09.09.2019 um 16:50 schrieb Attila Szegedi : > > +1. Ugh. I guess our default lexical context stack is 16 deep. > It is indeed :) Thanks for reviewing. Hannes >> On 2019. Sep 9., at 16:38, Hannes Wallnöfer >> wrote: >> >> Please review this off-by-one array index fix that was recently

Re: RFR: 8230709: Array index out of bounds in ES6 mode

+1. Ugh. I guess our default lexical context stack is 16 deep. > On 2019. Sep 9., at 16:38, Hannes Wallnöfer > wrote: > > Please review this off-by-one array index fix that was recently reported on > this list: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230709 > Webrev:

  1   2   3   4   5   6   7   8   9   10   >