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 >>>
