Subject:
Re: [Fwd: [Bug 13658] Changed - Rhino: null pointer exception on class with duplicate field/method]
Date:
Mon, 13 Sep 1999 20:57:32 -0400
From:
"Kurt Westerfeld" <kurt@westerfeld.com>
To:
"Norris Boyd" <norris@netscape.com>
I do have a patch for this, but it is intermixed with some other changes
that I have implemented for the get/set on Java instances (per my LC3
proposal). The bug requires changes that are a little involved actually;
basically it seems that when getting the default value for a "field and
methods" (which combines the same-named entities), the prototype of the
parent scope is deref-ed, and the parent scope is null. Hence, the scope
must be passed into the the cloned field and method values.
Also, the NativeJavaClass implementation passed "false" for isStatic on the
constructor of the FieldAndMethods Hashtable, which results in classes
having instance methods. Bad. I haven't filed a bug on that yet.
Additionally, I fixed a couple other NullPointerException nigglies thrown in
when exceptions are propagated in the same area. Finally, when getting the
default value for the field, it is helpful to convert a Scriptable to string
when that is requested (as when typing in the console).
I am attaching the changed files. The LC3++ code can be removed if you
want, which I can do for you but it will take a little longer. What is your
preference?
-----Original Message-----
From: Norris Boyd <norris@netscape.com>
To: Kurt Westerfeld <kurt@westerfeld.com>
Date: Monday, September 13, 1999 4:54 PM
Subject: [Fwd: [Bug 13658] Changed - Rhino: null pointer exception on class
with duplicate field/method]
>Kurt,
>
>Is this the bug that your patch fixes?
>
>Thanks,
>Norris
>
Turned off 'super' keyword - was letting through some cut'n'pasted java
code quietly and blowing big chunks out of the codegen/interpreter later.
Anybody know why 'super' had an interesting value here? - there was no
support for it on any path that I could see.
Subject:
Embedding the shell
Date:
Wed, 8 Sep 1999 16:01:44 -0400
From:
"Kurt Westerfeld" <kurt@westerfeld.com>
To:
"Norris Boyd" <norris@netscape.com>
Norris, please find the attached zip file containing the (minor)
modifications to the Rhino shell module that enables the shell to be
embedded in a host application.
There are two areas of change to be concerned about:
1. Any and all references to System.in/out/err have been modified to use
Main.in/out/err, which default to System.in/out/err. Methods to do a setIn,
setOut, and setErr were added. Note that in/out/err on Main were made
static public, so that the jikes compiler wouldn't complain (I had them as
static protected, but when accessed outside of the package, a warning was
issued).
2. The global and sharedGlobal static variables were made protected so
that my app can make use of them (to add extensions after an initial pass
through main()).
That's it.
I have successfully used the facility to drop a remote telnet server into
the shell interpreter, effectively giving our server a remote shell
interpreter. It's quite nice, as we have a lot of extensions to Rhino
written that blend into our server already.
PS, I am still working on the array issues, but made a lot of progress
today. I just wanted to get this stuff off my desk.
Thanks!
________________________________________________________________________
Kurt Westerfeld
Managed Object Solutions
2722 Merrilee Drive
Suite 350
Fairfax, VA 22031
Phone: 703.208.3330 x225
Fax: 703.208.3331
http://www.mosol.com
mailto:kurt@mosol.com
shell.zip
Name:
shell.zip
Type:
Zip Compressed Data (application/x-zip-compressed)
Encoding:
base64
==============================================================================
Subject:
Rhino Array Source (Fixed)
Date:
Thu, 9 Sep 1999 14:12:03 -0400
From:
"Kurt Westerfeld" <kurt@mosol.com>
To:
"Norris Boyd" <norris@netscape.com>
Attached is NativeJavaObject.java, which seems to now pass the tests supplied to me by you and Scott. Not a lot of change, but a lot of
testing and thinking was involved. <g>
PS. I also fixed a bug in reportConversionError() which was throwing an IllegalArgumentException inside of the MessageFormat class at times.
It also looks a little nicer (uses formatting from NativeJavaMethod) and closer to the C implementation.
NativeJavaObject.java
Name:
NativeJavaObject.java
Type:
Java Source File (text/java)
Encoding:
quoted-printable
The fix sort of works. But there are some new problems. I enclosed two JavaScript files, button.js and image.js.
If I load button.js first and then image.js, I got the following:
js> load("button.js");
js> load("image.js");
Ambiguous import: [JavaClass javax.swing.ImageIcon] and [JavaClass javax.swing.ImageIcon]
js> load("image.js");
Ambiguous import: [JavaClass java.net.URL] and [JavaClass java.net.URL]
js> load("image.js");
Ambiguous import: [JavaClass java.lang.System] and [JavaClass java.lang.System]
js> load("image.js");
loadImage for 0
Ambiguous import: [JavaClass java.awt.Toolkit] and [JavaClass java.awt.Toolkit]
js> load("image.js");
loadImage for 0
js>
If I load imag.js first and then button.js, I got the following:
js> load("image.js");
loadImage for 0
js: [JavaPackage java.lang.URL] is not a function.
[JavaPackage java.lang.URL] is not a function.
js> load("image.js");
js: [JavaPackage java.lang.ImageIcon] is not a function.
[JavaPackage java.lang.ImageIcon] is not a function.
js> load("image.js");
js: [JavaPackage java.lang.ImageIcon] is not a function.
[JavaPackage java.lang.ImageIcon] is not a function.
js> load("image.js");
js: [JavaPackage java.lang.ImageIcon] is not a function.
[JavaPackage java.lang.ImageIcon] is not a function.
js> load("button.js");
js: [JavaPackage java.lang.JButton] is not a function.
[JavaPackage java.lang.JButton] is not a function.
js> load("button.js");
js: [JavaPackage java.lang.JButton] is not a function.
[JavaPackage java.lang.JButton] is not a function.
js> load("image.js");
js: [JavaPackage java.lang.ImageIcon] is not a function.
[JavaPackage java.lang.ImageIcon] is not a function.
js>
It looks like something wrong in the image.js file but this should not interfere with button.js. It looks like some arbitary package objects are created, like java.lang.URL. This happened in NativeJavaPackage.get method. If a class of java.lang.URL is not found, a package object is then created. So next time the interpreter encounters URL, it somehow uses the object java.lang.URL instead of the correct class object java.net.URL.. This is one problem. The interference between button.js and jmage.js is another problem.
Howard
----- Original Message -----
From: Norris Boyd
To: \ Howard\\ Xuhua Lin
Sent: Thursday, August 12, 1999 12:58 PM
Subject: Re: ImporterTopLevel problem
Sorry I've been slow. I finished up the fix this morning and have posted it on the ftp site and checked into cvs.
Let me know if it works for you.
--Norris
\"Howard\" Xuhua Lin wrote:
Hi, Norris, what's the status of the ImporterTopeLevel problem (i.e if you use importPackage twice, you will get an "Ambiguous import" exception)? Are you still working on it? Howard
Subject:
ImporterTopLevel problem
Date:
Fri, 6 Aug 1999 15:42:50 -0400
From:
"\"Howard\" Xuhua Lin" <howard@softcom.com>
To:
"Norris Boyd" <norris@netscape.com>
CC:
"Andrew Wason" <aw@softcom.com>
Hi, The following script will cause an EvaluatorException: Ambiguous import: [JavaPackage java.awt.JButton] and [JavaPackage
java.awt.Packages.javax.swing.JButton] in the js shell:
js>importPackage(java.awt);
js>importPackage(Packages.javax.swing);
js>new JButton();.
The current JS shell will not print this exception message, even though the comment says "// Already printed message, so just fall
through". I add System.err.println(ee.getMessage()); for this exception.
The problem is that in NativeJavaPackage.get(String, Scriptable) method, if a ClassNotFoundException is caught, a
NativeJavaPackage object is created and passed back to ImporterTopLevel.get Method. So in ImporterTopLevel.get method, object v
is always not NOT_FOUND and the ambiguous exception will be thrown. Object v is supposed to be a Class object but it actually is
a Package object.
The fix can be either (1) in NativeJavaPackage.get(String, Scriptable) method, if a ClassNotFoundException is caught, return a
NOT_FOUND object (you may still create a Package object) or (2) in ImporterTopLevel.get method, make sure the returned object
from NativeJavaPackage.get method is of NativeJavaClass type.
Howard
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
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...
Support for jsGet_ and jsSet_ prefixes to methods for explicit getter
and setter definition.
Addition of "importClass" and "importPackage" top-level functions.
The beginnings of a history object accessible from the shell.
- check static members of instances in JavaMembers.put
- do not unwrap Wrappers before calling NativeJavaMethod.findFunction
or NativeJavaObject.coerceType; both methods may need extra information
provided by the wrapper.
- separate Java signatures for resolving overloaded methods and script
signatures for error messages, so we can distinguish primitive types
from classes.
- separate Java signatures for resolving overloaded methods and script
signatures for error messages, so we can distinguish primitive types
from classes.
- prevent a NativeJavaClass from being treated as a wrapped instance of
java.lang.Class
- correct bug which preferred the *less* specific of two classes in
NativeJavaMethod.preferSignature
- add new LC3 conversion rules to NativeJavaObject.coerceTypes.
- coerce JS numbers to Java numbers or chars only if the JS number is in
range.
Re: netscape.javascript.JSObject ?
Date:
Thu, 03 Jun 1999 17:52:42 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Norris Boyd <norris@netscape.com>
References:
1 , 2 , 3 , 4 , 5 , 6 , 7 , 8
Norris Boyd wrote:
>
> Sorry--missed the checkin of a new file. It's there now.
>
> I'd also added a small change for the "inheritance" of JavaScript array methods.
Actually, I've already done that (and for String as well). It still
fails some LC3 regression tests, though.
I'm including a tarfile that includes the previous changes and the new
ones.
Frank
Re: Rhino LiveConnect: need help?
Date:
Wed, 02 Jun 1999 19:33:37 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Scott Furman <fur@netscape.com>, Norris Boyd <norris@netscape.com>
CC:
mallen@eng.Sun.COM
References:
1 , 2 , 3 , 4
Scott Furman wrote:
> In order to bring Rhino LiveConnect support up to the level of the
> C-engine, the features of LiveConnect version 2 and version 3 would
> need to be added. You can see some details of LC2 and LC3 features
> here. I would guess that 80% of the time would be spent implementing
> one feature: LC3's new method overload resolution scheme.
OK, I think I have something that implements the new overloaded method
resolution scheme ... I'm still working on getting the regression tests
running smoothly, but from command-line testing it seems to work. It's
not the *cleanest* code I've ever done, though: in particular, it has
too many static methods and type-checking code for my tastes. (Hey,
should we spin the type coercion and comparison stuff to some other
module entirely? Right now it's mostly in JavaNativeObject, with the
preference stuff in JavaNativeMethod.) I'm also not sure why some of
this stuff is public, and whether there might be backward-compatibility
problems with what I've done, particularly in repurposing the
COMPARISON_* constants.
Would you guys be kind enough to review this for me? I'm hoping to
check it in once I get an ID, but it wouldn't hurt to have another pair
of eyes or three (pairs, I mean). I've attached a tar/gzip of the
source files I've changed (or added), plus a diff.
Thanks,
Frank
Re: Rhino LiveConnect: need help?
Date:
Wed, 02 Jun 1999 19:33:37 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Scott Furman <fur@netscape.com>, Norris Boyd <norris@netscape.com>
CC:
mallen@eng.Sun.COM
References:
1 , 2 , 3 , 4
Scott Furman wrote:
> In order to bring Rhino LiveConnect support up to the level of the
> C-engine, the features of LiveConnect version 2 and version 3 would
> need to be added. You can see some details of LC2 and LC3 features
> here. I would guess that 80% of the time would be spent implementing
> one feature: LC3's new method overload resolution scheme.
OK, I think I have something that implements the new overloaded method
resolution scheme ... I'm still working on getting the regression tests
running smoothly, but from command-line testing it seems to work. It's
not the *cleanest* code I've ever done, though: in particular, it has
too many static methods and type-checking code for my tastes. (Hey,
should we spin the type coercion and comparison stuff to some other
module entirely? Right now it's mostly in JavaNativeObject, with the
preference stuff in JavaNativeMethod.) I'm also not sure why some of
this stuff is public, and whether there might be backward-compatibility
problems with what I've done, particularly in repurposing the
COMPARISON_* constants.
Would you guys be kind enough to review this for me? I'm hoping to
check it in once I get an ID, but it wouldn't hurt to have another pair
of eyes or three (pairs, I mean). I've attached a tar/gzip of the
source files I've changed (or added), plus a diff.
Thanks,
Frank
rogerl%netscape.com
beard%netscape.com
norris%netscape.com
mccabe%netscape.com
frankm%eng.sun.com
mang%subcarrier.org