From anuradha199528 at gmail.com Tue Nov 13 10:31:18 2018 From: anuradha199528 at gmail.com (Anuradha Karunarathna) Date: Tue, 13 Nov 2018 16:01:18 +0530 Subject: Unclear part in ENGINE_SCOPE and engine.eval() Message-ID: Hi, I'm using nashon by embedding it in Java(not viacommand line). I found that *The default context's ENGINE_SCOPE is a wrapped instance of ECMAScript "global" object - which is the "this" in top level script expressions. * So I wonder where other variables are stored in the engine. I tested a sample to load JS functions in a one file to another and the codes could be found below. Only *Require,require,function1,function2* and *libModule* were found in the engine scope. I want to know where other evalated code variables(eg: *testModule,function3 and math in lib.js and increment in test.js*) are stored? I am happy to clearup this thing.. -------------------------------------java code----------------------------------------------- ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn"); Invocable invocable = (Invocable) engine; engine.eval("load('require.js');"); engine.eval("var require = Require()"); engine.eval(new FileReader("script.js")); Object result = invocable.invokeFunction("function2", 50); Bindings engineBindings = engine.getBindings(ScriptContext.ENGINE_SCOPE); engineBindings.forEach((k,v)->System.out.println("key : " + k + " value : " + v)); -------------------------------------------require.js------------------------------------------- var Require=(function () { var File = java.io.File, FileReader = java.io.FileReader, BufferedReader = java.io.BufferedReader; var _require = function( path ) { var file, moduleInfo, buffered, head = '(function(exports,module,require,__filename,__dirname){ ', code = '', tail = '})', line = null; file = new File(path); buffered = new BufferedReader(new FileReader(file)); while ( ( line = buffered.readLine()) !== null ) { code += line + '\n'; } buffered.close(); moduleInfo = { exports: {}, require: _requireWrapper() }; code = head + code + tail; var compiledWrapper = null; try { compiledWrapper = eval(code); } catch (e) { throw new Error( "Error evaluating module " + path + " line #" + e.lineNumber + " : " + e.message, e.lineNumber ); } var args = [ moduleInfo.exports, /* exports */ moduleInfo, /* module */ moduleInfo.require, /* require */ ]; try { compiledWrapper .apply(null, args); } catch (e) { throw new Error( "Error executing module " + path + " line #" + e.lineNumber + " : " + e.message, e.lineNumber ); } return moduleInfo; }; var _requireWrapper = function() { return function( path ) { var module = _require(path ); return module.exports; }; }; return _requireWrapper(); }) -----------------------------------------script.js---------------------------------------------------- var libModule = require('lib.js'); var function1 =function(name){ print('Hi I am in script.js'+ name); return "greetings from javascript"; }; var function2 = function(number) { libModule.function3(number); return libModule.math(number); }; -----------------------------------------------lib.js--------------------------------------------------- var testModule=require('test.js'); var function3= function(number) { print('Hi ' + number); }; function math(number){ number = testModule.increment(number); return number; }; module.exports.math =math; module.exports.function3=function3; ----------------------------------------------test.js--------------------------------------------------------------- function increment(number){ number+=5; return number; } ; module.exports.increment=increment; --------------------------------------------------------------------------------------------------------------------- Thanks in advance. Anuradha From hannes.wallnoefer at oracle.com Thu Nov 29 17:01:25 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 29 Nov 2018 18:01:25 +0100 Subject: RFR: 8210943: Hiding of inner classes not resolved properly Message-ID: <297BF1EF-38A7-4CAC-85EB-D5A0D4A93466@oracle.com> 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 by Class.getClasses(), but these may contain inherited classes that are shadowed and thus not visible from the current class. The solution is to make sure we use the first inner class with any given name. Thanks, Hannes From jan.lahoda at oracle.com Thu Nov 29 21:06:23 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 29 Nov 2018 22:06:23 +0100 Subject: RFR: JDK-8214491: Upgrade to JLine 3.9.0 Message-ID: <5C0054CF.3040009@oracle.com> Hi, I'd like to update the internal JLine used by JShell and jjs to JLine 3.9.0. Two notable advantages of this version is multi-line snippet editing and better UI on Windows (escape sequence support on Windows). As a consequence, this patch drops EditingHistory, as it does not seem to be needed anymore. JBS: https://bugs.openjdk.java.net/browse/JDK-8214491 The full patch is here: http://cr.openjdk.java.net/~jlahoda/8214491/webrev.00/ To make the changes more clear, I've split it into two: -replacement of existing JLine with the new on in jdk.internal.le, no changes to JLine code: http://cr.openjdk.java.net/~jlahoda/8214491/webrev.00.replace/ -tweaks to JLine (repackaging, eliminating references to j.u.l.Logger, adding hooks to wrap input streams with our stop-detecting input stream, adding unicode escapes to unicode characters, support for Windows without JNA), adjustments to JShell and jjs (unfortunately, 3.9.0 is not compatible with the JLine 2 branch, so the changes are substantial): http://cr.openjdk.java.net/~jlahoda/8214491/webrev.00.update/ Any feedback is welcome! Thanks, Jan From hannes.wallnoefer at oracle.com Fri Nov 30 10:58:27 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 30 Nov 2018 11:58:27 +0100 Subject: RFR: 8214525: Bit rot in Nashorn Ant script Message-ID: <5BC476F7-20B6-4062-A9E1-3E954AAF366D@oracle.com> 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 modularized version of -linkoffline. Thanks, Hannes From szegedia at gmail.com Fri Nov 30 11:14:52 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 30 Nov 2018 12:14:52 +0100 Subject: RFR: 8210943: Hiding of inner classes not resolved properly In-Reply-To: <297BF1EF-38A7-4CAC-85EB-D5A0D4A93466@oracle.com> References: <297BF1EF-38A7-4CAC-85EB-D5A0D4A93466@oracle.com> Message-ID: +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 nested classes returned by Class.getClasses(), but these may contain inherited classes that are shadowed and thus not visible from the current class. The solution is to make sure we use the first inner class with any given name. > > Thanks, > Hannes From szegedia at gmail.com Fri Nov 30 11:15:59 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 30 Nov 2018 12:15:59 +0100 Subject: RFR: 8214525: Bit rot in Nashorn Ant script In-Reply-To: <5BC476F7-20B6-4062-A9E1-3E954AAF366D@oracle.com> References: <5BC476F7-20B6-4062-A9E1-3E954AAF366D@oracle.com> Message-ID: <981387D9-DC55-40CF-91F3-8E713D779DA7@gmail.com> +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 modularized version of -linkoffline. > > Thanks, > Hannes From james.laskey at oracle.com Fri Nov 30 13:04:57 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 30 Nov 2018 09:04:57 -0400 Subject: RFR: 8214525: Bit rot in Nashorn Ant script In-Reply-To: <5BC476F7-20B6-4062-A9E1-3E954AAF366D@oracle.com> References: <5BC476F7-20B6-4062-A9E1-3E954AAF366D@oracle.com> Message-ID: <3813FA1C-9893-43E6-8305-40ABF55A5C30@oracle.com> +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 download and switches javadoc tasks to modularized version of -linkoffline. > > Thanks, > Hannes From james.laskey at oracle.com Fri Nov 30 13:03:13 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 30 Nov 2018 09:03:13 -0400 Subject: RFR: 8210943: Hiding of inner classes not resolved properly In-Reply-To: <297BF1EF-38A7-4CAC-85EB-D5A0D4A93466@oracle.com> References: <297BF1EF-38A7-4CAC-85EB-D5A0D4A93466@oracle.com> Message-ID: <17D06426-5533-49A6-8FAE-DFA9599B5427@oracle.com> +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 by Class.getClasses(), but these may contain inherited classes that are shadowed and thus not visible from the current class. The solution is to make sure we use the first inner class with any given name. > > Thanks, > Hannes From jan.lahoda at oracle.com Fri Nov 30 14:04:02 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 30 Nov 2018 15:04:02 +0100 Subject: RFR: JDK-8214491: Upgrade to JLine 3.9.0 In-Reply-To: <69454e30-2adf-eaac-7459-841aaafb3599@oracle.com> References: <5C0054CF.3040009@oracle.com> <69454e30-2adf-eaac-7459-841aaafb3599@oracle.com> Message-ID: <5C014352.8000400@oracle.com> 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 escape. > > utils/Display.java -- please document the change Will do. (As a note, this is used when reading user input in cases like: { System.out.print("Provide input:"); System.in.read(); } where, when the read is executed, the user should enter some input, but should not be able to get the cursor into the printed text.) > > utils/StyleResolver.java et. al. -- if we want less surface area to > update when we get new versions, we could perhaps a non-op logger. No > changes required. Why is logging pulled out? jdk.internal.le currently does not depend on java.logging. jdk.jshell does, so there would be no problem with using j.u.l.Logger for jshell, but jjs does not depend on java.logging. If it would be OK to make jjs depend on java.logging, we can undo these changes. Another alternative would be to convert the use of Logger to System.Logger, but that requires non-trivial changes as well. > > terminal/impl/jna/win/Kernel32.java -- short doc of the Windows change Will do. Thanks! Jan > > Review of JShell tool and test code in separate email. > > -Robert > > > On 11/29/18 1:06 PM, Jan Lahoda wrote: >> Hi, >> >> I'd like to update the internal JLine used by JShell and jjs to JLine >> 3.9.0. Two notable advantages of this version is multi-line snippet >> editing and better UI on Windows (escape sequence support on Windows). >> As a consequence, this patch drops EditingHistory, as it does not seem >> to be needed anymore. >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8214491 >> >> The full patch is here: >> http://cr.openjdk.java.net/~jlahoda/8214491/webrev.00/ >> >> >> To make the changes more clear, I've split it into two: >> -replacement of existing JLine with the new on in jdk.internal.le, no >> changes to JLine code: >> http://cr.openjdk.java.net/~jlahoda/8214491/webrev.00.replace/ >> >> -tweaks to JLine (repackaging, eliminating references to j.u.l.Logger, >> adding hooks to wrap input streams with our stop-detecting input >> stream, adding unicode escapes to unicode characters, support for >> Windows without JNA), adjustments to JShell and jjs (unfortunately, >> 3.9.0 is not compatible with the JLine 2 branch, so the changes are >> substantial): >> http://cr.openjdk.java.net/~jlahoda/8214491/webrev.00.update/ >> >> Any feedback is welcome! >> >> Thanks, >> Jan From hannes.wallnoefer at oracle.com Fri Nov 30 14:15:35 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 30 Nov 2018 15:15:35 +0100 Subject: RFR: 8214525: Bit rot in Nashorn Ant script In-Reply-To: <3813FA1C-9893-43E6-8305-40ABF55A5C30@oracle.com> References: <5BC476F7-20B6-4062-A9E1-3E954AAF366D@oracle.com> <3813FA1C-9893-43E6-8305-40ABF55A5C30@oracle.com> Message-ID: <66619848-C2BD-427F-9ED7-4BCFE048AACF@oracle.com> 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: >> >> 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 modularized version of -linkoffline. >> >> Thanks, >> Hannes >