It would be nice if the rhino shell would accept a URL as the source
for javascript.
I've added this feature to my local copy so that I can launch rhino
with js scripts using JavaWebStart.
Below is a context diff of the changes I made to
toolsrc/org/mozilla/javascript/tools/shell/Main.java
There is a bug in the JavaMembers class called to wrap a Java object.
In JavaMembers.lookup(), code was added to override the static type. The
code works in the case of an Enumeration returning an Object which would
have to be casted to the appropriate type.
The code does not work when the static type is an interface. In this case,
the interface class is the one which should be reflected, not a parent class
of the dynamic type. A simple staticType.isInterface() check around the
parent traversal code fixes the problem.
Jeff
I have found a couple problems with running Rhino 1.5R2 in a heavily
multi-threaded environment. The attached patches fix the problems.
- org.mozilla.javascript.optimizer.InvokerImpl - This class was accessing
the shared classNumber outside of the synchronized block.
- org.mozilla.javascript.optimizer.OptClassNameHelper - The reset method was
not synchronized. It needs to be because the class using the classNames map
is synchronized and does not handle nulling of the variable while it's
looping on the map.
Jeff
- The most significant fix, to keep JSStackFrame.spbase, the operand stack base pointer for an active frame, null except when there is an operand stack allocated and in use by js_Interpret. Previously, spbase would point after args and local vars (if any), then advance upon allocation of the (possibly discontiguous) operand stack space. This made for a fatal ambiguity: js_AllocStack, called by XPConnect, could not tell when there was allocated operand stack space above the frame's sp, which needs to be set to a known (JSVAL_VOID) state for exact GC to work. Now, the GC doesn't have to mark any operand stack space for a frame whose spbase is null, and js_AllocStack doesn't need to void any unused space for such a frame.
- Fixes to reload the JSRuntime's callHook or executeHook after calling or executing, in case the debugger removes the hook. In which case, it must clean up any dynamic memory held by hookData, but in any event, in which case the engine must not call the post-call or post-execute hook.
- While debugging with rginda, I was horrified to see his trivial testcase function, expressed as a lambda, fail to be invoked using the "inline_call" machinery in js_Interpret (which avoids js_Interpret recursion through js_Invoke for most JS functions). The problem was a test of fun->flags == 0 conditioning the /* inline_call: */ code. Since that test was written, at least one JSFUN_* flag (JSFUN_LAMBDA, used only for pretty-printing or accurate decompilation) has been added. But all along, that test was an over-optimization (testing against 0 without &'ing certain flags), making for an accident waiting to happen -- which did happen. The relevant flags are JSFUN_HEAVYWEIGHT (set by the compiler when a function calls eval, uses with, or otherwise needs an activation object for its scope; if lightweight, the compiler can see the function's scope and eliminate it via specialized bytecodes) and JSFUN_BOUND_METHOD (for Java method calls, where |this| binds statically to the instance, not dynamically to the calling expression reference's base object, as in JS).
don't allow gc's during script hooks if CAUTIOUS_SCRIPTHOOK is defined (which it is, by default.) Should help with stability until we can fix the real problems.
Use JSVAL_ macros instead of JSD_* calls in jsdValue::GetJSType method, avoiding two c++ frames per call.
Also, fixes for :
#91343, (non-latin1 fails for [\S])
#78156, (Unicode line terminator matching)
#87231, (/(A)?(A.*)/ didn't reset paren state for empty first match)
