We have found a problem in string.replace() when replacing a regular
expression with a dollar sign. The following code works right when the
replacement string does not contain "$":
$ java -jar js.jar
js> var re = new RegExp("%%%");
js> var price = "%%% 1.99";
js> price.replace(re, "USD");
USD 1.99
js> price.replace(re, "$");
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException
at
org.mozilla.javascript.regexp.ReplaceData.interpretDollar(RegExpImpl.java:40 0)
at
org.mozilla.javascript.regexp.ReplaceData.findReplen(RegExpImpl.java:502)
at
org.mozilla.javascript.regexp.RegExpImpl.replace(RegExpImpl.java:116)
at
org.mozilla.javascript.NativeString.execMethod(NativeString.java:266)
at org.mozilla.javascript.IdFunction.call(IdFunction.java:78)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1222)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:1940)
at
org.mozilla.javascript.InterpretedScript.call(InterpretedScript.java:68)
at
org.mozilla.javascript.InterpretedScript.exec(InterpretedScript.java:59)
at org.mozilla.javascript.Context.evaluateReader(Context.java:773)
at
org.mozilla.javascript.tools.shell.Main.evaluateReader(Main.java:312)
at
org.mozilla.javascript.tools.shell.Main.processSource(Main.java:219)
at org.mozilla.javascript.tools.shell.Main.exec(Main.java:106)
at org.mozilla.javascript.tools.shell.Main.main(Main.java:68)
We are converting from spidermonkey to rhino and it appears that the
name property for the constructor function returns "constructor" for
all builtin types. Spidermonkey would return "Date" or "Array" or
whatever. Is there a workaround? This code needs to work with both
interpreters.
Here is an example of the rhino behavior:
js> var i=new Date;
js> i.constructor.name
constructor
js> Date.name
constructor
js> function bob(){}
js> bob.name
bob
js> var i = new Array();
js> i.constructor.name
constructor
js>
I'm the maintainer of JPackage project rhino package (see
jpackage.sourceforge.net). I just found two problems for building it (version
1.52 from cvs):
- the property src.debugger is badly initialised in toolsrc/build.xml. See
patch attached for correction. Moreover, this was a real pain to make offline
building possible. I guess it's a licensing problem that prevents you
including those files in rhino sources ?
- the produced javadoc has an empty (0 sized) package-list file. Have you got
any idea why ?
-- Guillaume Rousse <rousse@ccr.jussieu.fr>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
In our browser we need to support scripts that use as an identifier name future reserved keywords such as interface. The scripts are rather old and perfectly legal under previous revisions of EcmaScript which does not included the list of almost every Java keyword to the future reserve.
To support this I added an option to query Context.hasFeature for FEATURE_RESERVED_KEYWORD_AS_IDENTIFIER:
/**
* if hasFeature(RESERVED_KEYWORD_AS_IDENTIFIER) returns true,
* treat future reserved keyword (see Ecma-262, section 7.5.3) as ordinary
* identifiers but warn about this usage
*/
public static final int FEATURE_RESERVED_KEYWORD_AS_IDENTIFIER = 3;
The corresponding code in TokenStream checks for it and issues just a warning when this feature is enabled.
I also think that it would be better not to return RESERVED as a token from TokenStream.getToken but report the specific syntax error immediately because it is very unclear from the error message:
js> x.interface = 1
js: "<stdin>", line 1: uncaught JavaScript exception: SyntaxError: missing name after . operator (<stdin>; line 1)
js: x.interface = 1
js: ..........^
what exactly went wrong. I can send a patch later for that.
Regards, Igor
I'm working on a project which uses rhino. I wanted to have finer
control over class generation and saving so I've done some patching
and clean up on the current rhino tip.
The biggest change I've made is the replacement of ClassOutput with
ClassRepository that has the single method:
public boolean storeClass(String className, byte[] classBytes,
boolean isTopLevel) throws IOException;
This interface allows any arbitary storage method, such as a
Hashtable/Map. In addition it also allows you to specify whether a
class should be loaded, via returning true or false. You can still use
ClassOutput as I've coded an internal wrapper.
With this interface it has also been possible to strip out the file
saving code from Codegen and OptClassNameHelper. The file
saving code is now an inner class FileClassRepository in Context. As
a consequence of this I've stripped out some methods from ClassNameHelper.
The resulting code is much more cleaner then before hand and everything
still works as per usual.
Other small additions are:
o Annonymous functions are now named class$1 instead of class1
o get/setClassName added to ClassNameHelper exposed in Context.
My final thoughts are, since all methods in ClassNameHelper except reset()
are now exposed whould n't it be much more "cleaner" to simply to some
how work around to eliminate reset() and provide getClassNameHelper()
via Context? You could then remove the numerous ClassNameHelper shadow
methods from Context.
Likewise, FileClassRepository could be made a public class very easily
and combined with the above result in a dozen or so less public methods in
Context.
Anyway, the changes can be found on http://www.cins.co.uk/rhino.zip
Hope it is of use to some
Kemal Bayram
I'm working on a project which uses rhino. I wanted to have finer
control over class generation and saving so I've done some patching
and clean up on the current rhino tip.
The biggest change I've made is the replacement of ClassOutput with
ClassRepository that has the single method:
public boolean storeClass(String className, byte[] classBytes,
boolean isTopLevel) throws IOException;
This interface allows any arbitary storage method, such as a
Hashtable/Map. In addition it also allows you to specify whether a
class should be loaded, via returning true or false. You can still use
ClassOutput as I've coded an internal wrapper.
With this interface it has also been possible to strip out the file
saving code from Codegen and OptClassNameHelper. The file
saving code is now an inner class FileClassRepository in Context. As
a consequence of this I've stripped out some methods from ClassNameHelper.
The resulting code is much more cleaner then before hand and everything
still works as per usual.
Other small additions are:
o Annonymous functions are now named class$1 instead of class1
o get/setClassName added to ClassNameHelper exposed in Context.
My final thoughts are, since all methods in ClassNameHelper except reset()
are now exposed whould n't it be much more "cleaner" to simply to some
how work around to eliminate reset() and provide getClassNameHelper()
via Context? You could then remove the numerous ClassNameHelper shadow
methods from Context.
Likewise, FileClassRepository could be made a public class very easily
and combined with the above result in a dozen or so less public methods in
Context.
Anyway, the changes can be found on http://www.cins.co.uk/rhino.zip
Hope it is of use to some
Kemal Bayram <rhino@cins.co.uk>
I suggest to move the code in ScriptableObject.get/put that deals with getter/setter
into separated methods so it would be easy to follow the code and the attached patch
does just that.
The following test case case leads to a compilation error in Rhino. In this
script alert is an user defined
function in the global object and it shows the value of the specified
parameter in a popup window. Save the script as a html file and run it under
Netscape and IE. The output via their JS engines is that alert(1)
executes but the execution of line fails as blks variable is undefined. The
Fix bug:
Rhino engine fails at compilation time itself and cannot excute the script.
It doesn't like the syntax of line.
Steven
/// **************** test case ************** ///
<script>
alert(1);
blks[ 10 << 2 ] |= true;
alert(2);
</script>
/// ********************** Error Message ************************** ////
evaluating script: null
java.lang.NullPointerException
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICodeFromTree(Compiled Code)
at
org.mozilla.javascript.Interpreter.generateScriptICode(Interpreter.java)
at org.mozilla.javascript.Interpreter.compile(Interpreter.java)
at org.mozilla.javascript.Context.compile(Context.java)
at org.mozilla.javascript.Context.compile(Context.java)
I must admit this is very subtitle, but still...
Here are the lines from
public void defineProperty(String propertyName, Object delegateTo,
Method getter, Method setter, int attributes)
GetterSlot slot = (GetterSlot)getSlotToSet(propertyName,
propertyName.hashCode(),
true);
slot.delegateTo = delegateTo;
slot.getter = getter;
slot.setter = setter;
slot.setterReturnsValue = setter != null && setter.getReturnType() != Void.TYPE;
slot.value = null;
slot.attributes = (short) attributes;
slot.flags = (byte)flags;
Now suppose that after the new slot is added, another thread is accessing it. Then it would see not yet ready slot with all nasty consequences! For example, SMP computer can re-arrange writes so the new value of slot.flags would be visible before slot.getter then another thread would generate null pointer exception.
race2_fix.diff fixes that by using the explicit Slot argument to addSlot instead of boolean flag so the new slot can be fully initialized and then inserted under synchronization to the table. I also call addSlot directly because it is supposed to be used with not-yet existed properties and split addSlot to addSlot and addSlotImpl so in case of table growth there is no need to re-enter already synchronized monitor.
This changes also allows to explicitly throw RuntimeException if defineProperty is called for the property that is already exists instead of either throwing cast exception in "GetterSlot slot = (GetterSlot)getSlotToSet(propertyName," or worth yet re-initializing already existed slot.
Regards, Igor
Unsynchronized ScriptableObject.getSlotToSet contains references/modifications
to the slots array which is no go under multithreading. The attached patch
replaces references to slots by references to its local copy and moves code
to allocate the initial array to synchronized addSlot.
The patch also replace throwing of RuntimeException in case of broken code by
if (Context.check && badCondition) Context.codeBug();
Regards, Igor
also has a significant regression introduced in it. The default compiler
not only works, but also is noticably faster. Ant takes care of the
selection of the compiler automatically based on the JDK level, so the
following patch should make things better all around.
Patch from Igor:
The 2 attached patches allow to avoid wrapping of array indexes to Double object
when Interpreter knows that the index is an integer number. It speed up array
benchmark by 5-10%
array_access.diff adds to ScriptRuntime getStrIdElem and setStrIdElem to get/set
properties which known to be strings plus it modifies NativeArray to use these methods.
interpreter.diff contains the Interpreter modifications to call get/setElem for
integer or string properties when the property type is known for sure.
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());
}
}
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
As profiler data show, the execution time of the nextNode and replaceCurrent
methods in PreorderNodeIterator contribute quite significantly to the total
time to run Context.compileReader.
replaceCurrent is slow because it calls Node.replaceChild which have to
iterate through all previous siblings to find the nearest to the current.
But it is easy to avoid this search by caching the previous sibling of the
current while iterating over the node tree in nextNode.
nextNode slowness is attributed to the usage of java.lang.Stack which is
expensive due to its synchronized methods. In the attched patch I replaced
it by the explicit array management.
It allows to cut Context.compileReader time by 5%-30% when processing
20K-3MB sources assembled form JS files in the test suite.
Note form omj/Parser.java:
* OPT source info collection is a potential performance bottleneck;
* Source wraps a java.lang.StringBuffer, which is synchronized. It
* might be faster to implement Source with its own char buffer and
* toString method.
It is indeed a bottleneck under JDK 1.1. When I replaced StringBuffer
by a char array (see the attached patch), execution time of
Context.compileReader decreased by 15%: to test I combined a few test
cases to get a 3MB JS source and then measured time to process it by
Context.compileReader in the interpreter mode.
Under JDK 1.3 the difference is less then 1%, but still using the explicit
string buffer saves memory. When converting StringBuffer to String Sun JDK
shares the internal char array in StringBuffer with new String, but in the
Parser case typically the capacity of this buffer is bigger then the actual
string length, so this unused space in source strings is wasted in the
interpreter mode that keeps these strings in InterpreterData.
Regards, Igor
========
I implemented that member expression as function name syntactic sugar to
support scripts using this MS extension. This is only available when
Context.hasFeature(Context.FEATURE_MEMBER_EXPR_AS_FUNCTION_NAME)
returns true to allow the deviation from the standard only when required.
The patch effectively transforms 'function <memberExpr>(...)...' to
'<memberExpr> = function(...)...' when <memberExpr> is not simple
identifier. I am not sure that MS implementation does exactly this
but hopefully it is sufficiently general to cover MS cases.
(The patch assumes that source_change.patch is already applied)
Regards, Igor
I implemented that member expression as function name syntactic sugar to support
scripts using this MS extension. This is only available when
Context.hasFeature(Context.FEATURE_MEMBER_EXPR_AS_FUNCTION_NAME)
returns true to allow the deviation from the standard only when required.
The patch effectively transforms 'function <memberExpr>(...)...' to
'<memberExpr> = function(...)...' when <memberExpr> is not simple identifier.
I am not sure that MS implementation does exactly this but hopefully it is
sufficiently general to cover MS cases.
(The patch assumes that source_change.patch is already applied)
Regards, Igor
Currently omj/TokenStream and omj/optimizer/Optimizer.java both contain
code to convert number value to a wrapper object of smallest size. The
attached patch moves this wrapping to Node constructor to avoid code
duplication and eliminate special treatment of exact integers in
Optimizer.java.
The constant folding code in omj/optimizer/Optimizer.java currently always
replaces x * 1, x - 0 by simply x which does not force the toNumber convertion,
which is visible, for example, via typeof. For example, when running at
optimization level 2, the following
function f() {
return "0" * 1;
}
print(typeof(f()));
prints "string" instead of expected "number".
The const_fold.patch fixes this via replacing x*1 by (+x) to force number convertion.
It assumes that the patch with number wrapping changes is in place.
