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

If you create one class in an empty package (like with sun.invoke.empty.Empty) and use it as host class, it should be ok, no ? Rémi - Mail original - > De: "Attila Szegedi" > À: "Remi Forax" > Cc: nashorn-dev@openjdk.java.net > Envoyé: Mercredi 9 Sep

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

.fr wrote: >> >> If you create one class in an empty package (like with >> sun.invoke.empty.Empty) and use it as host class, it should be ok, no ? >> >> Rémi >> >> - Mail original - >>> De: "Attila Szegedi" >>> À:

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

- Mail original - > De: "Attila Szegedi" > À: "Remi Forax" > Cc: "Nashorn-dev" > Envoyé: Samedi 2 Janvier 2016 16:54:05 > Objet: Re: Review request for JDK-8133299: Nashorn Java adapters should not > early bind to functions > &

Re: Any news from JDK-8151981 in Java8 ?

It's just that i've seen several times setCallSiteTargetNormal in the profile and each time it was my fault, creating a GWT with the two branches swaped, invalidating SwitchPoints too vigorously, etc. Rémi - Mail original - > De: "Hannes Wallnöfer" > À:

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 the last post. > > * I’m talking with folks

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 < [ mailto:fo..

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 perfor

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 https://code.go

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, e

ScriptObjectMirror and setMember

et the following output: 3 666 <- 2 3 It seems that setMember on an ScriptObjectMirror change the value of the mirror itself but not the value of the mirrored object. It doesn't seem to be the right semantics to me. Rémi [1] https://github.com/forax/proxy2/blob/master/demo8/funlist.j

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

g with the AST, now that we have lambdas, a HashMap AST node -> function to execute, is enough. see for an example of usage https://github.com/forax/vmboiler/blob/master/script/src/com/github/forax/vmboiler/sample/script/TypeInferer.java#L46 and the definition of a Visitor https://github.com/f

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

du/~palsberg/paper/compsac98.pdf On Friday 16 January 2015 04:22 AM, Remi Forax wrote: 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

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: http://cr.openjdk.java.net/~sundar/8

Bug in Nashorn Parser API (order of statements)

Hi guys, Hi Sundar, it seems that the parser groups all the function declarations before all the statements instead of following the order of the file. [forax@localhost jsjs]$ cat bug_parser.js var File = Java.type("java.io.File"); var Parser = Java.type("jdk.nashorn.api.tre

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 overf

JsJs

way: java -Xbootclasspath/p:lib/nashorn.jar -cp .:classes:lib/asm-debug-all-5.0.3.jar jsjs jsjs.js cheers, Rémi [1] https://github.com/forax/jsjs

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 A

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: Review request for JDK-8133299: Nashorn Java adapters should not early bind to functions

to do something like this [1] Happy new year, Rémi [1] https://github.com/forax/proxy2 - Mail original - > De: "Attila Szegedi" > À: "Nashorn-dev" > Envoyé: Samedi 2 Janvier 2016 16:01:56 > Objet: Review request for JDK-8133299: Nashorn Java adapters s

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" > Cc: nashorn-dev@openj

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 is > invoked as a function > Hi Sundar, Hi Mickael, > Hi

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: Buffered

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 2017, at 18:28, Hannes Wal

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 12 Décembre 2017 14:11:49 > Objet: Re: Any news from JDK-

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 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 compatibi

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: 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. There’

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 Unsafe.defineAnonymousCla

Re: Please review JDK-8010701 - Final part of immutable IR

On 04/18/2013 04:18 PM, Marcus Lagergren wrote: http://cr.openjdk.java.net/~lagergren/8010701/webrev/ It is with great satisfaction that I can announce that Attila and I are done with the completely immutable IR. We have as a proof of concept also removed Node.CopyState altogether. There can n