1. Replacing omj.debug.Debugger.enterFrame() by omj.debug.Debugger.getFrame() and omj.debug.DebugFrame.onEnter() to allow to return null from omj.debug.Debugger.getFrame to enable full optimization with debugger set if it is not interested in monitoring a particular frame
2. Changing type for the source argument in omj.debug.Debugger.handleCompilationDone from StringBuffer to String as Debugger instances should not be able to modify source even by chance.
The patch uses the special NOT_FOUND value to flag deleted indexes. It also
make sure that original array object passed to Function.call is not modified,
as all changes goes to cloned copy. It is not necessary for the fix, but it is
the only place in the current Rhino that can alter Object[] array passed to
Function.call and I think it is better to remove this exceptional case.
These changes add the cache optimization to the has methods and remove cache update from the put methods under the assumption that newly assigned properties would not be used immediately.
hi Norris,
in our product, which makes heavy use of Rhino, we have many Java Objects
we wrap with ECMAScript wrappers, which extend the ScriptableObject class
and implement the Wrapper interface. Those wrappers automagically wrap the
native Java object with the help of a WrapHandler implementation.
we now ran into a problem :
we have a java class with two overloaded static methods like this :
public class Test {
public static String create(File f) {}
public static String create(Custom c) {}
}
The Custom class exists as a native Java implementation like
public class Custom {}
and a accompanying ECMAScript wrapper like
public class CustomWrapper
extends ScriptableObject
implements Wrapper {}
in our ECMAScripts we make the wrapper class known as a host object along
the lines of
defineClass("CustomWrapper");
and can then use the object as a normal ECMAScript host object. no big deal
and working great.
but : the code
var s = Test.creat( new Custom( "xyz") );
fails with the information, that the methods are ambiguous, which of course
they are not.
Looking at the code of NativeJavaMethod.findFunction() and the helpers in
NativeJavaObject it seems, that the fact of the Custom host object being a
Wrapper is not taken into account. in an easy fix of
NativeJavaMethod.findFunction(), i simply replace all arguments, which are
Wrapper imlpementation by the wrapped object. this solves my problem, but
of course i'm not sure on side effects.
i attach the testcase as well as the fixed NativeJavaMethod class in the
jar file. to run the test with and without the fix, extract the jar and do
ant test
please let me know, what you think of this.
regards and thanks, f.
Felix Meschberger
I think there's a small problem with Igor's changes. The modifed Interpreter.java
seems to create unnecessary activation objects for InterpretedScripts. You can
see this in the debugger (local variables are present even for top level scripts).
I believe the attached change will fix the problem.
Regards,
Chris
VariableModel.java:220:30:220:40: Caution: This try block cannot throw a "checked exception" (JLS section 14.7) that can be caught here. You may have intended to catch a RuntimeException instead of an Exception.
Changes to omj.tools.debugger are mostly due to renames and refactoring, the new code is limited to ContextData class which contains simplified version of the code for DebugFrame stack from the current DebuggableEngineImplementation and FrameHelper class implementing DebugFrame.
...
The idea is to make Debugger responsible for creation of DebugFrame in
Interpreter.interpret which gives simple way for a Debugger implementation to
observe function enter/exit while completely removing the need to have code
for debug frame stack in the Rhino core as the Debugger implementation can
easily support this on its own when necessary. So I suggest to have:
public interface Debugger { ... }
and
public interface DebugFrame { ... }
which eliminates omj.InterpreterFrame and as DebuggableEngine shrinks down to
3 methods set/getDebugger and getDebuggerContextData, I simply moved them to
Context. The 3rd method is useful to refer to per Context debug data from a
Debugger implementation, but it can be removed as well as the same effect can
be achieved via Context.set/getThreadLocal.
non-ScriptableObject implementations of Scriptable.
I checked in fixes for the problems of serializing objects with FunctionObjects or
GetterSlots. With Foo.class in the current directory, I can now do:
[rhino] java -classpath 'build/rhino1_5R4pre/js.jar;.' org.mozilla.javascript.tools.shell.Main
Rhino 1.5 release 4 0000 00 00 (in progress)
js> defineClass("Foo")
js> f = new Foo
[object Foo]
js> print(f.counter)
0
js> print(f.counter)
1
js> serialize(f, "f.ser")
js> quit()
[rhino] java -classpath 'build/rhino1_5R4pre/js.jar;.' org.mozilla.javascript.tools.shell.Main
Rhino 1.5 release 4 0000 00 00 (in progress)
js> f = deserialize("f.ser")
[object Foo]
js> f.counter
2
js> f.counter
3
