From sundararajan.athijegannathan at oracle.com  Fri Aug  1 17:22:26 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 01 Aug 2014 22:52:26 +0530
Subject: Nashorn Roadmap & Rhino migration question
In-Reply-To: <53DA9C44.7080008@gmail.com>
References: <53DA9C44.7080008@gmail.com>
Message-ID: <53DBCCD2.6020203@oracle.com>

I'm addressing question (2). Nashorn uses thread context class loader to 
resolve Java classes from script. So, you can either set thread context 
class loader before creating nashorn script engine. Or  you can use 
jdk.nashorn.api.scripting.NashornScriptEngineFactory class directly. 
NashornScriptEngine.getScriptEngine(ClassLoader) method may be used to 
create an engine instance with user supplied class loader.

See also:

https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes
http://cr.openjdk.java.net/~sundar/jdk.nashorn.api/8u20/javadoc/

Hope this helps,
-Sundar


On Friday 01 August 2014 01:13 AM, Paul Bakker wrote:
> Hi,
>
> Maybe not the right place to ask these questions, but I could not find 
> another place to ask them.
>
> 1: What is the roadmap of Nashorn when it comes to EcmaScript 6. The 
> spec if quite final, mostly bugfixing. Assuming that at some point 
> EcmaScript 6 will be supported in Nashorn, what is the policy to 
> porting support back to existing Java versions? Can we expect to see 
> EcmaScript 6 support in Nashorn in Java 8, or would such features only 
> become available in new Java versions (so 9 or even 10)?
>
> 2: We currently integrate with Rhino directly (not the version what 
> was shipped with Java). One of the features we use is being able to 
> load instantiate Java classes from JavaScript using a custom 
> classloader, using the new Packages(classLoader) syntax (see 
> http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html). Is 
> this supported in Nashorn so way or the other?
>
> TIA,
>
> Paul


From james.laskey at oracle.com  Fri Aug  1 18:49:43 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 1 Aug 2014 15:49:43 -0300
Subject: Nashorn Roadmap & Rhino migration question
In-Reply-To: <53DA9C44.7080008@gmail.com>
References: <53DA9C44.7080008@gmail.com>
Message-ID: <C5BD0DCA-D79D-40F6-BDEE-274122302FB6@oracle.com>

Hi Paul,


On Jul 31, 2014, at 4:43 PM, Paul Bakker <pgbakker at gmail.com> wrote:

> Hi,
> 
> Maybe not the right place to ask these questions, but I could not find another place to ask them.
> 
> 1: What is the roadmap of Nashorn when it comes to EcmaScript 6. The spec if quite final, mostly bugfixing. Assuming that at some point EcmaScript 6 will be supported in Nashorn, what is the policy to porting support back to existing Java versions? Can we expect to see EcmaScript 6 support in Nashorn in Java 8, or would such features only become available in new Java versions (so 9 or even 10)?

In general, we like to move forward and try to avoid back ports when we can; bug fixes - sure, features - not so much.  And, it's not just about marketing, it's really about logistics.  At the development level, features (even simple ones) have dependencies with other changes in the software.  A back port can haul a lot of ancillary code with it (and not just Nashorn.)  At the product level, back ports require support from all the usual suspects, PM, SQE, Security, DOC, Sustaining, ... .  Releases are a lot of work.  Multiplied across platforms and releases, it is huge.

In the past, there has been a tendency to go slow with JVM releases.  However, JDK 8 has had the fastest/largest adoption of any JVM release.  We'd like to see that trend continue.  Keeping the arrow pointing forward is the right thing to do.

ES6 will be a slow rollout, based on what we sense is important to the JS community.  Not being specific, you will see some ES6 features in JDK 9.  More ES6 features will follow with update releases. 

> 
> 2: We currently integrate with Rhino directly (not the version what was shipped with Java). One of the features we use is being able to load instantiate Java classes from JavaScript using a custom classloader, using the new Packages(classLoader) syntax (see http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html). Is this supported in Nashorn so way or the other?

Sundar has responded for this question.

> 
> TIA,
> 
> Paul

Cheers,

-- Jim





From hannes.wallnoefer at oracle.com  Fri Aug  1 19:06:04 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 01 Aug 2014 21:06:04 +0200
Subject: Nashorn Roadmap & Rhino migration question
In-Reply-To: <53DA9C44.7080008@gmail.com>
References: <53DA9C44.7080008@gmail.com>
Message-ID: <53DBE51C.9060902@oracle.com>

Hi Paul,

Regarding your question on EcmaScript 6: Our plan is to add ES6 features 
incrementally. First on our list is block scoping with let and const 
which should be in the 8u40 release. We're also reviewing a patch of 
contributed Array, Object, String, Math, and Number functions added in 
ES6. Beyond that plans are still moving, but ES6 features will continue 
to show up in update and major releases.

Complete ES6 is quite a big undertaking so it's definitely beyond JDK8 
and at least the initial JDK9 release. Whether ES6 will be backported to 
a JDK 8 update release at some point is too early to tell I guess.

Regards,
Hannes

Am 2014-07-31 um 21:43 schrieb Paul Bakker:
> Hi,
>
> Maybe not the right place to ask these questions, but I could not find 
> another place to ask them.
>
> 1: What is the roadmap of Nashorn when it comes to EcmaScript 6. The 
> spec if quite final, mostly bugfixing. Assuming that at some point 
> EcmaScript 6 will be supported in Nashorn, what is the policy to 
> porting support back to existing Java versions? Can we expect to see 
> EcmaScript 6 support in Nashorn in Java 8, or would such features only 
> become available in new Java versions (so 9 or even 10)?
>
> 2: We currently integrate with Rhino directly (not the version what 
> was shipped with Java). One of the features we use is being able to 
> load instantiate Java classes from JavaScript using a custom 
> classloader, using the new Packages(classLoader) syntax (see 
> http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html). Is 
> this supported in Nashorn so way or the other?
>
> TIA,
>
> Paul


From pgbakker at gmail.com  Mon Aug  4 12:15:47 2014
From: pgbakker at gmail.com (Paul Bakker)
Date: Mon, 04 Aug 2014 14:15:47 +0200
Subject: Nashorn Roadmap & Rhino migration question
In-Reply-To: <C5BD0DCA-D79D-40F6-BDEE-274122302FB6@oracle.com>
References: <53DA9C44.7080008@gmail.com>
	<C5BD0DCA-D79D-40F6-BDEE-274122302FB6@oracle.com>
Message-ID: <53DF7973.5000404@gmail.com>

Hi,

Tnx for the clarifications.

@sundar: I realise that I didn't properly clarify my question. What we 
do in Rhino is load classes using a custom classloader inside scripting. 
like this:
     try {
         var cx = 
Packages.org.mozilla.javascript.Context.getCurrentContext()
         var savedCL = cx.getApplicationClassLoader()
         var mediaCL = java.net.URLClassLoader([new 
java.net.URL("mycustomprotocol:///bin/")], savedCL)
         cx.setApplicationClassLoader(mediaCL)
         var customPackages = new Packages(mediaCL); //See 
http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html

         var callBackClass = new customPackages.com.mycompany.MyClass({
                name: function(arg1, arg2) {
                     //Some code here
                 }
             })
     } catch (e) {
         log.error(e)
     } finally {
         cx.setApplicationClassLoader(savedCL);
     }

We do it this way, as something dynamic is needed, thus we cannot set 
the classloader when instantiating the scriptengine.

@Hannes, Jim: tnx for the insight. Glad to hear that some ES6 features 
are already targeted for 8u40. I understand that implementing the whole 
of ES6 is a major task. Wish I would be a person to be able to provide 
patches, but I'm afraid that's not something up my alley.

Paul

On 8/1/2014 8:49 PM, Jim Laskey (Oracle) wrote:
> Hi Paul,
>
>
> On Jul 31, 2014, at 4:43 PM, Paul Bakker <pgbakker at gmail.com> wrote:
>
>> Hi,
>>
>> Maybe not the right place to ask these questions, but I could not find another place to ask them.
>>
>> 1: What is the roadmap of Nashorn when it comes to EcmaScript 6. The spec if quite final, mostly bugfixing. Assuming that at some point EcmaScript 6 will be supported in Nashorn, what is the policy to porting support back to existing Java versions? Can we expect to see EcmaScript 6 support in Nashorn in Java 8, or would such features only become available in new Java versions (so 9 or even 10)?
> In general, we like to move forward and try to avoid back ports when we can; bug fixes - sure, features - not so much.  And, it's not just about marketing, it's really about logistics.  At the development level, features (even simple ones) have dependencies with other changes in the software.  A back port can haul a lot of ancillary code with it (and not just Nashorn.)  At the product level, back ports require support from all the usual suspects, PM, SQE, Security, DOC, Sustaining, ... .  Releases are a lot of work.  Multiplied across platforms and releases, it is huge.
>
> In the past, there has been a tendency to go slow with JVM releases.  However, JDK 8 has had the fastest/largest adoption of any JVM release.  We'd like to see that trend continue.  Keeping the arrow pointing forward is the right thing to do.
>
> ES6 will be a slow rollout, based on what we sense is important to the JS community.  Not being specific, you will see some ES6 features in JDK 9.  More ES6 features will follow with update releases.
>
>> 2: We currently integrate with Rhino directly (not the version what was shipped with Java). One of the features we use is being able to load instantiate Java classes from JavaScript using a custom classloader, using the new Packages(classLoader) syntax (see http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html). Is this supported in Nashorn so way or the other?
> Sundar has responded for this question.
>
>> TIA,
>>
>> Paul
> Cheers,
>
> -- Jim
>
>
>
>


From sundararajan.athijegannathan at oracle.com  Mon Aug  4 12:25:03 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 04 Aug 2014 17:55:03 +0530
Subject: Nashorn Roadmap & Rhino migration question
In-Reply-To: <53DF7973.5000404@gmail.com>
References: <53DA9C44.7080008@gmail.com>	<C5BD0DCA-D79D-40F6-BDEE-274122302FB6@oracle.com>
	<53DF7973.5000404@gmail.com>
Message-ID: <53DF7B9F.4050705@oracle.com>

Hi,

Nashorn engine picks up thread-context loader at the time of engine 
creation or user supplied loader (with nashorn specific extension API).

For the cases like you specify, you've to use reflection - but only to 
get to the class. Something like

// get java.lang.Class object of the desired class using the class 
loader "mediaCL"
var myClass = 
java.lang.Class.forName("customPackages.com.mycompany.MyClass", true, 
mediaCL);
// make "static" reference to that class.
// MyClass is an instance of StaticClass in nashorn
var MyClass = myClass.static;

// MyClass can be used just like you'd use other java classes from script

// new object
var obj = new MyClass();
// instance method
obj.mymethod("bar");
// static method
print(MyClass.myStaticBar());

Hope this helps,
-Sundar

On Monday 04 August 2014 05:45 PM, Paul Bakker wrote:
> Hi,
>
> Tnx for the clarifications.
>
> @sundar: I realise that I didn't properly clarify my question. What we 
> do in Rhino is load classes using a custom classloader inside 
> scripting. like this:
>     try {
>         var cx = 
> Packages.org.mozilla.javascript.Context.getCurrentContext()
>         var savedCL = cx.getApplicationClassLoader()
>         var mediaCL = java.net.URLClassLoader([new 
> java.net.URL("mycustomprotocol:///bin/")], savedCL)
>         cx.setApplicationClassLoader(mediaCL)
>         var customPackages = new Packages(mediaCL); //See 
> http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html
>
>         var callBackClass = new customPackages.com.mycompany.MyClass({
>                name: function(arg1, arg2) {
>                     //Some code here
>                 }
>             })
>     } catch (e) {
>         log.error(e)
>     } finally {
>         cx.setApplicationClassLoader(savedCL);
>     }
>
> We do it this way, as something dynamic is needed, thus we cannot set 
> the classloader when instantiating the scriptengine.
>
> @Hannes, Jim: tnx for the insight. Glad to hear that some ES6 features 
> are already targeted for 8u40. I understand that implementing the 
> whole of ES6 is a major task. Wish I would be a person to be able to 
> provide patches, but I'm afraid that's not something up my alley.
>
> Paul
>
> On 8/1/2014 8:49 PM, Jim Laskey (Oracle) wrote:
>> Hi Paul,
>>
>>
>> On Jul 31, 2014, at 4:43 PM, Paul Bakker <pgbakker at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Maybe not the right place to ask these questions, but I could not 
>>> find another place to ask them.
>>>
>>> 1: What is the roadmap of Nashorn when it comes to EcmaScript 6. The 
>>> spec if quite final, mostly bugfixing. Assuming that at some point 
>>> EcmaScript 6 will be supported in Nashorn, what is the policy to 
>>> porting support back to existing Java versions? Can we expect to see 
>>> EcmaScript 6 support in Nashorn in Java 8, or would such features 
>>> only become available in new Java versions (so 9 or even 10)?
>> In general, we like to move forward and try to avoid back ports when 
>> we can; bug fixes - sure, features - not so much.  And, it's not just 
>> about marketing, it's really about logistics.  At the development 
>> level, features (even simple ones) have dependencies with other 
>> changes in the software.  A back port can haul a lot of ancillary 
>> code with it (and not just Nashorn.)  At the product level, back 
>> ports require support from all the usual suspects, PM, SQE, Security, 
>> DOC, Sustaining, ... .  Releases are a lot of work.  Multiplied 
>> across platforms and releases, it is huge.
>>
>> In the past, there has been a tendency to go slow with JVM releases.  
>> However, JDK 8 has had the fastest/largest adoption of any JVM 
>> release.  We'd like to see that trend continue. Keeping the arrow 
>> pointing forward is the right thing to do.
>>
>> ES6 will be a slow rollout, based on what we sense is important to 
>> the JS community.  Not being specific, you will see some ES6 features 
>> in JDK 9.  More ES6 features will follow with update releases.
>>
>>> 2: We currently integrate with Rhino directly (not the version what 
>>> was shipped with Java). One of the features we use is being able to 
>>> load instantiate Java classes from JavaScript using a custom 
>>> classloader, using the new Packages(classLoader) syntax (see 
>>> http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html). Is 
>>> this supported in Nashorn so way or the other?
>> Sundar has responded for this question.
>>
>>> TIA,
>>>
>>> Paul
>> Cheers,
>>
>> -- Jim
>>
>>
>>
>>
>


From hannes.wallnoefer at oracle.com  Mon Aug  4 13:52:21 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 04 Aug 2014 15:52:21 +0200
Subject: Review request for JDK-8043956: Make code caching work with optimistic
	typing and lazy compilation
Message-ID: <53DF9015.4050009@oracle.com>

Please review JDK-8043956: Make code caching work with optimistic typing 
and lazy compilation:

http://cr.openjdk.java.net/~hannesw/8043956/webrev.01/

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Mon Aug  4 15:53:16 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 04 Aug 2014 21:23:16 +0530
Subject: RFR 8054223: Nashorn: AssertionError when use __DIR__ and
	ScriptEngine.eval()
Message-ID: <53DFAC6C.1010608@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8054223/

-Sundar

From marcus.lagergren at oracle.com  Mon Aug  4 15:56:01 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 4 Aug 2014 17:56:01 +0200
Subject: RFR 8054223: Nashorn: AssertionError when use __DIR__ and
	ScriptEngine.eval()
In-Reply-To: <53DFAC6C.1010608@oracle.com>
References: <53DFAC6C.1010608@oracle.com>
Message-ID: <B1E3C043-60E6-43F7-973A-31B0673C7BC2@oracle.com>

+1

On 04 Aug 2014, at 17:53, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8054223/
> 
> -Sundar


From hannes.wallnoefer at oracle.com  Mon Aug  4 16:07:29 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 04 Aug 2014 18:07:29 +0200
Subject: RFR 8054223: Nashorn: AssertionError when use __DIR__ and
	ScriptEngine.eval()
In-Reply-To: <53DFAC6C.1010608@oracle.com>
References: <53DFAC6C.1010608@oracle.com>
Message-ID: <53DFAFC1.7080800@oracle.com>

Looks good.

Hannes

Am 2014-08-04 um 17:53 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8054223/
>
> -Sundar


From marcus.lagergren at oracle.com  Mon Aug  4 16:20:43 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 4 Aug 2014 18:20:43 +0200
Subject: Review request for JDK-8043956: Make code caching work with
	optimistic typing and lazy compilation
In-Reply-To: <53DF9015.4050009@oracle.com>
References: <53DF9015.4050009@oracle.com>
Message-ID: <9669313F-42EC-4C46-82A1-8BCBE440260A@oracle.com>

Hi Hannes!

I get the general gist of this and it looks nice. Some questions though, which I probably ask because I am sunstruck by the 33 C in my house. I don?t understand all parts of the change, but I do understand it architecturally fine.
No particular priority or size order of questions below:

?8<--

Why is the project.properties diff empty?

What is the rationale of removing CompiledFunctions? I?m going to have some merge issues with this in my optimistic native code branch, but no biggies. Just curious as to how the model works instead. Is it just because it would add more serialization problems that it went away and turned into a list in ScriptFunctionData?

You?ve got JavaDoc warnings for public methods in FunctionInitializer.java 

Please explain the ?sourceURLDirective? field. 

Please explain the ?callSiteType? field that has been added to CompiledFunction. How was this represented before?

SpillProprerty - you are missing final for initMethodHandles param

CodeStore : missing various finals for code convention

Security anti pattern - you are using implicit toStrings in a doPrivileged block in CodeStore. Not sure if the JDK classes being toStringed are safe or final, but please check it it?s a problem, or generate the string before the doPrivileged.

CodeInstaller.java - finals missing

Why are the getters and setters in AccessorProperty now exposed? Because SpillProperty needs them for serialisation? Why? Why package private and not protected - I guess it?s stronger security so it should be fine.

What?s the deal with the dropped strict param in test/script/trusted/JDK-8006529.js?

Parser / FunctionNode - why has the setSourceURL logic gone - this is probably a question I ask because I can?t see 100% of the big picture due to heatstroke/slowness/stupidity/being almost 40. I know there?s a sourceURLDirective instead, but I am not 100 % on how it works and where

Type. Isn?t ?Z? a better boolean descriptor as it corresponds to what it?s called in Java. ?B? can be confused with ?byte?

OptimisticTypesPersistence: protocol.equals(?jar?) -> ?jar?.equals(protocol) to avoid potential unnecessary NullPointers. 

What?s the purpose of the PropertyMapWrapper? Is this just to get equals and hashCode for property maps? Not sure why it?s designed this way. I do know that it?s been around for a while and isn?t a part of this change, but I wanted to ask the question anyway to complete my mental model.

Comment to be removed? + // System.err.println("ADDED PROP MAP " + System.identityHashCode(object) + " // " + Debug.caller(2, 5));

Compiler: + Map<Integer, FunctionInitializer> functionInitializers; - maybe move the field to the top of the file with the other fields. Almost didn?t see it

CompilationPhase.java + CompileUnit newUnit = compiler.createCompileUnit(sb.toString(), oldUnit.getWeight());  wants a final

CodeGenerator - what did we use ?initializedFunctionIds? for? Why is it no longer needed. Why did we need it before? Why could we even try to initialize a function twice?

The FunctionInitializer class frequently confuses me, due to my weak brain. I?d like to see a longer descriptive comment, perhaps with a simple use case at the top of FunctionInitializer.


Architecturally, this looks very good!
Thanks for bashing your forehead against this one for some time, Hannes!

Regards
Marcus


On 04 Aug 2014, at 15:52, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8043956: Make code caching work with optimistic typing and lazy compilation:
> 
> http://cr.openjdk.java.net/~hannesw/8043956/webrev.01/
> 
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Mon Aug  4 17:00:47 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 04 Aug 2014 19:00:47 +0200
Subject: Review request for JDK-8043956: Make code caching work with
	optimistic typing and lazy compilation
In-Reply-To: <9669313F-42EC-4C46-82A1-8BCBE440260A@oracle.com>
References: <53DF9015.4050009@oracle.com>
	<9669313F-42EC-4C46-82A1-8BCBE440260A@oracle.com>
Message-ID: <53DFBC3F.2050102@oracle.com>

Hi Marcus, answers inline.

Am 2014-08-04 um 18:20 schrieb Marcus Lagergren:
> Hi Hannes!
>
> I get the general gist of this and it looks nice. Some questions 
> though, which I probably ask because I am sunstruck by the 33 C in my 
> house. I don?t understand all parts of the change, but I do understand 
> it architecturally fine.
> No particular priority or size order of questions below:
>
> ?8<--
>
> Why is the project.properties diff empty?

Removed trailing whitespace

>
> What is the rationale of removing CompiledFunctions? I?m going to have 
> some merge issues with this in my optimistic native code branch, but 
> no biggies. Just curious as to how the model works instead. Is it just 
> because it would add more serialization problems that it went away and 
> turned into a list in ScriptFunctionData?

The purpuse is just to simplify the code, which moved to either 
ScriptFunctionData or CompiledFunction. The idea is just to have

>
> You?ve got JavaDoc warnings for public methods in 
> FunctionInitializer.java

Will fix this.

>
> Please explain the ?sourceURLDirective? field.
>

We allow setting the source URL from a //@ or //# comment within the 
source. Previously we passed this through the whole compilation as a 
separate parameter, which caused lots of noise.

Attila suggested to rename this to "explicitURL" and I did so in my 
reworked patch.

> Please explain the ?callSiteType? field that has been added to 
> CompiledFunction. How was this represented before?

My intention was to add a shortcut for when the callsite type is exactly 
the same as when the function was compiled.

> SpillProprerty - you are missing final for initMethodHandles param

Will fix.

>
> CodeStore : missing various finals for code convention
>
> Security anti pattern - you are using implicit toStrings in a 
> doPrivileged block in CodeStore. Not sure if the JDK classes being 
> toStringed are safe or final, but please check it it?s a problem, or 
> generate the string before the doPrivileged.

I'll check this for the next webrev.


> CodeInstaller.java - finals missing
>
> Why are the getters and setters in AccessorProperty now exposed? 
> Because SpillProperty needs them for serialisation? Why? Why package 
> private and not protected - I guess it?s stronger security so it 
> should be fine.

Exactly. I didn't think it needed to be accissible from outside the package.

> What?s the deal with the dropped strict param in 
> test/script/trusted/JDK-8006529.js?

The param that was dropped was the sourceURL one. See my response to 
"sourceURLDirective" question above.

> Parser / FunctionNode - why has the setSourceURL logic gone - this is 
> probably a question I ask because I can?t see 100% of the big picture 
> due to heatstroke/slowness/stupidity/being almost 40. I know there?s a 
> sourceURLDirective instead, but I am not 100 % on how it works and where

We now set this in source instead of passing it along as separate param.

>
> Type. Isn?t ?Z? a better boolean descriptor as it corresponds to what 
> it?s called in Java. ?B? can be confused with ?byte?

Agreed.

>
> OptimisticTypesPersistence: protocol.equals(?jar?) -> 
> ?jar?.equals(protocol) to avoid potential unnecessary NullPointers.
>
> What?s the purpose of the PropertyMapWrapper? Is this just to get 
> equals and hashCode for property maps? Not sure why it?s designed this 
> way. I do know that it?s been around for a while and isn?t a part of 
> this change, but I wanted to ask the question anyway to complete my 
> mental model.
>
> Comment to be removed? + // System.err.println("ADDED PROP MAP " + 
> System.identityHashCode(object) + " // " + Debug.caller(2, 5));

Already removed.

>
> Compiler: + Map<Integer, FunctionInitializer> functionInitializers; - 
> maybe move the field to the top of the file with the other fields. 
> Almost didn?t see it
>
> CompilationPhase.java + CompileUnit newUnit = 
> compiler.createCompileUnit(sb.toString(), oldUnit.getWeight());  wants 
> a final
>
> CodeGenerator - what did we use ?initializedFunctionIds? for? Why is 
> it no longer needed. Why did we need it before? Why could we even try 
> to initialize a function twice?

I had to unify function initialization between eager and on-demand code 
and newly compiled and deserialized code, which is why I moved this 
functionality out of CodeGenerator and CompileUnit. Actually I don't 
think initializedFunctionIds was needed before. I'll check this again 
and maybe add an assertion or something.

>
> The FunctionInitializer class frequently confuses me, due to my weak 
> brain. I?d like to see a longer descriptive comment, perhaps with a 
> simple use case at the top of FunctionInitializer.

Will add this.

Thanks!

Hannes

>
> Architecturally, this looks very good!
> Thanks for bashing your forehead against this one for some time, Hannes!
>
> Regards
> Marcus
>
>
> On 04 Aug 2014, at 15:52, Hannes Wallnoefer 
> <hannes.wallnoefer at oracle.com <mailto:hannes.wallnoefer at oracle.com>> 
> wrote:
>
>> Please review JDK-8043956: Make code caching work with optimistic 
>> typing and lazy compilation:
>>
>> http://cr.openjdk.java.net/~hannesw/8043956/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Ehannesw/8043956/webrev.01/>
>>
>> Thanks,
>> Hannes
>


From marcus.lagergren at oracle.com  Tue Aug  5 08:10:02 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Tue, 5 Aug 2014 10:10:02 +0200
Subject: Review request for JDK-8043956: Make code caching work with
	optimistic typing and lazy compilation
In-Reply-To: <53DFBC3F.2050102@oracle.com>
References: <53DF9015.4050009@oracle.com>
	<9669313F-42EC-4C46-82A1-8BCBE440260A@oracle.com>
	<53DFBC3F.2050102@oracle.com>
Message-ID: <4614C2F4-137D-4071-98C5-AF9A0FFE6C29@oracle.com>

Very good summary Hannes - this answers all of my questions. The toStrings in the doPrivileged block is the only one that still worries me.
I?ll be happy to look at a new webrev, but I don?t think I have a lot to say.

Actually one more thing - so this is now a generic mechanism for storing and persisting all code, no matter if it?s optimistic or eager? Does it use Attila?s optimistic type storage, or is it new through and through? I see you have various weird dependencies between the code caches now

Have you checked that runtime performance is the same for e.g. Octane, given that you have been poking around a bit in the delicate AccessProperty/SpillProperty getters and setters.

Regards
Marcus

On 04 Aug 2014, at 19:00, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Hi Marcus, answers inline.
> 
> Am 2014-08-04 um 18:20 schrieb Marcus Lagergren:
>> Hi Hannes!
>> 
>> I get the general gist of this and it looks nice. Some questions though, which I probably ask because I am sunstruck by the 33 C in my house. I don?t understand all parts of the change, but I do understand it architecturally fine.
>> No particular priority or size order of questions below:
>> 
>> ?8<--
>> 
>> Why is the project.properties diff empty?
> 
> Removed trailing whitespace
> 
>> 
>> What is the rationale of removing CompiledFunctions? I?m going to have some merge issues with this in my optimistic native code branch, but no biggies. Just curious as to how the model works instead. Is it just because it would add more serialization problems that it went away and turned into a list in ScriptFunctionData?
> 
> The purpuse is just to simplify the code, which moved to either ScriptFunctionData or CompiledFunction. The idea is just to have
> 
>> 
>> You?ve got JavaDoc warnings for public methods in FunctionInitializer.java
> 
> Will fix this.
> 
>> 
>> Please explain the ?sourceURLDirective? field.
>> 
> 
> We allow setting the source URL from a //@ or //# comment within the source. Previously we passed this through the whole compilation as a separate parameter, which caused lots of noise.
> 
> Attila suggested to rename this to "explicitURL" and I did so in my reworked patch.
> 
>> Please explain the ?callSiteType? field that has been added to CompiledFunction. How was this represented before?
> 
> My intention was to add a shortcut for when the callsite type is exactly the same as when the function was compiled.
> 
>> SpillProprerty - you are missing final for initMethodHandles param
> 
> Will fix.
> 
>> 
>> CodeStore : missing various finals for code convention
>> 
>> Security anti pattern - you are using implicit toStrings in a doPrivileged block in CodeStore. Not sure if the JDK classes being toStringed are safe or final, but please check it it?s a problem, or generate the string before the doPrivileged.
> 
> I'll check this for the next webrev.
> 
> 
>> CodeInstaller.java - finals missing
>> 
>> Why are the getters and setters in AccessorProperty now exposed? Because SpillProperty needs them for serialisation? Why? Why package private and not protected - I guess it?s stronger security so it should be fine.
> 
> Exactly. I didn't think it needed to be accissible from outside the package.
> 
>> What?s the deal with the dropped strict param in test/script/trusted/JDK-8006529.js?
> 
> The param that was dropped was the sourceURL one. See my response to "sourceURLDirective" question above.
> 
>> Parser / FunctionNode - why has the setSourceURL logic gone - this is probably a question I ask because I can?t see 100% of the big picture due to heatstroke/slowness/stupidity/being almost 40. I know there?s a sourceURLDirective instead, but I am not 100 % on how it works and where
> 
> We now set this in source instead of passing it along as separate param.
> 
>> 
>> Type. Isn?t ?Z? a better boolean descriptor as it corresponds to what it?s called in Java. ?B? can be confused with ?byte?
> 
> Agreed.
> 
>> 
>> OptimisticTypesPersistence: protocol.equals(?jar?) -> ?jar?.equals(protocol) to avoid potential unnecessary NullPointers.
>> 
>> What?s the purpose of the PropertyMapWrapper? Is this just to get equals and hashCode for property maps? Not sure why it?s designed this way. I do know that it?s been around for a while and isn?t a part of this change, but I wanted to ask the question anyway to complete my mental model.
>> 
>> Comment to be removed? + // System.err.println("ADDED PROP MAP " + System.identityHashCode(object) + " // " + Debug.caller(2, 5));
> 
> Already removed.
> 
>> 
>> Compiler: + Map<Integer, FunctionInitializer> functionInitializers; - maybe move the field to the top of the file with the other fields. Almost didn?t see it
>> 
>> CompilationPhase.java + CompileUnit newUnit = compiler.createCompileUnit(sb.toString(), oldUnit.getWeight());  wants a final
>> 
>> CodeGenerator - what did we use ?initializedFunctionIds? for? Why is it no longer needed. Why did we need it before? Why could we even try to initialize a function twice?
> 
> I had to unify function initialization between eager and on-demand code and newly compiled and deserialized code, which is why I moved this functionality out of CodeGenerator and CompileUnit. Actually I don't think initializedFunctionIds was needed before. I'll check this again and maybe add an assertion or something.
> 
>> 
>> The FunctionInitializer class frequently confuses me, due to my weak brain. I?d like to see a longer descriptive comment, perhaps with a simple use case at the top of FunctionInitializer.
> 
> Will add this.
> 
> Thanks!
> 
> Hannes
> 
>> 
>> Architecturally, this looks very good!
>> Thanks for bashing your forehead against this one for some time, Hannes!
>> 
>> Regards
>> Marcus
>> 
>> 
>> On 04 Aug 2014, at 15:52, Hannes Wallnoefer <hannes.wallnoefer at oracle.com <mailto:hannes.wallnoefer at oracle.com>> wrote:
>> 
>>> Please review JDK-8043956: Make code caching work with optimistic typing and lazy compilation:
>>> 
>>> http://cr.openjdk.java.net/~hannesw/8043956/webrev.01/ <http://cr.openjdk.java.net/%7Ehannesw/8043956/webrev.01/>
>>> 
>>> Thanks,
>>> Hannes
>> 
> 


From hannes.wallnoefer at oracle.com  Tue Aug  5 09:45:49 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 05 Aug 2014 11:45:49 +0200
Subject: Review request for JDK-8043956: Make code caching work with
	optimistic typing and lazy compilation
In-Reply-To: <4614C2F4-137D-4071-98C5-AF9A0FFE6C29@oracle.com>
References: <53DF9015.4050009@oracle.com>
	<9669313F-42EC-4C46-82A1-8BCBE440260A@oracle.com>
	<53DFBC3F.2050102@oracle.com>
	<4614C2F4-137D-4071-98C5-AF9A0FFE6C29@oracle.com>
Message-ID: <53E0A7CD.6040708@oracle.com>

Am 2014-08-05 um 10:10 schrieb Marcus Lagergren:
> Very good summary Hannes - this answers all of my questions. The toStrings in the doPrivileged block is the only one that still worries me.
> I?ll be happy to look at a new webrev, but I don?t think I have a lot to say.
>
> Actually one more thing - so this is now a generic mechanism for storing and persisting all code, no matter if it?s optimistic or eager? Does it use Attila?s optimistic type storage, or is it new through and through? I see you have various weird dependencies between the code caches now

Yes, code store now works for both optimistic and non-optimistic.

While working on this I had it unified with Attila's optimistic type 
storage, using the exact same directory structure and naming 
conventions. But it didn't feel right for various reasons. Type caching 
only uses very small amounts of storage while class caching quickly runs 
into hundreds of MB. Because of this, it felt wrong to use a storage 
location that is hidden from the user. Also, using type caching storage 
wouldn't allow to override code store behaviour which we eventually plan 
to allow.

Can you be more explicit about what you mean by weird dependencies 
between code caches?


>
> Have you checked that runtime performance is the same for e.g. Octane, given that you have been poking around a bit in the delicate AccessProperty/SpillProperty getters and setters.

I haven't noticed any losses of performance during my tests, will double 
check to make sure.

Hannes

>
> Regards
> Marcus
>
> On 04 Aug 2014, at 19:00, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>
>> Hi Marcus, answers inline.
>>
>> Am 2014-08-04 um 18:20 schrieb Marcus Lagergren:
>>> Hi Hannes!
>>>
>>> I get the general gist of this and it looks nice. Some questions though, which I probably ask because I am sunstruck by the 33 C in my house. I don?t understand all parts of the change, but I do understand it architecturally fine.
>>> No particular priority or size order of questions below:
>>>
>>> ?8<--
>>>
>>> Why is the project.properties diff empty?
>> Removed trailing whitespace
>>
>>> What is the rationale of removing CompiledFunctions? I?m going to have some merge issues with this in my optimistic native code branch, but no biggies. Just curious as to how the model works instead. Is it just because it would add more serialization problems that it went away and turned into a list in ScriptFunctionData?
>> The purpuse is just to simplify the code, which moved to either ScriptFunctionData or CompiledFunction. The idea is just to have
>>
>>> You?ve got JavaDoc warnings for public methods in FunctionInitializer.java
>> Will fix this.
>>
>>> Please explain the ?sourceURLDirective? field.
>>>
>> We allow setting the source URL from a //@ or //# comment within the source. Previously we passed this through the whole compilation as a separate parameter, which caused lots of noise.
>>
>> Attila suggested to rename this to "explicitURL" and I did so in my reworked patch.
>>
>>> Please explain the ?callSiteType? field that has been added to CompiledFunction. How was this represented before?
>> My intention was to add a shortcut for when the callsite type is exactly the same as when the function was compiled.
>>
>>> SpillProprerty - you are missing final for initMethodHandles param
>> Will fix.
>>
>>> CodeStore : missing various finals for code convention
>>>
>>> Security anti pattern - you are using implicit toStrings in a doPrivileged block in CodeStore. Not sure if the JDK classes being toStringed are safe or final, but please check it it?s a problem, or generate the string before the doPrivileged.
>> I'll check this for the next webrev.
>>
>>
>>> CodeInstaller.java - finals missing
>>>
>>> Why are the getters and setters in AccessorProperty now exposed? Because SpillProperty needs them for serialisation? Why? Why package private and not protected - I guess it?s stronger security so it should be fine.
>> Exactly. I didn't think it needed to be accissible from outside the package.
>>
>>> What?s the deal with the dropped strict param in test/script/trusted/JDK-8006529.js?
>> The param that was dropped was the sourceURL one. See my response to "sourceURLDirective" question above.
>>
>>> Parser / FunctionNode - why has the setSourceURL logic gone - this is probably a question I ask because I can?t see 100% of the big picture due to heatstroke/slowness/stupidity/being almost 40. I know there?s a sourceURLDirective instead, but I am not 100 % on how it works and where
>> We now set this in source instead of passing it along as separate param.
>>
>>> Type. Isn?t ?Z? a better boolean descriptor as it corresponds to what it?s called in Java. ?B? can be confused with ?byte?
>> Agreed.
>>
>>> OptimisticTypesPersistence: protocol.equals(?jar?) -> ?jar?.equals(protocol) to avoid potential unnecessary NullPointers.
>>>
>>> What?s the purpose of the PropertyMapWrapper? Is this just to get equals and hashCode for property maps? Not sure why it?s designed this way. I do know that it?s been around for a while and isn?t a part of this change, but I wanted to ask the question anyway to complete my mental model.
>>>
>>> Comment to be removed? + // System.err.println("ADDED PROP MAP " + System.identityHashCode(object) + " // " + Debug.caller(2, 5));
>> Already removed.
>>
>>> Compiler: + Map<Integer, FunctionInitializer> functionInitializers; - maybe move the field to the top of the file with the other fields. Almost didn?t see it
>>>
>>> CompilationPhase.java + CompileUnit newUnit = compiler.createCompileUnit(sb.toString(), oldUnit.getWeight());  wants a final
>>>
>>> CodeGenerator - what did we use ?initializedFunctionIds? for? Why is it no longer needed. Why did we need it before? Why could we even try to initialize a function twice?
>> I had to unify function initialization between eager and on-demand code and newly compiled and deserialized code, which is why I moved this functionality out of CodeGenerator and CompileUnit. Actually I don't think initializedFunctionIds was needed before. I'll check this again and maybe add an assertion or something.
>>
>>> The FunctionInitializer class frequently confuses me, due to my weak brain. I?d like to see a longer descriptive comment, perhaps with a simple use case at the top of FunctionInitializer.
>> Will add this.
>>
>> Thanks!
>>
>> Hannes
>>
>>> Architecturally, this looks very good!
>>> Thanks for bashing your forehead against this one for some time, Hannes!
>>>
>>> Regards
>>> Marcus
>>>
>>>
>>> On 04 Aug 2014, at 15:52, Hannes Wallnoefer <hannes.wallnoefer at oracle.com <mailto:hannes.wallnoefer at oracle.com>> wrote:
>>>
>>>> Please review JDK-8043956: Make code caching work with optimistic typing and lazy compilation:
>>>>
>>>> http://cr.openjdk.java.net/~hannesw/8043956/webrev.01/ <http://cr.openjdk.java.net/%7Ehannesw/8043956/webrev.01/>
>>>>
>>>> Thanks,
>>>> Hannes


From sundararajan.athijegannathan at oracle.com  Wed Aug  6 11:08:48 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 06 Aug 2014 16:38:48 +0530
Subject: RFR 8053910: ScriptObjectMirror causing havoc with Invocation
	interface
Message-ID: <53E20CC0.9080302@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8053910/

ScriptObjectMirror, wrap/unwrap has caused pain. Uniformly wrapping all 
ScriptObject instances to be ScriptObjectMirror whenever Java boundary 
is crossed. Hopefully, it'll be easier to understand and code around 
ScriptObjectMirrors in Java side.

Thanks
-Sundar

From sundararajan.athijegannathan at oracle.com  Wed Aug  6 15:09:24 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 06 Aug 2014 20:39:24 +0530
Subject: RFR 8053910: ScriptObjectMirror causing havoc with Invocation
	interface
In-Reply-To: <53E20CC0.9080302@oracle.com>
References: <53E20CC0.9080302@oracle.com>
Message-ID: <53E24524.7000606@oracle.com>

Please ignore my earlier webrev. I've updated in place. Only limited 
issue of getInterface input param unwrap and wrapping of interface 
method result addressed against this bug.

We'd like to revisit ScriptObjectMirror for any Object type param of any 
java method later..

Thanks
-Sundar

On Wednesday 06 August 2014 04:38 PM, A. Sundararajan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8053910/
>
> ScriptObjectMirror, wrap/unwrap has caused pain. Uniformly wrapping 
> all ScriptObject instances to be ScriptObjectMirror whenever Java 
> boundary is crossed. Hopefully, it'll be easier to understand and code 
> around ScriptObjectMirrors in Java side.
>
> Thanks
> -Sundar


From marcus.lagergren at oracle.com  Wed Aug  6 16:36:07 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 6 Aug 2014 18:36:07 +0200
Subject: Review request for JDK-8043956: Make code caching work with
	optimistic typing and lazy compilation
In-Reply-To: <53E0A7CD.6040708@oracle.com>
References: <53DF9015.4050009@oracle.com>
	<9669313F-42EC-4C46-82A1-8BCBE440260A@oracle.com>
	<53DFBC3F.2050102@oracle.com>
	<4614C2F4-137D-4071-98C5-AF9A0FFE6C29@oracle.com>
	<53E0A7CD.6040708@oracle.com>
Message-ID: <750ED3DC-6825-4260-921D-CC8763C551B4@oracle.com>

+1 in that case.

On 05 Aug 2014, at 11:45, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Am 2014-08-05 um 10:10 schrieb Marcus Lagergren:
>> Very good summary Hannes - this answers all of my questions. The toStrings in the doPrivileged block is the only one that still worries me.
>> I?ll be happy to look at a new webrev, but I don?t think I have a lot to say.
>> 
>> Actually one more thing - so this is now a generic mechanism for storing and persisting all code, no matter if it?s optimistic or eager? Does it use Attila?s optimistic type storage, or is it new through and through? I see you have various weird dependencies between the code caches now
> 
> Yes, code store now works for both optimistic and non-optimistic.
> 
> While working on this I had it unified with Attila's optimistic type storage, using the exact same directory structure and naming conventions. But it didn't feel right for various reasons. Type caching only uses very small amounts of storage while class caching quickly runs into hundreds of MB. Because of this, it felt wrong to use a storage location that is hidden from the user. Also, using type caching storage wouldn't allow to override code store behaviour which we eventually plan to allow.
> 
> Can you be more explicit about what you mean by weird dependencies between code caches?
> 
> 
>> 
>> Have you checked that runtime performance is the same for e.g. Octane, given that you have been poking around a bit in the delicate AccessProperty/SpillProperty getters and setters.
> 
> I haven't noticed any losses of performance during my tests, will double check to make sure.
> 
> Hannes
> 
>> 
>> Regards
>> Marcus
>> 
>> On 04 Aug 2014, at 19:00, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>> 
>>> Hi Marcus, answers inline.
>>> 
>>> Am 2014-08-04 um 18:20 schrieb Marcus Lagergren:
>>>> Hi Hannes!
>>>> 
>>>> I get the general gist of this and it looks nice. Some questions though, which I probably ask because I am sunstruck by the 33 C in my house. I don?t understand all parts of the change, but I do understand it architecturally fine.
>>>> No particular priority or size order of questions below:
>>>> 
>>>> ?8<--
>>>> 
>>>> Why is the project.properties diff empty?
>>> Removed trailing whitespace
>>> 
>>>> What is the rationale of removing CompiledFunctions? I?m going to have some merge issues with this in my optimistic native code branch, but no biggies. Just curious as to how the model works instead. Is it just because it would add more serialization problems that it went away and turned into a list in ScriptFunctionData?
>>> The purpuse is just to simplify the code, which moved to either ScriptFunctionData or CompiledFunction. The idea is just to have
>>> 
>>>> You?ve got JavaDoc warnings for public methods in FunctionInitializer.java
>>> Will fix this.
>>> 
>>>> Please explain the ?sourceURLDirective? field.
>>>> 
>>> We allow setting the source URL from a //@ or //# comment within the source. Previously we passed this through the whole compilation as a separate parameter, which caused lots of noise.
>>> 
>>> Attila suggested to rename this to "explicitURL" and I did so in my reworked patch.
>>> 
>>>> Please explain the ?callSiteType? field that has been added to CompiledFunction. How was this represented before?
>>> My intention was to add a shortcut for when the callsite type is exactly the same as when the function was compiled.
>>> 
>>>> SpillProprerty - you are missing final for initMethodHandles param
>>> Will fix.
>>> 
>>>> CodeStore : missing various finals for code convention
>>>> 
>>>> Security anti pattern - you are using implicit toStrings in a doPrivileged block in CodeStore. Not sure if the JDK classes being toStringed are safe or final, but please check it it?s a problem, or generate the string before the doPrivileged.
>>> I'll check this for the next webrev.
>>> 
>>> 
>>>> CodeInstaller.java - finals missing
>>>> 
>>>> Why are the getters and setters in AccessorProperty now exposed? Because SpillProperty needs them for serialisation? Why? Why package private and not protected - I guess it?s stronger security so it should be fine.
>>> Exactly. I didn't think it needed to be accissible from outside the package.
>>> 
>>>> What?s the deal with the dropped strict param in test/script/trusted/JDK-8006529.js?
>>> The param that was dropped was the sourceURL one. See my response to "sourceURLDirective" question above.
>>> 
>>>> Parser / FunctionNode - why has the setSourceURL logic gone - this is probably a question I ask because I can?t see 100% of the big picture due to heatstroke/slowness/stupidity/being almost 40. I know there?s a sourceURLDirective instead, but I am not 100 % on how it works and where
>>> We now set this in source instead of passing it along as separate param.
>>> 
>>>> Type. Isn?t ?Z? a better boolean descriptor as it corresponds to what it?s called in Java. ?B? can be confused with ?byte?
>>> Agreed.
>>> 
>>>> OptimisticTypesPersistence: protocol.equals(?jar?) -> ?jar?.equals(protocol) to avoid potential unnecessary NullPointers.
>>>> 
>>>> What?s the purpose of the PropertyMapWrapper? Is this just to get equals and hashCode for property maps? Not sure why it?s designed this way. I do know that it?s been around for a while and isn?t a part of this change, but I wanted to ask the question anyway to complete my mental model.
>>>> 
>>>> Comment to be removed? + // System.err.println("ADDED PROP MAP " + System.identityHashCode(object) + " // " + Debug.caller(2, 5));
>>> Already removed.
>>> 
>>>> Compiler: + Map<Integer, FunctionInitializer> functionInitializers; - maybe move the field to the top of the file with the other fields. Almost didn?t see it
>>>> 
>>>> CompilationPhase.java + CompileUnit newUnit = compiler.createCompileUnit(sb.toString(), oldUnit.getWeight());  wants a final
>>>> 
>>>> CodeGenerator - what did we use ?initializedFunctionIds? for? Why is it no longer needed. Why did we need it before? Why could we even try to initialize a function twice?
>>> I had to unify function initialization between eager and on-demand code and newly compiled and deserialized code, which is why I moved this functionality out of CodeGenerator and CompileUnit. Actually I don't think initializedFunctionIds was needed before. I'll check this again and maybe add an assertion or something.
>>> 
>>>> The FunctionInitializer class frequently confuses me, due to my weak brain. I?d like to see a longer descriptive comment, perhaps with a simple use case at the top of FunctionInitializer.
>>> Will add this.
>>> 
>>> Thanks!
>>> 
>>> Hannes
>>> 
>>>> Architecturally, this looks very good!
>>>> Thanks for bashing your forehead against this one for some time, Hannes!
>>>> 
>>>> Regards
>>>> Marcus
>>>> 
>>>> 
>>>> On 04 Aug 2014, at 15:52, Hannes Wallnoefer <hannes.wallnoefer at oracle.com <mailto:hannes.wallnoefer at oracle.com>> wrote:
>>>> 
>>>>> Please review JDK-8043956: Make code caching work with optimistic typing and lazy compilation:
>>>>> 
>>>>> http://cr.openjdk.java.net/~hannesw/8043956/webrev.01/ <http://cr.openjdk.java.net/%7Ehannesw/8043956/webrev.01/>
>>>>> 
>>>>> Thanks,
>>>>> Hannes
> 


From pgbakker at gmail.com  Wed Aug  6 19:06:36 2014
From: pgbakker at gmail.com (Paul Bakker)
Date: Wed, 06 Aug 2014 21:06:36 +0200
Subject: Nashorn Roadmap & Rhino migration question
In-Reply-To: <C5BD0DCA-D79D-40F6-BDEE-274122302FB6@oracle.com>
References: <53DA9C44.7080008@gmail.com>
	<C5BD0DCA-D79D-40F6-BDEE-274122302FB6@oracle.com>
Message-ID: <53E27CBC.9000908@gmail.com>

Hi Sundar,

Does the approach you suggested also work for implementing 
interfaces/abstract classes, like I did in my example?

When we built this in Rhino, we had a hard time figuring out how to 
extend (Abstract) Java classes/implement Java interfaces through 
JavaScript that were loaded dynamically using a custom classloader at 
runtime in scripting.

The only way that worked in Rhino was using a custom Packages instance 
created with new Packages(ClassLoader). Loading a class through 
reflection and then trying to provide an implementation through 
JavaScript didn't work.

So, this is what we're doing in Rhino:

      try {
	 //Create custom classloader that extends applicationclassloader and set it temporarily as applicationclassloader
	 var cx = Packages.org.mozilla.javascript.Context.getCurrentContext()
          var savedCL = cx.getApplicationClassLoader()
          var mediaCL = java.net.URLClassLoader([new java.net.URL("mycustomprotocol:///bin/")], savedCL)
          cx.setApplicationClassLoader(mediaCL)

	 //Create custom Packages, using a custom classloader that extends the applicationclassloader
	 var customPackages = new Packages(mediaCL); //Seehttp://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html

	 //Extend abstract class 'MyClass', providing the implementation through JavaScript
          var callBackClass = new customPackages.com.mycompany.MyClass({
                 name: function(arg1, arg2) {
                      //Some code here
                  }
              })
      } catch (e) {
          log.error(e)
      } finally {
          cx.setApplicationClassLoader(savedCL);
      }

Paul

On 8/1/2014 8:49 PM, Jim Laskey (Oracle) wrote:
> Hi,
>
> Nashorn engine picks up thread-context loader at the time of engine
> creation or user supplied loader (with nashorn specific extension API).
>
> For the cases like you specify, you've to use reflection - but only to
> get to the class. Something like
>
> // get java.lang.Class object of the desired class using the class
> loader "mediaCL"
> var myClass =
> java.lang.Class.forName("customPackages.com.mycompany.MyClass", true,
> mediaCL);
> // make "static" reference to that class.
> // MyClass is an instance of StaticClass in nashorn
> var MyClass = myClass.static;
>
> // MyClass can be used just like you'd use other java classes from script
>
> // new object
> var obj = new MyClass();
> // instance method
> obj.mymethod("bar");
> // static method
> print(MyClass.myStaticBar());
>
> Hope this helps,
> -Sundarl,

From sundararajan.athijegannathan at oracle.com  Thu Aug  7 09:31:42 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 07 Aug 2014 15:01:42 +0530
Subject: Nashorn Roadmap & Rhino migration question
In-Reply-To: <53E27CBC.9000908@gmail.com>
References: <53DA9C44.7080008@gmail.com>	<C5BD0DCA-D79D-40F6-BDEE-274122302FB6@oracle.com>
	<53E27CBC.9000908@gmail.com>
Message-ID: <53E3477E.8000008@oracle.com>

Hi Paul,

Yes, it should work on all places where Java class access is needed.

*) Reflectively load your java class using Class.forName.
*) access value of "static" property on it.
*) resulting object (instance of StaticClass) can be used anywhere Java 
class is needed.
(superclass, interface, class-for-new, static method call, static field 
access).

Hope this helps,
-Sundar

On Thursday 07 August 2014 12:36 AM, Paul Bakker wrote:
> Hi Sundar,
>
> Does the approach you suggested also work for implementing 
> interfaces/abstract classes, like I did in my example?
>
> When we built this in Rhino, we had a hard time figuring out how to 
> extend (Abstract) Java classes/implement Java interfaces through 
> JavaScript that were loaded dynamically using a custom classloader at 
> runtime in scripting.
>
> The only way that worked in Rhino was using a custom Packages instance 
> created with new Packages(ClassLoader). Loading a class through 
> reflection and then trying to provide an implementation through 
> JavaScript didn't work.
>
> So, this is what we're doing in Rhino:
>
>      try {
>      //Create custom classloader that extends applicationclassloader 
> and set it temporarily as applicationclassloader
>      var cx = Packages.org.mozilla.javascript.Context.getCurrentContext()
>          var savedCL = cx.getApplicationClassLoader()
>          var mediaCL = java.net.URLClassLoader([new 
> java.net.URL("mycustomprotocol:///bin/")], savedCL)
>          cx.setApplicationClassLoader(mediaCL)
>
>      //Create custom Packages, using a custom classloader that extends 
> the applicationclassloader
>      var customPackages = new Packages(mediaCL); 
> //Seehttp://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html
>
>      //Extend abstract class 'MyClass', providing the implementation 
> through JavaScript
>          var callBackClass = new customPackages.com.mycompany.MyClass({
>                 name: function(arg1, arg2) {
>                      //Some code here
>                  }
>              })
>      } catch (e) {
>          log.error(e)
>      } finally {
>          cx.setApplicationClassLoader(savedCL);
>      }
>
> Paul
>
> On 8/1/2014 8:49 PM, Jim Laskey (Oracle) wrote:
>> Hi,
>>
>> Nashorn engine picks up thread-context loader at the time of engine
>> creation or user supplied loader (with nashorn specific extension API).
>>
>> For the cases like you specify, you've to use reflection - but only to
>> get to the class. Something like
>>
>> // get java.lang.Class object of the desired class using the class
>> loader "mediaCL"
>> var myClass =
>> java.lang.Class.forName("customPackages.com.mycompany.MyClass", true,
>> mediaCL);
>> // make "static" reference to that class.
>> // MyClass is an instance of StaticClass in nashorn
>> var MyClass = myClass.static;
>>
>> // MyClass can be used just like you'd use other java classes from 
>> script
>>
>> // new object
>> var obj = new MyClass();
>> // instance method
>> obj.mymethod("bar");
>> // static method
>> print(MyClass.myStaticBar());
>>
>> Hope this helps,
>> -Sundarl,


From sundararajan.athijegannathan at oracle.com  Thu Aug  7 13:18:25 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 07 Aug 2014 18:48:25 +0530
Subject: RFR 8051346: Test262 tests for ECMAScript 5 now in branch "es5-tests"
Message-ID: <53E37CA1.1000106@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8051346/

Thanks
-Sundar

From mark.reinhold at oracle.com  Thu Aug  7 16:29:40 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  7 Aug 2014 09:29:40 -0700 (PDT)
Subject: JEP 202: Nashorn Class Filter
Message-ID: <20140807162940.3CC39330B4@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/202

- Mark

From mark.reinhold at oracle.com  Thu Aug  7 16:36:48 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  7 Aug 2014 09:36:48 -0700 (PDT)
Subject: JEP 203: Nashorn: Lexically-scoped variable and constant declarations
Message-ID: <20140807163648.10234330BA@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/203

- Mark

From hannes.wallnoefer at oracle.com  Thu Aug  7 16:40:01 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 07 Aug 2014 18:40:01 +0200
Subject: Review request for JDK-8043956: Make code caching work with
	optimistic typing and lazy compilation
In-Reply-To: <750ED3DC-6825-4260-921D-CC8763C551B4@oracle.com>
References: <53DF9015.4050009@oracle.com>
	<9669313F-42EC-4C46-82A1-8BCBE440260A@oracle.com>
	<53DFBC3F.2050102@oracle.com>
	<4614C2F4-137D-4071-98C5-AF9A0FFE6C29@oracle.com>
	<53E0A7CD.6040708@oracle.com>
	<750ED3DC-6825-4260-921D-CC8763C551B4@oracle.com>
Message-ID: <53E3ABE1.1000400@oracle.com>

Am 2014-08-06 um 18:36 schrieb Marcus Lagergren:
> +1 in that case.

Thanks. I uploaded a new webrev with changes suggested by you and Attila:

http://cr.openjdk.java.net/~hannesw/8043956/webrev.02/

Hannes

>
> On 05 Aug 2014, at 11:45, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>
>> Am 2014-08-05 um 10:10 schrieb Marcus Lagergren:
>>> Very good summary Hannes - this answers all of my questions. The toStrings in the doPrivileged block is the only one that still worries me.
>>> I?ll be happy to look at a new webrev, but I don?t think I have a lot to say.
>>>
>>> Actually one more thing - so this is now a generic mechanism for storing and persisting all code, no matter if it?s optimistic or eager? Does it use Attila?s optimistic type storage, or is it new through and through? I see you have various weird dependencies between the code caches now
>> Yes, code store now works for both optimistic and non-optimistic.
>>
>> While working on this I had it unified with Attila's optimistic type storage, using the exact same directory structure and naming conventions. But it didn't feel right for various reasons. Type caching only uses very small amounts of storage while class caching quickly runs into hundreds of MB. Because of this, it felt wrong to use a storage location that is hidden from the user. Also, using type caching storage wouldn't allow to override code store behaviour which we eventually plan to allow.
>>
>> Can you be more explicit about what you mean by weird dependencies between code caches?
>>
>>
>>> Have you checked that runtime performance is the same for e.g. Octane, given that you have been poking around a bit in the delicate AccessProperty/SpillProperty getters and setters.
>> I haven't noticed any losses of performance during my tests, will double check to make sure.
>>
>> Hannes
>>
>>> Regards
>>> Marcus
>>>
>>> On 04 Aug 2014, at 19:00, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>>>
>>>> Hi Marcus, answers inline.
>>>>
>>>> Am 2014-08-04 um 18:20 schrieb Marcus Lagergren:
>>>>> Hi Hannes!
>>>>>
>>>>> I get the general gist of this and it looks nice. Some questions though, which I probably ask because I am sunstruck by the 33 C in my house. I don?t understand all parts of the change, but I do understand it architecturally fine.
>>>>> No particular priority or size order of questions below:
>>>>>
>>>>> ?8<--
>>>>>
>>>>> Why is the project.properties diff empty?
>>>> Removed trailing whitespace
>>>>
>>>>> What is the rationale of removing CompiledFunctions? I?m going to have some merge issues with this in my optimistic native code branch, but no biggies. Just curious as to how the model works instead. Is it just because it would add more serialization problems that it went away and turned into a list in ScriptFunctionData?
>>>> The purpuse is just to simplify the code, which moved to either ScriptFunctionData or CompiledFunction. The idea is just to have
>>>>
>>>>> You?ve got JavaDoc warnings for public methods in FunctionInitializer.java
>>>> Will fix this.
>>>>
>>>>> Please explain the ?sourceURLDirective? field.
>>>>>
>>>> We allow setting the source URL from a //@ or //# comment within the source. Previously we passed this through the whole compilation as a separate parameter, which caused lots of noise.
>>>>
>>>> Attila suggested to rename this to "explicitURL" and I did so in my reworked patch.
>>>>
>>>>> Please explain the ?callSiteType? field that has been added to CompiledFunction. How was this represented before?
>>>> My intention was to add a shortcut for when the callsite type is exactly the same as when the function was compiled.
>>>>
>>>>> SpillProprerty - you are missing final for initMethodHandles param
>>>> Will fix.
>>>>
>>>>> CodeStore : missing various finals for code convention
>>>>>
>>>>> Security anti pattern - you are using implicit toStrings in a doPrivileged block in CodeStore. Not sure if the JDK classes being toStringed are safe or final, but please check it it?s a problem, or generate the string before the doPrivileged.
>>>> I'll check this for the next webrev.
>>>>
>>>>
>>>>> CodeInstaller.java - finals missing
>>>>>
>>>>> Why are the getters and setters in AccessorProperty now exposed? Because SpillProperty needs them for serialisation? Why? Why package private and not protected - I guess it?s stronger security so it should be fine.
>>>> Exactly. I didn't think it needed to be accissible from outside the package.
>>>>
>>>>> What?s the deal with the dropped strict param in test/script/trusted/JDK-8006529.js?
>>>> The param that was dropped was the sourceURL one. See my response to "sourceURLDirective" question above.
>>>>
>>>>> Parser / FunctionNode - why has the setSourceURL logic gone - this is probably a question I ask because I can?t see 100% of the big picture due to heatstroke/slowness/stupidity/being almost 40. I know there?s a sourceURLDirective instead, but I am not 100 % on how it works and where
>>>> We now set this in source instead of passing it along as separate param.
>>>>
>>>>> Type. Isn?t ?Z? a better boolean descriptor as it corresponds to what it?s called in Java. ?B? can be confused with ?byte?
>>>> Agreed.
>>>>
>>>>> OptimisticTypesPersistence: protocol.equals(?jar?) -> ?jar?.equals(protocol) to avoid potential unnecessary NullPointers.
>>>>>
>>>>> What?s the purpose of the PropertyMapWrapper? Is this just to get equals and hashCode for property maps? Not sure why it?s designed this way. I do know that it?s been around for a while and isn?t a part of this change, but I wanted to ask the question anyway to complete my mental model.
>>>>>
>>>>> Comment to be removed? + // System.err.println("ADDED PROP MAP " + System.identityHashCode(object) + " // " + Debug.caller(2, 5));
>>>> Already removed.
>>>>
>>>>> Compiler: + Map<Integer, FunctionInitializer> functionInitializers; - maybe move the field to the top of the file with the other fields. Almost didn?t see it
>>>>>
>>>>> CompilationPhase.java + CompileUnit newUnit = compiler.createCompileUnit(sb.toString(), oldUnit.getWeight());  wants a final
>>>>>
>>>>> CodeGenerator - what did we use ?initializedFunctionIds? for? Why is it no longer needed. Why did we need it before? Why could we even try to initialize a function twice?
>>>> I had to unify function initialization between eager and on-demand code and newly compiled and deserialized code, which is why I moved this functionality out of CodeGenerator and CompileUnit. Actually I don't think initializedFunctionIds was needed before. I'll check this again and maybe add an assertion or something.
>>>>
>>>>> The FunctionInitializer class frequently confuses me, due to my weak brain. I?d like to see a longer descriptive comment, perhaps with a simple use case at the top of FunctionInitializer.
>>>> Will add this.
>>>>
>>>> Thanks!
>>>>
>>>> Hannes
>>>>
>>>>> Architecturally, this looks very good!
>>>>> Thanks for bashing your forehead against this one for some time, Hannes!
>>>>>
>>>>> Regards
>>>>> Marcus
>>>>>
>>>>>
>>>>> On 04 Aug 2014, at 15:52, Hannes Wallnoefer <hannes.wallnoefer at oracle.com <mailto:hannes.wallnoefer at oracle.com>> wrote:
>>>>>
>>>>>> Please review JDK-8043956: Make code caching work with optimistic typing and lazy compilation:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~hannesw/8043956/webrev.01/ <http://cr.openjdk.java.net/%7Ehannesw/8043956/webrev.01/>
>>>>>>
>>>>>> Thanks,
>>>>>> Hannes


From sundararajan.athijegannathan at oracle.com  Fri Aug  8 12:51:49 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 08 Aug 2014 18:21:49 +0530
Subject: RFR 8054651: Global.initConstructor and
	ScriptFunction.getPrototype(Object) can have stricter types
Message-ID: <53E4C7E5.4040304@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8054651/

PS. also contains few minor javadoc fixes to get no errors with "ant 
javadoc" target as well as excluding a test262 test from test262 run 
(for which a bug has been filed already).

Thanks
-Sundar

From james.laskey at oracle.com  Fri Aug  8 13:07:02 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 8 Aug 2014 10:07:02 -0300
Subject: RFR 8054651: Global.initConstructor and
	ScriptFunction.getPrototype(Object) can have stricter types
In-Reply-To: <53E4C7E5.4040304@oracle.com>
References: <53E4C7E5.4040304@oracle.com>
Message-ID: <E5CC6A08-B990-4817-B8F8-9C89EA708B8E@oracle.com>

+1

On Aug 8, 2014, at 9:51 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8054651/
> 
> PS. also contains few minor javadoc fixes to get no errors with "ant javadoc" target as well as excluding a test262 test from test262 run (for which a bug has been filed already).
> 
> Thanks
> -Sundar


From attila.szegedi at oracle.com  Fri Aug  8 13:18:42 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 8 Aug 2014 15:18:42 +0200
Subject: RFR 8054651: Global.initConstructor and
	ScriptFunction.getPrototype(Object) can have stricter types
In-Reply-To: <53E4C7E5.4040304@oracle.com>
References: <53E4C7E5.4040304@oracle.com>
Message-ID: <9C7A0E36-4DC9-4387-920E-F154C9CCE11A@oracle.com>

+1

On Aug 8, 2014, at 2:51 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8054651/
> 
> PS. also contains few minor javadoc fixes to get no errors with "ant javadoc" target as well as excluding a test262 test from test262 run (for which a bug has been filed already).
> 
> Thanks
> -Sundar


From sundararajan.athijegannathan at oracle.com  Mon Aug 11 13:32:49 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 11 Aug 2014 19:02:49 +0530
Subject: RFR 8054503:
	test/script/external/test262/test/suite/ch12/12.6/12.6.4/12.6.4-2.js
	fails with tip
Message-ID: <53E8C601.1000604@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8054503/

Thanks
-Sundar

From hannes.wallnoefer at oracle.com  Mon Aug 11 14:10:48 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 11 Aug 2014 16:10:48 +0200
Subject: Review request for JDK-8044851: nashorn properties leak memory
Message-ID: <53E8CEE8.8090402@oracle.com>

Please review JDK-8044851: nashorn properties leak memory

http://cr.openjdk.java.net/~hannesw/8044851/

Thanks,
Hannes

From attila.szegedi at oracle.com  Mon Aug 11 16:09:06 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 11 Aug 2014 18:09:06 +0200
Subject: Review request for JDK-8044851: nashorn properties leak memory
In-Reply-To: <53E8CEE8.8090402@oracle.com>
References: <53E8CEE8.8090402@oracle.com>
Message-ID: <2DD6AC06-D889-4272-9568-23A67D95DC9B@oracle.com>

+1

On Aug 11, 2014, at 4:10 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8044851: nashorn properties leak memory
> 
> http://cr.openjdk.java.net/~hannesw/8044851/
> 
> Thanks,
> Hannes


From attila.szegedi at oracle.com  Mon Aug 11 16:09:15 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 11 Aug 2014 18:09:15 +0200
Subject: RFR 8054503:
	test/script/external/test262/test/suite/ch12/12.6/12.6.4/12.6.4-2.js
	fails with tip
In-Reply-To: <53E8C601.1000604@oracle.com>
References: <53E8C601.1000604@oracle.com>
Message-ID: <8845E4C2-F55C-48FB-852B-4A8524BB0CFF@oracle.com>

+1

On Aug 11, 2014, at 3:32 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8054503/
> 
> Thanks
> -Sundar


From marcus.lagergren at oracle.com  Tue Aug 12 09:37:39 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Tue, 12 Aug 2014 11:37:39 +0200
Subject: Review request for JDK-8044851: nashorn properties leak memory
In-Reply-To: <53E8CEE8.8090402@oracle.com>
References: <53E8CEE8.8090402@oracle.com>
Message-ID: <0C97A5CB-16A5-43E1-B73E-EBE23081EDC4@oracle.com>

+1

On 11 Aug 2014, at 16:10, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8044851: nashorn properties leak memory
> 
> http://cr.openjdk.java.net/~hannesw/8044851/
> 
> Thanks,
> Hannes


From marcus.lagergren at oracle.com  Tue Aug 12 09:38:47 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Tue, 12 Aug 2014 11:38:47 +0200
Subject: RFR 8054503:
	test/script/external/test262/test/suite/ch12/12.6/12.6.4/12.6.4-2.js
	fails with tip
In-Reply-To: <53E8C601.1000604@oracle.com>
References: <53E8C601.1000604@oracle.com>
Message-ID: <A5282B5B-F710-406A-8274-B58A681A9C10@oracle.com>

+1

On 11 Aug 2014, at 15:32, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8054503/
> 
> Thanks
> -Sundar


From hannes.wallnoefer at oracle.com  Tue Aug 12 09:40:24 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 12 Aug 2014 11:40:24 +0200
Subject: Review request for JDK-8054898: Avoid creation of empty type info
	files
Message-ID: <53E9E108.2090101@oracle.com>

Please review JDK-8054898: Avoid creation of empty type info files:

http://cr.openjdk.java.net/~hannesw/8054898/

This is a one-liner to avoid creating a type info file when we don't 
have to.

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Tue Aug 12 10:12:16 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 12 Aug 2014 15:42:16 +0530
Subject: Review request for JDK-8054898: Avoid creation of empty type
	info files
In-Reply-To: <53E9E108.2090101@oracle.com>
References: <53E9E108.2090101@oracle.com>
Message-ID: <53E9E880.5090100@oracle.com>

+1

On Tuesday 12 August 2014 03:10 PM, Hannes Wallnoefer wrote:
> Please review JDK-8054898: Avoid creation of empty type info files:
>
> http://cr.openjdk.java.net/~hannesw/8054898/
>
> This is a one-liner to avoid creating a type info file when we don't 
> have to.
>
> Thanks,
> Hannes


From james.laskey at oracle.com  Tue Aug 12 11:14:04 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 12 Aug 2014 08:14:04 -0300
Subject: Review request for JDK-8054898: Avoid creation of empty type info
	files
In-Reply-To: <53E9E108.2090101@oracle.com>
References: <53E9E108.2090101@oracle.com>
Message-ID: <8C6F62CF-CF1C-4D29-9FCA-CE992A6565D6@oracle.com>

+1

On Aug 12, 2014, at 6:40 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8054898: Avoid creation of empty type info files:
> 
> http://cr.openjdk.java.net/~hannesw/8054898/
> 
> This is a one-liner to avoid creating a type info file when we don't have to.
> 
> Thanks,
> Hannes


From sundararajan.athijegannathan at oracle.com  Wed Aug 13 09:27:32 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 13 Aug 2014 14:57:32 +0530
Subject: RFR 8054993: type info cache may be disabled for test262 and tests
	explicitly changing that property should use @fork
Message-ID: <53EB2F84.1000900@oracle.com>

Please review cr.openjdk.java.net/~sundar/8054993/

Thanks
-Sundar

From hannes.wallnoefer at oracle.com  Wed Aug 13 09:28:44 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 13 Aug 2014 11:28:44 +0200
Subject: RFR 8054993: type info cache may be disabled for test262 and
	tests explicitly changing that property should use @fork
In-Reply-To: <53EB2F84.1000900@oracle.com>
References: <53EB2F84.1000900@oracle.com>
Message-ID: <53EB2FCC.5090901@oracle.com>

+1


Am 2014-08-13 um 11:27 schrieb A. Sundararajan:
> Please review cr.openjdk.java.net/~sundar/8054993/
>
> Thanks
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Aug 13 15:07:58 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 13 Aug 2014 20:37:58 +0530
Subject: RFR 8055034: jjs exits interactive mode if exception was thrown when
	trying to print value of last evaluated expression
Message-ID: <53EB7F4E.4050007@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055034/

Thanks,
-Sundar

From attila.szegedi at oracle.com  Wed Aug 13 15:14:30 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 13 Aug 2014 17:14:30 +0200
Subject: RFR 8055034: jjs exits interactive mode if exception was thrown
	when trying to print value of last evaluated expression
In-Reply-To: <53EB7F4E.4050007@oracle.com>
References: <53EB7F4E.4050007@oracle.com>
Message-ID: <FB71560D-D5D7-4FAB-8FA3-BAA05784D49D@oracle.com>

+1

On Aug 13, 2014, at 5:07 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055034/
> 
> Thanks,
> -Sundar


From james.laskey at oracle.com  Wed Aug 13 15:32:52 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 13 Aug 2014 12:32:52 -0300
Subject: RFR 8055034: jjs exits interactive mode if exception was thrown
	when trying to print value of last evaluated expression
In-Reply-To: <FB71560D-D5D7-4FAB-8FA3-BAA05784D49D@oracle.com>
References: <53EB7F4E.4050007@oracle.com>
	<FB71560D-D5D7-4FAB-8FA3-BAA05784D49D@oracle.com>
Message-ID: <4D289ABC-CE10-4B59-9A43-243CF2B88A3F@oracle.com>

+1

On Aug 13, 2014, at 12:14 PM, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> +1
> 
> On Aug 13, 2014, at 5:07 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
>> Please review http://cr.openjdk.java.net/~sundar/8055034/
>> 
>> Thanks,
>> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Thu Aug 14 12:33:46 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 14 Aug 2014 18:03:46 +0530
Subject: RFR 8055107: Extension directives to turn on callsite profiling,
	tracing, AST print and other debug features locally
Message-ID: <53ECACAA.1090208@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055107/

Thanks
-Sundar

From sundararajan.athijegannathan at oracle.com  Thu Aug 14 14:41:59 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 14 Aug 2014 20:11:59 +0530
Subject: RFR 8055139: test/script/trusted/JDK-8055107.js fails with access
	control exception
Message-ID: <53ECCAB7.8010403@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055139/

-Sundar

From marcus.lagergren at oracle.com  Fri Aug 15 12:49:05 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 15 Aug 2014 14:49:05 +0200
Subject: RFR 8055139: test/script/trusted/JDK-8055107.js fails with access
	control exception
In-Reply-To: <53ECCAB7.8010403@oracle.com>
References: <53ECCAB7.8010403@oracle.com>
Message-ID: <01D016C0-5637-432D-8FDA-B3A99CBD14D5@oracle.com>

+1

On 14 Aug 2014, at 16:41, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055139/
> 
> -Sundar


From marcus.lagergren at oracle.com  Fri Aug 15 12:49:11 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 15 Aug 2014 14:49:11 +0200
Subject: RFR 8055107: Extension directives to turn on callsite profiling,
	tracing, AST print and other debug features locally
In-Reply-To: <53ECACAA.1090208@oracle.com>
References: <53ECACAA.1090208@oracle.com>
Message-ID: <C0A44F91-0F21-42EE-9C35-3AFC7C0B8844@oracle.com>

+1

On 14 Aug 2014, at 14:33, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055107/
> 
> Thanks
> -Sundar


From benjamin.john.evans at gmail.com  Fri Aug 15 13:07:13 2014
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Fri, 15 Aug 2014 14:07:13 +0100
Subject: RFR 8055107: Extension directives to turn on callsite profiling, 
	tracing, AST print and other debug features locally
In-Reply-To: <C0A44F91-0F21-42EE-9C35-3AFC7C0B8844@oracle.com>
References: <53ECACAA.1090208@oracle.com>
	<C0A44F91-0F21-42EE-9C35-3AFC7C0B8844@oracle.com>
Message-ID: <CABKW8RhNECaQ8tNh4DgE29DN6g51r489MyNqrMJM04CDUPOG-A@mail.gmail.com>

Is there any chance of having some of these features available as a
public (or public-ish) API for tool builders?

On Fri, Aug 15, 2014 at 1:49 PM, Marcus Lagergren
<marcus.lagergren at oracle.com> wrote:
> +1
>
> On 14 Aug 2014, at 14:33, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>
>> Please review http://cr.openjdk.java.net/~sundar/8055107/
>>
>> Thanks
>> -Sundar
>

From attila.szegedi at oracle.com  Fri Aug 15 13:37:48 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 15 Aug 2014 15:37:48 +0200
Subject: Review request for JDK-8055186
Message-ID: <71D25061-D752-4FDC-A39D-2E2BF165E7AE@oracle.com>

Please review JDK-8055186 at <http://cr.openjdk.java.net/~attila/8055186/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055186>

This is the patch for backporting of optimistic typing to the jdk8u repository. 

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Mon Aug 18 14:04:16 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 18 Aug 2014 19:34:16 +0530
Subject: Review request for JDK-8055186
In-Reply-To: <71D25061-D752-4FDC-A39D-2E2BF165E7AE@oracle.com>
References: <71D25061-D752-4FDC-A39D-2E2BF165E7AE@oracle.com>
Message-ID: <53F207E0.6020108@oracle.com>


+1

On Friday 15 August 2014 07:07 PM, Attila Szegedi wrote:
> Please review JDK-8055186 at <http://cr.openjdk.java.net/~attila/8055186/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055186>
>
> This is the patch for backporting of optimistic typing to the jdk8u repository.
>
> Thanks,
>    Attila.


From marcus.lagergren at oracle.com  Mon Aug 18 14:04:18 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 18 Aug 2014 16:04:18 +0200
Subject: Review request for JDK-8055186
In-Reply-To: <71D25061-D752-4FDC-A39D-2E2BF165E7AE@oracle.com>
References: <71D25061-D752-4FDC-A39D-2E2BF165E7AE@oracle.com>
Message-ID: <3AF3C7DE-A4F5-4A4F-8782-279A3C99C20E@oracle.com>

+1, on the condition that the bin directory issues that we had are resolved. The 8 bin dir looks more modern with old stuff pruned away. The only new script that we need to go back from 9 is runopt.sh.

/M

On 15 Aug 2014, at 15:37, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8055186 at <http://cr.openjdk.java.net/~attila/8055186/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055186>
> 
> This is the patch for backporting of optimistic typing to the jdk8u repository. 
> 
> Thanks,
>  Attila.


From james.laskey at oracle.com  Mon Aug 18 14:04:24 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Mon, 18 Aug 2014 11:04:24 -0300
Subject: Review request for JDK-8055186
In-Reply-To: <71D25061-D752-4FDC-A39D-2E2BF165E7AE@oracle.com>
References: <71D25061-D752-4FDC-A39D-2E2BF165E7AE@oracle.com>
Message-ID: <FB51B8F2-008D-4DBD-9DDD-3F07B6DC8823@oracle.com>

+1

On Aug 15, 2014, at 10:37 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8055186 at <http://cr.openjdk.java.net/~attila/8055186/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055186>
> 
> This is the patch for backporting of optimistic typing to the jdk8u repository. 
> 
> Thanks,
>  Attila.


From hannes.wallnoefer at oracle.com  Tue Aug 19 09:20:45 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 19 Aug 2014 11:20:45 +0200
Subject: Review request for JDK-8055368: Ant build broken after modular source
	code change
Message-ID: <53F316ED.5090500@oracle.com>

Please review JDK-8055368: Ant build broken after modular source code 
change:

http://cr.openjdk.java.net/~hannesw/8055368/

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Tue Aug 19 09:25:02 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 19 Aug 2014 14:55:02 +0530
Subject: Review request for JDK-8055368: Ant build broken after modular
	source code change
In-Reply-To: <53F316ED.5090500@oracle.com>
References: <53F316ED.5090500@oracle.com>
Message-ID: <53F317EE.4050201@oracle.com>

+1

On Tuesday 19 August 2014 02:50 PM, Hannes Wallnoefer wrote:
> Please review JDK-8055368: Ant build broken after modular source code 
> change:
>
> http://cr.openjdk.java.net/~hannesw/8055368/
>
> Thanks,
> Hannes


From attila.szegedi at oracle.com  Tue Aug 19 11:45:32 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 19 Aug 2014 13:45:32 +0200
Subject: Review request for JDK-8055368: Ant build broken after modular
	source code change
In-Reply-To: <53F317EE.4050201@oracle.com>
References: <53F316ED.5090500@oracle.com> <53F317EE.4050201@oracle.com>
Message-ID: <073F8570-5ED7-4CE7-9333-1E6665248F76@oracle.com>

+1

On Aug 19, 2014, at 11:25 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> +1
> 
> On Tuesday 19 August 2014 02:50 PM, Hannes Wallnoefer wrote:
>> Please review JDK-8055368: Ant build broken after modular source code change:
>> 
>> http://cr.openjdk.java.net/~hannesw/8055368/
>> 
>> Thanks,
>> Hannes
> 


From sundararajan.athijegannathan at oracle.com  Tue Aug 19 12:01:28 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 19 Aug 2014 17:31:28 +0530
Subject: RFR 8055395: Nashorn should use source, target to be 1.8 and use
	ASM5 version for generated code
Message-ID: <53F33C98.9040508@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055395/

Thanks
-Sundar

From james.laskey at oracle.com  Tue Aug 19 12:11:37 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 19 Aug 2014 09:11:37 -0300
Subject: RFR 8055395: Nashorn should use source,
	target to be 1.8 and use ASM5 version for generated code
In-Reply-To: <53F33C98.9040508@oracle.com>
References: <53F33C98.9040508@oracle.com>
Message-ID: <163A7B06-1FFF-4EB5-A1BA-89758365BA5E@oracle.com>

+1

On Aug 19, 2014, at 9:01 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055395/
> 
> Thanks
> -Sundar


From attila.szegedi at oracle.com  Wed Aug 20 08:09:45 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 20 Aug 2014 10:09:45 +0200
Subject: Please review incremental change for 8055186 / 8055529
Message-ID: <AC5E5030-F3E2-4D8C-B6BB-4592D727176A@oracle.com>

Please review <http://cr.openjdk.java.net/~attila/8055186/webrev.01> It's the incremental change for the backport that deals with the remarks we got from the maintainers. I also filed this as a separate issue <https://bugs.openjdk.java.net/browse/JDK-8055529> "Clean up the bin directory" that I'll apply to the 9 repo (I'll include it in the backport message too so JBS can track it in the backport).

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Wed Aug 20 08:11:40 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 20 Aug 2014 13:41:40 +0530
Subject: Please review incremental change for 8055186 / 8055529
In-Reply-To: <AC5E5030-F3E2-4D8C-B6BB-4592D727176A@oracle.com>
References: <AC5E5030-F3E2-4D8C-B6BB-4592D727176A@oracle.com>
Message-ID: <53F4583C.702@oracle.com>

+1

On Wednesday 20 August 2014 01:39 PM, Attila Szegedi wrote:
> Please review <http://cr.openjdk.java.net/~attila/8055186/webrev.01> It's the incremental change for the backport that deals with the remarks we got from the maintainers. I also filed this as a separate issue <https://bugs.openjdk.java.net/browse/JDK-8055529> "Clean up the bin directory" that I'll apply to the 9 repo (I'll include it in the backport message too so JBS can track it in the backport).
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Wed Aug 20 12:21:33 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 20 Aug 2014 17:51:33 +0530
Subject: [8u40] Approval request for 8050078: Nashorn ClassFilter Support
Message-ID: <53F492CD.2070705@oracle.com>


Hi nashorn-dev,

Please review the above webrev: http://cr.openjdk.java.net/~sundar/8050078/

Hi jdk8u-dev,

Please approve the following fix to 8u40.

Bug: https://bugs.openjdk.java.net/browse/JDK-8050078
JEP: http://openjdk.java.net/jeps/202
Webrev: http://cr.openjdk.java.net/~sundar/8050078/

PS. This change is pushed to 8u40 first. This will be pushed to 
jdk9-dev/nashorn shortly (after adjusting for the recent jdk modular 
source layout change)

Thanks,
-Sundar


From james.laskey at oracle.com  Wed Aug 20 12:24:05 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 20 Aug 2014 09:24:05 -0300
Subject: [8u40] Approval request for 8050078: Nashorn ClassFilter Support
In-Reply-To: <53F492CD.2070705@oracle.com>
References: <53F492CD.2070705@oracle.com>
Message-ID: <199D8E5D-5CFB-441E-802F-4704BEC1E6BB@oracle.com>

+1

On Aug 20, 2014, at 9:21 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> 
> Hi nashorn-dev,
> 
> Please review the above webrev: http://cr.openjdk.java.net/~sundar/8050078/
> 
> Hi jdk8u-dev,
> 
> Please approve the following fix to 8u40.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8050078
> JEP: http://openjdk.java.net/jeps/202
> Webrev: http://cr.openjdk.java.net/~sundar/8050078/
> 
> PS. This change is pushed to 8u40 first. This will be pushed to jdk9-dev/nashorn shortly (after adjusting for the recent jdk modular source layout change)
> 
> Thanks,
> -Sundar
> 


From marcus.lagergren at oracle.com  Wed Aug 20 12:25:18 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 20 Aug 2014 14:25:18 +0200
Subject: Please review incremental change for 8055186 / 8055529
In-Reply-To: <AC5E5030-F3E2-4D8C-B6BB-4592D727176A@oracle.com>
References: <AC5E5030-F3E2-4D8C-B6BB-4592D727176A@oracle.com>
Message-ID: <90EFE466-F9CE-43FF-A2B4-F22E28B97DC3@oracle.com>

+1

On 20 Aug 2014, at 10:09, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review <http://cr.openjdk.java.net/~attila/8055186/webrev.01> It's the incremental change for the backport that deals with the remarks we got from the maintainers. I also filed this as a separate issue <https://bugs.openjdk.java.net/browse/JDK-8055529> "Clean up the bin directory" that I'll apply to the 9 repo (I'll include it in the backport message too so JBS can track it in the backport).
> 
> Thanks,
>  Attila.


From hannes.wallnoefer at oracle.com  Wed Aug 20 12:29:17 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 20 Aug 2014 14:29:17 +0200
Subject: [8u40] Approval request for 8050078: Nashorn ClassFilter Support
In-Reply-To: <53F492CD.2070705@oracle.com>
References: <53F492CD.2070705@oracle.com>
Message-ID: <53F4949D.1000208@oracle.com>

+1

Am 2014-08-20 um 14:21 schrieb A. Sundararajan:
>
> Hi nashorn-dev,
>
> Please review the above webrev: 
> http://cr.openjdk.java.net/~sundar/8050078/
>
> Hi jdk8u-dev,
>
> Please approve the following fix to 8u40.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8050078
> JEP: http://openjdk.java.net/jeps/202
> Webrev: http://cr.openjdk.java.net/~sundar/8050078/
>
> PS. This change is pushed to 8u40 first. This will be pushed to 
> jdk9-dev/nashorn shortly (after adjusting for the recent jdk modular 
> source layout change)
>
> Thanks,
> -Sundar
>


From marcus.lagergren at oracle.com  Wed Aug 20 12:29:57 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 20 Aug 2014 14:29:57 +0200
Subject: [8u40] Approval request for 8050078: Nashorn ClassFilter Support
In-Reply-To: <53F492CD.2070705@oracle.com>
References: <53F492CD.2070705@oracle.com>
Message-ID: <FEDEDC57-6623-4260-B530-C54FAEDADDCE@oracle.com>

+1

On 20 Aug 2014, at 14:21, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> 
> Hi nashorn-dev,
> 
> Please review the above webrev: http://cr.openjdk.java.net/~sundar/8050078/
> 
> Hi jdk8u-dev,
> 
> Please approve the following fix to 8u40.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8050078
> JEP: http://openjdk.java.net/jeps/202
> Webrev: http://cr.openjdk.java.net/~sundar/8050078/
> 
> PS. This change is pushed to 8u40 first. This will be pushed to jdk9-dev/nashorn shortly (after adjusting for the recent jdk modular source layout change)
> 
> Thanks,
> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Wed Aug 20 14:06:22 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 20 Aug 2014 19:36:22 +0530
Subject: RFR 8050078: Nashorn ClassFilter Support [jdk9 forward port]
Message-ID: <53F4AB5E.50006@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8050078/9/

This is forward port of the same fix in jdk8u40. No change other than 
the source directory change in jdk9.

-Sundar

From hannes.wallnoefer at oracle.com  Wed Aug 20 14:14:26 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 20 Aug 2014 16:14:26 +0200
Subject: RFR 8050078: Nashorn ClassFilter Support [jdk9 forward port]
In-Reply-To: <53F4AB5E.50006@oracle.com>
References: <53F4AB5E.50006@oracle.com>
Message-ID: <53F4AD42.8000109@oracle.com>

+1

Am 2014-08-20 um 16:06 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8050078/9/
>
> This is forward port of the same fix in jdk8u40. No change other than 
> the source directory change in jdk9.
>
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Aug 20 15:44:17 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 20 Aug 2014 21:14:17 +0530
Subject: RFR 8055687: Wrong "this" passed to JSObject.eval call
Message-ID: <53F4C251.2070404@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055687/

PS. piggybacking a sample and a fix in previous sample.

Thanks
-Sundar

From hannes.wallnoefer at oracle.com  Wed Aug 20 15:49:10 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 20 Aug 2014 17:49:10 +0200
Subject: RFR 8055687: Wrong "this" passed to JSObject.eval call
In-Reply-To: <53F4C251.2070404@oracle.com>
References: <53F4C251.2070404@oracle.com>
Message-ID: <53F4C376.3030701@oracle.com>

+1

Am 2014-08-20 um 17:44 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8055687/
>
> PS. piggybacking a sample and a fix in previous sample.
>
> Thanks
> -Sundar


From attila.szegedi at oracle.com  Wed Aug 20 15:49:23 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 20 Aug 2014 17:49:23 +0200
Subject: RFR 8055687: Wrong "this" passed to JSObject.eval call
In-Reply-To: <53F4C251.2070404@oracle.com>
References: <53F4C251.2070404@oracle.com>
Message-ID: <A884E513-7B0B-47C8-B5D3-23EEC4E8ECF0@oracle.com>

+1

On Aug 20, 2014, at 5:44 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055687/
> 
> PS. piggybacking a sample and a fix in previous sample.
> 
> Thanks
> -Sundar


From james.laskey at oracle.com  Wed Aug 20 15:52:12 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 20 Aug 2014 12:52:12 -0300
Subject: RFR 8055687: Wrong "this" passed to JSObject.eval call
In-Reply-To: <53F4C251.2070404@oracle.com>
References: <53F4C251.2070404@oracle.com>
Message-ID: <B8152301-3D52-4823-973D-E0DAFEEAAFB9@oracle.com>

+1

On Aug 20, 2014, at 12:44 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055687/
> 
> PS. piggybacking a sample and a fix in previous sample.
> 
> Thanks
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Aug 20 16:52:58 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 20 Aug 2014 22:22:58 +0530
Subject: [8u40] Please approve 8055687: Wrong "this" passed to JSObject.eval
	call
Message-ID: <53F4D26A.4020706@oracle.com>

Please approve backport of  8055687: Wrong "this" passed to 
JSObject.eval call

jdk9 webrev: http://cr.openjdk.java.net/~sundar/8055687/webrev.00/
jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3516182f0612
jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8055687/8u40/webrev.00/

* changes for source layout
* adding a sample to jdk8u (from jdk9)

Thanks
-Sundar

From sean.coffey at oracle.com  Wed Aug 20 21:11:17 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Wed, 20 Aug 2014 22:11:17 +0100
Subject: [8u40] Please approve 8055687: Wrong "this" passed to
	JSObject.eval call
In-Reply-To: <53F4D26A.4020706@oracle.com>
References: <53F4D26A.4020706@oracle.com>
Message-ID: <53F50EF5.1000702@oracle.com>

JDK 9 review thread : 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003282.html

Approved but pending a peer review for 8u changes.

regards,
Sean.

On 20/08/14 17:52, A. Sundararajan wrote:
> Please approve backport of  8055687: Wrong "this" passed to 
> JSObject.eval call
>
> jdk9 webrev: http://cr.openjdk.java.net/~sundar/8055687/webrev.00/
> jdk9 changeset: 
> http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3516182f0612
> jdk8u-dev webrev: 
> http://cr.openjdk.java.net/~sundar/8055687/8u40/webrev.00/
>
> * changes for source layout
> * adding a sample to jdk8u (from jdk9)
>
> Thanks
> -Sundar


From sundararajan.athijegannathan at oracle.com  Thu Aug 21 03:23:22 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 21 Aug 2014 08:53:22 +0530
Subject: [8u40] Please approve 8055687: Wrong "this" passed to
	JSObject.eval call
In-Reply-To: <53F50EF5.1000702@oracle.com>
References: <53F4D26A.4020706@oracle.com> <53F50EF5.1000702@oracle.com>
Message-ID: <53F5662A.6020505@oracle.com>

Hi Sean,

Thanks! Actually, I had to adjust 8u40 webrev to avoid backporting 
find_nonfinals.js sample script (which requires target 8 compilation 
with -parameters flag - which is enabled only in jdk9 nashorn build!).

Hi Nashorn folks,

Please review updated jdk8u40 webrev @ 
http://cr.openjdk.java.net/~sundar/8055687/8u40/webrev.01/

Thanks,
-Sundar

On Thursday 21 August 2014 02:41 AM, Se?n Coffey wrote:
> JDK 9 review thread : 
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003282.html
>
> Approved but pending a peer review for 8u changes.
>
> regards,
> Sean.
>
> On 20/08/14 17:52, A. Sundararajan wrote:
>> Please approve backport of  8055687: Wrong "this" passed to 
>> JSObject.eval call
>>
>> jdk9 webrev: http://cr.openjdk.java.net/~sundar/8055687/webrev.00/
>> jdk9 changeset: 
>> http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3516182f0612
>> jdk8u-dev webrev: 
>> http://cr.openjdk.java.net/~sundar/8055687/8u40/webrev.00/
>>
>> * changes for source layout
>> * adding a sample to jdk8u (from jdk9)
>>
>> Thanks
>> -Sundar
>


From hannes.wallnoefer at oracle.com  Thu Aug 21 08:24:33 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 21 Aug 2014 10:24:33 +0200
Subject: [8u40] Please approve 8055687: Wrong "this" passed to
	JSObject.eval call
In-Reply-To: <53F5662A.6020505@oracle.com>
References: <53F4D26A.4020706@oracle.com> <53F50EF5.1000702@oracle.com>
	<53F5662A.6020505@oracle.com>
Message-ID: <53F5ACC1.205@oracle.com>

+1

Am 2014-08-21 um 05:23 schrieb A. Sundararajan:
> Hi Sean,
>
> Thanks! Actually, I had to adjust 8u40 webrev to avoid backporting 
> find_nonfinals.js sample script (which requires target 8 compilation 
> with -parameters flag - which is enabled only in jdk9 nashorn build!).
>
> Hi Nashorn folks,
>
> Please review updated jdk8u40 webrev @ 
> http://cr.openjdk.java.net/~sundar/8055687/8u40/webrev.01/
>
> Thanks,
> -Sundar
>
> On Thursday 21 August 2014 02:41 AM, Se?n Coffey wrote:
>> JDK 9 review thread : 
>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003282.html
>>
>> Approved but pending a peer review for 8u changes.
>>
>> regards,
>> Sean.
>>
>> On 20/08/14 17:52, A. Sundararajan wrote:
>>> Please approve backport of  8055687: Wrong "this" passed to 
>>> JSObject.eval call
>>>
>>> jdk9 webrev: http://cr.openjdk.java.net/~sundar/8055687/webrev.00/
>>> jdk9 changeset: 
>>> http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3516182f0612
>>> jdk8u-dev webrev: 
>>> http://cr.openjdk.java.net/~sundar/8055687/8u40/webrev.00/
>>>
>>> * changes for source layout
>>> * adding a sample to jdk8u (from jdk9)
>>>
>>> Thanks
>>> -Sundar
>>
>


From james.laskey at oracle.com  Thu Aug 21 12:12:52 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 21 Aug 2014 09:12:52 -0300
Subject: [8u40] Please approve 8055687: Wrong "this" passed to
	JSObject.eval call
In-Reply-To: <53F50EF5.1000702@oracle.com>
References: <53F4D26A.4020706@oracle.com> <53F50EF5.1000702@oracle.com>
Message-ID: <DB4BACCA-3821-4E94-80C8-0741B73C9264@oracle.com>

+1

On Aug 20, 2014, at 6:11 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:

> JDK 9 review thread : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003282.html
> 
> Approved but pending a peer review for 8u changes.
> 
> regards,
> Sean.
> 
> On 20/08/14 17:52, A. Sundararajan wrote:
>> Please approve backport of  8055687: Wrong "this" passed to JSObject.eval call
>> 
>> jdk9 webrev: http://cr.openjdk.java.net/~sundar/8055687/webrev.00/
>> jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3516182f0612
>> jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8055687/8u40/webrev.00/
>> 
>> * changes for source layout
>> * adding a sample to jdk8u (from jdk9)
>> 
>> Thanks
>> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Thu Aug 21 14:24:03 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 21 Aug 2014 19:54:03 +0530
Subject: RFR 8055762: Nashorn misses linker for netscape.javascript.JSObject
	instances
Message-ID: <53F60103.8050200@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055762/

Thanks
-Sundar

From james.laskey at oracle.com  Thu Aug 21 15:38:32 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 21 Aug 2014 12:38:32 -0300
Subject: RFR 8055762: Nashorn misses linker for
	netscape.javascript.JSObject instances
In-Reply-To: <53F60103.8050200@oracle.com>
References: <53F60103.8050200@oracle.com>
Message-ID: <37C0406A-892A-49D4-9E9F-D19B9B9649D4@oracle.com>

+1

On Aug 21, 2014, at 11:24 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055762/
> 
> Thanks
> -Sundar


From sundararajan.athijegannathan at oracle.com  Fri Aug 22 05:30:24 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 22 Aug 2014 11:00:24 +0530
Subject: RFR 8055796: JSObject and browser JSObject linkers should provide
	fallback to call underlying Java methods directly
Message-ID: <53F6D570.5040905@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055796/

Thanks,
-Sundar

From sundararajan.athijegannathan at oracle.com  Fri Aug 22 09:11:38 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 22 Aug 2014 14:41:38 +0530
Subject: RFR 8055796: JSObject and browser JSObject linkers should provide
	fallback to call underlying Java methods directly
In-Reply-To: <53F6D570.5040905@oracle.com>
References: <53F6D570.5040905@oracle.com>
Message-ID: <53F7094A.6010001@oracle.com>

Please ignore earlier webrev. Please review updated one @ 
http://cr.openjdk.java.net/~sundar/8055796/webrev.01/

Thanks
-Sundar

On Friday 22 August 2014 11:00 AM, A. Sundararajan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8055796/
>
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Fri Aug 22 09:39:32 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 22 Aug 2014 11:39:32 +0200
Subject: RFR 8055796: JSObject and browser JSObject linkers should provide
	fallback to call underlying Java methods directly
In-Reply-To: <53F7094A.6010001@oracle.com>
References: <53F6D570.5040905@oracle.com> <53F7094A.6010001@oracle.com>
Message-ID: <3AA5B628-DCD0-4DFC-846A-6EA4EAB25E05@oracle.com>

+1

On Aug 22, 2014, at 11:11 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please ignore earlier webrev. Please review updated one @ http://cr.openjdk.java.net/~sundar/8055796/webrev.01/
> 
> Thanks
> -Sundar
> 
> On Friday 22 August 2014 11:00 AM, A. Sundararajan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8055796/
>> 
>> Thanks,
>> -Sundar
> 


From hannes.wallnoefer at oracle.com  Fri Aug 22 10:01:45 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 22 Aug 2014 12:01:45 +0200
Subject: RFR 8055796: JSObject and browser JSObject linkers should provide
	fallback to call underlying Java methods directly
In-Reply-To: <53F7094A.6010001@oracle.com>
References: <53F6D570.5040905@oracle.com> <53F7094A.6010001@oracle.com>
Message-ID: <53F71509.6090809@oracle.com>

+1

I don't like the fact that this will shadow property names containing 
'(' but I think it's an acceptable compromise.

Hannes

Am 2014-08-22 um 11:11 schrieb A. Sundararajan:
> Please ignore earlier webrev. Please review updated one @ 
> http://cr.openjdk.java.net/~sundar/8055796/webrev.01/
>
> Thanks
> -Sundar
>
> On Friday 22 August 2014 11:00 AM, A. Sundararajan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8055796/
>>
>> Thanks,
>> -Sundar
>


From sundararajan.athijegannathan at oracle.com  Fri Aug 22 10:29:05 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 22 Aug 2014 15:59:05 +0530
Subject: RFR 8055796: JSObject and browser JSObject linkers should provide
	fallback to call underlying Java methods directly
In-Reply-To: <53F71509.6090809@oracle.com>
References: <53F6D570.5040905@oracle.com> <53F7094A.6010001@oracle.com>
	<53F71509.6090809@oracle.com>
Message-ID: <53F71B71.3050002@oracle.com>

Yes, such properties are shadowed - but user can retrieve the value of 
such properties using

     var x = obj["getMember(String)"]('foo()');

Thanks
-Sundar


On Friday 22 August 2014 03:31 PM, Hannes Wallnoefer wrote:
> +1
>
> I don't like the fact that this will shadow property names containing 
> '(' but I think it's an acceptable compromise.
>
> Hannes
>
> Am 2014-08-22 um 11:11 schrieb A. Sundararajan:
>> Please ignore earlier webrev. Please review updated one @ 
>> http://cr.openjdk.java.net/~sundar/8055796/webrev.01/
>>
>> Thanks
>> -Sundar
>>
>> On Friday 22 August 2014 11:00 AM, A. Sundararajan wrote:
>>> Please review http://cr.openjdk.java.net/~sundar/8055796/
>>>
>>> Thanks,
>>> -Sundar
>>
>


From sundararajan.athijegannathan at oracle.com  Fri Aug 22 10:46:48 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 22 Aug 2014 16:16:48 +0530
Subject: [8u40] approval request for 8055762: Nashorn misses linker for
	netscape.javascript.JSObject instances
Message-ID: <53F71F98.2020602@oracle.com>

Hi,

Please approve.

Bug: https://bugs.openjdk.java.net/browse/JDK-8055762
jdk9 review thread: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003291.html
jdk8u40 webrev: http://cr.openjdk.java.net/~sundar/8055762/8u40/

8u40 webrev is same as jdk9 webrev except for modular source directory 
change in jdk9.

Thanks,
-Sundar

From sean.coffey at oracle.com  Fri Aug 22 11:01:23 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Fri, 22 Aug 2014 12:01:23 +0100
Subject: [8u40] approval request for 8055762: Nashorn misses linker for
	netscape.javascript.JSObject instances
In-Reply-To: <53F71F98.2020602@oracle.com>
References: <53F71F98.2020602@oracle.com>
Message-ID: <53F72303.3090003@oracle.com>

Approved.

regards,
Sean.

On 22/08/14 11:46, A. Sundararajan wrote:
> Hi,
>
> Please approve.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8055762
> jdk9 review thread: 
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003291.html
> jdk8u40 webrev: http://cr.openjdk.java.net/~sundar/8055762/8u40/
>
> 8u40 webrev is same as jdk9 webrev except for modular source directory 
> change in jdk9.
>
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Fri Aug 22 11:22:45 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 22 Aug 2014 16:52:45 +0530
Subject: [8u40] approval request for 8055796: JSObject and browser JSObject
	linkers should provide fallback to call underlying Java methods
	directly
Message-ID: <53F72805.9010300@oracle.com>

Hi,

Please approve.

Bug: https://bugs.openjdk.java.net/browse/JDK-8055796
jdk9 review thread: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003293.html
jdk8u40 webrev: http://cr.openjdk.java.net/~sundar/8055796/8u40/

8u40 webrev is same as jdk9 webrev except for modular source directory 
change in jdk9.

Thanks,
-Sundar

From sean.coffey at oracle.com  Fri Aug 22 11:23:47 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Fri, 22 Aug 2014 12:23:47 +0100
Subject: [8u40] approval request for 8055796: JSObject and browser JSObject
	linkers should provide fallback to call underlying Java methods
	directly
In-Reply-To: <53F72805.9010300@oracle.com>
References: <53F72805.9010300@oracle.com>
Message-ID: <53F72843.6070302@oracle.com>

Approved.

regards,
Sean.

On 22/08/14 12:22, A. Sundararajan wrote:
> Hi,
>
> Please approve.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8055796
> jdk9 review thread: 
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003293.html
> jdk8u40 webrev: http://cr.openjdk.java.net/~sundar/8055796/8u40/
>
> 8u40 webrev is same as jdk9 webrev except for modular source directory 
> change in jdk9.
>
> Thanks,
> -Sundar


From marcus.lagergren at oracle.com  Fri Aug 22 16:54:24 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 22 Aug 2014 18:54:24 +0200
Subject: RFR 8050078: Nashorn ClassFilter Support [jdk9 forward port]
In-Reply-To: <53F4AB5E.50006@oracle.com>
References: <53F4AB5E.50006@oracle.com>
Message-ID: <81CE1FC3-7430-42B8-818B-3BE21A072609@oracle.com>

+1

On 20 Aug 2014, at 16:06, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8050078/9/
> 
> This is forward port of the same fix in jdk8u40. No change other than the source directory change in jdk9.
> 
> -Sundar


From marcus.lagergren at oracle.com  Fri Aug 22 16:54:51 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 22 Aug 2014 18:54:51 +0200
Subject: RFR 8055762: Nashorn misses linker for
	netscape.javascript.JSObject instances
In-Reply-To: <53F60103.8050200@oracle.com>
References: <53F60103.8050200@oracle.com>
Message-ID: <369D6E49-A1A8-4EDA-8E58-873B7F4EFC33@oracle.com>

+1

On 21 Aug 2014, at 16:24, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055762/
> 
> Thanks
> -Sundar


From sundararajan.athijegannathan at oracle.com  Fri Aug 22 17:12:32 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 22 Aug 2014 22:42:32 +0530
Subject: RFR 8055830: JDK-8015969.js is silently failing
Message-ID: <53F77A00.1030403@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055830/

Thanks
-Sundar

From james.laskey at oracle.com  Fri Aug 22 17:37:13 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 22 Aug 2014 14:37:13 -0300
Subject: RFR 8055830: JDK-8015969.js is silently failing
In-Reply-To: <53F77A00.1030403@oracle.com>
References: <53F77A00.1030403@oracle.com>
Message-ID: <00D07EB6-3C42-400E-955C-6872EB52C00E@oracle.com>

+1

On Aug 22, 2014, at 2:12 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055830/
> 
> Thanks
> -Sundar


From marcus.lagergren at oracle.com  Sun Aug 24 16:15:44 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Sun, 24 Aug 2014 18:15:44 +0200
Subject: RFR 8055830: JDK-8015969.js is silently failing
In-Reply-To: <53F77A00.1030403@oracle.com>
References: <53F77A00.1030403@oracle.com>
Message-ID: <01436E70-91F6-4A07-94A1-F58D3148B9AF@oracle.com>

+1

On 22 Aug 2014, at 19:12, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055830/
> 
> Thanks
> -Sundar


From tal.liron at threecrickets.com  Mon Aug 25 04:26:56 2014
From: tal.liron at threecrickets.com (Tal Liron)
Date: Mon, 25 Aug 2014 12:26:56 +0800
Subject: Bug report: iteration on dicts fails if index var is not used
Message-ID: <53FABB10.6020702@threecrickets.com>

Sorry for using the mailing list, still unclear for me how to open 
Nashorn bugs (the standard form in bugreport.java.com does not have a 
"nashorn" subcategory). The bug is on trunk in 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn.

The following program will cause an exception when "isEmpty2" is called:

   Error: java.lang.ClassCastException: java.lang.String cannot be cast 
to jdk.nashorn.internal.runtime.Undefined

The only difference between isEmpty1 and isEmpty2 is the actual use of 
"k". If "k" is not referenced, the exception happens.


function isEmpty1(v) {
   for (var k in v) {
     print(v[k]+'\n')
     return false
   }
   return true
}

function isEmpty2(v) {
   for (var k in v) {
     return false
   }
   return true
}

x = {test: 'test'}

isEmpty1(x)
isEmpty2(x)


From attila.szegedi at oracle.com  Mon Aug 25 08:47:45 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 25 Aug 2014 10:47:45 +0200
Subject: Bug report: iteration on dicts fails if index var is not used
In-Reply-To: <53FABB10.6020702@threecrickets.com>
References: <53FABB10.6020702@threecrickets.com>
Message-ID: <B2C4D62F-04AE-4CAF-BFC2-90C0D3C75469@oracle.com>

Thanks, I recorded this as <https://bugs.openjdk.java.net/browse/JDK-8055870> It seems to be related to the static local variable type inference logic that I'm responsible for. I'll look into this ASAP. We just pushed a backport of JDK 9 optimistic typing feature to 8u-dev, and local static type inference is part of that.

I'll also try to figure out internally who's resposible for the bugreport page and see to it that a "Nashorn" subcategory gets added.

Attila.

On Aug 25, 2014, at 6:26 AM, Tal Liron <tal.liron at threecrickets.com> wrote:

> Sorry for using the mailing list, still unclear for me how to open Nashorn bugs (the standard form in bugreport.java.com does not have a "nashorn" subcategory). The bug is on trunk in http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn.
> 
> The following program will cause an exception when "isEmpty2" is called:
> 
>  Error: java.lang.ClassCastException: java.lang.String cannot be cast to jdk.nashorn.internal.runtime.Undefined
> 
> The only difference between isEmpty1 and isEmpty2 is the actual use of "k". If "k" is not referenced, the exception happens.
> 
> 
> function isEmpty1(v) {
>  for (var k in v) {
>    print(v[k]+'\n')
>    return false
>  }
>  return true
> }
> 
> function isEmpty2(v) {
>  for (var k in v) {
>    return false
>  }
>  return true
> }
> 
> x = {test: 'test'}
> 
> isEmpty1(x)
> isEmpty2(x)
> 


From sergey.lugovoy at oracle.com  Mon Aug 25 09:55:59 2014
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Mon, 25 Aug 2014 13:55:59 +0400
Subject: RFR 8055878: All tests failed with AccessControlException
Message-ID: <53FB082F.6010208@oracle.com>

Please review http://cr.openjdk.java.net/~yan/8055878/webrev.00

-- 
Thanks,
Sergey


From sundararajan.athijegannathan at oracle.com  Mon Aug 25 12:02:28 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 25 Aug 2014 17:32:28 +0530
Subject: RFR 8055878: All tests failed with AccessControlException
In-Reply-To: <53FB082F.6010208@oracle.com>
References: <53FB082F.6010208@oracle.com>
Message-ID: <53FB25D4.5070006@oracle.com>

+1

Policy file generated indeed is wrong..

PS. I wonder why it didn't (and does not!) fail for us locally with 
tip... Something strange..

-Sundar

On Monday 25 August 2014 03:25 PM, Sergey Lugovoy wrote:
> Please review http://cr.openjdk.java.net/~yan/8055878/webrev.00
>


From hannes.wallnoefer at oracle.com  Mon Aug 25 12:28:28 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 25 Aug 2014 14:28:28 +0200
Subject: RFR 8055878: All tests failed with AccessControlException
In-Reply-To: <53FB082F.6010208@oracle.com>
References: <53FB082F.6010208@oracle.com>
Message-ID: <53FB2BEC.8040108@oracle.com>

Looks good.

Hannes

Am 2014-08-25 um 11:55 schrieb Sergey Lugovoy:
> Please review http://cr.openjdk.java.net/~yan/8055878/webrev.00
>


From sergey.lugovoy at oracle.com  Mon Aug 25 13:06:46 2014
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Mon, 25 Aug 2014 17:06:46 +0400
Subject: RFR 8055811 Tests for Nashorn ClassFilter Support
Message-ID: <53FB34E6.1060709@oracle.com>

Please review   http://cr.openjdk.java.net/~yan/8055811/webrev.00/

Bug : https://bugs.openjdk.java.net/browse/JDK-8055811
SQE Test plan: https://bugs.openjdk.java.net/browse/JDK-8050967
JEP : https://bugs.openjdk.java.net/browse/JDK-8043717

-- 
Thanks,
Sergey


From sundararajan.athijegannathan at oracle.com  Mon Aug 25 13:16:05 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 25 Aug 2014 18:46:05 +0530
Subject: RFR 8055811 Tests for Nashorn ClassFilter Support
In-Reply-To: <53FB34E6.1060709@oracle.com>
References: <53FB34E6.1060709@oracle.com>
Message-ID: <53FB3715.8040606@oracle.com>

+1

On Monday 25 August 2014 06:36 PM, Sergey Lugovoy wrote:
> Please review   http://cr.openjdk.java.net/~yan/8055811/webrev.00/
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8055811
> SQE Test plan: https://bugs.openjdk.java.net/browse/JDK-8050967
> JEP : https://bugs.openjdk.java.net/browse/JDK-8043717
>


From attila.szegedi at oracle.com  Mon Aug 25 13:29:43 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 25 Aug 2014 15:29:43 +0200
Subject: RFR 8055811 Tests for Nashorn ClassFilter Support
In-Reply-To: <53FB3715.8040606@oracle.com>
References: <53FB34E6.1060709@oracle.com> <53FB3715.8040606@oracle.com>
Message-ID: <46FB1E67-D787-45CA-957E-AF962BAB1290@oracle.com>

+1

On Aug 25, 2014, at 3:16 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> +1
> 
> On Monday 25 August 2014 06:36 PM, Sergey Lugovoy wrote:
>> Please review   http://cr.openjdk.java.net/~yan/8055811/webrev.00/
>> 
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8055811
>> SQE Test plan: https://bugs.openjdk.java.net/browse/JDK-8050967
>> JEP : https://bugs.openjdk.java.net/browse/JDK-8043717
>> 
> 


From sundararajan.athijegannathan at oracle.com  Mon Aug 25 14:15:30 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 25 Aug 2014 19:45:30 +0530
Subject: RFR 8055899: Two nashorn tests fail in 8u40 nightly build with
	ClassNotFoundException
Message-ID: <53FB4502.9010000@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8055899/

Although I can't reproduce the ClassNotFoundException in my environment, 
I can see why it could fail where javafx is missing. or jfxrt.jar does 
not contain netscape.javascript.JSObject class. Modified tests to 
vacuously pass in case this class is missing.

Thanks,
-Sundar

From james.laskey at oracle.com  Mon Aug 25 14:18:27 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Mon, 25 Aug 2014 11:18:27 -0300
Subject: RFR 8055899: Two nashorn tests fail in 8u40 nightly build with
	ClassNotFoundException
In-Reply-To: <53FB4502.9010000@oracle.com>
References: <53FB4502.9010000@oracle.com>
Message-ID: <EEECCF36-976D-4E12-809C-885F4AA8BD3E@oracle.com>

+1

On Aug 25, 2014, at 11:15 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8055899/
> 
> Although I can't reproduce the ClassNotFoundException in my environment, I can see why it could fail where javafx is missing. or jfxrt.jar does not contain netscape.javascript.JSObject class. Modified tests to vacuously pass in case this class is missing.
> 
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Mon Aug 25 15:16:12 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 25 Aug 2014 17:16:12 +0200
Subject: Review request for JDK-8055870
Message-ID: <79FFB644-0769-4F61-B829-FA0680FE0727@oracle.com>

Please review JDK-8055870 at <http://cr.openjdk.java.net/~attila/8055870/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055870>


Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Mon Aug 25 15:25:56 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 25 Aug 2014 17:25:56 +0200
Subject: Review request for JDK-8055870
In-Reply-To: <79FFB644-0769-4F61-B829-FA0680FE0727@oracle.com>
References: <79FFB644-0769-4F61-B829-FA0680FE0727@oracle.com>
Message-ID: <53FB5584.5050402@oracle.com>

+1

Am 2014-08-25 um 17:16 schrieb Attila Szegedi:
> Please review JDK-8055870 at <http://cr.openjdk.java.net/~attila/8055870/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055870>
>
>
> Thanks,
>    Attila.


From attila.szegedi at oracle.com  Mon Aug 25 16:05:46 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 25 Aug 2014 18:05:46 +0200
Subject: Review request for JDK-8055911
Message-ID: <50832ECD-2B11-4FF4-8C7A-E413D9925EDD@oracle.com>

Please review JDK-8055911 at <http://cr.openjdk.java.net/~attila/8055911/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055911>

Thanks,
  Attila.

From attila.szegedi at oracle.com  Mon Aug 25 16:21:06 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 25 Aug 2014 18:21:06 +0200
Subject: Review request for JDK-8055913
Message-ID: <9EFF0C4B-2190-4AEE-A29F-9F66C43DA419@oracle.com>

Please review JDK-8055913 at <http://cr.openjdk.java.net/~attila/8055913/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055913>

Thanks,
  Attila.

From marcus.lagergren at oracle.com  Mon Aug 25 18:23:49 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 25 Aug 2014 20:23:49 +0200
Subject: Review request for JDK-8055870
In-Reply-To: <79FFB644-0769-4F61-B829-FA0680FE0727@oracle.com>
References: <79FFB644-0769-4F61-B829-FA0680FE0727@oracle.com>
Message-ID: <0AA02464-63A3-467B-8430-0DA084ADEC7B@oracle.com>

+1

On 25 Aug 2014, at 17:16, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8055870 at <http://cr.openjdk.java.net/~attila/8055870/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055870>
> 
> 
> Thanks,
>  Attila.


From marcus.lagergren at oracle.com  Mon Aug 25 18:24:04 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 25 Aug 2014 20:24:04 +0200
Subject: Review request for JDK-8055911
In-Reply-To: <50832ECD-2B11-4FF4-8C7A-E413D9925EDD@oracle.com>
References: <50832ECD-2B11-4FF4-8C7A-E413D9925EDD@oracle.com>
Message-ID: <0640A5FE-0D43-4219-BFAA-8AD61D4F921D@oracle.com>

+1

On 25 Aug 2014, at 18:05, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8055911 at <http://cr.openjdk.java.net/~attila/8055911/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055911>
> 
> Thanks,
>  Attila.


From marcus.lagergren at oracle.com  Mon Aug 25 18:27:39 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 25 Aug 2014 20:27:39 +0200
Subject: Review request for JDK-8055913
In-Reply-To: <9EFF0C4B-2190-4AEE-A29F-9F66C43DA419@oracle.com>
References: <9EFF0C4B-2190-4AEE-A29F-9F66C43DA419@oracle.com>
Message-ID: <A1A66A0E-9DFA-4A5B-A2B0-347AA1655A43@oracle.com>

+1

On 25 Aug 2014, at 18:21, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8055913 at <http://cr.openjdk.java.net/~attila/8055913/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055913>
> 
> Thanks,
>  Attila.


From sundararajan.athijegannathan at oracle.com  Tue Aug 26 02:58:51 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 26 Aug 2014 08:28:51 +0530
Subject: Review request for JDK-8055911
In-Reply-To: <50832ECD-2B11-4FF4-8C7A-E413D9925EDD@oracle.com>
References: <50832ECD-2B11-4FF4-8C7A-E413D9925EDD@oracle.com>
Message-ID: <53FBF7EB.7020908@oracle.com>

+1

-Sundar

On Monday 25 August 2014 09:35 PM, Attila Szegedi wrote:
> Please review JDK-8055911 at <http://cr.openjdk.java.net/~attila/8055911/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055911>
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Tue Aug 26 02:59:44 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 26 Aug 2014 08:29:44 +0530
Subject: Review request for JDK-8055913
In-Reply-To: <9EFF0C4B-2190-4AEE-A29F-9F66C43DA419@oracle.com>
References: <9EFF0C4B-2190-4AEE-A29F-9F66C43DA419@oracle.com>
Message-ID: <53FBF820.3050007@oracle.com>

+1

PS. do we need to revisit other equals, hashCode cases? A script to 
check perhaps?

-Sundar

On Monday 25 August 2014 09:51 PM, Attila Szegedi wrote:
> Please review JDK-8055913 at <http://cr.openjdk.java.net/~attila/8055913/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055913>
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Tue Aug 26 03:01:26 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 26 Aug 2014 08:31:26 +0530
Subject: Review request for JDK-8055870
In-Reply-To: <79FFB644-0769-4F61-B829-FA0680FE0727@oracle.com>
References: <79FFB644-0769-4F61-B829-FA0680FE0727@oracle.com>
Message-ID: <53FBF886.4080509@oracle.com>

+1

-Sundar

On Monday 25 August 2014 08:46 PM, Attila Szegedi wrote:
> Please review JDK-8055870 at <http://cr.openjdk.java.net/~attila/8055870/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055870>
>
>
> Thanks,
>    Attila.


From attila.szegedi at oracle.com  Tue Aug 26 09:28:29 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 26 Aug 2014 11:28:29 +0200
Subject: Review request for JDK-8055923
Message-ID: <CDC8323D-0DD6-449C-A0D0-4BAD1448FE76@oracle.com>

Please review JDK-8055923 at <http://cr.openjdk.java.net/~attila/8055923/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055923>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Tue Aug 26 09:45:23 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 26 Aug 2014 11:45:23 +0200
Subject: Review request for JDK-8055923
In-Reply-To: <CDC8323D-0DD6-449C-A0D0-4BAD1448FE76@oracle.com>
References: <CDC8323D-0DD6-449C-A0D0-4BAD1448FE76@oracle.com>
Message-ID: <53FC5733.50108@oracle.com>

Looks good.

Hannes

Am 2014-08-26 um 11:28 schrieb Attila Szegedi:
> Please review JDK-8055923 at <http://cr.openjdk.java.net/~attila/8055923/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055923>
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Tue Aug 26 10:18:53 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 26 Aug 2014 15:48:53 +0530
Subject: Review request for JDK-8055923
In-Reply-To: <CDC8323D-0DD6-449C-A0D0-4BAD1448FE76@oracle.com>
References: <CDC8323D-0DD6-449C-A0D0-4BAD1448FE76@oracle.com>
Message-ID: <53FC5F0D.3050604@oracle.com>

+1

-Sundar

On Tuesday 26 August 2014 02:58 PM, Attila Szegedi wrote:
> Please review JDK-8055923 at <http://cr.openjdk.java.net/~attila/8055923/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055923>
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Tue Aug 26 10:42:29 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 26 Aug 2014 16:12:29 +0530
Subject: RFR 8056050: runExternalJsTest method in
	test/jdk/nashorn/internal/runtime/ClassFilter.java
	slows down "ant test"
Message-ID: <53FC6495.5090005@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8056050/

Thanks
-Sundar

From sergey.lugovoy at oracle.com  Tue Aug 26 11:00:07 2014
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Tue, 26 Aug 2014 15:00:07 +0400
Subject: [9] Please approve JDK-8055811: Tests for Nashorn ClassFilter Support
Message-ID: <53FC68B7.9080208@oracle.com>


Please approve backport of 8055811: Tests for Nashorn ClassFilter Support
webrev : http://cr.openjdk.java.net/~yan/8055811/webrev.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8055811
jdk8u40 webrev: http://cr.openjdk.java.net/~yan/8055811/webrev.00/
jdk8u40 changeset: 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/fe439797def2


-- 
Thanks,
Sergey


From attila.szegedi at oracle.com  Tue Aug 26 11:22:12 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 26 Aug 2014 13:22:12 +0200
Subject: Review request for JDK-8055954
Message-ID: <281AE685-5CD5-4C2F-8DB0-CCCA0EB69CD6@oracle.com>

Please review JDK-8055954 at <http://cr.openjdk.java.net/~attila/8055954/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055954>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Tue Aug 26 11:30:44 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 26 Aug 2014 17:00:44 +0530
Subject: Review request for JDK-8055954
In-Reply-To: <281AE685-5CD5-4C2F-8DB0-CCCA0EB69CD6@oracle.com>
References: <281AE685-5CD5-4C2F-8DB0-CCCA0EB69CD6@oracle.com>
Message-ID: <53FC6FE4.9090300@oracle.com>

+1

-Sundar

On Tuesday 26 August 2014 04:52 PM, Attila Szegedi wrote:
> Please review JDK-8055954 at <http://cr.openjdk.java.net/~attila/8055954/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055954>
>
> Thanks,
>    Attila.


From james.laskey at oracle.com  Tue Aug 26 11:49:55 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 26 Aug 2014 08:49:55 -0300
Subject: RFR 8056050: runExternalJsTest method in
	test/jdk/nashorn/internal/runtime/ClassFilter.java slows down
	"ant test"
In-Reply-To: <53FC6495.5090005@oracle.com>
References: <53FC6495.5090005@oracle.com>
Message-ID: <5FEDD726-621F-4235-B384-CE05F7C3BF21@oracle.com>

+1

On Aug 26, 2014, at 7:42 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8056050/
> 
> Thanks
> -Sundar


From dalibor.topic at oracle.com  Tue Aug 26 12:50:44 2014
From: dalibor.topic at oracle.com (dalibor topic)
Date: Tue, 26 Aug 2014 14:50:44 +0200
Subject: RFR 8055811 Tests for Nashorn ClassFilter Support
In-Reply-To: <53FB34E6.1060709@oracle.com>
References: <53FB34E6.1060709@oracle.com>
Message-ID: <53FC82A4.7010109@oracle.com>

Retroactively approved for jdk8u-dev.

When you are looking for approval & review, rather than just a review, 
please make sure to follow the approval template: 
http://openjdk.java.net/projects/jdk8u/approval-template.html or your 
request might not get picked up immediately.

In this case, your subject line seemed to say 'hey I just want a review 
of this change', rather than what you meant.

cheers,
dalibor topic

On 25.08.2014 15:06, Sergey Lugovoy wrote:
> Please review   http://cr.openjdk.java.net/~yan/8055811/webrev.00/
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8055811
> SQE Test plan: https://bugs.openjdk.java.net/browse/JDK-8050967
> JEP : https://bugs.openjdk.java.net/browse/JDK-8043717
>

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From attila.szegedi at oracle.com  Tue Aug 26 12:54:42 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 26 Aug 2014 14:54:42 +0200
Subject: Review request for JDK-8056052
Message-ID: <55C0BB00-9D11-4AF2-8863-5B4228A6AEBF@oracle.com>

Please review JDK-8056052 at <http://cr.openjdk.java.net/~attila/8056052/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056052>

Thanks,
  Attila.

From james.laskey at oracle.com  Tue Aug 26 12:57:57 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 26 Aug 2014 09:57:57 -0300
Subject: Review request for JDK-8056052
In-Reply-To: <55C0BB00-9D11-4AF2-8863-5B4228A6AEBF@oracle.com>
References: <55C0BB00-9D11-4AF2-8863-5B4228A6AEBF@oracle.com>
Message-ID: <66DC662D-9065-4A25-9B36-36C085B85905@oracle.com>

+1

On Aug 26, 2014, at 9:54 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8056052 at <http://cr.openjdk.java.net/~attila/8056052/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056052>
> 
> Thanks,
>  Attila.


From james.laskey at oracle.com  Tue Aug 26 12:59:53 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 26 Aug 2014 09:59:53 -0300
Subject: Review request for JDK-8055954
In-Reply-To: <281AE685-5CD5-4C2F-8DB0-CCCA0EB69CD6@oracle.com>
References: <281AE685-5CD5-4C2F-8DB0-CCCA0EB69CD6@oracle.com>
Message-ID: <F774EC8E-21B2-48FE-8170-ECD3FD6B86F0@oracle.com>

+1

On Aug 26, 2014, at 8:22 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8055954 at <http://cr.openjdk.java.net/~attila/8055954/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8055954>
> 
> Thanks,
>  Attila.


From attila.szegedi at oracle.com  Tue Aug 26 13:51:39 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 26 Aug 2014 15:51:39 +0200
Subject: Review request for JDK-8056025
Message-ID: <4ECB8AB6-A778-4636-A65B-9AC95F3B5395@oracle.com>

Please review JDK-8056025 at <http://cr.openjdk.java.net/~attila/8056025/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056025>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Tue Aug 26 13:55:13 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 26 Aug 2014 19:25:13 +0530
Subject: Review request for JDK-8056025
In-Reply-To: <4ECB8AB6-A778-4636-A65B-9AC95F3B5395@oracle.com>
References: <4ECB8AB6-A778-4636-A65B-9AC95F3B5395@oracle.com>
Message-ID: <53FC91C1.4070209@oracle.com>

+1

-Sundar

On Tuesday 26 August 2014 07:21 PM, Attila Szegedi wrote:
> Please review JDK-8056025 at <http://cr.openjdk.java.net/~attila/8056025/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056025>
>
> Thanks,
>    Attila.


From james.laskey at oracle.com  Tue Aug 26 14:07:04 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 26 Aug 2014 11:07:04 -0300
Subject: Review request for JDK-8056025
In-Reply-To: <4ECB8AB6-A778-4636-A65B-9AC95F3B5395@oracle.com>
References: <4ECB8AB6-A778-4636-A65B-9AC95F3B5395@oracle.com>
Message-ID: <957A7F3A-9594-403A-951A-8EBE69D0B137@oracle.com>

+1

On Aug 26, 2014, at 10:51 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8056025 at <http://cr.openjdk.java.net/~attila/8056025/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056025>
> 
> Thanks,
>  Attila.


From sundararajan.athijegannathan at oracle.com  Tue Aug 26 17:08:36 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 26 Aug 2014 22:38:36 +0530
Subject: RFR 8056094: [nashorn] tests fail when running via jtreg
Message-ID: <53FCBF14.3070102@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8056094/

Thanks
-Sundar

From james.laskey at oracle.com  Tue Aug 26 17:18:15 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 26 Aug 2014 14:18:15 -0300
Subject: RFR 8056094: [nashorn] tests fail when running via jtreg
In-Reply-To: <53FCBF14.3070102@oracle.com>
References: <53FCBF14.3070102@oracle.com>
Message-ID: <62F69DF4-2D31-42B3-B6AC-E87C3D913C3C@oracle.com>

+1

On Aug 26, 2014, at 2:08 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8056094/
> 
> Thanks
> -Sundar


From hannes.wallnoefer at oracle.com  Tue Aug 26 17:26:01 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 26 Aug 2014 19:26:01 +0200
Subject: RFR 8056094: [nashorn] tests fail when running via jtreg
In-Reply-To: <53FCBF14.3070102@oracle.com>
References: <53FCBF14.3070102@oracle.com>
Message-ID: <53FCC329.7080507@oracle.com>

+1


Am 2014-08-26 um 19:08 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8056094/
>
> Thanks
> -Sundar


From tal.liron at threecrickets.com  Tue Aug 26 18:06:37 2014
From: tal.liron at threecrickets.com (Tal Liron)
Date: Wed, 27 Aug 2014 02:06:37 +0800
Subject: Bug report: AtomicInteger is converted to a Number when returned
	from function
Message-ID: <53FCCCAD.2010009@threecrickets.com>

The bug is on trunk in http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn.

In the following program, the first part works as expected. However, in 
the second part, it will fail at "x.incrementAndGet()" because "x" is 
not an AtomicInteger instance.

My guess is that the same bug may affect other Atomic* classes.



x = new java.util.concurrent.atomic.AtomicInteger()
x.incrementAndGet()
print(x + '\n')

function getAtomic() {
   return new java.util.concurrent.atomic.AtomicInteger()
}

x = getAtomic()
x.incrementAndGet()
print(x + '\n')


From sundararajan.athijegannathan at oracle.com  Wed Aug 27 03:53:55 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 27 Aug 2014 09:23:55 +0530
Subject: Bug report: AtomicInteger is converted to a Number when returned
	from function
In-Reply-To: <53FCCCAD.2010009@threecrickets.com>
References: <53FCCCAD.2010009@threecrickets.com>
Message-ID: <53FD5653.1020405@oracle.com>

Yes, this is a bug with 8u-dev and 9-dev - but not reproduced with 8u20 
binary. With 8u-dev and 9-dev, the scripts runs fine with 
--optimistic-types set to false. I've filed a bug:

https://bugs.openjdk.java.net/browse/JDK-8056129

Thanks for reporting this issue.

Thanks
-Sundar

On Tuesday 26 August 2014 11:36 PM, Tal Liron wrote:
> The bug is on trunk in 
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn.
>
> In the following program, the first part works as expected. However, 
> in the second part, it will fail at "x.incrementAndGet()" because "x" 
> is not an AtomicInteger instance.
>
> My guess is that the same bug may affect other Atomic* classes.
>
>
>
> x = new java.util.concurrent.atomic.AtomicInteger()
> x.incrementAndGet()
> print(x + '\n')
>
> function getAtomic() {
>   return new java.util.concurrent.atomic.AtomicInteger()
> }
>
> x = getAtomic()
> x.incrementAndGet()
> print(x + '\n')
>


From tal.liron at threecrickets.com  Wed Aug 27 04:29:34 2014
From: tal.liron at threecrickets.com (Tal Liron)
Date: Wed, 27 Aug 2014 12:29:34 +0800
Subject: Bug report: AtomicInteger is converted to a Number when returned
	from function
In-Reply-To: <53FD5653.1020405@oracle.com>
References: <53FCCCAD.2010009@threecrickets.com> <53FD5653.1020405@oracle.com>
Message-ID: <53FD5EAE.5070500@threecrickets.com>

I'm a bit confused as to 8u-dev:

1) When is the next JDK8 release, and what will be its version? (8u ...?)
2) Am I doing the right thing by testing 8u-dev if I want my application 
to work well with the next JDK8 release?

As it stands, 8u20 has too many issues, making it impossible for me to 
deploy on it. But I want my application to be ready for the next general 
release of JDK8. (Of course, I also want to help in improving Nashorn by 
reporting bugs)

On 08/27/2014 11:53 AM, A. Sundararajan wrote:
> Yes, this is a bug with 8u-dev and 9-dev - but not reproduced with 
> 8u20 binary. With 8u-dev and 9-dev, the scripts runs fine with 
> --optimistic-types set to false.

From sundararajan.athijegannathan at oracle.com  Wed Aug 27 04:35:43 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 27 Aug 2014 10:05:43 +0530
Subject: Bug report: AtomicInteger is converted to a Number when returned
	from function
In-Reply-To: <53FD5EAE.5070500@threecrickets.com>
References: <53FCCCAD.2010009@threecrickets.com> <53FD5653.1020405@oracle.com>
	<53FD5EAE.5070500@threecrickets.com>
Message-ID: <53FD601F.4060508@oracle.com>

Hi,

* Latest released 8 update is 8u20. Available @ 
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html. 


* Next 8 update "early access" binary can be downloaded @ 
https://jdk8.java.net/download.html

* 8u-dev nashorn development repository is @ 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn

If you are using the above nashorn repo, then you're testing the latest 
nashorn code on the 8 update series.

Please send us bug reports - either by posting in the mailing list or by 
filing bug reports.

Thanks,
-Sundar

On Wednesday 27 August 2014 09:59 AM, Tal Liron wrote:
> I'm a bit confused as to 8u-dev:
>
> 1) When is the next JDK8 release, and what will be its version? (8u ...?)
> 2) Am I doing the right thing by testing 8u-dev if I want my 
> application to work well with the next JDK8 release?
>
> As it stands, 8u20 has too many issues, making it impossible for me to 
> deploy on it. But I want my application to be ready for the next 
> general release of JDK8. (Of course, I also want to help in improving 
> Nashorn by reporting bugs)
>
> On 08/27/2014 11:53 AM, A. Sundararajan wrote:
>> Yes, this is a bug with 8u-dev and 9-dev - but not reproduced with 
>> 8u20 binary. With 8u-dev and 9-dev, the scripts runs fine with 
>> --optimistic-types set to false.


From tal.liron at threecrickets.com  Wed Aug 27 04:58:03 2014
From: tal.liron at threecrickets.com (Tal Liron)
Date: Wed, 27 Aug 2014 12:58:03 +0800
Subject: Bug report: AtomicInteger is converted to a Number when returned
	from function
In-Reply-To: <53FD601F.4060508@oracle.com>
References: <53FCCCAD.2010009@threecrickets.com>
	<53FD5653.1020405@oracle.com>	<53FD5EAE.5070500@threecrickets.com>
	<53FD601F.4060508@oracle.com>
Message-ID: <53FD655B.3090103@threecrickets.com>

OK, so my goal is for my application to be stable on 8u40.

1) When is 8u40 scheduled to be released?
2) Will 8u-dev eventually be 8u40? Am I doing the correct thing by 
testing against 8u-dev?

On 08/27/2014 12:35 PM, A. Sundararajan wrote:
> Hi,
>
> * Latest released 8 update is 8u20. Available @ 
> http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html. 
>
>
> * Next 8 update "early access" binary can be downloaded @ 
> https://jdk8.java.net/download.html
>
> * 8u-dev nashorn development repository is @ 
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn
>
> If you are using the above nashorn repo, then you're testing the 
> latest nashorn code on the 8 update series.
>
> Please send us bug reports - either by posting in the mailing list or 
> by filing bug reports.
>
> Thanks,
> -Sundar
>
> On Wednesday 27 August 2014 09:59 AM, Tal Liron wrote:
>> I'm a bit confused as to 8u-dev:
>>
>> 1) When is the next JDK8 release, and what will be its version? (8u 
>> ...?)
>> 2) Am I doing the right thing by testing 8u-dev if I want my 
>> application to work well with the next JDK8 release?
>>
>> As it stands, 8u20 has too many issues, making it impossible for me 
>> to deploy on it. But I want my application to be ready for the next 
>> general release of JDK8. (Of course, I also want to help in improving 
>> Nashorn by reporting bugs)
>>
>> On 08/27/2014 11:53 AM, A. Sundararajan wrote:
>>> Yes, this is a bug with 8u-dev and 9-dev - but not reproduced with 
>>> 8u20 binary. With 8u-dev and 9-dev, the scripts runs fine with 
>>> --optimistic-types set to false.
>


From sundararajan.athijegannathan at oracle.com  Wed Aug 27 05:02:56 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 27 Aug 2014 10:32:56 +0530
Subject: Bug report: AtomicInteger is converted to a Number when returned
	from function
In-Reply-To: <53FD655B.3090103@threecrickets.com>
References: <53FCCCAD.2010009@threecrickets.com>	<53FD5653.1020405@oracle.com>	<53FD5EAE.5070500@threecrickets.com>	<53FD601F.4060508@oracle.com>
	<53FD655B.3090103@threecrickets.com>
Message-ID: <53FD6680.2060805@oracle.com>

Hi,

1) http://openjdk.java.net/projects/jdk8u/releases/8u40.html

2) Yes. You're testing with the correct nashorn repo (jdk8u-dev/nashorn).

-Sundar

On Wednesday 27 August 2014 10:28 AM, Tal Liron wrote:
> OK, so my goal is for my application to be stable on 8u40.
>
> 1) When is 8u40 scheduled to be released?
> 2) Will 8u-dev eventually be 8u40? Am I doing the correct thing by 
> testing against 8u-dev?
>
> On 08/27/2014 12:35 PM, A. Sundararajan wrote:
>> Hi,
>>
>> * Latest released 8 update is 8u20. Available @ 
>> http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html. 
>>
>>
>> * Next 8 update "early access" binary can be downloaded @ 
>> https://jdk8.java.net/download.html
>>
>> * 8u-dev nashorn development repository is @ 
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn
>>
>> If you are using the above nashorn repo, then you're testing the 
>> latest nashorn code on the 8 update series.
>>
>> Please send us bug reports - either by posting in the mailing list or 
>> by filing bug reports.
>>
>> Thanks,
>> -Sundar
>>
>> On Wednesday 27 August 2014 09:59 AM, Tal Liron wrote:
>>> I'm a bit confused as to 8u-dev:
>>>
>>> 1) When is the next JDK8 release, and what will be its version? (8u 
>>> ...?)
>>> 2) Am I doing the right thing by testing 8u-dev if I want my 
>>> application to work well with the next JDK8 release?
>>>
>>> As it stands, 8u20 has too many issues, making it impossible for me 
>>> to deploy on it. But I want my application to be ready for the next 
>>> general release of JDK8. (Of course, I also want to help in 
>>> improving Nashorn by reporting bugs)
>>>
>>> On 08/27/2014 11:53 AM, A. Sundararajan wrote:
>>>> Yes, this is a bug with 8u-dev and 9-dev - but not reproduced with 
>>>> 8u20 binary. With 8u-dev and 9-dev, the scripts runs fine with 
>>>> --optimistic-types set to false.
>>
>


From sundararajan.athijegannathan at oracle.com  Wed Aug 27 06:21:35 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 27 Aug 2014 11:51:35 +0530
Subject: RFR 8056123: Anonymous function statements leak internal function
	names into global scope
Message-ID: <53FD78EF.7030608@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8056123/

Thanks
-Sundar

From sundararajan.athijegannathan at oracle.com  Wed Aug 27 10:26:15 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 27 Aug 2014 15:56:15 +0530
Subject: Reviewed fix for 8056052. Didn't respond to email list...
Message-ID: <53FDB247.6060001@oracle.com>

+1 on this request...

http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-August/003336.html

Thanks,
-Sundar


From attila.szegedi at oracle.com  Wed Aug 27 11:16:40 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 27 Aug 2014 13:16:40 +0200
Subject: RFR 8056123: Anonymous function statements leak internal function
	names into global scope
In-Reply-To: <53FD78EF.7030608@oracle.com>
References: <53FD78EF.7030608@oracle.com>
Message-ID: <30437F8E-FDFC-44B3-8EF7-FFBBAC0A5E53@oracle.com>

+1

On Aug 27, 2014, at 8:21 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8056123/
> 
> Thanks
> -Sundar


From marcus.lagergren at oracle.com  Wed Aug 27 12:14:09 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 27 Aug 2014 14:14:09 +0200
Subject: Please review JDK-8055906
Message-ID: <A2649584-EB3C-42C1-91F4-D05A5F6A7356@oracle.com>

http://cr.openjdk.java.net/~lagergren/8055906

Exception is throw for control flow purposes - it must not fill in stack trace for speed. In fact, the same exception can be reused.

/M


From attila.szegedi at oracle.com  Wed Aug 27 12:17:22 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 27 Aug 2014 14:17:22 +0200
Subject: Please review JDK-8055906
In-Reply-To: <A2649584-EB3C-42C1-91F4-D05A5F6A7356@oracle.com>
References: <A2649584-EB3C-42C1-91F4-D05A5F6A7356@oracle.com>
Message-ID: <28085400-CA1A-4193-B2F8-71AA55985799@oracle.com>

+1

On Aug 27, 2014, at 2:14 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

> http://cr.openjdk.java.net/~lagergren/8055906
> 
> Exception is throw for control flow purposes - it must not fill in stack trace for speed. In fact, the same exception can be reused.
> 
> /M
> 


From hannes.wallnoefer at oracle.com  Wed Aug 27 12:25:04 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 27 Aug 2014 14:25:04 +0200
Subject: Please review JDK-8055906
In-Reply-To: <A2649584-EB3C-42C1-91F4-D05A5F6A7356@oracle.com>
References: <A2649584-EB3C-42C1-91F4-D05A5F6A7356@oracle.com>
Message-ID: <53FDCE20.4020405@oracle.com>

+1


Am 2014-08-27 um 14:14 schrieb Marcus Lagergren:
> http://cr.openjdk.java.net/~lagergren/8055906
>
> Exception is throw for control flow purposes - it must not fill in stack trace for speed. In fact, the same exception can be reused.
>
> /M
>


From hannes.wallnoefer at oracle.com  Wed Aug 27 12:26:07 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 27 Aug 2014 14:26:07 +0200
Subject: RFR 8056123: Anonymous function statements leak internal function
	names into global scope
In-Reply-To: <53FD78EF.7030608@oracle.com>
References: <53FD78EF.7030608@oracle.com>
Message-ID: <53FDCE5F.6010402@oracle.com>

+1

Am 2014-08-27 um 08:21 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8056123/
>
> Thanks
> -Sundar


From attila.szegedi at oracle.com  Thu Aug 28 14:06:11 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 28 Aug 2014 16:06:11 +0200
Subject: Review request for JDK-8056243
Message-ID: <A21EA41B-16EC-46A9-B93F-5FA770F5354B@oracle.com>

Please review JDK-8056243 at <http://cr.openjdk.java.net/~attila/8056243/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056243>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Thu Aug 28 14:32:35 2014
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 28 Aug 2014 20:02:35 +0530
Subject: Review request for JDK-8056243
In-Reply-To: <A21EA41B-16EC-46A9-B93F-5FA770F5354B@oracle.com>
References: <A21EA41B-16EC-46A9-B93F-5FA770F5354B@oracle.com>
Message-ID: <53FF3D83.9050605@oracle.com>

+1

On Thursday 28 August 2014 07:36 PM, Attila Szegedi wrote:
> Please review JDK-8056243 at <http://cr.openjdk.java.net/~attila/8056243/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056243>
>
> Thanks,
>    Attila.


From marcus.lagergren at oracle.com  Thu Aug 28 14:40:50 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Thu, 28 Aug 2014 16:40:50 +0200
Subject: Review request for JDK-8056243
In-Reply-To: <A21EA41B-16EC-46A9-B93F-5FA770F5354B@oracle.com>
References: <A21EA41B-16EC-46A9-B93F-5FA770F5354B@oracle.com>
Message-ID: <6E454CED-52CE-4159-A3E3-04FAFABB1C5A@oracle.com>

+1

On 28 Aug 2014, at 16:06, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8056243 at <http://cr.openjdk.java.net/~attila/8056243/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056243>
> 
> Thanks,
>  Attila.


From attila.szegedi at oracle.com  Fri Aug 29 08:45:49 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 29 Aug 2014 10:45:49 +0200
Subject: Bug report: AtomicInteger is converted to a Number when returned
	from function
In-Reply-To: <53FCCCAD.2010009@threecrickets.com>
References: <53FCCCAD.2010009@threecrickets.com>
Message-ID: <B934CCD2-AE3A-4A88-BF23-E254699D6616@oracle.com>

Yes, this is a bug. It stems from our (new in 8u-dev) optimistic handling of types. Basically, the "x=getAtomic()" line is first compiled with the assumption that whatever getAtomic() returns might be representable as an int. As it happens, AtomicInteger extends Number, and the return value filter will see that it's a number and that its value can indeed be represented as int, so it'll coerce it into a primitive int. We'll have to change the responsible logic to be more strict (e.g. only allow actual primitive wrapper types to be coerced). 

In the first case it doesn't happen because we have the assumption that "new " operator always returns an object, so we don't attempt to treat it as an int at all.

Thanks for sticking with us; I know it's no fun getting cut on the bleeding edge? The --optimistic-types=false command line option to Nashorn will turn optimistic types off in case this is blocking you, but I advise that you generally test with them being on (as it's certainly the biggest improvement in the latest Nashorn bits), and we'll keep ironing out the wrinkles.

Thanks,
  Attila.

On Aug 26, 2014, at 8:06 PM, Tal Liron <tal.liron at threecrickets.com> wrote:

> The bug is on trunk in http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn.
> 
> In the following program, the first part works as expected. However, in the second part, it will fail at "x.incrementAndGet()" because "x" is not an AtomicInteger instance.
> 
> My guess is that the same bug may affect other Atomic* classes.
> 
> 
> 
> x = new java.util.concurrent.atomic.AtomicInteger()
> x.incrementAndGet()
> print(x + '\n')
> 
> function getAtomic() {
>  return new java.util.concurrent.atomic.AtomicInteger()
> }
> 
> x = getAtomic()
> x.incrementAndGet()
> print(x + '\n')
> 


From tal.liron at threecrickets.com  Fri Aug 29 09:09:50 2014
From: tal.liron at threecrickets.com (Tal Liron)
Date: Fri, 29 Aug 2014 17:09:50 +0800
Subject: Bug report: AtomicInteger is converted to a Number when returned
	from function
In-Reply-To: <B934CCD2-AE3A-4A88-BF23-E254699D6616@oracle.com>
References: <53FCCCAD.2010009@threecrickets.com>
	<B934CCD2-AE3A-4A88-BF23-E254699D6616@oracle.com>
Message-ID: <5400435E.9030409@threecrickets.com>

My pleasure! Well, not quite pleasure, but am happy to help. :) I have a 
lot of code that needs to run on Nashorn, so it is a good test of what 
breaks.

And perhaps unfortunately, I must use the bleeding edge, because the 
Nashorn released in 8u20 was too broken for Prudence to run.

And yes, of course I will test using the defaults instead of 
"optimistic-types=false".

On 08/29/2014 04:45 PM, Attila Szegedi wrote:
> Yes, this is a bug. It stems from our (new in 8u-dev) optimistic handling of types. Basically, the "x=getAtomic()" line is first compiled with the assumption that whatever getAtomic() returns might be representable as an int. As it happens, AtomicInteger extends Number, and the return value filter will see that it's a number and that its value can indeed be represented as int, so it'll coerce it into a primitive int. We'll have to change the responsible logic to be more strict (e.g. only allow actual primitive wrapper types to be coerced).
>
> In the first case it doesn't happen because we have the assumption that "new " operator always returns an object, so we don't attempt to treat it as an int at all.
>
> Thanks for sticking with us; I know it's no fun getting cut on the bleeding edge? The --optimistic-types=false command line option to Nashorn will turn optimistic types off in case this is blocking you, but I advise that you generally test with them being on (as it's certainly the biggest improvement in the latest Nashorn bits), and we'll keep ironing out the wrinkles.


From attila.szegedi at oracle.com  Fri Aug 29 13:23:11 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 29 Aug 2014 15:23:11 +0200
Subject: Review request for JDK-8056913
Message-ID: <9EC22F78-B654-41DA-B6FB-B1F3193CE573@oracle.com>

Please review JDK-8056913 at <http://cr.openjdk.java.net/~attila/8056913/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056913>

Thanks,
  Attila.

From marcus.lagergren at oracle.com  Fri Aug 29 13:35:02 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 29 Aug 2014 15:35:02 +0200
Subject: Review request for JDK-8056913
In-Reply-To: <9EC22F78-B654-41DA-B6FB-B1F3193CE573@oracle.com>
References: <9EC22F78-B654-41DA-B6FB-B1F3193CE573@oracle.com>
Message-ID: <8561C627-B17F-40F2-9D89-D2A4EE56A798@oracle.com>

+1 

On 29 Aug 2014, at 15:23, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8056913 at <http://cr.openjdk.java.net/~attila/8056913/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056913>
> 
> Thanks,
>  Attila.


From james.laskey at oracle.com  Fri Aug 29 13:38:18 2014
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 29 Aug 2014 10:38:18 -0300
Subject: Review request for JDK-8056913
In-Reply-To: <9EC22F78-B654-41DA-B6FB-B1F3193CE573@oracle.com>
References: <9EC22F78-B654-41DA-B6FB-B1F3193CE573@oracle.com>
Message-ID: <9EE6F646-2752-4C6D-8925-2BDF6DC35CBB@oracle.com>

+1

On Aug 29, 2014, at 10:23 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Please review JDK-8056913 at <http://cr.openjdk.java.net/~attila/8056913/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8056913>
> 
> Thanks,
>  Attila.


From hannes.wallnoefer at oracle.com  Fri Aug 29 14:20:06 2014
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 29 Aug 2014 16:20:06 +0200
Subject: Review request for JDK-8051889: Implement block scoping in symbol
	assignment and scope computation
Message-ID: <54008C16.4070700@oracle.com>

Please review JDK-8051889: Implement block scoping in symbol assignment 
and scope computation:

http://cr.openjdk.java.net/~hannesw/8051889/webrev.04/

This is an rather complete implementation of lexical scoping as defined 
in ES6. Still missing is some special treatment of for-let loops and 
switch statements.

Thanks,
Hannes

From attila.szegedi at oracle.com  Fri Aug 29 14:21:29 2014
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 29 Aug 2014 16:21:29 +0200
Subject: Review request for JDK-8051889: Implement block scoping in symbol
	assignment and scope computation
In-Reply-To: <54008C16.4070700@oracle.com>
References: <54008C16.4070700@oracle.com>
Message-ID: <8C0A20C2-4C74-419F-8CDD-C04DD3578B0A@oracle.com>

+1

On Aug 29, 2014, at 4:20 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8051889: Implement block scoping in symbol assignment and scope computation:
> 
> http://cr.openjdk.java.net/~hannesw/8051889/webrev.04/
> 
> This is an rather complete implementation of lexical scoping as defined in ES6. Still missing is some special treatment of for-let loops and switch statements.
> 
> Thanks,
> Hannes


From marcus.lagergren at oracle.com  Fri Aug 29 14:38:23 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 29 Aug 2014 16:38:23 +0200
Subject: Review request for JDK-8051889: Implement block scoping in symbol
	assignment and scope computation
In-Reply-To: <54008C16.4070700@oracle.com>
References: <54008C16.4070700@oracle.com>
Message-ID: <DA3BF381-0C6B-4D54-A4C0-8EC04621ACC9@oracle.com>

+1

On 29 Aug 2014, at 16:20, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8051889: Implement block scoping in symbol assignment and scope computation:
> 
> http://cr.openjdk.java.net/~hannesw/8051889/webrev.04/
> 
> This is an rather complete implementation of lexical scoping as defined in ES6. Still missing is some special treatment of for-let loops and switch statements.
> 
> Thanks,
> Hannes


From ars.kov at gmail.com  Wed Aug 20 15:17:38 2014
From: ars.kov at gmail.com (Arseniy Kovalchuk)
Date: Wed, 20 Aug 2014 15:17:38 -0000
Subject: Is there any way to implement equals and hashCode using Nashorn
	javascript?
Message-ID: <CADufK4xQZ2B21YXimjNA6-dTwt7ZoJHsTzA1c3=k8RxbNenaiQ@mail.gmail.com>

Good day.

I?ve faced with the following problem. I?d like to use java.util.HashMap
and/or java.util.PriorityQueue in Nashorn script, where I need to use
particular custom object as a key in the HashMap, and also use
HashMap.containsKey() to check if there is a key in the Map (another option
is to check if the object in a Collection.contains(Object o)).

So, obviously, I need to implement equals and hashCode in my object basing
on some field values. I'd like to highlight, that it would be very
important to not code custom Java class nor interface :). In other words,
is it possible to implement this only in JavaScript?

For example:

var PriorityQueue = java.util.PriorityQueue;var HashMap =
java.util.HashMap;var Integer = java.lang.Integer;
// Sample 1// Doesn't work, equals and hashCode are not being
invokedfunction Vertex1(from, cost) {
    this.from = from;
    this.cost = cost;

    this.equals = function(other) { return this.from == other.from; }
    this.hashCode = function() { return Integer.hashCode(this.from); }}
var hm = new HashMap();
hm.put(new Vertex1(1, 10), 10);
hm.put(new Vertex1(1, 20), 21);// Prints size is 2, but I'd like to see 1
print("HashMap size: " + hm.size());// Prints false
print("HashMap1 contains: " + hm.containsKey(new Vertex1(1, 20)));

Another way when methods are being invoked, but there is no obvious way to
access `other` object's `from` field in the equals method!

var HashMap = java.util.HashMap;var JInteger = java.lang.Integer;var
JObject = Java.extend(java.lang.Object);
var createVertex = (function() {
    var
    _equals = function(other) {
        print(this + ' vs ' + other);
        return this._from === other.from;
    };
    _hashCode = function() {
        var hashCode = JInteger.hashCode(this._from);
        print(hashCode);
        return hashCode;
    };
    return function(from, cost) {
        return new JObject() {
            _from : from,
            _cost : cost,
            equals : _equals,
            hashCode : _hashCode,
        }
    }})();
var JSVertex = function(from, cost) {
    return new JObject() {
        _from : from,
        _cost : cost,
        equals : function(other) {
            print(this + ' vs ' + other);
            return this._from === other._from;
        },
        hashCode : function() {
            var hashCode = JInteger.hashCode(this._from);
            print(hashCode);
            return hashCode;
        }
    }}
var v1 = JSVertex(1, 10);var v2 = JSVertex(1, 20);//var v1 =
createVertex(1, 10);//var v2 = createVertex(1, 20);var v3 =
createVertex(1, 20);
print(v1.class === v2.class); // returns true
print(v2.class === v3.class); // returns truevar hm = new HashMap();
hm.put(v1, 10);
hm.put(v2, 21);
print("HashMap size: " + hm.size()); // Prints 2, but I'd like to see 1
print("HashMap contains: " + hm.containsKey(v3)); // Prints false

Please refer to the stackoverflow question for details
http://stackoverflow.com/questions/25379340/nashorn-java-collections-how-to-implement-equals-and-hashcode-in-pure-javascri

Sincerely,

Arseny Kovalchuk.

-- 
? ?????????,
??????? ?????????

*ars.kov at gmail.com <ars.kov at gmail.com>*
*+375 29 666-16-16*