The change required to move security domain information form InterpreterData to its Scriptable wrappers. To simplify it and to make the interpreted functions to behave exactly as class compiled I merged InterpretedScript into InterpretedFunction which allowed to remove many casts and discrepancies when handling script and function instances.
2. Explicitly passing Interpreter instances to Context.compile... functions to avoid changing optimization level even temporarily.
3. Uniform initialization of class compiled and interpreted functions and scripts to avoid code duplication.
Since changes to fix bug 254778 made the parser the sole source of syntax error reports, it removed the need to check for errors after tree transformation.
The patch removes those checks and moves all reporting about syntax errors into omj/Parser.java.
Since E4X implementation needs to know the activation scope for tracking of default namespaces, previously an elaborated schema was added to set/restore the activation scope which relied on the fact that scrip and function with activation record should always call special entry/exit functions.
But that does not work for functions without activation records since they never call any special entry/exit pairs. So if application call such function directly, the function would not store its top scope anywhere and the E4X subsystem would not be able to get E4X library object.
The patch fixes with introduction of 2 functions, hasTopCall and doTopCall to ScriptRuntime and adding the following code prefix to each implementation of Callable.call that can start execution of script code:
public Object call(Context cx, Scriptable scope,
Scriptable thisObj, Object[] args)
throws JavaScriptException
{
// Prefix start
if (!ScriptRuntime.hasTopCall(cx)) {
return ScriptRuntime.doTopCall(this, cx, scope, thisObj, args);
}
// Prefix end
...
In this way there is always registered top scope during script execution and the previous elaborated schema became unnecessary so I reverted that part to almost pre-E4x state.
2. xml/XMLObject do not define lib() method and instead defines few abstract methods to create "with" proxies and perform addition.
3. XMLLib implementation is stored in the scope using ScriptableObject.associateValue() and does not depend on presence of proper XML object.
ScriptRuntime.get(Name|Prop|Elem|Value)FunctionAndThis provides uniform way to get function object and its this during function calls. It allowed to simplify handling of method calls both in interpreter and optimizer and opened a way to implement independent processing of function and property namespaces.
