We have a tool that looks for a scary noop case of assigning an instance field
to itself. this usually comes from a constructor that assigns a argument to a
instance field with the same name and then later the argument changes name. we
ran our tool on all of our classes we have in our classpath here and found this
problem in your code.
rhino1_5R2/src/org/mozilla/javascript/regexp/NativeRegExp.java line 159 it has:
this.flags = flags;
This seems to be a bad cut and paste from the CompilerState constructor on line
2155. or has some initialization that used to work been lost?
There is a bug in JavaScriptException which prevents it from being used with
out a Rhino Context. When the getMessage() method is invoked on it, the
exception goes to the ScriptRuntime to toString the value. If you have
already exited your context, the runtime will throw an error. The solution
is to simply remove the overridden getMessage method from
JavaScriptException. JavaScriptException's constructor calls the Exception
constructor with the toString'ed value. The default implementation of
getMessage will return the exception message.
Jeff
I'm having problems getting inner class objects with Rhino.
I create a Hashmap, which is an implementation of Map. Map.Entry is an
inner interface of Map with key-value pairs. If I have a Map object,
"property", I should be able to get the key element with the expression
"property.key".
When I look at the "property" class name that Rhino returns I get:
"java.util.HashMap$Entry". I don't believe Rhino has a notion of the
inner Map.Entry object. The expression "property" succeeds. The
expression "property.key", which should retrieve the Map.Entry
keyValue(), fails with a "unexpected IllegalAccessException accessing
Java field".
I'm including a simple example that illustrates the problem. I hope you
can shed some light on this. Thanks!
Justyna
< Justyna.Horwat@Sun.com >
----
import java.io.*;
import java.util.*;
import org.mozilla.javascript.*;
public class MapTest {
public static void main(String argv[]) {
Test test = new Test();
test.testMap();
}
}
class Test {
Map map;
Set set;
Iterator it;
Map.Entry entry;
public void testMap() {
System.out.println("testMap");
map = new HashMap();
populate();
set = map.entrySet();
it = set.iterator();
// let's see if Map is populated correctly
while (it.hasNext()) {
entry = (Map.Entry) it.next();
System.out.println("entry: " + entry.getClass().getName());
System.out.println("key: " + entry.getKey());
System.out.println("value: " + entry.getValue());
}
evaluate();
}
void populate() {
map.put("firstKey", "firstValue");
map.put("secondKey", "secondValue");
map.put("thirdKey", "thirdValue");
map.put("fourthKey", "fourthValue");
}
public void evaluate() {
Context cx = Context.enter();
Scriptable scope = cx.initStandardObjects(null);
set = map.entrySet();
it = set.iterator();
while (it.hasNext()) {
entry = (Map.Entry) it.next();
scope.put("property", scope, cx.toObject(entry,scope));
}
Object eval = null;
try {
// attempt to get Map.Entry key value using Rhino
eval = cx.evaluateString(scope, "property.key", "", 0,
null);
// Unwrap scoped object
if (eval instanceof Wrapper)
eval = ((Wrapper) eval).unwrap();
} catch (JavaScriptException jse) {
System.out.println("EXCEPTION: " + jse.getMessage());
}
// DELETE
System.out.println("RHINO result: " + eval + ":");
System.out.println("RHINO class: " + eval.getClass().getName());
}
}
with JSRESOLVE_ASSIGNING, wrongly), plus a few miscellaneous bugfixes.
- Combine the JSStackFrame members constructing, special, overrides, and
reserved into a uint32 flags member.
- Separate JOF_ASSIGNING from the JOF_SET bytecode format flag, and impute
JSRESOLVE_ASSIGNING from the presence of JOF_ASSIGNING among the current
opcode's format flags. To handle the for-in loop opcodes, which do more
than simply assign -- in particular, they do property lookups whose resolve
hook outcalls should not be flagged with JSRESOLVE_ASSIGNING -- a new frame
flag, JSFRAME_ASSIGNING, has been added.
- Fix interpreter version selection to respect JS_SetVersion, whose effect on
cx->version is "sticky".
- Fix js_DecompileValueGenerator to deal with JSOP_ENUMELEM -- it never had,
as this testcase shows (it crashes without this patch):
version(120);
eval("function fe(s) { for (it[s] in this); }");
try { fe('rdonly'); } catch (e) { print(e); }
My optimization for PreorderNodeIterator has a bug that would cause an attempt
to access stack[-1] in
currentParent = (current == null) ? null : stack[stackTop - 1];
when current refers to a start node sibling. This is not visible in Rhino because
currently PreorderNodeIterator is always started from nodes with node.next == null.
iter.diff fixes that plus it removes currentParent field because it is always
available as stack[stackTop - 1] and code to access its value are executed less
frequently than the lines to update it in nextNode
Regarsd, Igor
jaggernaut%netscape.com
pschwartau%netscape.com
nboyd%atg.com
jband%netscape.com
brendan%mozilla.org
dougt%netscape.com
bryner%netscape.com
rginda%netscape.com
dbradley%netscape.com
dbaron%fas.harvard.edu