- teach nsGenericFactory about nsIClassInfo, and nsIClassInfo.idl to the
builds
- add a heaping serving of macro love for classes that want to support it
- convert many modules to use nsGenericModule the new way
- handful of warning and modeline fixes
- nsSample and some XPConnect test classes now have nsIClassInfo support for
testing
r=pchwartau, sr=brendan
Just add an _IS_LITTLE_ENDIAN for XP_OS2 for now. Eventually, we need to figure
out how to get jstypes.h included in here, since it already has a LITTLE_ENDIAN define.
r=pchwartau, sr=brendan
Rework makefile.win and js.mak for the eventual ability to include jstypes.h in fdlibm.h
Not turned on yet because I can't get it working right on Linux
- Fix bug where script jssrcnote vector terminator was not XDRed.
- Ensure that memory is cleared by serializing zero padding bytes as needed
under JS_XDRBytes and JS_XDRString.
- Fix JS_XDRValue to handle undefined and null JS types properly (bug 31003).
Also make it cast from jsint to uint32 and back carefully, so as to work
with negative numbers even on targets where jsval is a signed 64 bit type.
- Add JS_XDRScript public API.
- Optimize the per-JSXDRState class registry so it uses a JSDHashTable upon
searching for a class-id by name in an overpopulated (for linear search)
registry table.
- Clean up API nits such as JS_XDRNewBase => JS_XDRInitBase, with parameter
list rotation to put cx last (JS_XDRInitBase is an infallible init helper,
not an error-reporting, cx-comes-first, API entry point).
- Fix some XXX comments, unneeded masks, other nits.
- Make sure all JS XDR API functions start with JS_XDR.
* fixed ImporterTopLevel constructor - it now calls
cx.initStandardObjects before defining any functions. The old
constructor is still around for backwards compatibility.
- Fix scope chain for nested functions at top-level (JSOP_DEFFUN), in a part of another statement (JSOP_CLOSURE), and unnamed in an expression (JSOP_ANONFUNOBJ) to match ECMA-262 13.2. My bad: fp->varobj was used up till now, instead of fp->scopeChain; we still *bind* the name of a statement-level (top or not) nested function in fp->varobj. This fixes bug 69559. (r=rogerl, sr=jband)
- Add an Intern command to the shell, for GC vs. intern'ed atom testing.
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
until JS_DestroyRuntime is called (68450, r=rginda, sr=jband).
- NUL-terminate tagbuf in tagify, for the HTML helpers such as string.big()
(66648, r=timeless, sr=jband).
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?
- Remove bogus JS_ASSERT(!outermost) from the code that deals with a "#n="
type string being returned from js_EnterSharpObject, where the hash entry
is not yet sharp (because we haven't seen the object twice during depth
first search). This case trivially arises for the outermost object in,
e.g., 'o={}; o.foo=o; uneval(o)'.
- Avoid parenthesizing #n={...} object initializers for uneval, as they are
not ambiguous (whereas {foo:1}, e.g., is ambiguous because it could be a
block statement containing a labeled expression statement, or it could be
an object initializer).
- Death to tabs!
dprice%netscape.com
pschwartau%netscape.com
shaver%mozilla.org
nboyd%atg.com
brendan%mozilla.org
mkaply%us.ibm.com
rogerl%netscape.com
matthias%sorted.org
beard%netscape.com
jband%netscape.com
disttsc%bart.nl
waldemar%netscape.com