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
