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