1. Keyword search via Java Hahstable is replaced by explicit "switch"
code generated by idswitch tool. It not only speed up keyword search and
eliminates all Integer objects created to hold keyword tokens and
corresponding Hahstable structures, but it also reduces code size due to
very poor array initialization support in JVM.
2. It replaces the isXDigit method by xDigitToInt that either converts
its argument to 0..15 or returns -1 if it is not a hex digit and updates
the method usage accordingly The patch updates NativeGlobal.js_unescape
to reflect this usage change.
In the attached patch I added documentation, did some inlining in the
get method implementation to gain some speed and overrode defineProperty
so it plays better with id-based properties.
-----
The patch fixes a bug in getIds method where the assignment "result =
tmp" was missed, adds the public method activateIdMap(int maxId) to
IdScriptable and changes setAttributes method not to allow setting of
attributes that are less restrictive then ones returned by
getIdDefaultAttributes. That was supposed to be the case and the patch
makes it explicit.
-----
The patch makes BaseFunction.setImmunePrototypeProperty public so it can
be called from other packages (regexp).
-----
The patch switches NativeRegExp and NativeRegExpCtor to use
IdScriptable. It also changes code in a few places to passes Context and
RegExpImpl directly instead of using Context.getCurrentContext().
The patch also fixes a bug when
for (var i in RegExp) { print(i); }
would not include $1..$9 in the output in violation with Ecma. It was
caused by not overriding ScriptableObject.getIds in
NativeRegExpCtor.
-----
The patch changes NativeCall to use IdScriptable. This is done mostly
for uniformity with other Native* classes plus it would allow to call
NativeCall.init directly and make NativeCall package private.
-----
The patch changes NativeScript to use id-based properties. Due to
inheritance from NativeFunction, id support requires to take into
account the fact that there are instance ids available from
BaseFunction. This is the reason to use "int prototypeIdShift" instead
of "boolean prototypeFlag" so it can store instance id offset.
The patch updates ScriptRuntime.callOrNewSpecial to check against
IdFunction and not FunctionObject for the Script exec method where it
also add finally clause to make sure that Context.exit would always be
called after Context.enter in the evalScript method.
-----
After converting NativeScript and NativeFunction to use IdScriptable,
they get scope argument directly as a parameter of execMethod call, so
cx.ctorScope is not used any more. The patch removes code to set/unset
cx.ctorScope.
-----
[This patch depends on conversion of NativeScript and NativeCall to use
IdScriptable and the patch to remove access of ctorScope from
FunctionObject]
The patch changes Context.initStandardObjects to call NativeCall.init
and NativeScript.init directly plus it unrolls the lazily initialization
loop. Due to rather poor support of an array initialization in Java byte
code, it actually decreases code size while eliminating are creation of
array object. The patch also removes ctorScope field as unused.
-----
The patch makes sure that ids used by NativeGlobal are visible only in
the object instance that initializes global scope and removes some junk
white space at line ends.
-----
To use the idswitch tool to generate map for strings that can not be
part of Id_ Java identifier like $*, I added code to the tool to look
for "// #string=...#" in the id definition line. The attached README
file also contains some documentation about the tool and should go to
idswitch directory.
The patch was made from toolsrc/org/mozilla/javascript/tools via:
cvs diff -u > idswitch_patch
----
The patch changes Notification to extend from BaseFunction and adjusts
Context, FunctionObject and NativeScript accordingly.
----
The patch changes BaseFunction.jsConstructor to use the scope argument
passed to execMethod instead of using cx.ctorScope. This argument is
null in this case because when calling execMethod IdFunction.construct
does not set cx.ctorScope because scope is passed to execMethod as argument.
for classes implementing the Function interface and switch
IdFunction.java to use it. The code in BaseFunction to serve as
Function.prototype is not used yet. The patch modifies NativeCall so it
can be used against BaseFunction.
The patch was made from org/mozilla directory via
diff -uN javascript.0 javascript > BaseFunction_patch
in fields of the object itself instead of using the standard property
hashtable in ScriptableObject.java. This saves 3 object instances per
NativeError (2 slot entries and hashtable array itself) and given the
fact that NativeGlobal defines a few permanent Error instances, it is
visible saving even after taking into account code size increase.
The change also gives a good test of IdScriptable implementation.
-----
This patch introduces the uniform decompile method for NativeFunction
and IdFunction with the signature:
public String decompile(Context cx, int indent, boolean justbody)
instead of NativeFunction.decompile(int indent, boolean toplevel,
boolean justbody) and IdScriptable.toStringForScript(Context cx) and
replaces the special treatment of NativeJavaMethod in
NativeFunction.jsFunction_toString by overriding decompile in
NativeJavaMethod
-----
This patch adds getFunctionName to NativeFunction to return function
name and replaces few places with jsGet_name usage by getFunctionName
The patch was made via
diff -ru javascript.0 javascript > name_patch
from org/mozilla directory
Rhino: behavior update for IdScriptable subclasses
Date:
Fri, 18 May 2001 11:45:00 +0200
From:
Igor Bukanov <igor.bukanov@windriver.com>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The attached patch introduces separation between id-base properties in
prototype instances and the rest of objects so it is possible to
allocate some ids for each instance and the rest only for prototype. The
patch adds to each descendants of IdScriptable a special prototypeFlag
which set to true only if object serves as a global prototype and all
methods that check/return ids first check for that flag. (This is the
reason for the patch size: diff is not very well in dealing with
indentation changes.)
In this way ids for prototype properties are completely hidden from
potential subclasses and there is no need to define methods like
getMaximumId in most cases, only if some ids present in each instance,
IdScriptable.maxInstanceId should be overridden to return max id present
in each instance.
The patch also replaces 2 boolean fields in IdScriptable by bit masks in
the setupFlag field.
Subject:
Embedding Rhino in an Applet
Resent-Date:
Thu, 17 May 2001 14:53:05 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
Thu, 17 May 2001 16:39:14 -0700
From:
"Chester Kustarz II" <chester@monkey.org>
Organization:
monkey.org
To:
mozilla-jseng@mozilla.org
Newsgroups:
netscape.public.mozilla.jseng
Hello, I am trying to find a scripting language with an interpreter that I
can embed in an applet in order to run test scripts inside the applet. I
have already tried TCL-based Jacl and they do not support running inside an
applet. I then downloaded the Rhino/JS interpreter but am having trouble
getting it to run inside the browser (IE 5.5). Here is the exception I am
getting:
com.ms.security.SecurityExceptionEx[org/mozilla/javascript/ScriptRuntime.<cl
init>]: Reflective access to class java.lang.Thread prohibited.
at com/ms/security/permissions/ReflectionPermission.check
at com/ms/security/PolicyEngine.deepCheck
at com/ms/security/PolicyEngine.checkPermission
at com/ms/security/StandardSecurityManager.chk
at com/ms/security/StandardSecurityManager.checkMemberAccess
at java/lang/Class.checkMemberAccess
at java/lang/Class.getDeclaredMethod
at org/mozilla/javascript/ScriptRuntime.<clinit>
at org/mozilla/javascript/ScriptableObject.getExclusionList
at org/mozilla/javascript/ScriptableObject.defineClass
at org/mozilla/javascript/Context.initStandardObjects
at org/mozilla/javascript/Context.initStandardObjects
at RhinoShellApplet.init
at com/ms/applet/AppletPanel.securedCall0
at com/ms/applet/AppletPanel.securedCall
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.run
at java/lang/Thread.run
com.ms.security.SecurityExceptionEx[org/mozilla/javascript/Context.initStand
ardObjects]: Unable to access system property:
org.mozilla.javascript.JavaAdapter
at com/ms/security/permissions/PropertyPermission.check
at com/ms/security/PolicyEngine.shallowCheck
at com/ms/security/PolicyEngine.checkCallersPermission
at com/ms/security/StandardSecurityManager.chk
at com/ms/security/StandardSecurityManager.checkPropertyAccess
at java/lang/System.getProperty
at org/mozilla/javascript/Context.initStandardObjects
at org/mozilla/javascript/Context.initStandardObjects
at RhinoShellApplet.init
at com/ms/applet/AppletPanel.securedCall0
at com/ms/applet/AppletPanel.securedCall
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.run
at java/lang/Thread.run
1. In that patch I forgot to remove "import org.mozilla.classfile.*" and
simply catch Exception in newInvokerMaster which is not a good practice.
The attached patch FunctionObject_patch fixes that and removes other
unused imports.
2. In org.mozilla.classfile.DefiningClassLoader defineClass method first
tries to call via ClassManager the defineClass method in a class loader
that loaded DefiningClassLoader itself. But this would define new
classes in that class loader so they would not be subject of the garbage
collection until a classloader that loads DefiningClassLoader would go
away even if a DefiningClassLoader instance is gone. The
DefiningClassLoader_patch removes that and simply calls super.defineClass.
The patch also change the order of class search in loadClass so the
loader first looks for a class among its defined classes and only after
that in parent loaders.
Regards, Igor
1. In that patch I forgot to remove "import org.mozilla.classfile.*" and
simply catch Exception in newInvokerMaster which is not a good practice.
The attached patch FunctionObject_patch fixes that and removes other
unused imports.
2. In org.mozilla.classfile.DefiningClassLoader defineClass method first
tries to call via ClassManager the defineClass method in a class loader
that loaded DefiningClassLoader itself. But this would define new
classes in that class loader so they would not be subject of the garbage
collection until a classloader that loads DefiningClassLoader would go
away even if a DefiningClassLoader instance is gone. The
DefiningClassLoader_patch removes that and simply calls super.defineClass.
The patch also change the order of class search in loadClass so the
loader first looks for a class among its defined classes and only after
that in parent loaders.
Regards, Igor
> Igor Bukanov wrote:
>
>
>>Norris Boyd wrote:
>>
>>
>>>The intention was to keep classfile and JavaAdapter optional. Those
>>>dependencies crept in. We can use Invoker optionally--perhaps I should do
>>>some performance numbers to see if it's worth it.
>>>
>>I implemented that patch, it splits Invoker.java into Invoker.java and
>>its implementation in optimizer/InvokerImpl.java The reason to put it
>>into optimizer package is that Invoker is very similar in spirit to
>>NativeScript: it generates classes to speed up access and in this way
>>there is no need to have separated option not to use: one can simply
>>remove optimizer all together.
>>
>
> Yes, that sounds great.
>
>
>>
>>I noticed during implementation that JavaAdapter.DefiningClassLoader and
>>optimizer/JavaScriptClassLoader contains the same code, so maybe they
>>can be moved to org.mozilla.classfile package under one name?
>>
>
> Yes, that sounds like a good change too. Thanks for noticing that.
The update is pretty messy: it touches FunctionObject which I changed to
remove the special treatment of NativeWith in the previous patch, and it
also add/removes files.
Here is a description:
DefiningClassLoader.java should go to org/mozilla/classfile. It is the
same code that was in omj/optimizer/JavaScriptClassLoader.java with
class rename and adding public attribute and correspondingly
omj.optimizer/JavaScriptClassLoader.java should be removed. I guess it
would be nice to preserve logs/history in CVS during the move.
InvokerImpl.java should go to omj/optimizer. It is mostly what
omj.Invoker was.
invoker_changes_patch was generated via
cvs diff -u Invoker.java JavaAdapter.java optimizer/Codegen.java
and contains changes against the current CVS
FunctionObject_invoker_patch was generated via
diff -u ../../mozilla.1/javascript/FunctionObject.java FunctionObject.java
and contains changes against that With patch.
Igor
constructor, removes the special treatment of the With object from
IdScriptable and FunctionObject, adds to IdFunction the
initAsConstructor method similar in spirit to
FunctionObject.addAsConstructor (it is called now from IdScriptable and
NativeWith) and replaces in Context.java lazy initialization of
NativeWith by direct call of NativeWith.scopeInit.
The attached patch moves the IdFunction.Master interface to the
separated file IdFunctionMaster and eliminates getParentScope from the
interface: it is simpler to set scope explicitly.
The patch assumes the changes in IdFunction.java from the previous patch
and were produced via:
diff -uP javascript.2000-05-10 javascript
Regards, Igor
The attached patch allows subclasses of IdScriptable to override
hasIdValur/deleteIdValue and uses lazy initialization for idMapData
array to avoid its creation when an IdScriptable descendant does not
have any functions. The patch also touches NativeMath.java to replace in
its scopeInit method
super.scopeInit(cx, scope, sealed);
by
activateIdMap(cx, sealed);
This is the only reason NativeMath needs to call
IdScriptable.scopeInit() which is intended for creation
constructor/prototype pair.
Regards, Igor
Rhino: optimization for NativeFunction.java
Date:
Mon, 07 May 2001 14:19:59 +0200
From:
Igor Bukanov <igor.bukanov@windriver.com>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
This is the first of 3 patches that are completly independent from each
other.
Currently in NativeFunction its name stored as the first element in the
names array. But this lead to creation of a single element array for
each FunctionObject and for each script function that does not have
arguments or variables. The attached patch splits NativeFunction names
into simple functionName and argNames arrays and adjust code elsewhere
accordingly. This patch can increase memory footprint for anonymous
script functions without arguments because it adds additional field to
each NativeFunction, but I do not think this is a case to worry about.
Regards, Igor
Date: Mon, 07 May 2001 14:25:34 +0200
From: Igor Bukanov <igor.bukanov@windriver.com>
Organization: Wind River
To: Norris Boyd <nboyd@atg.com>
The current code that implements execMethod/methodArity for IdFunction
support returns an arbitrary value for id that is not known. This is not
very good behavior because it may hide bugs in the id support and it
also does not allow to distinguish ids that are used for function from
ids used for properties like String.length.
To fix this I changed semantic of the methodArity method to return -1
for an unknown/non-method id and added code to throw an exception for
bad ids. This change requires to adjust all NativeSomething objects that
use IdScriptabl and after a release all such interface changes would be
no go, but is not a release yet, right?
I also eliminated the "IdFunction f" argument from
IdFunction.Master.methodArity and the tagId field from IdFunction. When
I wrote the initial code for IdFunction.java, I added that just to be
able to use same id number in a class that implements IdFunction.Master
and its descendants via checking idTag. But that does not work in
general because IdScriptable can use id for non-function fields as well
so to avoid id clashes another way should be used. For example, if
someone would like to extend NativeMath to support more functionality,
he can use:
class Math2: extends NativeMath {
private static idBase;
{
if (idBase == 0) idBase = super.getMaximumId();
}
public int methodArity(int methodId) {
switch (methodId - idBase) {
case Id_foo: return 2;
case Id_bar: return 3;
}
return super.methodArity(methodId);
}
public Object execMethod
(int methodId, IdFunction f,
Context cx, Scriptable scope, Scriptable thisObj, Object[] args)
throws JavaScriptException
{
switch (methodId - idBase) {
case Id_foo: return ...;
case Id_bar: return ...;
}
return super.execMethod(methodId, f, cx, scope, thisObj, args);
}
protected int getMaximumId() { return idBase + MAX_ID; }
protected String getIdName(int id) {
switch (id - idBase) {
case Id_foo: return "for";
case Id_bar: return "bar";
}
return super.getIdName(id);
}
...
private static final int
Id_foo = 1,
Id_bar = 2,
MAX_ID = 2;
etc.
Note that a simpler solution to make MAX_ID field public in NativeMath
and write in Math2:
private static final int
Id_foo = NativeMath.MAX_ID + 1,
Id_bar = NativeMath.MAX_ID + 2,
MAX_ID = NativeMath.MAX_ID + 2;
does not work because in this way adding any new id to NativeMath would
break binary compatibility with Math2.
Rhino: fix for race conditions in listeners code in Context.java
Date:
Mon, 07 May 2001 14:22:57 +0200
From:
Igor Bukanov <igor.bukanov@windriver.com>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The current code for listeners and contextListeners in Context.java is
not race condition free. If contextListeners Vector would be modified
during context event firing loops, the code can produce
index-out-of-bounds exception. The problem with listeners array is more
subbtle and comes from the fact that ListenerCollection.java uses code like:
for(Enumeration enum = getAllListeners();enum.hasMoreElements();) {
Object listener = enum.nextElement();
if(iface.isInstance(listener)) {
array.addElement(listener);
}
}
where getAllListeners() uses Vector.elements to get element enumeration.
But to work with such enumeration in a thread safe way, one has to
synchronized against Vector, otherwise between enum.hasMoreElements()
and enum.nextElement() the last element can be removed.
Initially I thought to fix ListenerCollection and use it for
contextListeners as well, but then I realized that in its current form
ListenerCollection is very inefficient (it produces too many objects
just to get simple array to fire events), so I wrote ListenerArray.java
and use it in Context.java. It makes life simpler and shrinks code as well.
Subject:
rhino bug(s)
Date:
Mon, 30 Apr 2001 23:07:00 -0700
From:
Mike Dixon <MDixon@placeware.com>
To:
nboyd@atg.com
hi. i'm a happy rhino user, and just stumbled across what looks like a
pretty basic bug in the property stuff on ScriptableObject... (i'm running
1.5, but it looks like this code hasn't changed in CVS.) since it looks
like you're actively developing (even though it's been a while since
1.5...) i figured you might be interested -- apologies if i missed a more
formal bug reporting process...
the symptom was that i got a "Hashtable internal error" thrown from
getSlotToSet. reading the code, here's what i think could happen:
- create a new object (slots.length is initially 5)
- add 3 properties
- delete those 3 properties
(now count == 0, and slots[i] == REMOVED for 3 values of i)
- add 2 more properties
now assume that you're unlucky, and that these two hash to different values
than the first three; now you have 2 elements of slots[] containing real
slots, and the other three containing REMOVED.
now what happens when you try to create another slot? getSlotToSet is only
willing to put something in a null slot[], and you haven't got one, so you
get the internal error.
writing this message encouraged me to try to write a test case to reproduce
it, and in fact it's trivial:
js> x={}; x.a=x.b=x.c=1; delete x.a; delete x.b; delete x.c; x.d=x.e=1
1
js> x.whatever=1
(boom)
by the way, while reading the code i also noticed what looks like another,
less consequential bug: addSlot increments count before deciding to grow
the table, which is done with a recursive call, which will cause count to
be incremented again -- right? as far as i can tell, setting count too big
will only cause it to grow the table a little early next time, so it
doesn't really matter, but it looks wrong.
.mike.
mozilla/js/rhino/org is now distributed between
mozilla/js/rhino/src and mozilla/js/rhino/toolsrc.
The build.xml has been split in three.
Docs now live in the project directory.
These changes mean that the cvs directories mirror the distribution and thus a distribution
will build the same way as a cvs build.
I attach optimization patch for NativeDate that makes all js... methods
private, removes passing of unnecessary parameters and replaces
checkInstance by realThis call with false as the third parameter.
Regards, Igor
Hi, Norris!
Here is another small optimization for NativeDate in DayFromMonth method
where it replaces arrays by few ifs.
Regards, Igor
Rhino: patch for IdScriptable.java and question about useDynamicScope
Date:
Mon, 16 Apr 2001 17:55:19 +0200
From:
Igor Bukanov <igor.bukanov@windriver.com>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
Here is a patch to IdScriptable.java that fixes sealed semantic and
makes Something.prototype.constructor to behave just as having DONTENUM
attribute, not DONTENUM|READONLY|PERMANENT. It also renames
seal_function to sealFunctions.
I also have a following question. I added nextInstanceCheck to
IdScriptable.java and its usage in realThis in NativeDate to emulate
code from FunctionObject where it looks up prototype in search for
NativeSomething instance if useDynamicScope is true. But could you
describe why it is necessary? I can understand why doing something like
var proto = new Date();
function Test() { }
Test.prototype = proto;
var test = new Test();
print(test.getDay()); // same as proto.getDay()
would be useful in ceratain situations, but what it has to do with
shared scopes?
Regards, Igor
Minor fix to JSDebugger
Date:
Wed, 28 Mar 2001 16:34:24 -0800
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
nboyd@atg.com
Hi Norris,
Attached is a minor fix to the JSDebugger GUI that causes the tool-bar buttons to all have the same width.
I checked out and modified a file from CVS today. See the screenshot below.
Cheers,
Chris
* fixed ImporterTopLevel constructor - it now calls
cx.initStandardObjects before defining any functions. The old
constructor is still around for backwards compatibility.
Rhino Context.setTargetClassFileName() null pointer exception
Date:
Tue, 20 Feb 2001 15:28:20 -0800
From:
"Ryan Manwiller" <rdm@europa.com>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I'm setting the file name to compile to a file. However, on subsequent
compiles, I don't want to compile to a file, so I tried
setTargetClassFileName(null). This causes a NullPpinterException in
OptClassNameHelper.setTargetClassFileName(OptClassNameHelper.java:76)
It seems that Context.setTargetClassFileName() should check for null.
Thanks
Subject:
Rhino Exception Handling: Inconsistency btw Old/New Versions of 1.5
Date:
Mon, 05 Feb 2001 06:07:07 -0800
From:
Timothy Bergeron <bergeron@resumerabbit.com>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I've been using Rhino for about a year with almost no problems. However,
I downloaded the latest Rhino tip (rhino15R2pre) and discovered a
significant difference in exception handling.
I rely heavily on JavaScript code like the following:
try {
var em = new ExceptionMaker();
em.npe(); // method throws a java.lang.NullPointerException
//em.ae(); // method throws a Packages.AutomationException
}
catch (e if (e instanceof java.lang.NullPointerException)) {
java.lang.System.out.println("Caught a NullPointerException");
e.printStackTrace();
}
catch (e if (e instanceof Packages.AutomationException)) {
java.lang.System.out.println("Caught an AutomationException");
}
catch (e) {
java.lang.System.out.println("Caught an unexpected exception: "+e);
}
finally {
java.lang.System.out.println("Finally!");
}
Previous Rhino versions worked as expected. The exception thrown from
within the host object would be caught and the appropriate actions could
be taken.
With the most recent tip, the thrown exceptions simply are not caught
within the JavaScript. They propagate back to the Java function invoking
the (in my case) Context.evaluateReader() method.
Running the above JS fragement with the older tip displayed the
following stack trace (when the NullPointerException was caught):
Rhino Version: JavaScript-Java 1.5 release 1 2000 03 15
Caught a NullPointerException
java.lang.NullPointerException
at java.lang.Throwable.<init>(Throwable.java:84)
at java.lang.Exception.<init>(Exception.java:35)
at java.lang.RuntimeException.<init>(RuntimeException.java:39)
at
java.lang.NullPointerException.<init>(NullPointerException.java:45)
at ExceptionMaker.jsFunction_npe(ExceptionMaker.java:13)
at java.lang.reflect.Method.invoke(Native Method)
at
org.mozilla.javascript.FunctionObject.call(FunctionObject.java:497)
at
org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1205)
at org.mozilla.javascript.gen.c1.call(exception.js:3)
at org.mozilla.javascript.gen.c1.exec(exception.js)
at
org.mozilla.javascript.Context.evaluateReader(Context.java:739)
at js.main(js.java:14)
Finally!
When run with the latest tip, the output is:
Rhino Version: JavaScript-Java 1.5 release 1 2000 03
15 Finally!
Exception in thread "main" java.lang.NullPointerException
at java.lang.Throwable.<init>(Throwable.java:84)
at java.lang.Exception.<init>(Exception.java:35)
at java.lang.RuntimeException.<init>(RuntimeException.java:39)
at
java.lang.NullPointerException.<init>(NullPointerException.java:45)
at ExceptionMaker.jsFunction_npe(ExceptionMaker.java:13)
at inv2.invoke()
at
org.mozilla.javascript.FunctionObject.doInvoke(FunctionObject.java:843)
at
org.mozilla.javascript.FunctionObject.call(FunctionObject.java:486)
at
org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1199)
at org.mozilla.javascript.gen.c1.call(Unknown Source)
at org.mozilla.javascript.gen.c1.exec(Unknown Source)
at
org.mozilla.javascript.Context.evaluateReader(Context.java:778)
at js.main(js.java:14)
Curiously, both Rhino versions seem to be returning the same string from
Context.getImplementionVerison();
Anyway, the results from the two runs are clearly different: In the
first case, the exception is thown, the correct catch block is invoked
(hence the stace trace), and the finally block is invoked. In the second
case, the exception is thrown, the finally block is invoked, and the
exception is handled by the calling Java method rather than being
handled by the JavaScript code.
After some research, it appears this change was introducted by a
modification to FunctionObject.call() (See
http://bugzilla.mozilla.org/show_bug.cgi?id=64788) which used to have:
try {
Object result = (method != null)
? method.invoke(thisObj, invokeArgs)
: ctor.newInstance(invokeArgs);
return hasVoidReturn ? Undefined.instance : result;
}
but now has:
Object result = method == null ?
ctor.newInstance(invokeArgs)
: doInvoke(thisObj,
invokeArgs);
If I comment out the new code and replace it with the old, the expected
exception handling returns. Is this just an oversight or the new
expected behavior? Are there any negative side effects (other then the
speed decrease in method invocation) if I use the latest tip but use the
old method invocation procedure in FunctionObject.call() rather than the
new?
Re: [Rhino in Java] compiling .js to class file gives "bad local" error
Date:
Wed, 31 Jan 2001 09:41:45 +0100
From:
"Sylvia E. Schleutermann" <ses@h-m-s.com>
Organization:
.hms Health Management Systems
Newsgroups:
netscape.public.mozilla.jseng
References:
1 , 2
I have found out some more. Looking really quickly over the JVM specs, I
found that
indeed the astore-command requires that the variables index be below 128.
However,
the book also said that if more index space is needed, a "wide" command can
be used to
be able to address up to 65xxx variables.
Question: is there a possibility to integrate this "wide"-command into the
class compiler?
Some option, that can be set? Or am I on the wrong tracks?
Please help, since I want to avoid spreading the script over many classes to
avoid the
size limitation. Cheers, Sylvia
Sylvia E. Schleutermann <ses@h-m-s.com> wrote in message
news:956sv9$9g53@secnews.netscape.com...
> I have found out that it is definitely the number of variables.
> I removed all variables and then the script compiled into class files
> with one base class and inner classes for each function in the script.
>
> What is the limitation exactly, i.e. does anyone know how many (global)
> variables
> I can use? Or is there some other kind of work around?
>
> Cheers, Sylvia
>
>
> Sylvia E. Schleutermann <ses@h-m-s.com> wrote in message
> news:956qtv$6kh3@secnews.netscape.com...
> > Hello,
> > when compiling a *.js file to class file, I get a "bad local" runtime
> > exception.
> > Stepping through the source, the following happens in reverse order:
> >
> > Codegen.xstore (75, 58, 209)
> > -> in the switch - default case, there is a comparison
> > for local (=209), which is compared to Byte.MAX_VALUE (=127).
> > When greater, the above exception is thrown.
> >
> > Codegen.astore (209)
> > -> calls Codegen.xstore (ByteCode.ASTORE_0, ByteCode.ASTORE, 209)
> >
> > Codegen.generatePrologue (<context>, <tree>, true, -1) // -1 is
> > directParameterCount
> > -> sets itsZeroArgArray = getNewWordLocal(); // here, the 209 is
> > produced
> > -> calls astore (itsZeroArgArray)
> >
> > From what I can read from the source code, the 209 seems to be a counter
> for
> > "locals", perhaps
> > local variables?? The function that is being compiled does initialize
many
> > variables - would it help
> > to move the initialize code out of the function into separate code
blocks?
> >
> > The function looks like this
> >
> > function rule_Disclaimer()
> > {
> > try { VAR1 = <init code 1>;} catch (exception) { VAR1 = <default
init
> > code 1>; }
> > try { VAR2 = <init code 2>;} catch (exception) { VAR2 = <default
init
> > code 2>;}
> > ... (about 58 such variables)
> >
> > var cond = true;
> >
> > < rest of code>
> > }
> >
> > When I compile the script for interpreted mode, all works well. The
> > variables VAR1 to VAR58 are to be global
> > variables (global to the whole script).
> >
> > I appreciate any help! Thanks, Sylvia
> >
> >
>
>
expressions. The method "prefix" on a RegExp behaves exactly the same
as the "exec" method except it returns "undefined" if the match failed
because there was an insufficient number of characters in the
input. E.g.
/^foo/.prefix("foo") => ["foo"] (just like exec)
/^foo/.prefix("fox") => null (just like exec)
/^foo/.prefix("fo") => undefined (whereas exec returns null)
Subject:
[Rhino] Question
Date:
Tue, 30 Jan 2001 20:18:21 +0900
From:
"get21" <get21@secsm.org>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I found something unusual to me when I hacking the Rhino source code.
In tagify method of NativeString Class,
When it adds tag to its string(this.string), it does not use quotation
marks.
For example, the result of tagify("A HREF", "A", value) in
jsFunction_link(String value) is
<A HREF=Some Value>Original String Value</A>
Not,
<A HREF="Some Value">Original String Value</A>
This question might sound silly, but I'm curious why.
Thanks in advance,
Nam
--
email : get21@secsm.org
home : http://get21.secsm.org
phone : 011-9092-1802
Subject:
minor Rhino bug
Date:
Tue, 23 Jan 2001 13:14:51 -0800
From:
dave russo <d-russo@ti.com>
To:
nboyd@atg.com
CC:
d-russo@ti.com
Norris,
While using the new Rhino debugger (from the latest tip) I started to get "No
Context associated with current Thread" exceptions when expanding host objects
in the "Context:" debugger window.
In looking at the code, I discovered that NativeObject.toString seems to assume
that Context.getContext() may return null. In fact, getContext() always returns
a non-null context or throws an exception.
I changed NativeObject.toString to never throw an exception (see below) and this
eliminated the problem I was seeing (of course).
It would be nice to incorporate this in a future Rhino tip or, if this change is
inappropriate, any guidance would be appreciated. Thanks in advance.
I changed NativeObject.toString to:
public String toString() {
try {
Context cx = Context.getContext();
return jsFunction_toString(cx, this, null, null);
}
catch (Exception e) {
return "[object " + getClassName() + "]";
}
}
from:
public String toString() {
Context cx = Context.getContext();
if (cx != null)
return jsFunction_toString(cx, this, null, null);
else
return "[object " + getClassName() + "]";
}
Re: Small usage simplification for Rhino
Date:
Tue, 23 Jan 2001 16:01:42 +0100
From:
Igor Bukanov <igor@icesoft.no>
To:
Norris Boyd <nboyd@atg.com>
References:
1 , 2 , 3 , 4
Norris Boyd wrote:
> Thanks. I've patched in your changes and checked it into CVS.
I also looked at other places with similar pattern of few lines of
common code to construct error messages. The following was occurred too
often not to avoid temptations to move it to a separated function:
NativeGlobal.constructError(
Context.getContext(), "TypeError",
ScriptRuntime.getMessage1("msg.default.value", arg),
this)
It can be replaced by
NativeGlobal.typeError1("msg.default.value", arg, this)
There are other similar usages but they are not to frequent to bother
with code reduction because even the above replacement saves just 200
bytes in uncompressed jars (it is expensive to introduce new methods in
Java).
In any case, if you think it makes any sense, patches are attached. They
are made via
diff -cbB javascript.orig javascript > patch_context
diff -bB javascript.orig javascript > patch_std
from org/mozilla directory.
Regards, Igor
Subject:
Recent rhino broke security support
Date:
Tue, 23 Jan 2001 08:07:45 -0500
From:
"Kurt Westerfeld" <kurt@managedobjects.com>
To:
"Norris Boyd" <nboyd@atg.com>
Norris.....I like the changes made to FunctionObject to do method invocation
much faster. Very slick.
Problem tho: this mechanism does not veer into the security support plugin
on context for defining a class. This is crucial do creating event adapter
code later in applet environments.
I'm going to look into this, but perhaps you could probably make the changes
faster than I.
Unfortunately for us, we found this problem yesterday at a customer site.
:-( Shame on us.
________________________________________________________________________
Kurt Westerfeld
Senior Software Architect
Managed Objects
mailto:kwester@ManagedObjects.com
703.770.7225
http://www.ManagedObjects.com
Managed Objects: manage technology > rule business
[Fwd: My Mistake in ScriptRuntime method]]]
Date:
Tue, 16 Jan 2001 15:48:26 +0100
From:
Igor Bukanov <igor@icesoft.no>
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
With my previous patch to fix in
org/mozilla/javascript/ScriptRuntime.java Integer.MIN_VALUE as index
problem I also added a bug to the unrelated code: I tried to minimize
object creation and unfortunately that untested "optimization" slippet
into my patch as well.
I replaced the lines 290, 291 in toNumber(String s) method from
String sub = s.substring(start, end+1);
if (sub.equals("Infinity"))
to
if (s.regionMatches(start, "Infinity", 0, 8))
But that should be
if (start + 7 == end && s.regionMatches(start, "Infinity", 0, 8))
Sory for troubles, Igor
290c290
< if (s.regionMatches(start, "Infinity", 0, 8))
---
> if (start + 7 == end && s.regionMatches(start, "Infinity", 0, 8))
Re: Debugger problem
Date:
Mon, 08 Jan 2001 14:16:30 -0800
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
Kurt Westerfeld <kurt@ManagedObjects.com>
CC:
Norris Boyd <nboyd@atg.com>
References:
1 , 2 , 3
Kurt, Norris,
Yes, with the change to the shell this should be possible. The problem before
was that if you loaded the same file with different relative path names, two
different windows in the debugger were created because everything (windows,
breakpoints, etc) is keyed off the source name.
The attached file contains the fix (and includes the workaround for
Desktop.getSelectedFrame).
There are still some bugs in transferring focus between the windows in the
Desktop. I haven't had time to track down the problem or a solution.
Chris
Kurt Westerfeld wrote:
> I would point out that "Source Name" of a script isn't necessarily a
> filename. In our system, scripts are run remotely from a script library
> that has no file system backing. Canonicalizing the file names is really
> unnecessary.
>
> Can't you just modify JSDebugger to not care what the name of the file is?
> If access to the original script is unavailable except through the file
> system, I'd be surprised.
>
> ----- Original Message -----
> From: Christopher Oliver <coliver@mminternet.com>
> To: Kurt Westerfeld <kurt@ManagedObjects.com>
> Cc: Norris Boyd <nboyd@atg.com>
> Sent: Sunday, January 07, 2001 2:23 AM
> Subject: Re: Debugger problem
>
> > Hi Kurt,
> >
> > I rather would say that it is a problem with the processFile method in the
> > shell's Main class. If you change the current working directory or the
> value
> > of the System property "user.dir" after compiling a script, relative path
> names
> > can become ambiguous. Norris, would it be ok to modify the shell to
> > "canonicalize" the names of files it compiles? That way the source name
> that
> > shows up in the stack and in DebuggableScript will always be unique. For
> > example:
> >
> > public static void processFile(Context cx, Scriptable scope,
> > String filename)
> > {
> > Reader in = null;
> > try {
> > in = new PushbackReader(new FileReader(filename));
> > int c = in.read();
> > // Support the executable script #! syntax: If
> > // the first line begins with a '#', treat the whole
> > // line as a comment.
> > if (c == '#') {
> > while ((c = in.read()) != -1) {
> > if (c == '\n' || c == '\r')
> > break;
> > }
> > ((PushbackReader) in).unread(c);
> > } else {
> > // No '#' line, just reopen the file and forget it
> > // ever happened. OPT closing and reopening
> > // undoubtedly carries some cost. Is this faster
> > // or slower than leaving the PushbackReader
> > // around?
> > in.close();
> > in = new FileReader(filename);
> > }
> > filename = new java.io.File(filename).getCanonicalPath();
> > <<<====== Add this
> > }
> > catch (FileNotFoundException ex) {
> > Context.reportError(ToolErrorReporter.getMessage(
> > "msg.couldnt.open",
> > filename));
> > exitCode = EXITCODE_FILE_NOT_FOUND;
> > return;
> > } catch (IOException ioe) {
> > globalState.getErr().println(ioe.toString());
> > }
> >
> > // Here we evalute the entire contents of the file as
> > // a script. Text is printed only if the print() function
> > // is called.
> > evaluateReader(cx, scope, in, filename, 1);
> > }
> >
> >
> > Attached is *my* latest version of the debugger code. Norris, have you
> made
> > any progress on cvs commit priveledges? The attached version fixes a
> number of
> > GUI bugs:
> >
> > 1) If you undocked the Variables window and popped up the Context
> combo-box and
> > then closed the window with the system menu, the Context pop-up was not
> cleaned
> > up properly.
> > 2) The first time you minimize a file window it appeared to dissappear
> when you
> > tried to restore it. This was due to the fact that I forgot to "pack" its
> > contents and as a result its requested size was 0x0.
> >
> > I also added a menu item to toggle whether to break on exceptions and one
> which
> > allows you to open (and compile) a JavaScript file without actually
> executing
> > it.
> >
> > I have also attached a Word document with some basic documentation for the
> > Debugger.
> >
> > Note that this version also includes all the changes to support debugging
> > scripts in the AWT dispatch thread.
> >
> > Chris
> >
> > Kurt Westerfeld wrote:
> >
> > > Hello. I ran into a null pointer exception in JSDebugger tonight, and I
> > > thought I'd drop you a note.
> > >
> > > The problem line is 2336, where a breakpoint is hit. To simulate, load
> the
> > > debugger using the command line syntax on a file that has not been
> resolved
> > > to cannonical path.
> > >
> > > Example,
> > >
> > > jshell -debug -f \myfile.fs
> > >
> > > At any rate, the "handleCompilationDone" routine takes \myfile.fs and
> turns
> > > it into a canonical path. If you hit a breakpoint in this file and say
> > > "go", when the breakpoint hits the file is not found, because the same
> > > canonical path resolution is not done. The resolution seems dubious,
> since
> > > it is only done in the compilation done callback, but I don't know the
> best
> > > way to suggest a fix since it seems that code had some purpose.
> > >
> > > Anyway, thought you'd wanna know.
> > >
> > > ________________________________________________________________________
> > > Kurt Westerfeld
> > > Senior Software Architect
> > > Managed Objects
> > > mailto:kwester@ManagedObjects.com
> > > 703.770.7225
> > > http://www.ManagedObjects.com
> > >
> > > Managed Objects: manage technology > rule business
> >
JSDebugger.java
Name:
JSDebugger.java
Type:
Java Class File (java/*)
Encoding:
base64
* Make use of DebuggableEngine interface to keep Context API smaller
* Change org.mozilla.javascript.debug.Frame to DebugFrame to avoid
confusion with java.awt.Frame
Subject:
Re: Rhino bug - Wrapper ??
Date:
Fri, 05 Jan 2001 03:46:11 +0530
From:
Mukund Balasubramanian <mukund@cs.stanford.edu>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
References:
1 , 2 , 3 , 4 , 5 , 6
That works too,
Should I assume that this would be a part of the next tip ? I agree with the
part about
overloading code too.
Anyways, thanks a load for your help and just tell me if I could be of any
help in any other
respects of the rhino project.
ThanX,
Mukund Balasubaramanian
Norris Boyd wrote:
> Actually, I was considering removing the unwrapping code from
NativeJavaConstructor. I was
> suprised that it was there. The code dates from before we implemented proper
method and
> constructor overloading in Rhino. It's the overloading code that should have
the responsibility
> for unwrapping.
>
> Does this patch work for you:
>
> Index: NativeJavaObject.java
> ===================================================================
> RCS file:
/cvsroot/mozilla/js/rhino/org/mozilla/javascript/NativeJavaObject.java
> ,v
> retrieving revision 1.29
> diff -u -r1.29 NativeJavaObject.java
> --- NativeJavaObject.java 2000/11/13 22:10:32 1.29
> +++ NativeJavaObject.java 2001/01/04 21:33:55
> @@ -673,6 +673,12 @@
>
> return Result;
> }
> + else if (value instanceof Wrapper) {
> + value = ((Wrapper)value).unwrap();
> + if (type.isInstance(value))
> + return value;
> + reportConversionError(value, type);
> + }
> else {
> reportConversionError(value, type);
> }
>
> This handles the case where the object is both a Scriptable and a Wrapper.
>
> --N
>
> Mukund Balasubramanian wrote:
>
> > Yes they do implement Scriptable.
> > From my preliminary inspection of the code, findFunction seems to be
preceediong the
> > coerceType call and I presume findFunction call is going to fail if the
arguments are
> > wrapped (bad types mismatching signature).
> > The constructor case DOES go through an explicit unwrapping stage as
shown by the cut
> > and paste code. My question is whether the same preamble in NativeJavaMethod
is a valid bug
> > fix.
> >
> > ThanX,
> >
> > Mukund Balasubramanian
> >
> > Norris Boyd wrote:
> >
> > > Do your objects that implement Wrapper also implement Scriptable? From
simple inspection
> > > of the code I'd think that both the constructor and method cases would go
through
> > > NativeJavaMethod.coerceType, which should unwrap. However, Scriptable
objects are picked
> > > off and handled before any unwrapping is considered.
> > >
> > > --N
> > >
> > > Mukund Balasubramanian wrote:
> > >
> > > > Yup,
> > > > Here it is - Line numbers 173-178 are cut and paste from
> > > > NativeJavaConstructor.java inside NativeJavaMethod.java
> > > >
> > > > /*** Call in NativeJavaMethod.java
> > > > public Object call(Context cx, Scriptable scope, Scriptable thisObj,
> > > > Object[] args)
> > > > throws JavaScriptException
> > > > {
> > > > // Eliminate useless args[0] and unwrap if required
> > > > for (int i = 0; i < args.length; i++) {
> > > > if (args[i] instanceof Wrapper) {
> > > > args[i] = ((Wrapper)args[i]).unwrap();
> > > > }
> > > > }
> > > >
> > > > // Find a method that matches the types given.
> > > > if (methods.length == 0) {
> > > > ****/
> > > >
> > > > Is this correct ? I presume it is because of the fact that the
constructor
> > > > does this.
> > > >
> > > > Any luck with my other question regarding generalizing the WrapHandler
to all
> > > > objects (including those returned by scriptable) and not only those
returned
> > > > through nativeJava***
> > > >
> > > > ThanX,
> > > >
> > > > Mukund Balasubramanian
> > > >
> > > > Norris Boyd wrote:
> > > >
> > > > > Could you post your proposed patch?
> > > > >
> > > > > Thanks,
> > > > > Norris
> > > > >
> > > > > Mukund Balasubramanian wrote:
> > > > >
> > > > > > Hi all,
> > > > > > I am trying to play around with writing a custom WrapHandler for
my
> > > > > > Java objects in Rhino. I found WrapHandler very useful.
> > > > > > Now I am stuck at a point where, even though my wrappers
implement
> > > > > > "Wrapper", they get unwrapped only on calles to Constructors using
> > > > > > Liveconnect. Normal methods dont seem to be doing any unwrapping.
> > > > > > Managed to build rhino with a bug fix (cut and paste code from
> > > > > > NativeJavaConstructor to NativeJavamethod), and it works.
> > > > > > Just wanted to verify if it is a known bug (while I wait for
> > > > > > bugzilla to mail me a passwd).
> > > > > >
> > > > > > BTW, also found something interesting, WrapHandler gets called only
when
> > > > > > the object is returned from NativeJava***, not ANY Object. Is that
the
> > > > > > way it is supposed to work ??
> > > > > >
> > > > > > ThanX for any help,
> > > > > >
> > > > > > Mukund Balasubramanian
Subject:
[Rhino] Script compiler bug?
Date:
Tue, 12 Dec 2000 22:08:23 GMT
From:
dave russo <d-russo@ti.com>
Organization:
Deja.com
Newsgroups:
netscape.public.mozilla.jseng
The following script does not seem to compile properly (using Rhino
1.5R1):
test.js:
var test = {};
test.foo = function () { print('foo')}
test.bar = function () { print('bar')}
After compiling test.js ("java org.mozilla.javascript.tools.jsc.Main
test.js"):
js> loadClass('test')
js> test.foo()
bar
js> load('test.js')
js> test.foo()
foo
Note that changing test.js to read:
var test = {};
test.foo = function foo() { print('foo')}
test.bar = function bar() { print('bar')}
Works around the problem. Is there a problem with anonymous functions?
Sent via Deja.com
http://www.deja.com/
