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 Greg, > > that’s a consequence of Java 17 removing the

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 compiles all scripts to JVM bytecode > and runs them as such.

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 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 sure I understand... So the target JVM > flavor for

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: Any news from JDK-8151981 in Java8 ?

Hi Hannes, it can also be Nashorn triggering too much deoptimizations creating a deoptimization storm. Rémi - Mail original - > De: "Hannes Wallnöfer" > À: "João Paulo Varandas" > Cc: nashorn-dev@openjdk.java.net > Envoyé: Mardi

Re: RFR (10): JDK-8181191: getUint32 returning Long

What about checked exceptions ? Rémi On July 23, 2017 1:55:13 PM GMT+02:00, Marcus Lagergren wrote: >This cache thing is my least favourite behavior in the entire JLS. >Crazy that it’s actually a mandated part of the language specification. > >+1 > >/M > >> On 13 Jun

Re: Getting Input From User

In Java, you can use the Console: System.console().readLine("") with the caveat that System.console() [1] can return null if no terminal is attached to the process. Otherwise you can use a Scanner: Scanner scanner = new Scanner(System.in); scanner.nextLine() or a BufferedReader:

Re: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function

- Mail original - > De: "Michael Haupt" > À: "Sundararajan Athijegannathan" > Cc: nashorn-dev@openjdk.java.net > Envoyé: Mercredi 25 Mai 2016 13:49:39 > Objet: Re: RFR 8157819: TypeError when a java.util.Comparator object

Re: time limit for compiled script

Hi Attila, if your JavaScript is single threaded, you can stop the execution of the script as you want (you also need that the exception used to stop the script to be non catchable) or am i wrong ? Rémi - Mail original - > De: "Attila Szegedi" > À: "Tomáš Zíma"

Re: Review request for JDK-8133299: Nashorn Java adapters should not early bind to functions

Hi Attila, no fully related to that issue but i think that the adapter code should be separated from Nashorn and integrated directly into the JDK as a better proxy implementation (compared to java.lang.reflect.Proxy), evey dynamic language runtimes need this kind of proxies. here is my attempt

Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code

Hi Attila, in your patch you're using several different host classes (i beleive one by script) and i don't understand why ? cheers, Rémi On 09/09/2015 03:35 PM, Attila Szegedi wrote: > Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading > Nashorn script code" at >

Re: JsJs

ping ? Rémi On 04/13/2015 09:08 AM, Remi Forax wrote: Hi guys, I've written a simple AOT compiler [1] that takes a javascript file and transform it to a .class file that can run with a very small runtime. It uses the Nashorn Parser API and also Nashorn to bootstrap itself (the AOT

JsJs

Hi guys, I've written a simple AOT compiler [1] that takes a javascript file and transform it to a .class file that can run with a very small runtime. It uses the Nashorn Parser API and also Nashorn to bootstrap itself (the AOT is written in JavaScript). While the runtime is fairly naive,

Re: RFR 8075207: Nashorn parser API returns StatementTree objects in out of order

Hi Sundar, Looks good ! just nitpicking, Java 8 introduces a method sort() on List so instead of Collections.sort(statList, (s1, s2)-(s1.getStart() - s2.getStart())); one can write statList.sort((s1, s2)-Integer.compare(s1.getStart(), s2.getStart())); (Integer.compare() is used avoid the

Re: RFR 8074671: Nashorn Parser API

On 03/09/2015 07:02 AM, A. Sundararajan wrote: Please review Nashorn Parser API. Introduces jdk.nashorn.api.tree package to support parser API for Nashorn. JEP: http://openjdk.java.net/jeps/236 Bug: https://bugs.openjdk.java.net/browse/JDK-8074671 Webrev:

Re: JEPs proposed to target JDK 9 (2015/1/15)

On 01/15/2015 11:31 PM, mark.reinh...@oracle.com wrote: [...] 236: Parser API for Nashorn http://openjdk.java.net/jeps/236 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Thursday,

Re: Forcing elements of List to be converted as java.lang.Long

On 11/27/2014 12:37 AM, Tim Fox wrote: Hi Attila, I understand the generic type info is erased, but my question was whether there is any way I can force Nashorn to convert the elements as Long rather than Integer when doing the conversion, e.g. using some special Nashorn specific syntax,

Re: A certain (type of?) callsite seems to always require relinking

Hi Attila, I've had the very same issue with a runtime of a proprietary language. What I've proposed in the JSR 292 cookbook for this case is to use a dispatch table https://code.google.com/p/jsr292-cookbook/source/browse/trunk/bimorphic-cache/src/jsr292/cookbook/bicache/RT.java

Re: Seeking help back in the land of Rhino

On 12/03/2013 02:34 PM, Tal Liron wrote: That's reasonable. (I guess you're referring to the final death of the permgen when you're talking about memory issues?) So, what are your thoughts on the JVM7 port? Do you think it's entirely non-viable? Pointless? Would result in a very poorly