From Rony.Flatscher at wu.ac.at Mon Mar 1 17:13:51 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 1 Mar 2021 18:13:51 +0100 Subject: Ad "Re: Run servlets on Nashorn written in server-side JavaScript" ... Message-ID: <2b854ddc-ce08-71eb-47a5-ddf58b7d8426@wu.ac.at> 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 List To: users at tomcat.apache.org Leo, On 26.02.2021 01:52, leo wrote: > On 25 Feb 2021, at 2:47, Rony G. Flatscher (Apache) wrote: > >> P.S.: Have tested my implementation with Nashorn on Java 8 and it works out of the box! Still, you >> would need to test the implementation thoroughly yourself (stability, performance, resources) and >> would be asked to come back with feedback on each of these qualities. So stay tuned, will publish a >> link to the implementation with a proper Nashorn/JavaScript sample war in this mail thread in a few >> days. > > How cool is this! Let me know when you it ready, please. Thanks a lot! O.K., had a few things I could finalize. Created two war files, "demoJavaScript.war" and "demoRhino.war". The first got tested against Nashorn, the second - you guessed it ;) - against Rhino (7.1.13). They are meant as little proof-of-concepts that should help you to get up and running with them. Please note that the libraries are beta, though appear to be stable. Yet, there may be errors/problems in them or there may be changes coming up. If you have feedback of any sorts, please come forward (stability, usability, performance, resources, etc.). Basically you just need to go to [1] and get the two war-files (copy to $CATALINA_HOME/webapps) plus either javax.ScriptTagLibs.jar (for Tomcat 9 or earlier) or jakarta.ScriptTagLibs.jar (for Tomcat 10) which you should copy to the shared directory at $CATALINA_HOME/lib and restart Tomcat to get them recognized. If you want to test with Rhino you should follow the directions at [1] and copy the mentioned two rhino jar files to the shared library directory as well. In general you should take the time and look over that page at [1], I tried to remain as brief as possible. :) Also please do not forget that the target audience of [1] has been so far the Rexx community and my BA students who learned programming using ooRexx in a semester and with that knowledge should now become able to create little web sites for their own purposes and maybe with some experience for small businesses/organizations given the information at [1] as a starting point. Of course, if there are any questions please do not hesitate and please ask them! HTH, ---rony [1] Homepage of the ScriptTagLibs libraries: ---rony From Thomas.BURRIS at 3ds.com Mon Mar 29 14:07:31 2021 From: Thomas.BURRIS at 3ds.com (BURRIS Thomas) Date: Mon, 29 Mar 2021 14:07:31 +0000 Subject: What do Source, LinkerCallSite, and PropertyMap instances correspond to? Message-ID: <1b7c8b8333da4ee485bb7242e28402aa@3ds.com> Hi all - My software currently uses Nashorn heavily. We've been trying to keep track of our memory usage but recently we've noticed major bloat. We did a memory analysis to see where stuff is and we found that instances of jdk.nashorn.internal.runtime.Source and jdk.nashorn.internal.runtime.linker.LinkerCallSite and jdk.nashorn.internal.runtime.PropertyMap take up half of our JDK's allotted memory. My question is: What do these classes tend to correspond to? For example, is Source a holder for compiled JS? (Probably not, but just an example.) Knowing this would help me understand what we need to look at specifically. Not knowing this means ... scramble and test 100 things to try to find correlation !! Thank you for your time and thoughts! Best Regards, Thomas BURRIS RDF Modeling R&D Software Architecture Director This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Syst?mes does not accept or assume any liability or responsibility for any use of or reliance on this email. Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at 3DS.compliance-privacy at 3ds.com For other languages, go to https://www.3ds.com/terms/email-disclaimer From szegedia at gmail.com Mon Mar 29 17:29:23 2021 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 29 Mar 2021 19:29:23 +0200 Subject: ECMAScript 6 through the ScriptEngineManager Message-ID: <8DC7E596-DC7A-427F-A909-5B45DE5D0DDA@gmail.com> Hi folks, 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 enabled by default. So, the problem I?d like to solve is: using only javax.script.* API, get Nashorn ScriptEngine that runs ES6. Using the Nashorn API you can do: import org.openjdk.nashorn.api.scripting.*; var factory = new NashornScriptEngineFactory(); var engine = factory.getScriptEngine(?--language=es6?) ? But there?s no way to do it through just using javax.script.* APIs. Let?s see some ideas that led nowhere: * specify ES6-specific MIME types: turns out, there?s none. text/javascript, application/javascript, text/ecmascript and application/ecmascript are all generic, non-versioned MIME types. * specify ES6-specific filename extensions: turns out, there are none. ?.js? is generic, non-versioned. I also have some ideas that do have legs. These are non-exclusive: * Add a separate ?NashornScriptEngineFactory6? class that answers to versioned names, e.g. ?Nashorn ES6? allowing people to ask for an ES6 engine by name. That engine would answer to no MIME types or filename extensions. * Add support for system property so people can launch the JVM with e.g. -Dorg.openjdk.nashorn.preferLanguage=es6. This could be used when people need to run existing systems that request a script engine with some name and they can?t change it. In this case, NashornScriptEngineFactory would be creating ES6 engines instead of ES5 engines when the property is set. I also considered allowing a special bindings key, so you could do something like: var manager = new ScriptEngineManager(); manager.put(?org.openjdk.nashorn.options?, new String[] { ?--language=es6? }); var engine = manager.getEngineByName(?javascript?); but FWIW, if you can do this, you might as well be using the Nashorn API from the top of this e-mail, or ask for manager.getEngineByName(?Nashorn ES6?). So in the end, the separate engine name for ES6 + a system property for the cases where users can?t affect the engine name seems sufficient to me. Thoughts? Attila. [0] Of course, it?s a whole other issue that ES6 support in Nashorn is incomplete; that?s not something I?m out to fix right now. It has enough goodies (const, let, arrow functions, etc.) that it?s justifiable that people would want to use what?s there. From Rony.Flatscher at wu.ac.at Wed Mar 31 11:43:01 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 31 Mar 2021 13:43:01 +0200 Subject: ECMAScript 6 through the ScriptEngineManager In-Reply-To: <8DC7E596-DC7A-427F-A909-5B45DE5D0DDA@gmail.com> References: <8DC7E596-DC7A-427F-A909-5B45DE5D0DDA@gmail.com> Message-ID: 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 enabled by default. Probably a stupid question: is there some incompatibility introduced in the ES6-mode of Nashorn compared to 5.1? If not, why not have Nashorn run in ES6 mode by default and maybe add a Bindings entry indicating the execution mode of Nashorn (being ES6 in this case)? Another idea might be to have two different Nashorn script engines packaged where one is contained in a module indicating ES5 and the other ES6 execution mode. Then it is "merely" a matter which module to download for a developer. An application needing Nashorn in ES6 mode can then rely on these features be present if the ES6-module gets used without a need to change anything in the script framework interfaces. Other than that I think the System property approach would be the most straight-forward one ("-Dorg.openjdk.nashorn.preferLanguage=es6") as developers are accustomed to this pattern. In any case, if there are two different execution modes possible it would be helpful to allow finding out at runtime which mode is currently in use (suggesting placing this information into the Bindings). ---rony > So, the problem I?d like to solve is: using only javax.script.* API, get Nashorn ScriptEngine that runs ES6. > > Using the Nashorn API you can do: > > import org.openjdk.nashorn.api.scripting.*; > > var factory = new NashornScriptEngineFactory(); > var engine = factory.getScriptEngine(?--language=es6?) > ? > > But there?s no way to do it through just using javax.script.* APIs. > > Let?s see some ideas that led nowhere: > * specify ES6-specific MIME types: turns out, there?s none. text/javascript, application/javascript, text/ecmascript and application/ecmascript are all generic, non-versioned MIME types. > * specify ES6-specific filename extensions: turns out, there are none. ?.js? is generic, non-versioned. > > I also have some ideas that do have legs. These are non-exclusive: > * Add a separate ?NashornScriptEngineFactory6? class that answers to versioned names, e.g. ?Nashorn ES6? allowing people to ask for an ES6 engine by name. That engine would answer to no MIME types or filename extensions. > * Add support for system property so people can launch the JVM with e.g. -Dorg.openjdk.nashorn.preferLanguage=es6. This could be used when people need to run existing systems that request a script engine with some name and they can?t change it. In this case, NashornScriptEngineFactory would be creating ES6 engines instead of ES5 engines when the property is set. > > I also considered allowing a special bindings key, so you could do something like: > > var manager = new ScriptEngineManager(); > manager.put(?org.openjdk.nashorn.options?, new String[] { ?--language=es6? }); > var engine = manager.getEngineByName(?javascript?); > > but FWIW, if you can do this, you might as well be using the Nashorn API from the top of this e-mail, or ask for manager.getEngineByName(?Nashorn ES6?). So in the end, the separate engine name for ES6 + a system property for the cases where users can?t affect the engine name seems sufficient to me. > > Thoughts? > > Attila. > > [0] Of course, it?s a whole other issue that ES6 support in Nashorn is incomplete; that?s not something I?m out to fix right now. It has enough goodies (const, let, arrow functions, etc.) that it?s justifiable that people would want to use what?s there.