Details
-
Bug
-
Resolution: Fixed
-
P4
-
None
-
None
-
b74
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8136310 | emb-9 | Sundararajan Athijegannathan | P4 | Resolved | Fixed | team |
JDK-8140961 | 8u91 | Sundararajan Athijegannathan | P4 | Resolved | Fixed | b01 |
JDK-8132519 | 8u72 | Sundararajan Athijegannathan | P4 | Resolved | Fixed | b01 |
JDK-8147330 | emb-8u91 | Sundararajan Athijegannathan | P4 | Resolved | Fixed | b01 |
Description
Object.freeze(this); var x = 10; print(x);
-> undefined
Object.freeze(this); eval("var x = 10"); print(x)
-> 10
eval "works around" frozen nature of Global object.
With v8 and Rhino, 'undefined' is printed in the first case. In the second case ReferenceError is thrown for "x"!!
Per my reading of the ECMAScript 5.1 spec., it appears "var x = 10" should result in TypeError in the "eval" case.
Reason:
* per 10.2.3 The Global Environment section
/ The global environment is a unique Lexical Environment which is created before any ECMAScript code is executed. The global environment’s Environment Record is an object environment record whose binding object is the global object (15.1). /
=> global is an object environment record.
* CreateMutableBinding on Object environment records is defined here:
https://es5.github.io/#x10.2.1.2.2
Step 5 is as follows:
/Call the [[DefineOwnProperty]] internal method of bindings, passing N, Property Descriptor {[[Value]]:undefined, [[Writable]]: true, [[Enumerable]]: true , [[Configurable]]: configValue}, and true as arguments./
* [[DefineOwnProperty]] as defined in https://es5.github.io/#x8.12.9
says:
/ In the following algorithm, the term “Reject” means “If Throw is true, then throw a TypeError exception, otherwise return false”./
And Step 3 is
/ If current is undefined and extensible is false, then Reject./
So, it appears TypeError should be thrown for frozen global when a new mutable binding is attempted on it.
In any case, Nashorn's current behaviour is inconsistent. at the mininum, "var x =10" via "eval" should also be ignored like v8 and rhino do. i.e., can not create new binding when global is frozen.
-> undefined
Object.freeze(this); eval("var x = 10"); print(x)
-> 10
eval "works around" frozen nature of Global object.
With v8 and Rhino, 'undefined' is printed in the first case. In the second case ReferenceError is thrown for "x"!!
Per my reading of the ECMAScript 5.1 spec., it appears "var x = 10" should result in TypeError in the "eval" case.
Reason:
* per 10.2.3 The Global Environment section
/ The global environment is a unique Lexical Environment which is created before any ECMAScript code is executed. The global environment’s Environment Record is an object environment record whose binding object is the global object (15.1). /
=> global is an object environment record.
* CreateMutableBinding on Object environment records is defined here:
https://es5.github.io/#x10.2.1.2.2
Step 5 is as follows:
/Call the [[DefineOwnProperty]] internal method of bindings, passing N, Property Descriptor {[[Value]]:undefined, [[Writable]]: true, [[Enumerable]]: true , [[Configurable]]: configValue}, and true as arguments./
* [[DefineOwnProperty]] as defined in https://es5.github.io/#x8.12.9
says:
/ In the following algorithm, the term “Reject” means “If Throw is true, then throw a TypeError exception, otherwise return false”./
And Step 3 is
/ If current is undefined and extensible is false, then Reject./
So, it appears TypeError should be thrown for frozen global when a new mutable binding is attempted on it.
In any case, Nashorn's current behaviour is inconsistent. at the mininum, "var x =10" via "eval" should also be ignored like v8 and rhino do. i.e., can not create new binding when global is frozen.
Attachments
Issue Links
- backported by
-
JDK-8132519 Non-extensible global is not handled property
- Resolved
-
JDK-8136310 Non-extensible global is not handled property
- Resolved
-
JDK-8140961 Non-extensible global is not handled property
- Resolved
-
JDK-8147330 Non-extensible global is not handled property
- Resolved