Error if an interface is declared [scriptable], but contains methods that can't be scripted because they refer to native-declared types, unless the method is declared [noscript].
This change is intended to make it easier to determine when an interface is not scriptable, and to make it easier to see what changes need to be made to make it scriptable.
As many of the .idl files in the tree defined [scriptable] interfaces that contained non-scriptable methods, I've sprinkled [noscript] throughout. As the interfaces weren't scriptable anyway, this shouldn't change their visibility to javascript.
Subject:
reflection and illegal package access
Date:
Wed, 04 Aug 1999 21:56:20 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com (Norris Boyd)
CC:
Howard Lin <howard@softcom.com>
If you run Rhino under JDK1.2 with a security manager:
java -Djava.security.manager=java.lang.SecurityManager
org.mozilla.javascript.tools.shell.Main
Then reflection fails for objects that are in a restricted access package
(e.g. sun.*). Rhino is reflecting based on the dynamic type of the object
instead of the declared static return type.
In this example, createImage is declared to return java.awt.Image, but it
returns sun.awt.image.OffScreenImage. Attempting to reflect this class
results in a java.security.AccessControlException for
java.lang.RuntimePermission accessClassInPackage.sun.awt.image.
Here is the script. You will need to type it in because you won't be able
to load it from a file due to the security manager.
var f = new java.awt.Frame();
f.setVisible(true);
var i = f.createImage(10,10);
Subject:
null arguments
Date:
Wed, 04 Aug 1999 13:22:35 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com
CC:
Howard Lin <howard@softcom.com>
When I try to pass a null argument to an interface implemented in JS, I get:
js: Cannot convert null to an object.
js: uncaught JavaScript exception:
org.mozilla.javascript.EvaluatorException: Cannot convert null to an object.
var b = new Packages.javax.swing.border.Border() {
getBorderInsets : function(c) {
return new Insets(0,0,0,0);
}
};
b.getBorderInsets(null);
Here is the stack trace where the exception is happening:
java.lang.reflect.InvocationTargetException:
org.mozilla.javascript.EvaluatorException: Cannot convert null to an object.
at
org.mozilla.javascript.tools.ToolErrorReporter.runtimeError(ToolErrorReporte
r.java:106)
at org.mozilla.javascript.Context.reportRuntimeError(Context.java:484)
at org.mozilla.javascript.Context.reportRuntimeError(Context.java:500)
at
org.mozilla.javascript.ScriptRuntime.toObject(ScriptRuntime.java:529)
at org.mozilla.javascript.Context.toObject(Context.java:1107)
at adapter0.getBorderInsets(<adapter>)
at java.lang.reflect.Method.invoke(Native Method)
at
org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java,
Compiled Code)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1256)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java,
Compiled Code)
at
org.mozilla.javascript.InterpretedScript.call(InterpretedScript.java:49)
at
org.mozilla.javascript.InterpretedScript.exec(InterpretedScript.java:37)
at org.mozilla.javascript.Context.evaluateReader(Context.java:691)
at
org.mozilla.javascript.tools.shell.Main.processSource(Main.java, Compiled Code)
at org.mozilla.javascript.tools.shell.Main.main(Main.java:146)
Context.toObject does not allow wrapping nulls.
JavaAdapter.generateOverride should generate bytecode to check if an
argument is null and if it is not call Context.toObject.
I'll take a look at fixing this after the other JavaAdapter patches get
checked in so we don't get out of sync.
Andrew
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
* Accept patch from Andrew Wason <aw@softcom.com>:
Subject:
Re: partial interface problem
Date:
Wed, 04 Aug 1999 13:04:37 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com
CC:
Howard Lin <howard@softcom.com>
>I'm having a problem implementing a Java interface in JS where I don't
>implement all the methods, and one of the methods I don't define returns
>non-void.
I have a patch for this. I generate bytecode in
JavaAdapter.generateReturnResult to check the return type on the stack from
JavaAdapter.callMethod. If it is Undefined, return null.
I'm not positive this is the right way to fix this - maybe it should be
fixed closer to the source (e.g. prevent callMethod from returning
Undefined to begin with)
Andrew
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
Subject:
default JavaAdapter patch
Date:
Tue, 20 Jul 1999 15:35:01 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com
CC:
mccabe@netscape.com, rogerl@netscape.com
Attached is a patch to the patch I sent a while ago for the JavaAdapter stuff.
If a SecurityManager is installed, attempting to access the
"org.mozilla.javascript.JavaAdapter" system property can throw a
SecurityException. This should not prevent the default JavaAdapter
implementation from being used.
Andrew
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
Subject:
Rhino reflection patch
Date:
Wed, 28 Jul 1999 18:14:52 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com
CC:
mccabe@netscape.com, rogerl@netscape.com, Howard Lin <howard@softcom.com>
When JavaAdapter generates an adapter class, it does not take into account
the types of method parameters when wrapping the generated methods arguments.
This means that if a non-public class implements a public interface the
non-public class type will be wrapped instead of the declared public
interface - and methods cannot be invoked via the wrapper.
I have attached sample code (reflect-demo.zip) which shows this. The
JavaScript caller.js generates an adapter implementing the CallerInterface
interface. CallerInterface has a method (doSomething) which takes an
argument of type pkg.Interface. pkg.Target is a non-public class that
implements pkg.Interface. If an instance of pkg.Target is passed to the
CallerInterface adapter doSomething method, an Error is thrown because
pkg.Target.doSomething is called (instead of pkg.Interface.doSomething) and
pkg.Target is not public.
I have attached a patch to Context.java, ScriptRuntime.java and
JavaAdapter.java. I overloaded toObject in Context and ScriptRuntime to
take a 3rd argument which is the declared type of the object being
wrapped. This is passed to NativeJavaObject.wrap so that it generates the
correct wrapper. I changed JavaAdapter.generateOverride to generate
bytecode calling Context.toObject passing the declared Class type of the
argument.
Context.java also includes my previously submitted patch for dealing with
SecurityExceptions and the JavaAdapter property (because this patch has not
been checked into CVS yet).
Andrew
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
reflect-patch.txt
Name:
reflect-patch.txt
Type:
Plain Text (text/plain)
reflect-demo.zip
Name:
reflect-demo.zip
Type:
Zip Compressed Data (application/x-zip-compressed)
Encoding:
base64
2) add a test that acts as a sample for doing oberloaded methods on xpconnect wraped natives.
3) add a NOT_IMPLEMENTED method to wrapped native for getting the prototype JS object.
4) Set the global object of the JSContext as the wrapped native JSObject's parent when creating this JSObject. This makes JS code compiled against the wrapper actuall work!
5) fix the refcounting on factories in the tests/components module
Thanks go to Andrew Wason <aw@softcom.com> for finding this problem and providing the patch:
If we implement a Java interface in JavaScript, and a method in that interface returns a Java object, we get a java.lang.IncompatibleClassChangeError: org/mozilla/javascript/Wrapper exception.
We have attached a sample JavaScript file which duplicates the error.
The problem is JavaAdapter is generating an INVOKEVIRTUAL bytecode to call Wrapper.unwrap, but Wrapper is an interface and so INVOKEINTERFACE should be used instead. As a result of this change, the IFEQ bytecode generated needs to jump more bytes. We have attached a patch that fixes the problem.
Andrew
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
- normalized initial MPL comment to match the format of others in the tree, including an initial -*- Mode line.
- removed RCS $log$, etc. comments. We use CVS, and they just make spurious changes...
- js_DecompileValueGenerator had rusted due to bytecode/source-note changes,
or maybe parts of it never worked right. Anyway, it now does not induce a
crashing underflow in the decompiler. As part of this fix, it now takes a
checkStack flag telling whether to look for the jsval v argument on the JS
stack. The calls from ImportProperty, js_SetProperty, and js_DeleteProperty
pass in v a jsval for the property id, which should not be sought after on
the stack (it might happen to be there due to o['p'] = 2, but we want to
decompile o["p"], not "p").
- js_DecompileValueGenerator would load a generating pc even if the value v
did not match the pc's corresponding stack item! Oops. This lead to less
than idea diagnostics.
- js_DecompileValueGenerator was also not mapping JSOP_TRAP to the real op at
a sufficiently early and univeral point in its control flow.
- Fix PopOff to assert and check for stack underflow in the decompiler, and
beef up PushOff too (it asserted, but did not check).
- js_ReportIsNotFunction now avoids JS_InternString by indexing directly into
cx->runtime->atomState.typeAtoms with the result of JS_TypeOfValue.
- Removed unnecessary local GC root reserved by non-zero trailing member of
obj_eval's JSFunctionSpec initializer.
