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)
improvements:
Subject:
Rhino: Problem in NativeJavaMethod
Date:
Tue, 14 Aug 2001 10:23:35 +0200
From:
felix.meschberger@day.com
To:
Norris Boyd <nboyd@atg.com>
Hi Norris,
While working with wrapped Java classes we discovered a problem in
NativeJavaMethod : If the public method to be called is part of a
non-public class, the Sun Java VM throws an IllegalAccessException. This
bug in the Sun VM has been reported as Bug 4071593 to Sun, but has not been
resolved since....
I implemented a circumvention, for which I provide you the patch. I quickly
tested it, and it seems to work.
Regards
Felix
And here's the patch :
diff -w -r1.19 NativeJavaMethod.java
227a228,234
> /**
> * Due to a bug in Suns VM, public methods in private
> * classes are not accessible by default (Sun Bug #4071593).
> * We have to explicitly set the method accessible beforehand
> */
> meth.setAccessible(true);
>
-----------------------------------------------------------------
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying to
this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble-free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:felix.meschberger@day.com
http://www.day.com
Felix Meschberger
Development
Day Interactive AG
Steinenberg 21-23
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
jband%netscape.com
nboyd%atg.com
rginda%netscape.com
pschwartau%netscape.com
brendan%mozilla.org
thesteve%netscape.com
rogerl%netscape.com
rjesup%wgate.com