Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

[Sundararajan Athijegannathan]

Also, we have to recall ConsString as optimization to represent JS 
"string" primitive has caused lot of pain.. (internal type hiding, 
conversion in places...). We fixed number of issues after introducing 
ConsString. If we were to introduce JSNumber type, we may have to do 
similar conversions (like what is being done for ConsString) everywhere 
-- to hide and present Number to the java side...


I agree with Hannes that it is important to use java.lang.* primitive 
wrappers being used to represent JS primitives for seamless integration.


-Sundar

On 1/12/2016 4:10 AM, Hannes Wallnoefer wrote:

Am 2016-01-11 um 19:45 schrieb Attila Szegedi:
Specifically in relation to the remark that JSType.isNumber check is 
getting long… I think we could be even more conservative if we wished 
to, namely only recognizing Integer and Double as wrapped numbers. 
Within Nashorn, byte, short, float, and long don't occur naturally, 
only int and double occur. Their wrappers (Byte, Short, etc.) 
therefore also can’t appear. The only way to introduce them is 
through POJO methods with such return types (e.g. Byte.valueOf()). 
I’m not sure we’re under an obligation to consider those equivalent 
to JS numbers. We could declare that Byte, Short, Float, and Long are 
not numbers just host objects, albeit ones that JSType.toNumber 
understands.


I guess we could do that, but we would (IMO) needlessly change the 
rules we set up with Nashorn in JDK8. I think that making Java number 
primitives equivalent to JS numbers is actually a nice feature. 
Unfortunately it doesn't really work for longs because JS happens to 
use double as its only number type, but I don't think that means we 
should throw out the idea as a whole.


Also, an important point here is that we can't really safely 
distinguish between primitive number types and object wrappers in 
Nashorn. A java.lang.Short or java.lang.Float may just be a primitive 
that happens to be handled in an object context.


Actually, I can take this train of thought in an even more drastic 
direction. Consider this: we would be at liberty to internally box 
numbers any way we want and not rely on java.lang.Double and friends 
at all! It’s just convenient to box JS primitive number values (and 
booleans, BTW) using readily available java.lang.* boxes, but we 
could have a NashornNumber and NashornBoolean classes for internal 
boxing of JS primitive numbers and booleans, when they need to be 
boxed. Then we could even allow ourselves to not recognize any Java 
primitive wrapper objects as special cases of JS primitive values at 
all. The thought is actually not so far fetched in the sense that we 
already have ConsString too, an alternative internal string 
representation that is not a java.lang.String. We’d just have to take 
care that such NashornNumber boxes are handled in all places where 
ConsString is handled and converted into a Double when passing from 
Nashorn to outside world.


That would provide a 100% consistent way of handling wrapper classes: 
they’re all just POJOs at that point, no special treatment whatsoever.


I think what I wrote above also applies here - that seamlessness is 
actually nice and that we don't really control whether a numeric value 
from Java is handled as primitive or as wrapper object in Nashorn - 
that may vary on how JavaScript code was used/optimized/compiled 
before, what the code does with it, etc.


In Rhino, we had explicit wrapper classes for things to be treated as 
objects (e.g. a java.lang.Double would be wrapped in a JavaObject 
wrapper or whatever it was called). Since Nashorn does not use object 
wrappers, I think it would be hard to distinguish between primitive 
numbers and object wrappers in this way. It would als feel kind of 
arbitrary to me.


Hannes


Attila.

On Jan 11, 2016, at 1:48 PM, Hannes Wallnoefer 
 wrote:


You are right of course, there needs to be consistency between 
typeof operator and treatment as JS numbers.


This is in fact an unpleasant problem to solve. I've struggled 
trying to fix this without breaking any existing code, but I've come 
to the conclusion that it is not possible. Since we can't treat all 
Java longs/Longs as JS numbers, we'd have to differentiate depending 
on whether the value can be represented as double without losing 
precision.


In a way we already do this with optimistic types, but I consider it 
more a bug than a feature. It's weird (and error prone) if the 
return value for a Java method returning long is reported as number 
or object depending on the actual value.


So I think the right thing to do is draw a clear line between which 
Java primitive/wrapper types represent JS numbers and which don't. 
I've uploaded a new webrev that implements this:


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

Note that the only types to be treated as JS numbers are the direct 
wrapper classes for Java primitives that can be fully represented as 
doubles. This means also things like Atomi

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

[Hannes Wallnoefer]

Am 2016-01-11 um 19:45 schrieb Attila Szegedi:

Specifically in relation to the remark that JSType.isNumber check is getting 
long… I think we could be even more conservative if we wished to, namely only 
recognizing Integer and Double as wrapped numbers. Within Nashorn, byte, short, 
float, and long don't occur naturally, only int and double occur. Their 
wrappers (Byte, Short, etc.) therefore also can’t appear. The only way to 
introduce them is through POJO methods with such return types (e.g. 
Byte.valueOf()). I’m not sure we’re under an obligation to consider those 
equivalent to JS numbers. We could declare that Byte, Short, Float, and Long 
are not numbers just host objects, albeit ones that JSType.toNumber understands.


I guess we could do that, but we would (IMO) needlessly change the rules 
we set up with Nashorn in JDK8. I think that making Java number 
primitives equivalent to JS numbers is actually a nice feature. 
Unfortunately it doesn't really work for longs because JS happens to use 
double as its only number type, but I don't think that means we should 
throw out the idea as a whole.


Also, an important point here is that we can't really safely distinguish 
between primitive number types and object wrappers in Nashorn. A 
java.lang.Short or java.lang.Float may just be a primitive that happens 
to be handled in an object context.



Actually, I can take this train of thought in an even more drastic direction. 
Consider this: we would be at liberty to internally box numbers any way we want 
and not rely on java.lang.Double and friends at all! It’s just convenient to 
box JS primitive number values (and booleans, BTW) using readily available 
java.lang.* boxes, but we could have a NashornNumber and NashornBoolean classes 
for internal boxing of JS primitive numbers and booleans, when they need to be 
boxed. Then we could even allow ourselves to not recognize any Java primitive 
wrapper objects as special cases of JS primitive values at all. The thought is 
actually not so far fetched in the sense that we already have ConsString too, 
an alternative internal string representation that is not a java.lang.String. 
We’d just have to take care that such NashornNumber boxes are handled in all 
places where ConsString is handled and converted into a Double when passing 
from Nashorn to outside world.

That would provide a 100% consistent way of handling wrapper classes: they’re 
all just POJOs at that point, no special treatment whatsoever.


I think what I wrote above also applies here - that seamlessness is 
actually nice and that we don't really control whether a numeric value 
from Java is handled as primitive or as wrapper object in Nashorn - that 
may vary on how JavaScript code was used/optimized/compiled before, what 
the code does with it, etc.


In Rhino, we had explicit wrapper classes for things to be treated as 
objects (e.g. a java.lang.Double would be wrapped in a JavaObject 
wrapper or whatever it was called). Since Nashorn does not use object 
wrappers, I think it would be hard to distinguish between primitive 
numbers and object wrappers in this way. It would als feel kind of 
arbitrary to me.


Hannes


Attila.


On Jan 11, 2016, at 1:48 PM, Hannes Wallnoefer  
wrote:

You are right of course, there needs to be consistency between typeof operator 
and treatment as JS numbers.

This is in fact an unpleasant problem to solve. I've struggled trying to fix 
this without breaking any existing code, but I've come to the conclusion that 
it is not possible. Since we can't treat all Java longs/Longs as JS numbers, 
we'd have to differentiate depending on whether the value can be represented as 
double without losing precision.

In a way we already do this with optimistic types, but I consider it more a bug 
than a feature. It's weird (and error prone) if the return value for a Java 
method returning long is reported as number or object depending on the actual 
value.

So I think the right thing to do is draw a clear line between which Java 
primitive/wrapper types represent JS numbers and which don't. I've uploaded a 
new webrev that implements this:

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

Note that the only types to be treated as JS numbers are the direct wrapper 
classes for Java primitives that can be fully represented as doubles. This 
means also things like AtomicInteger and DoubleAdder will be reported and 
treated as objects. I think that's the correct thing to do as they are not 
primitive numbers in the first place. They are still converted to numbers when 
used in such a context in JS. So I think the only place where this change is a 
actually painful/surprising is longs.

Unfortunately the check for number type in JSType.isNumber gets a bit long as 
we have to individually check for all primitive wrapper classes. I've done 
extensive benchmarking and I don't think it has an impact on performance. In 
any way, I wouldn't know how to handle this differently.

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

[Attila Szegedi]

Specifically in relation to the remark that JSType.isNumber check is getting 
long… I think we could be even more conservative if we wished to, namely only 
recognizing Integer and Double as wrapped numbers. Within Nashorn, byte, short, 
float, and long don't occur naturally, only int and double occur. Their 
wrappers (Byte, Short, etc.) therefore also can’t appear. The only way to 
introduce them is through POJO methods with such return types (e.g. 
Byte.valueOf()). I’m not sure we’re under an obligation to consider those 
equivalent to JS numbers. We could declare that Byte, Short, Float, and Long 
are not numbers just host objects, albeit ones that JSType.toNumber understands.

Actually, I can take this train of thought in an even more drastic direction. 
Consider this: we would be at liberty to internally box numbers any way we want 
and not rely on java.lang.Double and friends at all! It’s just convenient to 
box JS primitive number values (and booleans, BTW) using readily available 
java.lang.* boxes, but we could have a NashornNumber and NashornBoolean classes 
for internal boxing of JS primitive numbers and booleans, when they need to be 
boxed. Then we could even allow ourselves to not recognize any Java primitive 
wrapper objects as special cases of JS primitive values at all. The thought is 
actually not so far fetched in the sense that we already have ConsString too, 
an alternative internal string representation that is not a java.lang.String. 
We’d just have to take care that such NashornNumber boxes are handled in all 
places where ConsString is handled and converted into a Double when passing 
from Nashorn to outside world.

That would provide a 100% consistent way of handling wrapper classes: they’re 
all just POJOs at that point, no special treatment whatsoever.

Attila.

> On Jan 11, 2016, at 1:48 PM, Hannes Wallnoefer  
> wrote:
> 
> You are right of course, there needs to be consistency between typeof 
> operator and treatment as JS numbers.
> 
> This is in fact an unpleasant problem to solve. I've struggled trying to fix 
> this without breaking any existing code, but I've come to the conclusion that 
> it is not possible. Since we can't treat all Java longs/Longs as JS numbers, 
> we'd have to differentiate depending on whether the value can be represented 
> as double without losing precision.
> 
> In a way we already do this with optimistic types, but I consider it more a 
> bug than a feature. It's weird (and error prone) if the return value for a 
> Java method returning long is reported as number or object depending on the 
> actual value.
> 
> So I think the right thing to do is draw a clear line between which Java 
> primitive/wrapper types represent JS numbers and which don't. I've uploaded a 
> new webrev that implements this:
> 
> http://cr.openjdk.java.net/~hannesw/8143896/webrev.01/
> 
> Note that the only types to be treated as JS numbers are the direct wrapper 
> classes for Java primitives that can be fully represented as doubles. This 
> means also things like AtomicInteger and DoubleAdder will be reported and 
> treated as objects. I think that's the correct thing to do as they are not 
> primitive numbers in the first place. They are still converted to numbers 
> when used in such a context in JS. So I think the only place where this 
> change is a actually painful/surprising is longs.
> 
> Unfortunately the check for number type in JSType.isNumber gets a bit long as 
> we have to individually check for all primitive wrapper classes. I've done 
> extensive benchmarking and I don't think it has an impact on performance. In 
> any way, I wouldn't know how to handle this differently.

> 
> Let me know what you think.
> 
> Hannes
> 
> Am 2016-01-04 um 05:00 schrieb Sundararajan Athijegannathan:
>> I think I already commented on this webrev -- that we need to cover tests 
>> for BigInteger, BigDecimal.
>> 
>> Also, I'm not sure linking Double and Int by nashorn  primitive linkers is 
>> the right solution. AtomicInteger, DoubleAdder etc. are all Number subtypes. 
>> We return "number" when typeof is used on any Number subtype.
>> Now, that means JS code will see these as 'number' type objects -- yet 
>> Number.prototype methods won't work on those!! I know this is hard problem 
>> -- we also have another (somewhat related) BigDecimal, BigInteger toString / 
>> String conversion issue. We need to discuss this.
>> 
>> -Sundar
>> 
>> On 1/2/2016 8:29 PM, Attila Szegedi wrote:
>>> +1
>>> 
 On Dec 18, 2015, at 3:54 PM, Hannes Wallnoefer 
  wrote:
 
 Please review JDK-8143896: java.lang.Long is implicitly converted to double
 
 http://cr.openjdk.java.net/~hannesw/8143896/webrev/
 
 Thanks,
 Hannes
>> 
> 

Re: Contributing to Nashorn

[Jim Laskey (Oracle)]

The same as OpenJDK, submit an OCA and then we can accept contributions for 
review. see http://openjdk.java.net/contribute/

- Jim



> On Jan 11, 2016, at 11:59 AM, Vivin Suresh Paliath  
> wrote:
> 
> Hello,
> 
> I was wondering about the guidelines for contributing to Nashorn? Is it the
> same as contributing to OpenJDK? Does Nashorn accept contributions from
> outside parties? Thanks!
> 
> Vivin
> 
> -- 
> Ruin untold;
> And thine own sadness,
> Sing in the grass,
> When eve has forgot, that no more hear common things that gleam and pass;
> But seek alone to lip, sad Rose of love and ruin untold;
> And thine own mother
> Can know it as I know
> More than another
> What makes your own sadness,
> Set in her eyes.
> 
> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02".
> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01".
> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01".
> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02".
> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02".
> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01".
> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01".
> ":13:02:11:01:02:11:01:12:02";map{print chr unpack"
> i",pack"B32",$_}$j=~m/.{8}/g

Contributing to Nashorn

[Vivin Suresh Paliath]

Hello,

I was wondering about the guidelines for contributing to Nashorn? Is it the
same as contributing to OpenJDK? Does Nashorn accept contributions from
outside parties? Thanks!

Vivin

-- 
Ruin untold;
And thine own sadness,
Sing in the grass,
When eve has forgot, that no more hear common things that gleam and pass;
But seek alone to lip, sad Rose of love and ruin untold;
And thine own mother
Can know it as I know
More than another
What makes your own sadness,
Set in her eyes.

map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02".
":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01".
":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01".
":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02".
":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02".
":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01".
":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01".
":13:02:11:01:02:11:01:12:02";map{print chr unpack"
i",pack"B32",$_}$j=~m/.{8}/g

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

[Sundararajan Athijegannathan]

As discussed offline, please leave Nashorn Parser API changes for a 
separate issue.


-Sundar

On 1/11/2016 8:07 PM, Hannes Wallnoefer wrote:
I fixed a bug with converstion to number for the strict equality 
operator, which also revealed some left over usage of long in Nashorn 
internals. New webrev is here:


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

Hannes

Am 2016-01-11 um 13:48 schrieb Hannes Wallnoefer:
You are right of course, there needs to be consistency between typeof 
operator and treatment as JS numbers.


This is in fact an unpleasant problem to solve. I've struggled trying 
to fix this without breaking any existing code, but I've come to the 
conclusion that it is not possible. Since we can't treat all Java 
longs/Longs as JS numbers, we'd have to differentiate depending on 
whether the value can be represented as double without losing precision.


In a way we already do this with optimistic types, but I consider it 
more a bug than a feature. It's weird (and error prone) if the return 
value for a Java method returning long is reported as number or 
object depending on the actual value.


So I think the right thing to do is draw a clear line between which 
Java primitive/wrapper types represent JS numbers and which don't. 
I've uploaded a new webrev that implements this:


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

Note that the only types to be treated as JS numbers are the direct 
wrapper classes for Java primitives that can be fully represented as 
doubles. This means also things like AtomicInteger and DoubleAdder 
will be reported and treated as objects. I think that's the correct 
thing to do as they are not primitive numbers in the first place. 
They are still converted to numbers when used in such a context in 
JS. So I think the only place where this change is a actually 
painful/surprising is longs.


Unfortunately the check for number type in JSType.isNumber gets a bit 
long as we have to individually check for all primitive wrapper 
classes. I've done extensive benchmarking and I don't think it has an 
impact on performance. In any way, I wouldn't know how to handle this 
differently.


Let me know what you think.

Hannes

Am 2016-01-04 um 05:00 schrieb Sundararajan Athijegannathan:
I think I already commented on this webrev -- that we need to cover 
tests for BigInteger, BigDecimal.


Also, I'm not sure linking Double and Int by nashorn primitive 
linkers is the right solution. AtomicInteger, DoubleAdder etc. are 
all Number subtypes. We return "number" when typeof is used on any 
Number subtype.
Now, that means JS code will see these as 'number' type objects -- 
yet Number.prototype methods won't work on those!! I know this is 
hard problem -- we also have another (somewhat related) BigDecimal, 
BigInteger toString / String conversion issue. We need to discuss this.


-Sundar

On 1/2/2016 8:29 PM, Attila Szegedi wrote:

+1

On Dec 18, 2015, at 3:54 PM, Hannes Wallnoefer 
 wrote:


Please review JDK-8143896: java.lang.Long is implicitly converted 
to double


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

Thanks,
Hannes

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

[Hannes Wallnoefer]

I fixed a bug with converstion to number for the strict equality 
operator, which also revealed some left over usage of long in Nashorn 
internals. New webrev is here:


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

Hannes

Am 2016-01-11 um 13:48 schrieb Hannes Wallnoefer:
You are right of course, there needs to be consistency between typeof 
operator and treatment as JS numbers.


This is in fact an unpleasant problem to solve. I've struggled trying 
to fix this without breaking any existing code, but I've come to the 
conclusion that it is not possible. Since we can't treat all Java 
longs/Longs as JS numbers, we'd have to differentiate depending on 
whether the value can be represented as double without losing precision.


In a way we already do this with optimistic types, but I consider it 
more a bug than a feature. It's weird (and error prone) if the return 
value for a Java method returning long is reported as number or object 
depending on the actual value.


So I think the right thing to do is draw a clear line between which 
Java primitive/wrapper types represent JS numbers and which don't. 
I've uploaded a new webrev that implements this:


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

Note that the only types to be treated as JS numbers are the direct 
wrapper classes for Java primitives that can be fully represented as 
doubles. This means also things like AtomicInteger and DoubleAdder 
will be reported and treated as objects. I think that's the correct 
thing to do as they are not primitive numbers in the first place. They 
are still converted to numbers when used in such a context in JS. So I 
think the only place where this change is a actually 
painful/surprising is longs.


Unfortunately the check for number type in JSType.isNumber gets a bit 
long as we have to individually check for all primitive wrapper 
classes. I've done extensive benchmarking and I don't think it has an 
impact on performance. In any way, I wouldn't know how to handle this 
differently.


Let me know what you think.

Hannes

Am 2016-01-04 um 05:00 schrieb Sundararajan Athijegannathan:
I think I already commented on this webrev -- that we need to cover 
tests for BigInteger, BigDecimal.


Also, I'm not sure linking Double and Int by nashorn  primitive 
linkers is the right solution. AtomicInteger, DoubleAdder etc. are 
all Number subtypes. We return "number" when typeof is used on any 
Number subtype.
Now, that means JS code will see these as 'number' type objects -- 
yet Number.prototype methods won't work on those!! I know this is 
hard problem -- we also have another (somewhat related) BigDecimal, 
BigInteger toString / String conversion issue. We need to discuss this.


-Sundar

On 1/2/2016 8:29 PM, Attila Szegedi wrote:

+1

On Dec 18, 2015, at 3:54 PM, Hannes Wallnoefer 
 wrote:


Please review JDK-8143896: java.lang.Long is implicitly converted 
to double


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

Thanks,
Hannes

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

[Hannes Wallnoefer]

You are right of course, there needs to be consistency between typeof 
operator and treatment as JS numbers.


This is in fact an unpleasant problem to solve. I've struggled trying to 
fix this without breaking any existing code, but I've come to the 
conclusion that it is not possible. Since we can't treat all Java 
longs/Longs as JS numbers, we'd have to differentiate depending on 
whether the value can be represented as double without losing precision.


In a way we already do this with optimistic types, but I consider it 
more a bug than a feature. It's weird (and error prone) if the return 
value for a Java method returning long is reported as number or object 
depending on the actual value.


So I think the right thing to do is draw a clear line between which Java 
primitive/wrapper types represent JS numbers and which don't. I've 
uploaded a new webrev that implements this:


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

Note that the only types to be treated as JS numbers are the direct 
wrapper classes for Java primitives that can be fully represented as 
doubles. This means also things like AtomicInteger and DoubleAdder will 
be reported and treated as objects. I think that's the correct thing to 
do as they are not primitive numbers in the first place. They are still 
converted to numbers when used in such a context in JS. So I think the 
only place where this change is a actually painful/surprising is longs.


Unfortunately the check for number type in JSType.isNumber gets a bit 
long as we have to individually check for all primitive wrapper classes. 
I've done extensive benchmarking and I don't think it has an impact on 
performance. In any way, I wouldn't know how to handle this differently.


Let me know what you think.

Hannes

Am 2016-01-04 um 05:00 schrieb Sundararajan Athijegannathan:
I think I already commented on this webrev -- that we need to cover 
tests for BigInteger, BigDecimal.


Also, I'm not sure linking Double and Int by nashorn  primitive 
linkers is the right solution. AtomicInteger, DoubleAdder etc. are all 
Number subtypes. We return "number" when typeof is used on any Number 
subtype.
Now, that means JS code will see these as 'number' type objects -- yet 
Number.prototype methods won't work on those!! I know this is hard 
problem -- we also have another (somewhat related) BigDecimal, 
BigInteger toString / String conversion issue. We need to discuss this.


-Sundar

On 1/2/2016 8:29 PM, Attila Szegedi wrote:

+1

On Dec 18, 2015, at 3:54 PM, Hannes Wallnoefer 
 wrote:


Please review JDK-8143896: java.lang.Long is implicitly converted to 
double


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

Thanks,
Hannes

Re: Review request for JDK-8144919: Implement missing member handler for BeansLinker

[Michael Haupt]

Hi Attila,

lower-case thumbs up, with one remark in addition to Sundar's. In 
BeansLinkerTest, related to the comment "No assertion for the setter; we just 
expect it to silently succeed" - if it's expected to succeed, shouldn't success 
be tested by verifying the set value?

Best,

Michael

> Am 11.01.2016 um 05:03 schrieb Sundararajan Athijegannathan 
> :
> 
> * Spec. changes look good.
> 
> * Review comments on code changes:
> 
> Minor: BeansLinker.java - whitespace missing after "if"if(collectionType != 
> CollectionType.MAP && isFixedKey)
> and few other "if" statements too.
> 
> +1
> 
> PS. Not sure if the samples under $nashorn/samples have any dependency on 
> (older) BeansLinker behaviour.
> 
> -Sundar
> 
> On 1/6/2016 5:08 PM, Attila Szegedi wrote:
>> Excellent, thanks for preparing it. It looks good to me.
>> 
>> Attila.
>> 
>>> On Jan 6, 2016, at 12:28 PM, Sundararajan Athijegannathan 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> specdiff for this API change is here -> 
>>> http://cr.openjdk.java.net/~sundar/8144919/dynalink_specdiff/overview-summary.html
>>> 
>>> Thanks,
>>> -Sundar
>>> 
>>> On 12/24/2015 2:01 AM, Attila Szegedi wrote:
 Please review JDK-8144919 "Implement missing member handler for 
 BeansLinker" at  
 for 
 
 This change dependes on JDK-8144917, a review request for which 
 immediately preceded this one. I only plan to commit the two together 
 after they have been both reviewed.
 
 Note that I need a CCC review for this, as it touches the Dynalink public 
 API (details in the JIRA issue). As such, even if I get 2 reviews on this, 
 I will not be committing either this or 8144917 until CCC approval is 
 obtained.
 
 Thanks,
   Attila.
> 

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
  Oracle is committed to developing 
practices and products that help protect the environment

Re: Review request for JDK-8144917: Prepare AbstractJavaLinker/BeanLinker codebase for missing member implementation

[Michael Haupt]

Hi Attila,

lower-case thumbs-up, with one remark: 
AbstractJavaLinker.getNextComponent(ComponentLinkRequest) could be rewritten 
like so (matching patterns applied elsewhere in the patch):

GuardedInvocationComponent getNextComponent(final ComponentLinkRequest req) 
throws Exception {
if (!req.operations.isEmpty()) {
final GuardedInvocationComponent gic = 
getGuardedInvocationComponent(req);
return gic != null ? gic : getNextComponent(req.popOperations());
}
return null;
}

Best,

Michael

> Am 23.12.2015 um 21:30 schrieb Attila Szegedi :
> 
> Please review JDK-8144917 "Prepare AbstractJavaLinker/BeanLinker codebase for 
> missing member implementation" at 
>  for 
> 
> 
> This change has no functional effects, it's a refactoring for easier 
> introduction of the no-such-member implementation (JDK-8144919), a review for 
> which will immediately follow. I only plan to commit the two together after 
> they have been both reviewed.
> 
> Thanks,
>  Attila.

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
  Oracle is committed to developing 
practices and products that help protect the environment