It looks plausible that this could be related to my Error prototype issue from 
a few weeks back.

See http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003581.html

So I’d be happy to test the fix, or Hannes, in that message there are detailed 
reproduction instructions for a test case I developed.

— David.
On Oct 30, 2014, at 1:29 PM, Baq Haidri <[email protected]> wrote:

> Thanks guys, that's great news.
> 
> -----
> baq
> 
> ________________________________________
> From: Hannes Wallnoefer [[email protected]]
> Sent: Thursday, October 30, 2014 4:15 AM
> To: Marcus Lagergren; Baq Haidri
> Cc: [email protected]; Mark Pascual
> Subject: Re: Nashorn incorrectly binds "this" in constructors created and 
> returned by another function
> 
> I have a fix for this and I'm currently running tests to verify it. This
> will definitley make it into 8u40.
> 
> Hannes
> 
> Am 2014-10-30 um 11:46 schrieb Marcus Lagergren:
>> Any bugfix we manage to check in before the end of November will make it 
>> into 8u40. Hannes has diagnosed the problem and this is a p2, which is the 
>> highest priority of all Nashorn bugs for 8u40 right now (no p1s are filed), 
>> so I would say it is very likely it will make it into 8u40. Hannes - can you 
>> elaborate?
>> 
>> Regards
>> Marcus
>> 
>>> On 29 Oct 2014, at 20:09, Baq Haidri <[email protected]> wrote:
>>> 
>>> [email protected]
>>> 
>>> Hi Jim,
>>> 
>>> Thanks for escalating this so quickly.  This one's a pretty important for 
>>> us as LinkedIn is looking to standardize our production fleet to 8u40 as 
>>> soon as the GA release is available.  Can you give us an idea of whether 
>>> the fix will make it in to 8u40?
>>> 
>>> -----
>>> baq
>>> 
>>> ________________________________________
>>> From: Jim Laskey (Oracle) [[email protected]]
>>> Sent: Monday, October 27, 2014 12:09 PM
>>> To: Josh Fleming
>>> Cc: [email protected]; Mark Pascual; Baq Haidri
>>> Subject: Re: Nashorn incorrectly binds "this" in constructors created and 
>>> returned by another function
>>> 
>>> Just to let you know this has been promoted to 
>>> https://bugs.openjdk.java.net/browse/JDK-8062132.  We are investigating.
>>> 
>>> 
>>> On Oct 27, 2014, at 4:03 PM, Josh Fleming <[email protected]> wrote:
>>> 
>>>> Hi folks,
>>>> 
>>>> I filed a bug for this on the Oracle site (Review ID: JI-9016048), but was 
>>>> told that this list is the best place to discuss it.
>>>> 
>>>> So this is a strange one. It seems that the latest release of Nashorn 
>>>> incorrectly binds "this" in a constructor function under the following 
>>>> conditions:
>>>> 
>>>> * At least 2 level prototype hierarchy (for the sake of discussion let's 
>>>> call them Parent and Child)
>>>> * Child constructor functions are created and returned by a higher order 
>>>> "factory” function
>>>> * Child constructors call the Parent constructor, which uses “this”
>>>> * Multiple Child prototypes share the same Parent prototype
>>>> * The Child prototypes disagree in the *number* of their properties
>>>> 
>>>> When the second Child object instantiates, its constructor calls the 
>>>> Parent constructor, whose “this” is incorrectly bound to a Parent object 
>>>> rather than the Child.
>>>> 
>>>> Here's the jrunscript reduction (or 
>>>> https://gist.github.com/joshvfleming/0539f00dd12392483596):
>>>> 
>>>> // -- BEGIN CODE --
>>>> function subclass(parentConstructor, proto) {
>>>> function C() {
>>>>   parentConstructor.call(this);
>>>> }
>>>> 
>>>> C.prototype = Object.create(parentConstructor.prototype);
>>>> 
>>>> for (var prop in proto) {
>>>>   if (proto.hasOwnProperty(prop)) {
>>>>     C.prototype[prop] = proto[prop];
>>>>   }
>>>> }
>>>> 
>>>> return C;
>>>> }
>>>> 
>>>> var Parent = function() {
>>>> this.init();
>>>> };
>>>> 
>>>> Parent.prototype = {
>>>> init: null
>>>> }
>>>> 
>>>> var Child1 = subclass(Parent, {
>>>> prop1: 1,
>>>> init: function() {
>>>>   print('!!! child 1');
>>>> }
>>>> });
>>>> 
>>>> var Child2 = subclass(Parent, {
>>>> init: function() {
>>>>   print('!!! child 2');
>>>> }
>>>> });
>>>> 
>>>> new Child1();
>>>> new Child2();
>>>> // -- END CODE --
>>>> 
>>>> Expected output:
>>>> 
>>>> !!! child 1
>>>> !!! child 2
>>>> 
>>>> Actual output:
>>>> 
>>>> !!! child 1
>>>> script error in file scripts/nashorn_this_binding_bug_reduction.js : 
>>>> TypeError: null is not a function in 
>>>> scripts/nashorn_this_binding_bug_reduction.js at line number 19
>>>> 
>>>> The script blows up at line 19 (see above or 
>>>> https://gist.github.com/joshvfleming/0539f00dd12392483596) when the Parent 
>>>> constructor tries to call "this.init()". This function has been overridden 
>>>> in the Child objects that we instantiate at the bottom, but Nashorn 
>>>> incorrectly binds "this" to the Parent object, whose “init” is bound to 
>>>> "null" instead of an "init" function.
>>>> 
>>>> One especially strange and interesting aspect of this is that it depends 
>>>> on the relative number of properties of the two Child prototypes. The 
>>>> reduction above fails because Child1 has the "prop1" property, but Child2 
>>>> has none. If you add any property at all to Child2, the error goes away. 
>>>> If you add still another property, the error returns.
>>>> 
>>>> Affected JRE:
>>>> 
>>>> Java version "1.8.0_25"
>>>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>>>> 
>>>> This bug appears to be a regression, as the following older JRE returns 
>>>> the "Expected" output:
>>>> 
>>>> java version "1.8.0_05"
>>>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
>>>> 
>>>> We’re stuck on 1.8.0_05 at this point, because one of our 3rd party 
>>>> libraries uses this inheritance pattern.
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> jf
>>>> 
> 

Reply via email to