Re: Proper ClassLoader with ClassShutter

[Tony Zakula]

Thanks Sundar.  I am not having any issues currently, all seems to be
working great.  We just added the ClassFilter so I had to change the
constructor from:

engine = new NashornScriptEngineFactory().getScriptEngine(new
String[]{"-ccs=1000", "-ot=true", "-pcc=true"});

TO

engine = new NashornScriptEngineFactory().getScriptEngine(new
String[]{"-ccs=1000", "-ot=true", "-pcc=true"},
ClassLoader.getSystemClassLoader(), nashornClassFilter);

I saw notes on the ClassFilter in the docs, but not an example with the
ClassLoader, so I just wanted to be sure I was not going to cause myself
any issues.

Tony

On Mon, Mar 21, 2016 at 10:12 AM, Sundararajan Athijegannathan <
sundararajan.athijegannat...@oracle.com> wrote:

> By default Nashorn uses the thread context loader - which is usually
> ClassLoader.getSystemClassLoader() [ which is the launcher loader ].
>
> So,  your API call looks fine. What is the specific issue, if any,
> you've in mind?
>
> Thanks
> -Sundar
>
> On 3/20/2016 10:45 PM, Tony Zakula wrote:
> > Hey All,
> >
> > I am using a ClassShutter to limit the Java classes scripts can use, but
> I
> > am wondering how to use the proper ClassLoader in the constructor.  The
> > following seems to work fine, but is there a better way?  Our
> > initialization code looks like the following:
> >
> > // There is a bug on startup sometimes with persistent code cache
> > where you get a null pointer
> > // https://bugs.openjdk.java.net/browse/JDK-8134304 - We can
> > swallow it because things run normally
> > ScriptEngine engine = null;
> >
> > // Custom ClassFilter
> > NashornClassFilter nashornClassFilter = new NashornClassFilter();
> >
> > try {
> > engine = new NashornScriptEngineFactory().getScriptEngine(new
> > String[]{"-ccs=1000", "-ot=true", "-pcc=true"},
> > ClassLoader.getSystemClassLoader(), nashornClassFilter);
> > }
> > catch (Exception e) {}
> >
> > Thanks,
> >
> > Tony
>
>

Re: Proper ClassLoader with ClassShutter

[Sundararajan Athijegannathan]

By default Nashorn uses the thread context loader - which is usually
ClassLoader.getSystemClassLoader() [ which is the launcher loader ].

So,  your API call looks fine. What is the specific issue, if any,
you've in mind?

Thanks
-Sundar

On 3/20/2016 10:45 PM, Tony Zakula wrote:
> Hey All,
>
> I am using a ClassShutter to limit the Java classes scripts can use, but I
> am wondering how to use the proper ClassLoader in the constructor.  The
> following seems to work fine, but is there a better way?  Our
> initialization code looks like the following:
>
> // There is a bug on startup sometimes with persistent code cache
> where you get a null pointer
> // https://bugs.openjdk.java.net/browse/JDK-8134304 - We can
> swallow it because things run normally
> ScriptEngine engine = null;
>
> // Custom ClassFilter
> NashornClassFilter nashornClassFilter = new NashornClassFilter();
>
> try {
> engine = new NashornScriptEngineFactory().getScriptEngine(new
> String[]{"-ccs=1000", "-ot=true", "-pcc=true"},
> ClassLoader.getSystemClassLoader(), nashornClassFilter);
> }
> catch (Exception e) {}
>
> Thanks,
>
> Tony

Re: Review request for JDK-8151809: ES6 Map/Set insertion with existing keys changes iteration order

[Attila Szegedi]

+1

> On Mar 21, 2016, at 11:05 AM, Michael Haupt  wrote:
> 
> Hi Hannes,
> 
> lower-case thumbs up.
> 
> Best,
> 
> Michael
> 
>> Am 14.03.2016 um 17:09 schrieb Hannes Wallnoefer 
>> :
>> 
>> Please review:
>> 
>> Webrev: http://cr.openjdk.java.net/~hannesw/8151809/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151809
>> 
>> Thanks,
>> Hannes
> 
> -- 
> 
> 
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, 
> Germany
> 
> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
> München
> Registergericht: Amtsgericht München, HRA 95603
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
> 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
> Oracle is committed to developing 
> practices and products that help protect the environment
> 

Re: Review request for JDK-8151700: Add support for ES6 for-of

[Attila Szegedi]

It’s almost as if ForNode.isForInOrOf() should be a method :-)

The methods of the Iterator in ScriptRuntime.toES6Iterator should have a 
pass-through catch block for Error too, e.g. instead of "catch(final 
RuntimeException r)” use “catch(final RuntimeException|Error r)”

Other than this, +1.

Attila.

> On Mar 21, 2016, at 10:34 AM, Hannes Wallnoefer 
>  wrote:
> 
> Please review JDK-8151700: Add support for ES6 for-of:
> 
> http://cr.openjdk.java.net/~hannesw/8151700/webrev/
> 
> This enables ES6 for-of loops. The ES6 iterator is wrapped in a 
> java.util.Iterator so it uses the exact same codegen infrastructure as for-in.
> 
> Hannes

Re: Review request for JDK-8151811: Const declarations do not work in for..in loops

[Attila Szegedi]

+1

> On Mar 21, 2016, at 10:30 AM, Hannes Wallnoefer 
>  wrote:
> 
> Please review JDK-8151811: Const declarations do not work in for..in loops:
> 
> http://cr.openjdk.java.net/~hannesw/8151811/webrev/
> 
> This is pretty trivial because most of it is fixed in JDK-8151810 (previous 
> review request) already.
> 
> Hannes

Re: Review request for JDK-8151810: for-in iteration does not provide per-iteration scope

[Attila Szegedi]

Just a minor thing: consider if it’d make sense to move most of 
CodeGenerator.providesScopeCreator it’d into a method on the Block (all parts 
of the expression except for _es6 env check). Looking at 
CodeGenerator.providesScopeCreator it’s doing an awful lot of “block.” this and 
“block.” that.

Other than that, +1.

Attila.


> On Mar 21, 2016, at 10:23 AM, Hannes Wallnoefer 
>  wrote:
> 
> Please review JDK-8151810: for-in iteration does not provide per-iteration 
> scope.
> 
> http://cr.openjdk.java.net/~hannesw/8151810/webrev/
> 
> This issue popped up while I was implementing ES6 for-of statement. It turns 
> out that like for-of, the ES5 for-in statement needs a per-iteration scope 
> when used with a lexical declaration which I oversaw in my initial 
> implementation of ES6 block scope.
> 
> With normal for-statement this is pretty straightforward, because the spec 
> says that values from the previous iteration are reused in the next 
> iteration, which means that a const is actually a single const through all 
> iterations of the loop. This means that we can simply clone the existing 
> per-iteration scope at the end of the loop, which is what we do.
> 
> However, with for-in/of per iteration scopes are independent of each other. 
> Therefore, something like "for (const a of [1, 2, 3]) {...}" actually gets a 
> new const for each iteration. Now we could fake it and use a cloned scope and 
> reset the const using some magic, but doing that caused all kinds of problems 
> (weird interaction with const declaration logic and temporal dead zone 
> detection, unstable scope maps etc).
> 
> So the solution I came up with is that the block that provides the scope for 
> for-in statements (which is a synthetic block/block statement) registers its 
> scope creator in case it has one. The for-node can then reuse the scope 
> creator to create an object with the exact same property map and 
> uninitialized consts/lets.
> 
> Hannes

Re: Review request for JDK-8147613

[Michael Haupt]

Hi Srini,

lower-case thumbs up. Running the jjs tests on Windows is excellent progress. 
I'll sponsor the push.

Best,

Michael

> Am 18.03.2016 um 15:01 schrieb Srinivas Dama :
> 
> Hi,
> 
> Please review :
> Webrev : http://cr.openjdk.java.net/~sdama/8147613/webrev.00/
> It covers fix for both:
> https://bugs.openjdk.java.net/browse/JDK-8147613
> https://bugs.openjdk.java.net/browse/JDK-8147788
> 
> Regards,
> Srinivas
> 

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: Review request for JDK-8151809: ES6 Map/Set insertion with existing keys changes iteration order

[Michael Haupt]

Hi Hannes,

lower-case thumbs up.

Best,

Michael

> Am 14.03.2016 um 17:09 schrieb Hannes Wallnoefer 
> :
> 
> Please review:
> 
> Webrev: http://cr.openjdk.java.net/~hannesw/8151809/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151809
> 
> Thanks,
> Hannes

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Review request for JDK-8151700: Add support for ES6 for-of

[Hannes Wallnoefer]

Please review JDK-8151700: Add support for ES6 for-of:

http://cr.openjdk.java.net/~hannesw/8151700/webrev/

This enables ES6 for-of loops. The ES6 iterator is wrapped in a 
java.util.Iterator so it uses the exact same codegen infrastructure as 
for-in.


Hannes

Review request for JDK-8151811: Const declarations do not work in for..in loops

[Hannes Wallnoefer]

Please review JDK-8151811: Const declarations do not work in for..in loops:

http://cr.openjdk.java.net/~hannesw/8151811/webrev/

This is pretty trivial because most of it is fixed in JDK-8151810 
(previous review request) already.


Hannes

Review request for JDK-8151810: for-in iteration does not provide per-iteration scope

[Hannes Wallnoefer]

Please review JDK-8151810: for-in iteration does not provide 
per-iteration scope.


http://cr.openjdk.java.net/~hannesw/8151810/webrev/

This issue popped up while I was implementing ES6 for-of statement. It 
turns out that like for-of, the ES5 for-in statement needs a 
per-iteration scope when used with a lexical declaration which I oversaw 
in my initial implementation of ES6 block scope.


With normal for-statement this is pretty straightforward, because the 
spec says that values from the previous iteration are reused in the next 
iteration, which means that a const is actually a single const through 
all iterations of the loop. This means that we can simply clone the 
existing per-iteration scope at the end of the loop, which is what we do.


However, with for-in/of per iteration scopes are independent of each 
other. Therefore, something like "for (const a of [1, 2, 3]) {...}" 
actually gets a new const for each iteration. Now we could fake it and 
use a cloned scope and reset the const using some magic, but doing that 
caused all kinds of problems (weird interaction with const declaration 
logic and temporal dead zone detection, unstable scope maps etc).


So the solution I came up with is that the block that provides the scope 
for for-in statements (which is a synthetic block/block statement) 
registers its scope creator in case it has one. The for-node can then 
reuse the scope creator to create an object with the exact same property 
map and uninitialized consts/lets.


Hannes