Re: RFR: 8230766: Changed message in IllegalMonitorStateException

+1 > On 2019. Sep 9., at 16:41, Hannes Wallnöfer > wrote: > > Please review this fix for a test failing because of a changed exception > message in java.lang.Object.wait(): > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230766 > Webrev:

Re: ArrayIndexOutOfBoundsException in LexicalContext.java#inUnprotectedSwitchContext

Hi Anton, Thanks for the report - that’s a really interesting one! I’ll file a bug for it, but given that Nashorn is deprecated and this is part of the incomplete ES6 support I don’t think it will be deemed worthy of a 8u backport. Hannes > Am 09.08.2019 um 11:16 schrieb Anton Mitrofanov :

Re: RFR: 8223451: Make optimistic types disabled by default

+1 > On Jul 9, 2019, at 11:48 AM, Hannes Wallnöfer > wrote: > > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223451 > Webrev: http://cr.openjdk.java.net/~hannesw/8223451/webrev.00/ > > A lot of Nashorn usage we see is with command line scripts from the Node.js > and Web

Re: RFR: 8223451: Make optimistic types disabled by default

Looks good! -Sundar On 09/07/19, 8:18 PM, Hannes Wallnöfer wrote: Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8223451 Webrev: http://cr.openjdk.java.net/~hannesw/8223451/webrev.00/ A lot of Nashorn usage we see is with command line scripts from the Node.js and Web

Re: RFR: Update double-conversion to version 3.1.5

+1. This is really a refreshingly small change :-) Attila. > On 2019. Jul 9., at 15:23, Hannes Wallnöfer > wrote: > > Please review the update of the Java port of the V8 double conversion library > to the most recent release. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227391 >

Re: Nashorn on the module-path

> Have you brought this up on nashorn-dev... No, but cc-ed that list now. > ...as this might require digging into the dynalink linker > and how method handles are used. Do you think it's still worth the effort in regard of Nashorn being deprecated for removal? Perhaps the underlying reason may

Re: Nashorn on the module-path

On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < sundararajan.athijegannat...@oracle.com> wrote: > How can this be reproduced at out end? I compiled a small example project at [1] that describes and demonstrates the issue. Please view the README.md file for details. You may

Re: Nashorn on the module-path

Hi Christian, I cloned and tried your example project. When I run the project, I get one successful and one aborted tests in both cases: Module path output: └─ JUnit Jupiter ✔ └─ CheckTests ✔ ├─ test() ✔ └─ emitStringRepresentationOfTestModule() ■ Assumption failed: module

Re: Nashorn on the module-path

Thanks. I'll check it out. -Sundar On 27/05/19, 3:10 PM, Christian Stein wrote: On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan > wrote: How can this be reproduced at out end? I compiled a small example project at [1] that

Re: Nashorn on the module-path

How can this be reproduced at out end? Thanks -Sundar On 26/05/19, 2:47 PM, Christian Stein wrote: Have you brought this up on nashorn-dev... No, but cc-ed that list now. ...as this might require digging into the dynalink linker and how method handles are used. Do you think it's still

Re: Nashorn on the module-path

Christian, I can’t see the rest of the thread so I don’t have a context. Sent from my iPhone On May 26, 2019, at 6:17 AM, Christian Stein wrote: >> Have you brought this up on nashorn-dev... > > No, but cc-ed that list now. > >> ...as this might require digging into the dynalink linker >>

Re: (Adopt)OpenJDK 8 and Nashorn

Nashorn is part of the JDK, so should be present. Note however, Nashorn is deprecated until a replacement finds its way in. Cheers, -- Jim > On May 23, 2019, at 9:48 AM, Houtman, Roland > wrote: > > Dear Devs, > > Today I learned by surprise that the AdoptOpenJDK 8 contains the Nashorn >

Re: RFR: 8222528: Fix javadoc headers in Nashorn sources

Looks good -Sundar On 16/04/19, 6:26 PM, Hannes Wallnöfer wrote: Please review: Issue: https://bugs.openjdk.java.net/browse/JDK-8222528 Webrev: http://cr.openjdk.java.net/~hannesw/8222528/webrev.00/ Javadoc now requires that headings be consistent with accessibility guidelines. Since h1 is

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

Thanks for fixing! Interactive mode manual testing is fine - tab completion, multi-line edit, built-in/external editor, history object all seem fine. +1 Thanks, -Sundar On 10/12/18, 6:33 PM, Jan Lahoda wrote: Thanks for testing Sundar! I've tried to update the jjs completion handling to

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

Thanks for testing Sundar! I've tried to update the jjs completion handling to fix this problem here: http://cr.openjdk.java.net/~jlahoda/8214491/webrev.05/ Delta from previous patch: http://cr.openjdk.java.net/~jlahoda/8214491/webrev.delta.04.05/ What do you think? Thanks, Jan On

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

Hi Jan, Tests are fine. Because there are not many UI automated tests for jjs, I tried to manually test few features. Tab-completion seems to be messed up. Only top-level completion seems to work. Property/method completion and inside multi-line method etc. don't seem to work. Thanks,

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

Hi Sundar, Thanks for finding the problem! I was running tier1-3 tests, but seems these are not there. Seems the problem is how JLine(3) handles "dumb" terminals, it probably does not affect interactive use. So, adjusting the expected output should hopefully be OK. Updated patch:

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

I built jdk and ran nashorn tests with this patch. Two tests fail with this patch - but those tests pass without this patch: [testng] Test test/nashorn/script/nosecurity/JDK-8055034.js failed at line 1 - [testng] expected: 'jjs> var x = Object.create(null);' [testng] found:

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

Thumbs up! -Robert On 12/9/18 2:45 PM, Jan Lahoda wrote: On 9.12.2018 16:40, Robert Field wrote: Ok. Go ahead and incorporate the text. I'll make a separate bug to sync the representation of keys in the other help entries. An updated patch (with your text):

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

On 9.12.2018 16:40, Robert Field wrote: Ok. Go ahead and incorporate the text. I'll make a separate bug to sync the representation of keys in the other help entries. An updated patch (with your text): http://cr.openjdk.java.net/~jlahoda/8214491/webrev.03/ Delta from previous patch:

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

Ok. Go ahead and incorporate the text. I'll make a separate bug to sync the representation of keys in the other help entries. Robert On December 9, 2018 6:36:26 AM Jan Lahoda wrote: Hi Robert, On 9.12.2018 02:40, Robert Field wrote: OK, here is my thinking on a /help keys entry. Note:

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

Hi Robert, On 9.12.2018 02:40, Robert Field wrote: OK, here is my thinking on a /help keys entry. Note: I'm using the I think this looks great! representation for keys used by the User's Guide -- which I assume is the official tech pubs style -- seems we should be consistent; If we are

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

OK, here is my thinking on a /help keys entry.  Note: I'm using the representation for keys used by the User's Guide -- which I assume is the official tech pubs style -- seems we should be consistent; If we are however, the other /help entries should be brought into compliance (they seem to be

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

On 12/8/18 11:47 AM, Jan Lahoda wrote: On 8.12.2018 20:39, Robert Field wrote: Thanks for updating. Good to have /help for line editing keys, however:    (1) The supported keys should be listed without requiring that the user knows or looks-up readline. More so, since only some readline keys

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

On 8.12.2018 20:39, Robert Field wrote: Thanks for updating. Good to have /help for line editing keys, however: (1) The supported keys should be listed without requiring that the user knows or looks-up readline. More so, since only some readline keys are supposed. (2) "/edit" is a

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

Hi, I've updated the patch to reflect the comments so far, the current version is here: http://cr.openjdk.java.net/~jlahoda/8214491/webrev.01/ Delta since the previous version is here for convenience: http://cr.openjdk.java.net/~jlahoda/8214491/webrev.delta.00.01/ In this version, while

Re: JShell: Request for ideas: Editing multiline snippets, adding lines

On 6.12.2018 06:08, Michel Trudeau wrote: What about Ctrl-Enter ? Actually, Alt-Enter turnes out to work on Linux (KDE Konsole) as a shortcut to add a new line. The main issue here is that we can only use shortcuts for which the terminal will produce an escape sequence, and IIRC on Mac this

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

CC'ing nashorn-dev. -Sundar On 05/12/18, 10:48 PM, Jan Lahoda wrote: Hi Robert, On 4.12.2018 23:59, Robert Field wrote: I saw no issues with JShell tool and test portions of the webrev. I did not review the nashorn changes. Thanks for looking at this! Testing it: editing multi-line

Re: RFR: 8214795: Add safety check to dynalink inner class lookup

+1 > On 2018. Dec 5., at 15:33, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214795 > Webrev: http://cr.openjdk.java.net/~hannesw/8214795/webrev.00/ > > This is to make sure we use the right inner classes regardless of the order > of

Re: RFR: 8214795: Add safety check to dynalink inner class lookup

This code is ultimately invoked from BeanLinker constructor, so always on a single thread; there’s no race here. putIfAbsent was used here previously solely for its effect of not replacing existing mappings, not because of its atomicity. Attila. > On 2018. Dec 5., at 15:45, Jim Laskey wrote:

Re: RFR: 8214795: Add safety check to dynalink inner class lookup

Wouldn’t you still use innerClasses.putIfAbsent in case there is a race? > On Dec 5, 2018, at 10:33 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214795 > Webrev: http://cr.openjdk.java.net/~hannesw/8214795/webrev.00/ > > This is to make

Re: RFR: 8214795: Add safety check to dynalink inner class lookup

Looks good. -Sundar On 05/12/18, 8:03 PM, Hannes Wallnöfer wrote: Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8214795 Webrev: http://cr.openjdk.java.net/~hannesw/8214795/webrev.00/ This is to make sure we use the right inner classes regardless of the order of classes

Re: RFR: 8214795: Add safety check to dynalink inner class lookup

Looks good -Sundar On 05/12/18, 8:03 PM, Hannes Wallnöfer wrote: Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8214795 Webrev: http://cr.openjdk.java.net/~hannesw/8214795/webrev.00/ This is to make sure we use the right inner classes regardless of the order of classes

Re: RFR: 8210943: Hiding of inner classes not resolved properly

Huh… so even within the single array returned from a single call to Classes.getClasses() we can have two classes of the same short name? I foolishly presumed this wouldn’t be the case. I guess in this case the full solution would indeed to provide an ordering on the classes, first on the name,

Re: RFR: 8210943: Hiding of inner classes not resolved properly

Attila, the subclass-to-superclass traversal is actually not done in dynalink but directly in java.lang.Class.getClasses(). So Sundar has a point in that my code relies on implementation rather than specified behaviour of Class.getClasses(). Now I do think it is highly unlikely that the order

Re: RFR: 8210943: Hiding of inner classes not resolved properly

The relevant Dynalink algorithm processes the class before moving on to superclass, so Hannes fix is correct in that we won’t stomp over a subclass’ inner class (inserted into the map earlier) with the superclass’ inner class (encountered later by the algorithm). So yeah, getClasses() doesn’t

Re: RFR: 8210943: Hiding of inner classes not resolved properly

That should have been "do I miss something here?" :) -Sundar On 01/12/18, 11:43 AM, Sundararajan Athijegannathan wrote: Class.getClasses() javadoc does not mention anything about order of classes returned. https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getClasses() Do we

Re: RFR: 8210943: Hiding of inner classes not resolved properly

Class.getClasses() javadoc does not mention anything about order of classes returned. https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getClasses() Do we need a check using Class.getDeclaringClass() or do I something here? Thanks, -Sundar On 30/11/18, 4:44 PM, Attila Szegedi

Re: RFR: 8214525: Bit rot in Nashorn Ant script

Am 30.11.2018 um 14:04 schrieb Jim Laskey : > > +1 > > too bad you have to hardcode the version 12 docs aren’t in their final place, and who knows if they’ll change the URL scheme again :) Thanks! Hannes >> On Nov 30, 2018, at 6:58 AM, Hannes Wallnöfer >> wrote: >> >> Please review: >>

Re: RFR: JDK-8214491: Upgrade to JLine 3.9.0

On 30.11.2018 04:10, Robert Field wrote: Nit: Why are the hyphens in the comments of AnsiWriter.java changed to unicode? These were unicode hyphens (–), not ordinary hyphens (-). I could have replace them with ordinary hyphens, but opted to keeping the semantics the same by using a unicode

Re: RFR: 8214525: Bit rot in Nashorn Ant script

+1 too bad you have to hardcode the version > On Nov 30, 2018, at 6:58 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214525 > Webrev: http://cr.openjdk.java.net/~hannesw/8214525/webrev.00/ > > This enables gzip encoding for the YUI

Re: RFR: 8210943: Hiding of inner classes not resolved properly

+1 > On Nov 29, 2018, at 1:01 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210943 > Webrev: http://cr.openjdk.java.net/~hannesw/8210943/webrev.00/ > > AccessibleMembersLookup#lookupAccessibleMembers adds all nested classes > returned

Re: RFR: 8214525: Bit rot in Nashorn Ant script

+1 > On 2018. Nov 30., at 11:58, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214525 > Webrev: http://cr.openjdk.java.net/~hannesw/8214525/webrev.00/ > > This enables gzip encoding for the YUI download and switches javadoc tasks to >

Re: RFR: 8210943: Hiding of inner classes not resolved properly

+1. Thanks for fixing this. > On 2018. Nov 29., at 18:01, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210943 > Webrev: http://cr.openjdk.java.net/~hannesw/8210943/webrev.00/ > > AccessibleMembersLookup#lookupAccessibleMembers adds all

Re: casting typed array to java byte[] is it possible?

Hi, Yes, I reproduced the issue with jdk8 (haven't tried graal.js though). Please file bug(s). -Sundar On 12/10/18, 7:29 PM, Paulo Lopes wrote: Interesting enough, with Java>=9 the length is reported correctly, so in the case of: var bb = java.nio.ByteBuffer.allocateDirect(12) var ab = new

Re: casting typed array to java byte[] is it possible?

to start with. > > > > > > Paulo Lopes > > Principal Software Engineer > > > > > >Original Message > > From: hannes.wallnoe...@oracle.com > > Sent: October 12, 2018 10:10 AM > > To: pmart...@redhat.com > > Cc: nashorn-dev@openjdk.java.

Re: casting typed array to java byte[] is it possible?

Sent: October 12, 2018 10:10 AM To: pmart...@redhat.com Cc: nashorn-dev@openjdk.java.net Subject: Re: casting typed array to java byte[] is it possible? Hi Paulo, Java.to() would be the way to go, but as you found out it does not support typed arrays. What works is to convert the typed array to an ordi

Re: casting typed array to java byte[] is it possible?

Subject: Re: casting typed array to java byte[] is it possible? Hi Paulo, Java.to() would be the way to go, but as you found out it does not support typed arrays. What works is to convert the typed array to an ordinary JS array and convert to byte[] from there:   Java.to(Array.prototype.slice.call

Re: casting typed array to java byte[] is it possible?

Hi Paulo, Java.to() would be the way to go, but as you found out it does not support typed arrays. What works is to convert the typed array to an ordinary JS array and convert to byte[] from there: Java.to(Array.prototype.slice.call(arr), 'byte[]‘); That’s obviously not very elegant nor

Re: Extending a Java class

protected methods of super class are made public in the generated script subclass. Java.super should have worked. If you can submit a simpler test case, it may be possible to see what's happening.. Thanks -Sundar On 02/10/18, 3:52 PM, Axel Dörfler wrote: Hi Sundar, Am 01/10/2018 um 05:00

Re: Extending a Java class

Hi Sundar, Am 01/10/2018 um 05:00 schrieb Sundararajan Athijegannathan: In your example, it seems you're trying to add a new method to the subtype created in script. That is not supported. You can override existing methods of superclass  - but not add a new method to the Java type. Bummer!

Re: Extending a Java class

Hi, In your example, it seems you're trying to add a new method to the subtype created in script. That is not supported. You can override existing methods of superclass - but not add a new method to the Java type. Note that all super methods (including protected ones) are available via

Re: Extending a Java class

Am 28/09/2018 um 11:34 schrieb Sundararajan Athijegannathan: It is hard to say what went wrong without looking at your full sample/test. Openjdk wiki page explains Java.extend function is here: http://hg.openjdk.java.net/jdk/jdk/file/7bd8d6b011c9/src/sample/nashorn/resourcetrysuggester.js

Re: Supporting TypeScript natively on Nashorn

The Nashorn team has no plans but you might check the GraalVM https://www.graalvm.org project to see what they might have in this area. Cheers, — Jim > On Aug 9, 2018, at 7:01 AM, Erko Knoll wrote: > > Hi, > > Great job with Nashorn, I really love it. However, based on the blog post > of >

Re: Nashorn script security permissions not working for .js

Make sure that test.js is loaded via URLReader or load primitive. i.e., nashorn engine should load the script pointed via URL - if you pass FileReader or loaded content to engine.eval, Nashorn will treat it as sandboxed - i.e., script loaded from untrusted source. If it still does not work for

Re: Nashorn deprecation

2018/7/3 16:19:48 -0700, Charles Oliver Nutter : > I was going to start another thread, but I thought it made sense to > reply here. > > I see the justification for deprecating Nashorn is given as "it's too > hard to maintain". I'd like to understand if that's the real > justification or if the

Re: Nashorn deprecation

>> >> >> Cheers, >> Paulo >> >> Original Message >> From: tonyzak...@gmail.com >> Sent: June 15, 2018 22:29 >> To: jlu...@riotgames.com >> Cc: yikesar...@gmail.com; nashorn-dev@openjdk.java.net >> Subject: Re: Nashorn deprecation >>

Re: Nashorn deprecation

s4x/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: tonyzak...@gmail.com > Sent: June 15, 2018 22:29 > To: jlu...@riotgames.com > Cc: yikesar...@gmail.com;

Re: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs

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

Re: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs

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.

Re: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs

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

Re: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs

+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

Re: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs

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

Re: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs

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

Re: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError()

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

Re: Nashorn deprecation

experimenting to smoothly allow us to run on JDK8,9,10,11 and Graal. Cheers, Paulo   Original Message   From: tonyzak...@gmail.com Sent: June 15, 2018 22:29 To: jlu...@riotgames.com Cc: yikesar...@gmail.com; nashorn-dev@openjdk.java.net Subject: Re: Nashorn deprecation Also replied to the thread

Re: Nashorn deprecation

onsideration. 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.j

Re: RFR: 8203814: javac --release=8 \"cannot find symbol\" for NashornException.getEcmaError()

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

Re: Nashorn deprecation

jdk.java.net/pipermail/jdk-dev/2018-June/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

Re: Nashorn deprecation

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/

Re: Nashorn deprecation

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

Re: Nashorn deprecation

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

Re: RFR: 8204290: Add check to limit number of capture groups

+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

Re: RFR: 8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails

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

Re: RFR: 8204290: Add check to limit number of capture groups

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

Re: RFR: 8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails

Looks good. PS. Reply to http://mail.openjdk.java.net/pipermail/nashorn-dev/2018-June/007393.html -Sundar

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

On 30/05/2018 16:06, Jan Lahoda wrote: Hi, An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.01/complete/ A webrev showing changes from the previous revision is here: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.01/delta/ The changes are: -updated

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

oves the JDK-specific changes and restores the >>>> vanilla 2.12.1 content: >>>> http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/undo-jdk-extras/ >>>> -a patch that replaces the 2.12.1 content with 2.14.6: >>>> http://cr.openjdk.java.net/~j

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

/webrev.00/undo-jdk-extras/ -a patch that replaces the 2.12.1 content with 2.14.6: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/upgrade-jline/ -a patch that re-applies the JDK-specific changes (like including adjusting packages, and removal/commenting out of usage of features that would

Re: Nashorn StackOverflowError

This is because the parser is recursively processing the if-else branches. This is one huge if statement. It's basically equivalent to if (true) { print(x); } else { if (true) { print(x); } else { if (true) { print(x); } else { … } } so the parser code

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

the vanilla 2.12.1 content: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/undo-jdk-extras/ -a patch that replaces the 2.12.1 content with 2.14.6: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/upgrade-jline/ -a patch that re-applies the JDK-specific changes (like including adjusting

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

an antipatch that removes the JDK-specific changes and restores the vanilla > 2.12.1 content: > http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/undo-jdk-extras/ > -a patch that replaces the 2.12.1 content with 2.14.6: > http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/upgr

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

that re-applies the JDK-specific changes (like including adjusting packages, and removal/commenting out of usage of features that would require undesirable dependencies, and any changes that had to be done to other modules): http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/adding-jdk-extras/ JBS

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

changes and restores the vanilla 2.12.1 content: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/undo-jdk-extras/ -a patch that replaces the 2.12.1 content with 2.14.6: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/upgrade-jline/ -a patch that re-applies the JDK-specific changes (like

Re: RFR: 8200716: Object propertyIsEnumerable buggy behavior on short integer-string key

+1 -Sundar On 07/05/18, 10:10 PM, Hannes Wallnöfer wrote: Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8200716 Webrev: http://cr.openjdk.java.net/~hannesw/8200716/webrev/ Thanks, Hannes

Re: RFR: 8200716: Object propertyIsEnumerable buggy behavior on short integer-string key

+1 > On May 7, 2018, at 1:40 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200716 > Webrev: http://cr.openjdk.java.net/~hannesw/8200716/webrev/ > > Thanks, > Hannes

Re: Longs aren't numbers in Java 8u162

On 2018-05-02 15:24, Hannes Wallnöfer wrote: Hi Ryan, Yes, this change was intentional. We were aware at the time that it would cause some problems, but on the other hand treating longs as > numbers clashed with the ECMA spec and caused silent loss of precision. Somewhat related issue:

Re: Longs aren't numbers in Java 8u162

Hi Ryan, Yes, this change was intentional. We were aware at the time that it would cause some problems, but on the other hand treating longs as numbers clashed with the ECMA spec and caused silent loss of precision. In most cases there should be simple workarounds, like using the unary +

Re: Longs aren't numbers in Java 8u162

This seems like it could be a side effect of a bug I reported where using a number as the key in an object in Nashorn made an array of the at least the size of the number and then inserted in the index of the number specified. The bug was fixed around that version that you mention. On Mon, Apr

Re: RFR: 8198816: AbstractScriptEngine.getScriptContext creation of SimpleScriptContext is inefficient

+1 -Sundar On 23/04/18, 8:34 AM, Hannes Wallnöfer wrote: Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8198816 Webrev: http://cr.openjdk.java.net/~hannesw/8198816/webrev/ Thanks, Hannes

Re: RFR: 8198816: AbstractScriptEngine.getScriptContext creation of SimpleScriptContext is inefficient

+1 > On Apr 23, 2018, at 12:34 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198816 > Webrev: http://cr.openjdk.java.net/~hannesw/8198816/webrev/ > > Thanks, > Hannes

Re: RFR: 8201466: Nashorn: defineProperty setters/getters on prototype object ignored with numeric property names

+1 > On Apr 23, 2018, at 10:49 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201466 > Webrev: http://cr.openjdk.java.net/~hannesw/8201466/webrev/ > > Thanks, > Hannes

Re: RFR: 8201466: Nashorn: defineProperty setters/getters on prototype object ignored with numeric property names

Looks good. -Sundar On 23/04/18, 6:49 AM, Hannes Wallnöfer wrote: Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8201466 Webrev: http://cr.openjdk.java.net/~hannesw/8201466/webrev/ Thanks, Hannes

Re: JSObject without Java-based conversion to JSON

Where is it filed? Curious. We use Jackson and annotations to avoid circular references. On Sat, Apr 14, 2018 at 5:52 AM, Victor Polischuk wrote: > Hi Sundar, > > Thank you for the answer. I have filed a RFE #9053373, with the minimal > intrusion in the API which already

Re: JSObject without Java-based conversion to JSON

Hi Sundar, Thank you for the answer. I have filed a RFE #9053373, with the minimal intrusion in the API which already should allow people to work with Nashorn more comfortably. /Victor --- Original message --- From: "Sundararajan Athijegannathan"

Re: JSObject without Java-based conversion to JSON

Please note that a general Java object graph may involve circular references. Without modifying JSON somehow, it is not possible to handle such cases. That said, please do file a rfe with your ideas and we can discuss. -Sundar On 11/04/18, 10:18 AM, Victor Polischuk wrote: Dear all, I

Re: Is there a way to reference the engine from a linker?

1 PM > To: plo...@redhat.com > Cc: nashorn-dev@openjdk.java.net > Subject: Re: Is there a way to reference the engine from a linker? > > Sorry for an awfully late response, but hope it might still help: > Java.asJSONCompatible delegates on the Java side to > jdk.nashorn.api.scriptin

Re: Is there a way to reference the engine from a linker?

To: plo...@redhat.com Cc: nashorn-dev@openjdk.java.net Subject: Re: Is there a way to reference the engine from a linker? Sorry for an awfully late response, but hope it might still help: Java.asJSONCompatible delegates on the Java side to jdk.nashorn.api.scripting.wrapAsJSONCompatible. It’s part

Re: Is there a way to reference the engine from a linker?

Sorry for an awfully late response, but hope it might still help: Java.asJSONCompatible delegates on the Java side to jdk.nashorn.api.scripting.wrapAsJSONCompatible. It’s part of Nashorn’s supported public API, so it should be fine for you to call it. I’m actually wondering how useful is that

Re: Cast/boxing/unboxing of numbers Java 9

Disabling optimistic-types will make it behave like JDK 8 and shouldn’t have any side effects. In fact, you can make JDK 8 behave like JDK 9 by passing -ot=true. Hannes > Am 27.03.2018 um 19:56 schrieb Paulo Oliveira : > > Hello, > > Firstly, thanks for the

<    1   2   3   4   5   6   7   8   9   10   >