From jluzon at riotgames.com Mon Apr 10 22:21:29 2017 From: jluzon at riotgames.com (Jesus Luzon) Date: Mon, 10 Apr 2017 15:21:29 -0700 Subject: Can't get Multithreaded Nashorn uses to Scale In-Reply-To: <927BE131-BC1E-42F4-8165-B169BD96A0BF@oracle.com> References: <31833CD9-8263-478E-9400-87D5D561C29A@oracle.com> <927BE131-BC1E-42F4-8165-B169BD96A0BF@oracle.com> Message-ID: I looked in the 8u changelog and did not see anything that makes it seem like this was added, so I'm bumping this to see if someone knows the status of this and if there's any place I can just check if this has been released in a Java 8 update. On Mon, Jan 9, 2017 at 2:57 PM, Hannes Walln?fer < hannes.wallnoefer at oracle.com> wrote: > The fix is in JDK 9 now. I will propose this to be backported this to 8u, > which means it should appear in some 8u release soon, but I can?t make any > promise about a specific release or date. > > Hannes > > > > Am 09.01.2017 um 23:44 schrieb Jesus Luzon : > > > > Hey folks, > > > > Looked at the ticket and noticed it has been marked as fixed. woot! > Thank you so much! > > > > My team has been asking me if I can find out the date this fix will get > released. I noticed the version on there (version 9) states it has no > release date yet. Is there any tentative date you all have for the net > release this would be included in? Even a ballpark figure would be awesome. > > > > Thanks. > > > > On Fri, Dec 9, 2016 at 2:49 AM, Jesus Luzon > wrote: > > Wow I totally missed the var. Thanks for that! I actually had changed > our code to use ThreadLocal ScriptObjectMirrors created from the > CompiledScript with the following code: > > > > ScriptObjectMirror mirror = mirrorThreadLocal.get(); > > if (mirror == null) { > > Bindings bindings = compiledScript.getEngine().createBindings(); > > compiledScript.eval(bindings); > > mirror = (ScriptObjectMirror) bindings.get("transform"); > > mirrorThreadLocal.set(mirror); > > } > > return (String) mirror.call(null, something); > > > > Given that we will always run standalone functions to filter data, is > there one we should be using over the other? > > > > Lastly thanks for filing the bug. I'll keep track of it so I can make > sure to upgrade when a fix comes out. > > > > On Fri, Dec 9, 2016 at 2:37 AM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > > Jesus, > > > > I looked at this issue more in depth and there are two problems here, > one on your side and one on ours: > > > > The problem with your code is that you left out the ?var? declaration of > the ?response? variable in the third line of your function. This means that > ?response? is allocated as a global variable outside the scope of the > function. When you run this in parallel with multiple threads you actually > access the same object from multiple threads, meaning your output will be > corrupt. > > > > Because of things like this, it is actually a good idea to run > JavaScript in strict mode (e.g. by using ?use strict? directive in your > JavaScript code, or by creating the engine with -strict option). Another > solution would be to use multiple engines or bindings, which should not > have a big performance impact once the other problem is fixed. > > > > Which leads us to the problem on our side, which is performance of > sparse arrays. As you have noticed, using something that is not a valid > array index greatly improves performance, and that is because some array > element assignment are implemented very inefficiently in Nashorn. I?ve > filed a bug for this: > > > > https://bugs.openjdk.java.net/browse/JDK-8170977 > > > > Once this bug is fixed, using numeric keys should be roughly as fast as > using non-numeric ones. > > > > Hannes > > > > > > > Am 09.12.2016 um 04:47 schrieb Jesus Luzon : > > > > > > I came up with a workaround which is getting us through this but it > definitely seems like this is a bug. The gist is I append an arbitrary > string (we made it complex on our end to make it unlikely something else > has this string inside) to the key and then remove all instances of said > string on the JSON String resulting from calling stringify. We are leaving > this for overnight testing but it showed promising results immediately. > > > > > > String script = "function transform(input) {" + > > > "var result = JSON.parse(input);" + > > > "response = {};\n" + > > > "for (var i = 0; i < result.length; i++) {\n" + > > > " var summoner = {};\n" + > > > " summoner.id = result[i].id;\n" + > > > " summoner.name = result[i].name;\n" + > > > " summoner.profileIconId = > result[i].profileIconId;\n" + > > > " summoner.revisionDate = > result[i].revisionDate;\n" + > > > " summoner.summonerLevel = result[i].level;\n" + > > > " response[\"someArbitraryString\" + summoner.id] > = summoner;\n" + > > > "}\n" + > > > "var stringy = JSON.stringify(response);" + > > > "result = stringy.replace(/someArbitraryString/g, > \"\");" + > > > "return result;" + > > > "};"; > > > > > > On Thu, Dec 8, 2016 at 4:54 PM, Jesus Luzon > wrote: > > > It doesn't seem like changing to a string fixed it. We dug deeper and > found a very interesting issue though. After running the invocable a few > thousand times, when we put a breakpoint in ArrayData.computerIteratorKeys() > and we found that it would stop at an execution from SparseArrayData with > an underlying array of size 923392, stored length of 461672 (this is one of > our IDs, the largest 6 digit one). Because of this we tried a run changing > all the IDs in the array we pass in to number from 1-38 and this thing went > blazing fast. When putting a break point in the same place, this array in > SpareArrayData was now of size 39. We then changed an id in the array we > take in to be 1337 and the size of the array in the SparseArrayData was > 1338. > > > > > > I don't understand why or how to prevent but it's using this ID as an > index for SpareArrayData underlying array. If someone can help me find a > workaround for this I would be extremely grateful. > > > > > > On Thu, Dec 8, 2016 at 3:52 AM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > > > Yes, this is very likely to be the cause of the problem. However, I do > think we should be able to handle sparse array data better, so it?s quite > possible that you exposed some weak spot in our implementation. I?ll have a > look into what?s going on. > > > > > > Hannes > > > > > > > > > > Am 08.12.2016 um 00:40 schrieb Jesus Luzon : > > > > > > > > Looks like the memory leak is due to the way we wrote our code and > how javascript works. I was expecting the line response[summoner.id] = > summoner; to build a map but it turns out that if you use a number as the > "key", javscript automatically fills the indexes in the middle with null > (Undefined type?). When these IDs are very large, it is creating huge > arrays that take longer to garbage collect than the code executing. I am > about to start testing this on our end to make sure we see the improvements > we expect. > > > > > > > > Does this idea seem like it is reasonably possible? > > > > > > > > On Wed, Dec 7, 2016 at 11:23 AM, Jesus Luzon > wrote: > > > > Yes, it's an array of objects which I'll paste. And yes, I'm just > calling invokeFunction from many many different threads. I'm also going to > go back and take a look at all the heap dumps we have to re-confirm what I > mentioned. > > > > > > > > "[\n" + > > > > " {\n" + > > > > " \"id\": 6011511,\n" + > > > > " \"accountId\": 203192481,\n" + > > > > " \"name\": \"Adam Pro Qarda?\",\n" + > > > > " \"profileIconId\": 25,\n" + > > > > " \"level\": 5,\n" + > > > > " \"expPoints\": 83,\n" + > > > > " \"infPoints\": 1475,\n" + > > > > " \"revisionDate\": 1406631727000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 2810674,\n" + > > > > " \"accountId\": 200706913,\n" + > > > > " \"name\": \"ABZ Devrim\",\n" + > > > > " \"profileIconId\": 663,\n" + > > > > " \"level\": 13,\n" + > > > > " \"expPoints\": 982,\n" + > > > > " \"infPoints\": 10472,\n" + > > > > " \"revisionDate\": 1450791227000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 5411195,\n" + > > > > " \"accountId\": 202647689,\n" + > > > > " \"name\": \"Ace HypcronN\",\n" + > > > > " \"profileIconId\": 911,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 73,\n" + > > > > " \"infPoints\": 182445,\n" + > > > > " \"revisionDate\": 1480781650000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 1363020,\n" + > > > > " \"accountId\": 1357837,\n" + > > > > " \"name\": \"AdanaLee\",\n" + > > > > " \"profileIconId\": 502,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 125,\n" + > > > > " \"infPoints\": 719299,\n" + > > > > " \"revisionDate\": 1480530778000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 8261198,\n" + > > > > " \"accountId\": 205027096,\n" + > > > > " \"name\": \"Achilehuz\",\n" + > > > > " \"profileIconId\": 1381,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 10,\n" + > > > > " \"infPoints\": 158603,\n" + > > > > " \"revisionDate\": 1480770307000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 12685857,\n" + > > > > " \"accountId\": 207591166,\n" + > > > > " \"name\": \"ac?mas?zpicc\",\n" + > > > > " \"profileIconId\": 9,\n" + > > > > " \"level\": 21,\n" + > > > > " \"expPoints\": 840,\n" + > > > > " \"infPoints\": 16659,\n" + > > > > " \"revisionDate\": 1480515325000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 10860127,\n" + > > > > " \"accountId\": 206507727,\n" + > > > > " \"name\": \"AAngelFlyy\",\n" + > > > > " \"profileIconId\": 1395,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 10,\n" + > > > > " \"infPoints\": 73111,\n" + > > > > " \"revisionDate\": 1480787870000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 3292376,\n" + > > > > " \"accountId\": 201048714,\n" + > > > > " \"name\": \"ACAB1907\",\n" + > > > > " \"profileIconId\": 20,\n" + > > > > " \"level\": 6,\n" + > > > > " \"expPoints\": 305,\n" + > > > > " \"infPoints\": 2107,\n" + > > > > " \"revisionDate\": 1402448089000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 461671,\n" + > > > > " \"accountId\": 446571,\n" + > > > > " \"name\": \"Acta Est Fabul?\",\n" + > > > > " \"profileIconId\": 1435,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 47,\n" + > > > > " \"infPoints\": 644672,\n" + > > > > " \"revisionDate\": 1480626505000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 394183,\n" + > > > > " \"accountId\": 379083,\n" + > > > > " \"name\": \"acekse4\",\n" + > > > > " \"profileIconId\": 27,\n" + > > > > " \"level\": 5,\n" + > > > > " \"expPoints\": 223,\n" + > > > > " \"infPoints\": 908,\n" + > > > > " \"revisionDate\": 1348116544000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 5941247,\n" + > > > > " \"accountId\": 203106300,\n" + > > > > " \"name\": \"abdul7878\",\n" + > > > > " \"profileIconId\": 26,\n" + > > > > " \"level\": 3,\n" + > > > > " \"expPoints\": 10,\n" + > > > > " \"infPoints\": 401,\n" + > > > > " \"revisionDate\": 1406029148000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 2467446,\n" + > > > > " \"accountId\": 200459837,\n" + > > > > " \"name\": \"ActionC\",\n" + > > > > " \"profileIconId\": 986,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 74,\n" + > > > > " \"infPoints\": 401367,\n" + > > > > " \"revisionDate\": 1480808608000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 9402979,\n" + > > > > " \"accountId\": 205698832,\n" + > > > > " \"name\": \"Ablenia \",\n" + > > > > " \"profileIconId\": 1129,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 19,\n" + > > > > " \"infPoints\": 163518,\n" + > > > > " \"revisionDate\": 1480687603000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 13187505,\n" + > > > > " \"accountId\": 207898213,\n" + > > > > " \"name\": \"aDaMiYiM\",\n" + > > > > " \"profileIconId\": 1301,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 116,\n" + > > > > " \"infPoints\": 45214,\n" + > > > > " \"revisionDate\": 1480793258000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 4141059,\n" + > > > > " \"accountId\": 201688290,\n" + > > > > " \"name\": \"Abimin?ar?\",\n" + > > > > " \"profileIconId\": 898,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 152,\n" + > > > > " \"infPoints\": 752477,\n" + > > > > " \"revisionDate\": 1480635961000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 5702134,\n" + > > > > " \"accountId\": 202899395,\n" + > > > > " \"name\": \"Above the Clouds\",\n" + > > > > " \"profileIconId\": 684,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 110,\n" + > > > > " \"infPoints\": 288096,\n" + > > > > " \"revisionDate\": 1471011372000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 5810740,\n" + > > > > " \"accountId\": 202985228,\n" + > > > > " \"name\": \"aBimm\",\n" + > > > > " \"profileIconId\": 11,\n" + > > > > " \"level\": 13,\n" + > > > > " \"expPoints\": 1180,\n" + > > > > " \"infPoints\": 10736,\n" + > > > > " \"revisionDate\": 1409832684000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 5817751,\n" + > > > > " \"accountId\": 203050678,\n" + > > > > " \"name\": \"AD Glor?am\",\n" + > > > > " \"profileIconId\": 982,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 111,\n" + > > > > " \"infPoints\": 304658,\n" + > > > > " \"revisionDate\": 1480795250000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 9851802,\n" + > > > > " \"accountId\": 206011054,\n" + > > > > " \"name\": \"AdarAllame\",\n" + > > > > " \"profileIconId\": 911,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 48,\n" + > > > > " \"infPoints\": 73763,\n" + > > > > " \"revisionDate\": 1479422812000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 12735622,\n" + > > > > " \"accountId\": 207587019,\n" + > > > > " \"name\": \"absinthe666\",\n" + > > > > " \"profileIconId\": 903,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 83,\n" + > > > > " \"infPoints\": 40302,\n" + > > > > " \"revisionDate\": 1480782923000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 6371389,\n" + > > > > " \"accountId\": 203416952,\n" + > > > > " \"name\": \"adamsat?c?\",\n" + > > > > " \"profileIconId\": 3,\n" + > > > > " \"level\": 4,\n" + > > > > " \"expPoints\": 17,\n" + > > > > " \"infPoints\": 685,\n" + > > > > " \"revisionDate\": 1409320171000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 7828139,\n" + > > > > " \"accountId\": 204927980,\n" + > > > > " \"name\": \"AbsoluteForce\",\n" + > > > > " \"profileIconId\": 950,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 139,\n" + > > > > " \"infPoints\": 208789,\n" + > > > > " \"revisionDate\": 1480804396000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 1373229,\n" + > > > > " \"accountId\": 1358441,\n" + > > > > " \"name\": \"AbsoluteDeath\",\n" + > > > > " \"profileIconId\": 7,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 34,\n" + > > > > " \"infPoints\": 223655,\n" + > > > > " \"revisionDate\": 1471867646000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 7694972,\n" + > > > > " \"accountId\": 204803668,\n" + > > > > " \"name\": \"ac pnp\",\n" + > > > > " \"profileIconId\": 937,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 161,\n" + > > > > " \"infPoints\": 249681,\n" + > > > > " \"revisionDate\": 1480801507000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 1373524,\n" + > > > > " \"accountId\": 1350474,\n" + > > > > " \"name\": \"Abd??\",\n" + > > > > " \"profileIconId\": 1301,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 103,\n" + > > > > " \"infPoints\": 286803,\n" + > > > > " \"revisionDate\": 1476621827000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 1650227,\n" + > > > > " \"accountId\": 200000503,\n" + > > > > " \"name\": \"AD Ambrosia\",\n" + > > > > " \"profileIconId\": 1152,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 139,\n" + > > > > " \"infPoints\": 156333,\n" + > > > > " \"revisionDate\": 1480805320000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 8331358,\n" + > > > > " \"accountId\": 205073925,\n" + > > > > " \"name\": \"acarmanyust2\",\n" + > > > > " \"profileIconId\": 0,\n" + > > > > " \"level\": 2,\n" + > > > > " \"expPoints\": 43,\n" + > > > > " \"infPoints\": 318,\n" + > > > > " \"revisionDate\": 1423915139000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 1862106,\n" + > > > > " \"accountId\": 200139838,\n" + > > > > " \"name\": \"aboU\",\n" + > > > > " \"profileIconId\": 1155,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 0,\n" + > > > > " \"infPoints\": 412616,\n" + > > > > " \"revisionDate\": 1480771055000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 2362628,\n" + > > > > " \"accountId\": 685649,\n" + > > > > " \"name\": \"Ac?F?sT?k\",\n" + > > > > " \"profileIconId\": 1074,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 48,\n" + > > > > " \"infPoints\": 233882,\n" + > > > > " \"revisionDate\": 1480786233000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 4323909,\n" + > > > > " \"accountId\": 201917672,\n" + > > > > " \"name\": \"Addrenalin\",\n" + > > > > " \"profileIconId\": 603,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 55,\n" + > > > > " \"infPoints\": 220605,\n" + > > > > " \"revisionDate\": 1432647338000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 377206,\n" + > > > > " \"accountId\": 362106,\n" + > > > > " \"name\": \"Aburame Shino\",\n" + > > > > " \"profileIconId\": 844,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 84,\n" + > > > > " \"infPoints\": 354087,\n" + > > > > " \"revisionDate\": 1477666556000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 5377433,\n" + > > > > " \"accountId\": 202697921,\n" + > > > > " \"name\": \"AcEcolton35\",\n" + > > > > " \"profileIconId\": 984,\n" + > > > > " \"level\": 25,\n" + > > > > " \"expPoints\": 751,\n" + > > > > " \"infPoints\": 30061,\n" + > > > > " \"revisionDate\": 1475503024000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 2381404,\n" + > > > > " \"accountId\": 200333680,\n" + > > > > " \"name\": \"adafakaaa\",\n" + > > > > " \"profileIconId\": 663,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 8,\n" + > > > > " \"infPoints\": 534204,\n" + > > > > " \"revisionDate\": 1480719827000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 1281203,\n" + > > > > " \"accountId\": 1259342,\n" + > > > > " \"name\": \"AC Klondike\",\n" + > > > > " \"profileIconId\": 898,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 27,\n" + > > > > " \"infPoints\": 191429,\n" + > > > > " \"revisionDate\": 1480294973000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 13161471,\n" + > > > > " \"accountId\": 207847181,\n" + > > > > " \"name\": \"adar21\",\n" + > > > > " \"profileIconId\": 26,\n" + > > > > " \"level\": 10,\n" + > > > > " \"expPoints\": 143,\n" + > > > > " \"infPoints\": 3558,\n" + > > > > " \"revisionDate\": 1476529855000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 5841915,\n" + > > > > " \"accountId\": 202998794,\n" + > > > > " \"name\": \"Achilles29\",\n" + > > > > " \"profileIconId\": 666,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 41,\n" + > > > > " \"infPoints\": 219714,\n" + > > > > " \"revisionDate\": 1480777744000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 2853062,\n" + > > > > " \"accountId\": 200726707,\n" + > > > > " \"name\": \"AbIanStarBebegim\",\n" + > > > > " \"profileIconId\": 909,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 64,\n" + > > > > " \"infPoints\": 297580,\n" + > > > > " \"revisionDate\": 1480556859000\n" + > > > > " },\n" + > > > > " {\n" + > > > > " \"id\": 8323114,\n" + > > > > " \"accountId\": 205093515,\n" + > > > > " \"name\": \"Absuruk\",\n" + > > > > " \"profileIconId\": 6,\n" + > > > > " \"level\": 30,\n" + > > > > " \"expPoints\": 21,\n" + > > > > " \"infPoints\": 121086,\n" + > > > > " \"revisionDate\": 1480820801000\n" + > > > > " }\n" + > > > > "]" > > > > > > > > On Wed, Dec 7, 2016 at 7:01 AM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > > > > Hi Jesus, > > > > > > > > I?m trying to reproduce the problem, and just want to make sure I > get the missing pieces right. > > > > > > > > You already showed us how you?re setting up the engine and the JS > code you?re running. I assume the JSON code you?re parsing is a simple > array of objects? And you?re just calling Invocable.invokeFunction on the > ScriptEngine from multiple threads in parallel, right? > > > > > > > > Thanks, > > > > Hannes > > > > > > > > > > > > > Am 07.12.2016 um 00:03 schrieb Jesus Luzon : > > > > > > > > > > When we share one invocable across many threads and run > invokeFunction it > > > > > happens, such as this: > > > > > > > > > > ExecutorService executor = Executors.newFixedThreadPool(50); > > > > >> > > > > >> Invocable invocable = generateInvocable(script); > > > > >> > > > > >> AtomicLong count = new AtomicLong(); > > > > >> > > > > >> for (int i = 0; i < 50; i++) { > > > > >> > > > > >> executor.submit(new Runnable() { > > > > >> > > > > >> @Override > > > > >> > > > > >> public void run() { > > > > >> > > > > >> try { > > > > >> > > > > >> while(true) { > > > > >> > > > > >> invocable.invokeFunction(" > transform", > > > > >>> something); > > > > >> > > > > >> count.incrementAndGet(); > > > > >> > > > > >> } > > > > >> > > > > >> } catch (NoSuchMethodException | > ScriptException > > > > >>> e) { > > > > >> > > > > >> e.printStackTrace(); > > > > >> > > > > >> } > > > > >> > > > > >> } > > > > >> > > > > >> }); > > > > >> > > > > >> } > > > > >> > > > > >> > > > > > > > > > > > > > > > On Tue, Dec 6, 2016 at 2:59 PM, Jim Laskey (Oracle) < > james.laskey at oracle.com > > > > >> wrote: > > > > > > > > > >> Intersting. The example you posted demonstrates this behaviour? > If so > > > > >> I?ll file a bug and dig in. It sounds like an object is being > reused > > > > >> across invocations and accumulating changes to the property map. > > > > >> > > > > >> ? Jim > > > > >> > > > > >> > > > > >> On Dec 6, 2016, at 5:12 PM, Jesus Luzon > wrote: > > > > >> > > > > >> With more threads you are impacting the same 8 cores, so it will > taper off > > > > >>> after 8 threads. If it?s a 2x4 core machine then I can see 4 > being a > > > > >>> threshold depending on System performance. Transport: I meant > if you were > > > > >>> using sockets to provide the script. > > > > >> > > > > >> This makes sense. This one's on me then. > > > > >> > > > > >> > > > > >>> So you are using the same invocable instance for all threads? > If so, > > > > >>> then you are probably good to go. As far as leaks are > concerned, not sure > > > > >>> how you would get leaks from Nashorn. The JSON object is > written in Java, > > > > >>> and little JavaScript involved. > > > > >> > > > > >> > > > > >> > > > > >>> In your example, pull up Invocable invocable = > generateInvocable(script); > > > > >>> out of the loop and use the same invocable for all threads. > > > > >> > > > > >> > > > > >> We were using one invocable across all threads and we were getting > > > > >> slowdowns on execution, high CPU Usage and memory leaks that led > to > > > > >> OutOfMemory errors. I could trace the leak to > > > > >> > > > > >> jdk.nashorn.internal.objects.Global -> *objectSpill* Object[8] -> > > > > >> jdk.nashorn.internal.scripts.JO4 -> *arrayData* > > > > >> jdk.nashorn.internal.runtime.arrays.SparseArraysData -> > *underlying* > > > > >> jdk.nashorn.internal.runtime.arrays.DeletedArrayFilter > > > > >> > > > > >> which just keeps growing forever. > > > > >> > > > > >> On Tue, Dec 6, 2016 at 6:30 AM, Jim Laskey (Oracle) < > > > > >> james.laskey at oracle.com> wrote: > > > > >> > > > > >>> > > > > >>> On Dec 6, 2016, at 9:56 AM, Jesus Luzon > wrote: > > > > >>> > > > > >>> The cost of creating a new engine is significant. So share an > engine > > > > >>>> across threads but use *eval > > > > >>>> script/ScriptEngine.html#eval(java.lang.String,%20javax. > script.ScriptContext)>* > > > > >>>> (String > > > > >>>> String.html> > > > > >>>> script, ScriptContext > > > > >>>> script/ScriptContext.html> > > > > >>>> context) instead, separate context per execution. If your > JavaScript > > > > >>>> code does not modify globals you can get away with using the > same engine, > > > > >>>> same compiled script on each thread. > > > > >>> > > > > >>> > > > > >>> I guess there's a few things here I don't understand. One thing > I'm > > > > >>> trying to do is sharing a CompiledScript (which is why I'm using > > > > >>> invocable). Also, what exactly does modify globals mean? All our > filters do > > > > >>> the same thing, make a function that takes a JSON String, turns > it into a > > > > >>> JSON, modifies it and then stringifies it back. No state is > changed of > > > > >>> anything else but there are temporary vars created inside the > scope of the > > > > >>> function. When we run this multithreaded, running invokeFunction > slows down > > > > >>> significantly and we get crazy memory leaks. > > > > >>> > > > > >>> > > > > >>> So you are using the same invocable instance for all threads? > If so, > > > > >>> then you are probably good to go. As far as leaks are > concerned, not sure > > > > >>> how you would get leaks from Nashorn. The JSON object is > written in Java, > > > > >>> and little JavaScript involved. > > > > >>> > > > > >>> > > > > >>> Of course there are many factors involved n performance. How > many cores > > > > >>>> do you have on the test machine? How much memory in the > process? What > > > > >>>> transport are you using between threads? That sort of thing. > Other than > > > > >>>> constructing then engine and context Nashorn performance should > scale. > > > > >>> > > > > >>> I'm using an 8 core machine to test with 2.5Gs of RAM allocated > to the > > > > >>> process. Not sure what transports between threads means, but > this is the > > > > >>> code I'm benchmarking with. Increasing the number of threads > actually makes > > > > >>> it go faster until about 4 threads, then adding more threads > takes the same > > > > >>> amount to get to 1000 and and after a certain point it is just > slower to > > > > >>> get to 1000 counts. Some of our filters need to be able to run > over 1000 > > > > >>> times a second (across all threads) and the fastest time I could > actually > > > > >>> get with this was about 2.4 seconds for a 1000 counts. > > > > >>> > > > > >>>> ExecutorService executor = Executors.newFixedThreadPool( > 50); > > > > >>>> > > > > >>>> AtomicLong count = new AtomicLong(); > > > > >>>> > > > > >>>> for (int i = 0; i < 50; i++) { > > > > >>>> > > > > >>>> executor.submit(new Runnable() { > > > > >>>> > > > > >>>> @Override > > > > >>>> > > > > >>>> public void run() { > > > > >>>> > > > > >>>> > > > > >>>>> try { > > > > >>>> > > > > >>>> Invocable invocable = > > > > >>>>> generateInvocable(script); > > > > >>>> > > > > >>>> while(true) { > > > > >>>> > > > > >>>> invocable.invokeFunction(" > transform", > > > > >>>>> something); > > > > >>>> > > > > >>>> count.incrementAndGet(); > > > > >>>> > > > > >>>> } > > > > >>>> > > > > >>>> } catch (NoSuchMethodException | > ScriptException > > > > >>>>> e) { > > > > >>>> > > > > >>>> e.printStackTrace(); > > > > >>>> > > > > >>>> } > > > > >>>> > > > > >>>> } > > > > >>>> > > > > >>>> }); > > > > >>>> > > > > >>>> } > > > > >>>> > > > > >>>> long lastTimestamp = System.currentTimeMillis(); > > > > >>>> > > > > >>>> while(true) { > > > > >>>> > > > > >>>> > > > > >>>>> if (count.get() > 1000) { > > > > >>>> > > > > >>>> count.getAndAdd(-1000); > > > > >>>> > > > > >>>> System.out.println((System.currentTimeMillis() - > > > > >>>>> lastTimestamp)/1000.0); > > > > >>>> > > > > >>>> lastTimestamp = System.currentTimeMillis(); > > > > >>>> > > > > >>>> } > > > > >>>> > > > > >>>> } > > > > >>>> > > > > >>>> > > > > >>> With more threads you are impacting the same 8 cores, so it will > taper > > > > >>> off after 8 threads. If it?s a 2x4 core machine then I can see > 4 being a > > > > >>> threshold depending on System performance. Transport: I meant > if you were > > > > >>> using sockets to provide the script. > > > > >>> > > > > >>> In your example, pull up Invocable invocable = > generateInvocable(script); > > > > >>> out of the loop and use the same invocable for all threads. > > > > >>> > > > > >>> - Jim > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> On Tue, Dec 6, 2016 at 5:31 AM, Jim Laskey (Oracle) < > > > > >>> james.laskey at oracle.com> wrote: > > > > >>> > > > > >>>> > > > > >>>> On Dec 6, 2016, at 9:19 AM, Jesus Luzon > wrote: > > > > >>>> > > > > >>>> Hey Jim, > > > > >>>> > > > > >>>> I looked at it and I will look into loadWithNewGlobal to see > what > > > > >>>> exactly it does since it could be relevant. As for the rest, > for my use > > > > >>>> case having threads in the JS would not help. We're using > Nashorn to build > > > > >>>> JSON filters in a Dynamic Proxy Service and need any of the > threads > > > > >>>> processing a request to be able to execute the script to filter. > > > > >>>> > > > > >>>> > > > > >>>> The cost of creating a new engine is significant. So share an > engine > > > > >>>> across threads but use *eval > > > > >>>> script/ScriptEngine.html#eval(java.lang.String,%20javax. > script.ScriptContext)>* > > > > >>>> (String > > > > >>>> String.html> > > > > >>>> script, ScriptContext > > > > >>>> script/ScriptContext.html> > > > > >>>> context) instead, separate context per execution. If your > JavaScript > > > > >>>> code does not modify globals you can get away with using the > same engine, > > > > >>>> same compiled script on each thread. > > > > >>>> > > > > >>>> > > > > >>>> Also, when you say a new engine per threads is the worst case > what > > > > >>>> exactly do you mean? I would expect an initial cost of > compiling the script > > > > >>>> on each thread and then each engine should be able to do its > own thing, but > > > > >>>> what I'm seeing is that when running with more than 10 threads > all my > > > > >>>> engines get slow at executing code, even though they are all > completely > > > > >>>> separate from each other. > > > > >>>> > > > > >>>> > > > > >>>> Of course there are many factors involved n performance. How > many cores > > > > >>>> do you have on the test machine? How much memory in the > process? What > > > > >>>> transport are you using between threads? That sort of thing. > Other than > > > > >>>> constructing then engine and context Nashorn performance should > scale. > > > > >>>> > > > > >>>> > > > > >>>> On Tue, Dec 6, 2016 at 5:07 AM, Jim Laskey (Oracle) < > > > > >>>> james.laskey at oracle.com> wrote: > > > > >>>> > > > > >>>>> Jesus, > > > > >>>>> > > > > >>>>> Probably the most informative information is in this blog. > > > > >>>>> > > > > >>>>> https://blogs.oracle.com/nashorn/entry/nashorn_multi_ > threading_and_mt > > > > >>>>> > > > > >>>>> This example uses Executors but threads would work as well. > > > > >>>>> > > > > >>>>> I did a talk that looked at different methods to max out > multithreading > > > > >>>>> performance. A new engine per thread is the worst case. A > new context per > > > > >>>>> thread does much better. A new global per thread is the best > while > > > > >>>>> remaining thread safe. > > > > >>>>> > > > > >>>>> Cheers, > > > > >>>>> > > > > >>>>> ? Jim > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> On Dec 6, 2016, at 8:45 AM, Jesus Luzon > wrote: > > > > >>>>> > > > > >>>>> Hey folks, > > > > >>>>> > > > > >>>>> I've tried many different ways of using Nashorn multithreaded > based on > > > > >>>>> what > > > > >>>>> I've found on the internet and I still can't get a single one > to scale. > > > > >>>>> Even the most naive method of making many script engines with > my script > > > > >>>>> tends to bottleneck itself when I have more than 10 threads > invoking > > > > >>>>> functions. > > > > >>>>> > > > > >>>>> I'm using the following code to compile my script and > > > > >>>>> invocable.invokeFunction("transform", input) to execute: > > > > >>>>> > > > > >>>>> static Invocable generateInvocable(String script) throws > > > > >>>>> ScriptException { > > > > >>>>> ScriptEngineManager manager = new ScriptEngineManager(); > > > > >>>>> ScriptEngine engine = > > > > >>>>> manager.getEngineByName(JAVASCRIPT_ENGINE_NAME); > > > > >>>>> Compilable compilable = (Compilable) engine; > > > > >>>>> final CompiledScript compiled = > compilable.compile(script); > > > > >>>>> compiled.eval(); > > > > >>>>> return (Invocable) engine; > > > > >>>>> } > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> The script I'm compiling is: > > > > >>>>> > > > > >>>>> String script = "function transform(input) {" + > > > > >>>>> "var result = JSON.parse(input);" + > > > > >>>>> "response = {};\n" + > > > > >>>>> "for (var i = 0; i < result.length; i++) {\n" + > > > > >>>>> " var summoner = {};\n" + > > > > >>>>> " summoner.id = result[i].id;\n" + > > > > >>>>> " summoner.name = result[i].name;\n" + > > > > >>>>> " summoner.profileIconId = > > > > >>>>> result[i].profileIconId;\n" + > > > > >>>>> " summoner.revisionDate = > result[i].revisionDate;\n" + > > > > >>>>> " summoner.summonerLevel = > result[i].level;\n" + > > > > >>>>> " response[summoner.id] = summoner;\n" + > > > > >>>>> "}\n" + > > > > >>>>> "result = response;" + > > > > >>>>> "return JSON.stringify(result);" + > > > > >>>>> "};"; > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> I've also tried other more scaleable ways to work with scripts > > > > >>>>> concurrently, but given that this is the most naive method > where > > > > >>>>> everything > > > > >>>>> is brand new and I still get slowness calling them > concurrently I fear > > > > >>>>> that > > > > >>>>> maybe I'm overlooking something extremely basic on my code. > > > > >>>>> > > > > >>>>> Thanks. > > > > >>>>> -Jesus Luzon > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From hannes.wallnoefer at oracle.com Tue Apr 11 08:43:19 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 11 Apr 2017 10:43:19 +0200 Subject: Can't get Multithreaded Nashorn uses to Scale In-Reply-To: References: <31833CD9-8263-478E-9400-87D5D561C29A@oracle.com> <927BE131-BC1E-42F4-8165-B169BD96A0BF@oracle.com> Message-ID: <735F4D65-FCD6-47D5-BF65-06C50E58961C@oracle.com> I just downloaded 8u152 b02 from https://jdk8.java.net/download.html and the fix is included, which can be tested by running the original test code (runs about 10x faster than in previous 8u releases). Unfortunately, I don?t know when 8u152 will be released, I don?t think that date has been set yet. Hannes > Am 11.04.2017 um 00:21 schrieb Jesus Luzon : > > I looked in the 8u changelog and did not see anything that makes it seem like this was added, so I'm bumping this to see if someone knows the status of this and if there's any place I can just check if this has been released in a Java 8 update. > > On Mon, Jan 9, 2017 at 2:57 PM, Hannes Walln?fer wrote: > The fix is in JDK 9 now. I will propose this to be backported this to 8u, which means it should appear in some 8u release soon, but I can?t make any promise about a specific release or date. > > Hannes > From srinivas.dama at oracle.com Fri Apr 14 05:48:23 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Thu, 13 Apr 2017 22:48:23 -0700 (PDT) Subject: RFR: 8178315: nashorn ant build failure with @moduleGraph javadoc tag Message-ID: <907634e3-b6b0-4969-9f17-42e2ebe366b3@default> Hi, Please review http://cr.openjdk.java.net/~bgopularam/sdama/8178315/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8178315 . Regards, Srinivas From sundararajan.athijegannathan at oracle.com Fri Apr 14 12:42:44 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 14 Apr 2017 18:12:44 +0530 Subject: RFR: 8178315: nashorn ant build failure with @moduleGraph javadoc tag In-Reply-To: <907634e3-b6b0-4969-9f17-42e2ebe366b3@default> References: <907634e3-b6b0-4969-9f17-42e2ebe366b3@default> Message-ID: <58F0C3C4.3080301@oracle.com> +1 On 14/04/17, 11:18 AM, Srinivas Dama wrote: > Hi, > > > > Please review http://cr.openjdk.java.net/~bgopularam/sdama/8178315/webrev.00/ > > for https://bugs.openjdk.java.net/browse/JDK-8178315 . > > > > Regards, > > Srinivas From hannes.wallnoefer at oracle.com Fri Apr 14 14:19:26 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 14 Apr 2017 16:19:26 +0200 Subject: RFR: 8178315: nashorn ant build failure with @moduleGraph javadoc tag In-Reply-To: <58F0C3C4.3080301@oracle.com> References: <907634e3-b6b0-4969-9f17-42e2ebe366b3@default> <58F0C3C4.3080301@oracle.com> Message-ID: <7E1DCC3E-5123-4D35-BDD9-3AF8E38CDC3E@oracle.com> +1 Hannes > Am 14.04.2017 um 14:42 schrieb Sundararajan Athijegannathan : > > +1 > > On 14/04/17, 11:18 AM, Srinivas Dama wrote: >> Hi, >> >> >> >> Please review http://cr.openjdk.java.net/~bgopularam/sdama/8178315/webrev.00/ >> >> for https://bugs.openjdk.java.net/browse/JDK-8178315 . >> >> >> >> Regards, >> >> Srinivas From sundararajan.athijegannathan at oracle.com Wed Apr 19 04:43:04 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 19 Apr 2017 10:13:04 +0530 Subject: RFR 8178954: jjs uses wrong javadoc base URL Message-ID: <58F6EAD8.8050500@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8178954/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8178954 Thanks, -Sundar From hannes.wallnoefer at oracle.com Wed Apr 19 08:08:30 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 19 Apr 2017 10:08:30 +0200 Subject: RFR 8178954: jjs uses wrong javadoc base URL In-Reply-To: <58F6EAD8.8050500@oracle.com> References: <58F6EAD8.8050500@oracle.com> Message-ID: +1 Hannes > Am 19.04.2017 um 06:43 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8178954/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8178954 > > Thanks, > -Sundar From james.laskey at oracle.com Wed Apr 19 12:23:30 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 19 Apr 2017 09:23:30 -0300 Subject: RFR 8178954: jjs uses wrong javadoc base URL In-Reply-To: <58F6EAD8.8050500@oracle.com> References: <58F6EAD8.8050500@oracle.com> Message-ID: <197E7087-026F-4A97-BAE9-8280CDA84C6C@oracle.com> +1 > On Apr 19, 2017, at 1:43 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8178954/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8178954 > > Thanks, > -Sundar From yikesaroni at gmail.com Thu Apr 20 13:19:52 2017 From: yikesaroni at gmail.com (yikes aroni) Date: Thu, 20 Apr 2017 09:19:52 -0400 Subject: injecting a variable into a ScriptObjectMirror scope Message-ID: I have the feeling this isn't possible, but i want to be sure. If i have some code essentially like this creating a module with a closure String code = "(function() { var publ={}; publ.aaa = 123; publ.fn = function() { print('aaa='+aaa); print('bbb='+bbb); // I want to inject the value of bbb later, before calling "fn". } return publ; }"; ScriptObjectMirror som = scriptEngine.eval(code); after the creation of the SOM, is it possible for me to inject a variable "bbb" to the scope of the SOM object so that, when i invoke "fn", it evaluates the injected value of bbb? I've tried * som.put('bbb', 789); * som.setMember('bbb', 789); I've found that, if fn refers to bbb as "publ.bbb", then i can use setMember, but this is a restriction that doesn't work for my circumstance. I understand that there's no bbb in the closure, thus it is probably not possible, but maybe some Nashorn magic? thanks for any thoughts. From daniel.smith at oracle.com Mon Apr 24 21:27:51 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 24 Apr 2017 15:27:51 -0600 Subject: Call for Speakers -- 2017 JVM Language Summit Message-ID: <85FAD5B1-5296-4EA6-94D2-D35E14B949C6@oracle.com> CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, JULY-AUGUST 2017 We are pleased to announce the 2017 JVM Language Summit to be held at Oracle's Santa Clara campus on July 31-August 2, 2017. Registration is now open for speaker submissions and will remain open through May 22, 2017. There is no registration fee for speakers. A limited number of early registration slots are also available for regular attendees. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations (about 6 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-4 each day) and, possibly, impromptu "lightning talks." Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. Instructions for Speaker Registration If you'd like to give a presentation, please register as a Speaker and include a detailed abstract. Speaker registration will remain open through May 22. There is no fee. See below for help preparing your abstract and talk. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee. For a successful speaker submission, please note the following: - All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak bytecode here! - Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design or implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.) - Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire us to work together on JVM-based technologies that enable a rich ecosystem at higher layers. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2017 at jvmlangsummit.com From jonathan.gibbons at oracle.com Wed Apr 26 01:32:14 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Apr 2017 18:32:14 -0700 Subject: RFR 8179304: Please review minor changes to doc comments Message-ID: <58FFF89E.5050607@oracle.com> Please review these minor changes to make the doc comments HTML5 compliant. Mostly, the changes are about changing to or {@code} tags. There is one minor adjustment to the text content -- in TreeVisitor.java, I adjusted the name visitXYZ to visitXyz in line with similar usage elsewhere. JBS: https://bugs.openjdk.java.net/browse/JDK-8179304 Webrev: http://cr.openjdk.java.net/~jjg/8179304/webrev/ -- Jon From sundararajan.athijegannathan at oracle.com Wed Apr 26 10:02:26 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 26 Apr 2017 15:32:26 +0530 Subject: RFR 8179304: Please review minor changes to doc comments In-Reply-To: <58FFF89E.5050607@oracle.com> References: <58FFF89E.5050607@oracle.com> Message-ID: <59007032.6030100@oracle.com> Looks good. -Sundar On 26/04/17, 7:02 AM, Jonathan Gibbons wrote: > Please review these minor changes to make the doc comments HTML5 > compliant. > > Mostly, the changes are about changing to or {@code} tags. > > There is one minor adjustment to the text content -- in TreeVisitor.java, > I adjusted the name visitXYZ to visitXyz in line with similar usage > elsewhere. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8179304 > Webrev: http://cr.openjdk.java.net/~jjg/8179304/webrev/ > > -- Jon From hannes.wallnoefer at oracle.com Wed Apr 26 10:25:30 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 26 Apr 2017 12:25:30 +0200 Subject: RFR 8179304: Please review minor changes to doc comments In-Reply-To: <59007032.6030100@oracle.com> References: <58FFF89E.5050607@oracle.com> <59007032.6030100@oracle.com> Message-ID: <73D81AEF-8CE8-4942-9108-725BB4B41943@oracle.com> +1 Hannes > Am 26.04.2017 um 12:02 schrieb Sundararajan Athijegannathan : > > Looks good. > > -Sundar > > On 26/04/17, 7:02 AM, Jonathan Gibbons wrote: >> Please review these minor changes to make the doc comments HTML5 compliant. >> >> Mostly, the changes are about changing to or {@code} tags. >> >> There is one minor adjustment to the text content -- in TreeVisitor.java, >> I adjusted the name visitXYZ to visitXyz in line with similar usage elsewhere. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8179304 >> Webrev: http://cr.openjdk.java.net/~jjg/8179304/webrev/ >> >> -- Jon From james.laskey at oracle.com Wed Apr 26 12:15:06 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 26 Apr 2017 09:15:06 -0300 Subject: RFR 8179304: Please review minor changes to doc comments In-Reply-To: <58FFF89E.5050607@oracle.com> References: <58FFF89E.5050607@oracle.com> Message-ID: <125148BB-E805-4958-A61A-D21EAC6D286E@oracle.com> +1 > On Apr 25, 2017, at 10:32 PM, Jonathan Gibbons wrote: > > Please review these minor changes to make the doc comments HTML5 compliant. > > Mostly, the changes are about changing to or {@code} tags. > > There is one minor adjustment to the text content -- in TreeVisitor.java, > I adjusted the name visitXYZ to visitXyz in line with similar usage elsewhere. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8179304 > Webrev: http://cr.openjdk.java.net/~jjg/8179304/webrev/ > > -- Jon From sanaulla123 at gmail.com Wed Apr 26 13:25:59 2017 From: sanaulla123 at gmail.com (Mohammed Sanaulla) Date: Wed, 26 Apr 2017 16:25:59 +0300 Subject: Exception while using ES6 features (template strings) with Nashorn on JDK 9 Message-ID: Hello All, I am using build b166 of JDK 9. And I tried to run the following code: ScriptEngineManager engineManager = new ScriptEngineManager(); ScriptEngine engine = engineManager.getEngineByName("nashorn"); engine.eval("function sum(a, b) { return a + b; }"); System.out.println(engine.eval("sum(1, 2);")); engine.eval("var name = 'Sanaulla'"); System.out.println(engine.eval("print(`Hello Mr. ${name}`)")); The sum(1,2) works fine by printing 3. But the other part i.e using template strings throws the following exception: Exception in thread "main" javax.script.ScriptException: :1:6 Expected an operand but found error print(`Hello Mr. ${name}`) ^ in at line number 1 at column number 6 at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:536) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:523) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:154) at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at nashorn.demo/com.packt.JavascriptCodeFromJavaDemo.main(JavascriptCodeFromJavaDemo.java:13) Caused by: jdk.nashorn.internal.runtime.ParserException: :1:6 Expected an operand but found error print(`Hello Mr. ${name}`) ^ at jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:297) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:282) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4443) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4601) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4753) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4692) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.argumentList(Parser.java:3706) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:3389) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4421) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4601) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4753) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4692) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4570) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4566) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1847) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.statement(Parser.java:1155) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:909) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.program(Parser.java:844) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.parse(Parser.java:325) at jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.parse(Parser.java:285) at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compile(Context.java:1500) at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compileScript(Context.java:1467) at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compileScript(Context.java:750) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:534) ... 5 more I even tried running template strings from jjs console, but I am facing same issue. Can someone please guide me in using the ES6 features in Nashorn on JDK9? Regards, Sanaulla From james.laskey at oracle.com Wed Apr 26 14:00:07 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 26 Apr 2017 11:00:07 -0300 Subject: Exception while using ES6 features (template strings) with Nashorn on JDK 9 In-Reply-To: References: Message-ID: <7E3ACBF1-1726-4CCC-AB42-0E4F67C40431@oracle.com> You need to specify --language=es6 on the command line > On Apr 26, 2017, at 10:25 AM, Mohammed Sanaulla wrote: > > Hello All, > > I am using build b166 of JDK 9. > > And I tried to run the following code: > > ScriptEngineManager engineManager = new ScriptEngineManager(); > ScriptEngine engine = engineManager.getEngineByName("nashorn"); > engine.eval("function sum(a, b) { return a + b; }"); > System.out.println(engine.eval("sum(1, 2);")); > engine.eval("var name = 'Sanaulla'"); > System.out.println(engine.eval("print(`Hello Mr. ${name}`)")); > > The sum(1,2) works fine by printing 3. But the other part i.e using > template strings throws the following exception: > > Exception in thread "main" javax.script.ScriptException: :1:6 > Expected an operand but found error > print(`Hello Mr. ${name}`) > ^ in at line number 1 at column number 6 > at > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469) > at > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:536) > at > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:523) > at > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401) > at > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:154) > at > java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) > at > nashorn.demo/com.packt.JavascriptCodeFromJavaDemo.main(JavascriptCodeFromJavaDemo.java:13) > Caused by: jdk.nashorn.internal.runtime.ParserException: :1:6 > Expected an operand but found error > print(`Hello Mr. ${name}`) > ^ > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:297) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:282) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4443) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4601) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4753) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4692) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.argumentList(Parser.java:3706) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:3389) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4421) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4601) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4753) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4692) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4570) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4566) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1847) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.statement(Parser.java:1155) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:909) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.program(Parser.java:844) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.parse(Parser.java:325) > at > jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.parse(Parser.java:285) > at > jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compile(Context.java:1500) > at > jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compileScript(Context.java:1467) > at > jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compileScript(Context.java:750) > at > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:534) > ... 5 more > > I even tried running template strings from jjs console, but I am facing > same issue. > > Can someone please guide me in using the ES6 features in Nashorn on JDK9? > > Regards, > Sanaulla From kap4020 at gmail.com Wed Apr 26 14:06:49 2017 From: kap4020 at gmail.com (Karl Pietrzak) Date: Wed, 26 Apr 2017 10:06:49 -0400 Subject: Exception while using ES6 features (template strings) with Nashorn on JDK 9 In-Reply-To: <7E3ACBF1-1726-4CCC-AB42-0E4F67C40431@oracle.com> References: <7E3ACBF1-1726-4CCC-AB42-0E4F67C40431@oracle.com> Message-ID: Any thoughts given to making --language=es6 the default? On Wed, Apr 26, 2017 at 10:00 AM, Jim Laskey (Oracle) < james.laskey at oracle.com> wrote: > You need to specify --language=es6 on the command line > > > On Apr 26, 2017, at 10:25 AM, Mohammed Sanaulla > wrote: > > > > Hello All, > > > > I am using build b166 of JDK 9. > > > > And I tried to run the following code: > > > > ScriptEngineManager engineManager = new ScriptEngineManager(); > > ScriptEngine engine = engineManager.getEngineByName("nashorn"); > > engine.eval("function sum(a, b) { return a + b; }"); > > System.out.println(engine.eval("sum(1, 2);")); > > engine.eval("var name = 'Sanaulla'"); > > System.out.println(engine.eval("print(`Hello Mr. ${name}`)")); > > > > The sum(1,2) works fine by printing 3. But the other part i.e using > > template strings throws the following exception: > > > > Exception in thread "main" javax.script.ScriptException: :1:6 > > Expected an operand but found error > > print(`Hello Mr. ${name}`) > > ^ in at line number 1 at column number 6 > > at > > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine. > throwAsScriptException(NashornScriptEngine.java:469) > > at > > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine. > compileImpl(NashornScriptEngine.java:536) > > at > > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine. > compileImpl(NashornScriptEngine.java:523) > > at > > jdk.scripting.nashorn/jdk.nashorn.api.scripting. > NashornScriptEngine.evalImpl(NashornScriptEngine.java:401) > > at > > jdk.scripting.nashorn/jdk.nashorn.api.scripting. > NashornScriptEngine.eval(NashornScriptEngine.java:154) > > at > > java.scripting/javax.script.AbstractScriptEngine.eval( > AbstractScriptEngine.java:264) > > at > > nashorn.demo/com.packt.JavascriptCodeFromJavaDemo.main( > JavascriptCodeFromJavaDemo.java:13) > > Caused by: jdk.nashorn.internal.runtime.ParserException: :1:6 > > Expected an operand but found error > > print(`Hello Mr. ${name}`) > > ^ > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error( > AbstractParser.java:297) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error( > AbstractParser.java:282) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.unaryExpression(Parser.java:4443) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.expression(Parser.java:4601) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.conditionalExpression(Parser.java:4753) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.assignmentExpression(Parser.java:4692) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.argumentList(Parser.java:3706) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.leftHandSideExpression(Parser.java:3389) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.unaryExpression(Parser.java:4421) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.expression(Parser.java:4601) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.conditionalExpression(Parser.java:4753) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.assignmentExpression(Parser.java:4692) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.expression(Parser.java:4570) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.expression(Parser.java:4566) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.expressionStatement(Parser.java:1847) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.statement(Parser.java:1155) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.sourceElements(Parser.java:909) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.program(Parser.java:844) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.parse(Parser.java:325) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.parser. > Parser.parse(Parser.java:285) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.runtime. > Context.compile(Context.java:1500) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.runtime. > Context.compileScript(Context.java:1467) > > at > > jdk.scripting.nashorn/jdk.nashorn.internal.runtime. > Context.compileScript(Context.java:750) > > at > > jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine. > compileImpl(NashornScriptEngine.java:534) > > ... 5 more > > > > I even tried running template strings from jjs console, but I am facing > > same issue. > > > > Can someone please guide me in using the ES6 features in Nashorn on JDK9? > > > > Regards, > > Sanaulla > > -- Karl From hannes.wallnoefer at oracle.com Wed Apr 26 14:12:29 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 26 Apr 2017 16:12:29 +0200 Subject: Exception while using ES6 features (template strings) with Nashorn on JDK 9 In-Reply-To: <7E3ACBF1-1726-4CCC-AB42-0E4F67C40431@oracle.com> References: <7E3ACBF1-1726-4CCC-AB42-0E4F67C40431@oracle.com> Message-ID: <9AAA519F-C34E-45FB-9687-664AC8399780@oracle.com> Hi Mohammed, as Jim noted you have to enable ES6 features using the ?language=es6 option. The official Script API does not support engine options, but you can use the Nashorn API: import javax.script.ScriptEngine; import jdk.nashorn.api.scripting.NashornScriptEngineFactory; NashornScriptEngineFactory factory = new NashornScriptEngineFactory(); ScriptEngine engine = factory.getScriptEngine("--language=es6"); Hannes > Am 26.04.2017 um 16:00 schrieb Jim Laskey (Oracle) : > > You need to specify --language=es6 on the command line > >> On Apr 26, 2017, at 10:25 AM, Mohammed Sanaulla wrote: >> >> Hello All, >> >> I am using build b166 of JDK 9. >> >> And I tried to run the following code: >> >> ScriptEngineManager engineManager = new ScriptEngineManager(); >> ScriptEngine engine = engineManager.getEngineByName("nashorn"); >> engine.eval("function sum(a, b) { return a + b; }"); >> System.out.println(engine.eval("sum(1, 2);")); >> engine.eval("var name = 'Sanaulla'"); >> System.out.println(engine.eval("print(`Hello Mr. ${name}`)")); >> >> The sum(1,2) works fine by printing 3. But the other part i.e using >> template strings throws the following exception: >> >> Exception in thread "main" javax.script.ScriptException: :1:6 >> Expected an operand but found error >> print(`Hello Mr. ${name}`) >> ^ in at line number 1 at column number 6 >> at >> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469) >> at >> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:536) >> at >> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:523) >> at >> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401) >> at >> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:154) >> at >> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) >> at >> nashorn.demo/com.packt.JavascriptCodeFromJavaDemo.main(JavascriptCodeFromJavaDemo.java:13) >> Caused by: jdk.nashorn.internal.runtime.ParserException: :1:6 >> Expected an operand but found error >> print(`Hello Mr. ${name}`) >> ^ >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:297) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:282) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4443) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4601) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4753) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4692) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.argumentList(Parser.java:3706) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:3389) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4421) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4601) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4753) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4692) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4570) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4566) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1847) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.statement(Parser.java:1155) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:909) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.program(Parser.java:844) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.parse(Parser.java:325) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.parse(Parser.java:285) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compile(Context.java:1500) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compileScript(Context.java:1467) >> at >> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compileScript(Context.java:750) >> at >> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:534) >> ... 5 more >> >> I even tried running template strings from jjs console, but I am facing >> same issue. >> >> Can someone please guide me in using the ES6 features in Nashorn on JDK9? >> >> Regards, >> Sanaulla > From hannes.wallnoefer at oracle.com Wed Apr 26 14:14:54 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 26 Apr 2017 16:14:54 +0200 Subject: Exception while using ES6 features (template strings) with Nashorn on JDK 9 In-Reply-To: References: <7E3ACBF1-1726-4CCC-AB42-0E4F67C40431@oracle.com> Message-ID: <308E899C-2409-4F57-A4A1-8FE40EB11D2B@oracle.com> ES6 support is still work in progress, we only support some of it, so making it the default wouldn?t be a good idea. Hannes > Am 26.04.2017 um 16:06 schrieb Karl Pietrzak : > > Any thoughts given to making --language=es6 the default? > > On Wed, Apr 26, 2017 at 10:00 AM, Jim Laskey (Oracle) < > james.laskey at oracle.com> wrote: > >> You need to specify --language=es6 on the command line >> >>> On Apr 26, 2017, at 10:25 AM, Mohammed Sanaulla >> wrote: >>> >>> Hello All, >>> >>> I am using build b166 of JDK 9. >>> >>> And I tried to run the following code: >>> >>> ScriptEngineManager engineManager = new ScriptEngineManager(); >>> ScriptEngine engine = engineManager.getEngineByName("nashorn"); >>> engine.eval("function sum(a, b) { return a + b; }"); >>> System.out.println(engine.eval("sum(1, 2);")); >>> engine.eval("var name = 'Sanaulla'"); >>> System.out.println(engine.eval("print(`Hello Mr. ${name}`)")); >>> >>> The sum(1,2) works fine by printing 3. But the other part i.e using >>> template strings throws the following exception: >>> >>> Exception in thread "main" javax.script.ScriptException: :1:6 >>> Expected an operand but found error >>> print(`Hello Mr. ${name}`) >>> ^ in at line number 1 at column number 6 >>> at >>> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine. >> throwAsScriptException(NashornScriptEngine.java:469) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine. >> compileImpl(NashornScriptEngine.java:536) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine. >> compileImpl(NashornScriptEngine.java:523) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.api.scripting. >> NashornScriptEngine.evalImpl(NashornScriptEngine.java:401) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.api.scripting. >> NashornScriptEngine.eval(NashornScriptEngine.java:154) >>> at >>> java.scripting/javax.script.AbstractScriptEngine.eval( >> AbstractScriptEngine.java:264) >>> at >>> nashorn.demo/com.packt.JavascriptCodeFromJavaDemo.main( >> JavascriptCodeFromJavaDemo.java:13) >>> Caused by: jdk.nashorn.internal.runtime.ParserException: :1:6 >>> Expected an operand but found error >>> print(`Hello Mr. ${name}`) >>> ^ >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error( >> AbstractParser.java:297) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error( >> AbstractParser.java:282) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.unaryExpression(Parser.java:4443) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.expression(Parser.java:4601) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.conditionalExpression(Parser.java:4753) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.assignmentExpression(Parser.java:4692) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.argumentList(Parser.java:3706) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.leftHandSideExpression(Parser.java:3389) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.unaryExpression(Parser.java:4421) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.expression(Parser.java:4601) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.conditionalExpression(Parser.java:4753) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.assignmentExpression(Parser.java:4692) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.expression(Parser.java:4570) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.expression(Parser.java:4566) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.expressionStatement(Parser.java:1847) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.statement(Parser.java:1155) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.sourceElements(Parser.java:909) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.program(Parser.java:844) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.parse(Parser.java:325) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.parser. >> Parser.parse(Parser.java:285) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.runtime. >> Context.compile(Context.java:1500) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.runtime. >> Context.compileScript(Context.java:1467) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.internal.runtime. >> Context.compileScript(Context.java:750) >>> at >>> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine. >> compileImpl(NashornScriptEngine.java:534) >>> ... 5 more >>> >>> I even tried running template strings from jjs console, but I am facing >>> same issue. >>> >>> Can someone please guide me in using the ES6 features in Nashorn on JDK9? >>> >>> Regards, >>> Sanaulla >> >> > > > -- > Karl From kap4020 at gmail.com Wed Apr 26 14:18:33 2017 From: kap4020 at gmail.com (Karl Pietrzak) Date: Wed, 26 Apr 2017 10:18:33 -0400 Subject: how to help with ES6 features Message-ID: On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < hannes.wallnoefer at oracle.com> wrote: > ES6 support is still work in progress, we only support some of it, so > making it the default wouldn?t be a good idea. > Is there a feature I can help with? If someone points me in the right direction, I can submit a patch. I don't see anything in JIRA, really. From james.laskey at oracle.com Wed Apr 26 14:22:08 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 26 Apr 2017 11:22:08 -0300 Subject: how to help with ES6 features In-Reply-To: References: Message-ID: <9B125A45-F475-448A-B975-9245E36537B6@oracle.com> Yes, always looking for people to contribute. It is open source after all. Coordinate with Hannes. ? Jim > On Apr 26, 2017, at 11:18 AM, Karl Pietrzak wrote: > > On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > >> ES6 support is still work in progress, we only support some of it, so >> making it the default wouldn?t be a good idea. >> > > > Is there a feature I can help with? If someone points me in the right > direction, I can submit a patch. I don't see anything in JIRA, really. From hannes.wallnoefer at oracle.com Wed Apr 26 14:38:23 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 26 Apr 2017 16:38:23 +0200 Subject: how to help with ES6 features In-Reply-To: References: Message-ID: Here?s a list of things we have working and things we don?t: https://bugs.openjdk.java.net/browse/JDK-8066046 ES6 support in the parser is pretty much complete, so some features are arrow functions are ?almost? working, and others may not require too much effort. Hannes > Am 26.04.2017 um 16:18 schrieb Karl Pietrzak : > > On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > >> ES6 support is still work in progress, we only support some of it, so >> making it the default wouldn?t be a good idea. >> > > > Is there a feature I can help with? If someone points me in the right > direction, I can submit a patch. I don't see anything in JIRA, really. From pmlopes at gmail.com Thu Apr 27 11:16:03 2017 From: pmlopes at gmail.com (Paulo Lopes) Date: Thu, 27 Apr 2017 13:16:03 +0200 Subject: how to help with ES6 features In-Reply-To: References: Message-ID: Hi, For Vert.x javascript support I've prototyped the Promise API as per: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects I see that it is not in the complete list, If someone would "mentor" me with how to get it in nashorn, I'd gladly contribute the code. As an example here's some demo: https://gist.github.com/pmlopes/3d86f67943b3ffd9dd9aff73067de0a2 And it has been tested to work with babel.js to allow transpiling `async` `await` to Promise API. Cheers, Paulo On Wed, Apr 26, 2017 at 4:38 PM, Hannes Walln?fer < hannes.wallnoefer at oracle.com> wrote: > Here?s a list of things we have working and things we don?t: > > https://bugs.openjdk.java.net/browse/JDK-8066046 > > ES6 support in the parser is pretty much complete, so some features are > arrow functions are ?almost? working, and others may not require too much > effort. > > Hannes > > > > Am 26.04.2017 um 16:18 schrieb Karl Pietrzak : > > > > On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < > > hannes.wallnoefer at oracle.com> wrote: > > > >> ES6 support is still work in progress, we only support some of it, so > >> making it the default wouldn?t be a good idea. > >> > > > > > > Is there a feature I can help with? If someone points me in the right > > direction, I can submit a patch. I don't see anything in JIRA, really. > > -- Paulo Lopes www.jetdrone.com From hannes.wallnoefer at oracle.com Thu Apr 27 11:49:58 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 27 Apr 2017 13:49:58 +0200 Subject: how to help with ES6 features In-Reply-To: References: Message-ID: <36BC2947-B294-48B7-BCED-6F2CB5B67B1A@oracle.com> Hi Paulo, Excellent! I?d be happy to help you and sponsor this work. Do you think your existing code would work in Nashorn, or would it be a reimplementation based on that prototype? In any case, a link to the code would be nice to get an idea of what?s involved. Also, before contributing to OpenJDK you have to sign and send in the committer agreement as described in http://openjdk.java.net/contribute/ . If you aren?t a committer already we can help you with this. Hannes > Am 27.04.2017 um 13:16 schrieb Paulo Lopes : > > Hi, > > For Vert.x javascript support I've prototyped the Promise API as per: > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise > http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects > > I see that it is not in the complete list, If someone would "mentor" me with how to get it in nashorn, I'd gladly contribute the code. > > As an example here's some demo: > > https://gist.github.com/pmlopes/3d86f67943b3ffd9dd9aff73067de0a2 > > And it has been tested to work with babel.js to allow transpiling `async` `await` to Promise API. > > Cheers, > Paulo > > > On Wed, Apr 26, 2017 at 4:38 PM, Hannes Walln?fer wrote: > Here?s a list of things we have working and things we don?t: > > https://bugs.openjdk.java.net/browse/JDK-8066046 > > ES6 support in the parser is pretty much complete, so some features are arrow functions are ?almost? working, and others may not require too much effort. > > Hannes > > > > Am 26.04.2017 um 16:18 schrieb Karl Pietrzak : > > > > On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < > > hannes.wallnoefer at oracle.com> wrote: > > > >> ES6 support is still work in progress, we only support some of it, so > >> making it the default wouldn?t be a good idea. > >> > > > > > > Is there a feature I can help with? If someone points me in the right > > direction, I can submit a patch. I don't see anything in JIRA, really. > > > > > -- > Paulo Lopes > www.jetdrone.com From pmlopes at gmail.com Thu Apr 27 12:07:51 2017 From: pmlopes at gmail.com (Paulo Lopes) Date: Thu, 27 Apr 2017 14:07:51 +0200 Subject: how to help with ES6 features In-Reply-To: <36BC2947-B294-48B7-BCED-6F2CB5B67B1A@oracle.com> References: <36BC2947-B294-48B7-BCED-6F2CB5B67B1A@oracle.com> Message-ID: I can make it work with nashorn. Currently it does run on nashorn jdk8 plus I need a executor impl for the async part. Of course I'm using vert.x for this ;) However this could be a runtime configuration and by default use a simple ThreadPool as it exists on the JDK itself and allow (say with some runtime config) to provide a custom executor. The executor is basically the equivalent of the not yet standard: setImmediate(function); Or node's: nextTick(function); So in nashorn it can be just a java.lang.Runnable and a ThreadPoolExecutor. Cheers, Paulo On Thu, Apr 27, 2017 at 1:49 PM, Hannes Walln?fer < hannes.wallnoefer at oracle.com> wrote: > Hi Paulo, > > Excellent! I?d be happy to help you and sponsor this work. > > Do you think your existing code would work in Nashorn, or would it be a > reimplementation based on that prototype? In any case, a link to the code > would be nice to get an idea of what?s involved. > > Also, before contributing to OpenJDK you have to sign and send in the > committer agreement as described in http://openjdk.java.net/contribute/ . > If you aren?t a committer already we can help you with this. > > Hannes > > > > Am 27.04.2017 um 13:16 schrieb Paulo Lopes : > > > > Hi, > > > > For Vert.x javascript support I've prototyped the Promise API as per: > > > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/ > Reference/Global_Objects/Promise > > http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects > > > > I see that it is not in the complete list, If someone would "mentor" me > with how to get it in nashorn, I'd gladly contribute the code. > > > > As an example here's some demo: > > > > https://gist.github.com/pmlopes/3d86f67943b3ffd9dd9aff73067de0a2 > > > > And it has been tested to work with babel.js to allow transpiling > `async` `await` to Promise API. > > > > Cheers, > > Paulo > > > > > > On Wed, Apr 26, 2017 at 4:38 PM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > > Here?s a list of things we have working and things we don?t: > > > > https://bugs.openjdk.java.net/browse/JDK-8066046 > > > > ES6 support in the parser is pretty much complete, so some features are > arrow functions are ?almost? working, and others may not require too much > effort. > > > > Hannes > > > > > > > Am 26.04.2017 um 16:18 schrieb Karl Pietrzak : > > > > > > On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < > > > hannes.wallnoefer at oracle.com> wrote: > > > > > >> ES6 support is still work in progress, we only support some of it, so > > >> making it the default wouldn?t be a good idea. > > >> > > > > > > > > > Is there a feature I can help with? If someone points me in the right > > > direction, I can submit a patch. I don't see anything in JIRA, really. > > > > > > > > > > -- > > Paulo Lopes > > www.jetdrone.com > > -- Paulo Lopes www.jetdrone.com From james.laskey at oracle.com Thu Apr 27 12:48:39 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 27 Apr 2017 09:48:39 -0300 Subject: how to help with ES6 features In-Reply-To: References: <36BC2947-B294-48B7-BCED-6F2CB5B67B1A@oracle.com> Message-ID: If we can get more people involved, maybe I should come up with some scheme of free Nashorn t-shirts for those people that contribute code. :-) > On Apr 27, 2017, at 9:07 AM, Paulo Lopes wrote: > > I can make it work with nashorn. Currently it does run on nashorn jdk8 plus > I need a executor impl for the async part. Of course I'm using vert.x for > this ;) However this could be a runtime configuration and by default use a > simple ThreadPool as it exists on the JDK itself and allow (say with some > runtime config) to provide a custom executor. > > The executor is basically the equivalent of the not yet standard: > > setImmediate(function); > > Or node's: > > nextTick(function); > > So in nashorn it can be just a java.lang.Runnable and a ThreadPoolExecutor. > > Cheers, > Paulo > > > On Thu, Apr 27, 2017 at 1:49 PM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > >> Hi Paulo, >> >> Excellent! I?d be happy to help you and sponsor this work. >> >> Do you think your existing code would work in Nashorn, or would it be a >> reimplementation based on that prototype? In any case, a link to the code >> would be nice to get an idea of what?s involved. >> >> Also, before contributing to OpenJDK you have to sign and send in the >> committer agreement as described in http://openjdk.java.net/contribute/ . >> If you aren?t a committer already we can help you with this. >> >> Hannes >> >> >>> Am 27.04.2017 um 13:16 schrieb Paulo Lopes : >>> >>> Hi, >>> >>> For Vert.x javascript support I've prototyped the Promise API as per: >>> >>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/ >> Reference/Global_Objects/Promise >>> http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects >>> >>> I see that it is not in the complete list, If someone would "mentor" me >> with how to get it in nashorn, I'd gladly contribute the code. >>> >>> As an example here's some demo: >>> >>> https://gist.github.com/pmlopes/3d86f67943b3ffd9dd9aff73067de0a2 >>> >>> And it has been tested to work with babel.js to allow transpiling >> `async` `await` to Promise API. >>> >>> Cheers, >>> Paulo >>> >>> >>> On Wed, Apr 26, 2017 at 4:38 PM, Hannes Walln?fer < >> hannes.wallnoefer at oracle.com> wrote: >>> Here?s a list of things we have working and things we don?t: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8066046 >>> >>> ES6 support in the parser is pretty much complete, so some features are >> arrow functions are ?almost? working, and others may not require too much >> effort. >>> >>> Hannes >>> >>> >>>> Am 26.04.2017 um 16:18 schrieb Karl Pietrzak : >>>> >>>> On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < >>>> hannes.wallnoefer at oracle.com> wrote: >>>> >>>>> ES6 support is still work in progress, we only support some of it, so >>>>> making it the default wouldn?t be a good idea. >>>>> >>>> >>>> >>>> Is there a feature I can help with? If someone points me in the right >>>> direction, I can submit a patch. I don't see anything in JIRA, really. >>> >>> >>> >>> >>> -- >>> Paulo Lopes >>> www.jetdrone.com >> >> > > > -- > Paulo Lopes > www.jetdrone.com From hannes.wallnoefer at oracle.com Thu Apr 27 12:49:43 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 27 Apr 2017 14:49:43 +0200 Subject: how to help with ES6 features In-Reply-To: References: <36BC2947-B294-48B7-BCED-6F2CB5B67B1A@oracle.com> Message-ID: Hi Paulo, that sounds like a reasonable approach. Hannes > Am 27.04.2017 um 14:07 schrieb Paulo Lopes : > > I can make it work with nashorn. Currently it does run on nashorn jdk8 plus I need a executor impl for the async part. Of course I'm using vert.x for this ;) However this could be a runtime configuration and by default use a simple ThreadPool as it exists on the JDK itself and allow (say with some runtime config) to provide a custom executor. > > The executor is basically the equivalent of the not yet standard: > > setImmediate(function); > > Or node's: > > nextTick(function); > > So in nashorn it can be just a java.lang.Runnable and a ThreadPoolExecutor. > > Cheers, > Paulo > > > On Thu, Apr 27, 2017 at 1:49 PM, Hannes Walln?fer wrote: > Hi Paulo, > > Excellent! I?d be happy to help you and sponsor this work. > > Do you think your existing code would work in Nashorn, or would it be a reimplementation based on that prototype? In any case, a link to the code would be nice to get an idea of what?s involved. > > Also, before contributing to OpenJDK you have to sign and send in the committer agreement as described in http://openjdk.java.net/contribute/ . If you aren?t a committer already we can help you with this. > > Hannes > > > > Am 27.04.2017 um 13:16 schrieb Paulo Lopes : > > > > Hi, > > > > For Vert.x javascript support I've prototyped the Promise API as per: > > > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise > > http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects > > > > I see that it is not in the complete list, If someone would "mentor" me with how to get it in nashorn, I'd gladly contribute the code. > > > > As an example here's some demo: > > > > https://gist.github.com/pmlopes/3d86f67943b3ffd9dd9aff73067de0a2 > > > > And it has been tested to work with babel.js to allow transpiling `async` `await` to Promise API. > > > > Cheers, > > Paulo > > > > > > On Wed, Apr 26, 2017 at 4:38 PM, Hannes Walln?fer wrote: > > Here?s a list of things we have working and things we don?t: > > > > https://bugs.openjdk.java.net/browse/JDK-8066046 > > > > ES6 support in the parser is pretty much complete, so some features are arrow functions are ?almost? working, and others may not require too much effort. > > > > Hannes > > > > > > > Am 26.04.2017 um 16:18 schrieb Karl Pietrzak : > > > > > > On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < > > > hannes.wallnoefer at oracle.com> wrote: > > > > > >> ES6 support is still work in progress, we only support some of it, so > > >> making it the default wouldn?t be a good idea. > > >> > > > > > > > > > Is there a feature I can help with? If someone points me in the right > > > direction, I can submit a patch. I don't see anything in JIRA, really. > > > > > > > > > > -- > > Paulo Lopes > > www.jetdrone.com > > > > > -- > Paulo Lopes > www.jetdrone.com From szegedia at gmail.com Thu Apr 27 14:18:44 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 27 Apr 2017 16:18:44 +0200 Subject: how to help with ES6 features In-Reply-To: References: <36BC2947-B294-48B7-BCED-6F2CB5B67B1A@oracle.com> Message-ID: It should likely be written to be able to work with either generally any j.u.concurrent.ExecutorService (or even better just j.u.concurrent.Executor if the contract is simple enough), and provide a default using some of the j.u.c.Executors static factory methods, e.g. an Executors.newCachedThreadPool(). Attila. > On 27 Apr 2017, at 14:07, Paulo Lopes wrote: > > I can make it work with nashorn. Currently it does run on nashorn jdk8 plus > I need a executor impl for the async part. Of course I'm using vert.x for > this ;) However this could be a runtime configuration and by default use a > simple ThreadPool as it exists on the JDK itself and allow (say with some > runtime config) to provide a custom executor. > > The executor is basically the equivalent of the not yet standard: > > setImmediate(function); > > Or node's: > > nextTick(function); > > So in nashorn it can be just a java.lang.Runnable and a ThreadPoolExecutor. > > Cheers, > Paulo > > > On Thu, Apr 27, 2017 at 1:49 PM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > >> Hi Paulo, >> >> Excellent! I?d be happy to help you and sponsor this work. >> >> Do you think your existing code would work in Nashorn, or would it be a >> reimplementation based on that prototype? In any case, a link to the code >> would be nice to get an idea of what?s involved. >> >> Also, before contributing to OpenJDK you have to sign and send in the >> committer agreement as described in http://openjdk.java.net/contribute/ . >> If you aren?t a committer already we can help you with this. >> >> Hannes >> >> >>> Am 27.04.2017 um 13:16 schrieb Paulo Lopes : >>> >>> Hi, >>> >>> For Vert.x javascript support I've prototyped the Promise API as per: >>> >>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/ >> Reference/Global_Objects/Promise >>> http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects >>> >>> I see that it is not in the complete list, If someone would "mentor" me >> with how to get it in nashorn, I'd gladly contribute the code. >>> >>> As an example here's some demo: >>> >>> https://gist.github.com/pmlopes/3d86f67943b3ffd9dd9aff73067de0a2 >>> >>> And it has been tested to work with babel.js to allow transpiling >> `async` `await` to Promise API. >>> >>> Cheers, >>> Paulo >>> >>> >>> On Wed, Apr 26, 2017 at 4:38 PM, Hannes Walln?fer < >> hannes.wallnoefer at oracle.com> wrote: >>> Here?s a list of things we have working and things we don?t: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8066046 >>> >>> ES6 support in the parser is pretty much complete, so some features are >> arrow functions are ?almost? working, and others may not require too much >> effort. >>> >>> Hannes >>> >>> >>>> Am 26.04.2017 um 16:18 schrieb Karl Pietrzak : >>>> >>>> On Wed, Apr 26, 2017 at 10:14 AM, Hannes Walln?fer < >>>> hannes.wallnoefer at oracle.com> wrote: >>>> >>>>> ES6 support is still work in progress, we only support some of it, so >>>>> making it the default wouldn?t be a good idea. >>>>> >>>> >>>> >>>> Is there a feature I can help with? If someone points me in the right >>>> direction, I can submit a patch. I don't see anything in JIRA, really. >>> >>> >>> >>> >>> -- >>> Paulo Lopes >>> www.jetdrone.com >> >> > > > -- > Paulo Lopes > www.jetdrone.com