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
Subject:
Re: Modified Context.java
Date:
Sat, 15 May 1999 08:01:37 +0000
From:
"Ian D. Stewart" <idstewart@softhome.net>
To:
Norris Boyd <norris@netscape.com>
References:
1 , 2 , 3 , 4 , 5
Ian D. Stewart wrote:
Norris Boyd wrote:
Can I help with EventListener collector?
Actually, I have a working implementation complete (attatched), but by all means, feel free to add any functionality you feel
may be missing, or to tweak the code .
Norris,
After I sent I my last e-mail, I noticed some potential issues using Object[] in ListenerCollection.getListeners(Class iface).
I'm attatching a new version, which uses a Vector object. This should resolve those issues.
Ian
Rhino SecurityException patch
Date:
Tue, 11 May 1999 12:25:50 -0400
From:
Andrew Wason <aw@softcom.com>
To:
Norris Boyd <norris@netscape.com>
Sorry if you aren't the right person to submit Rhino patches to.
I couldn't get Rhino to run under JDK1.2 with a SecurityManager installed
(e.g. java -Djava.security.manager=java.lang.SecurityManager). I
understand the JavaAdapter stuff won't work - but I would still like to use
Rhino without that piece.
I've attached a small patch which catches and ignores the
SecurityExceptions so that Rhino can run with a SecurityManager but without
JavaAdapter.
Andrew
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
Subject:
Context.newArray() bug
Date:
Thu, 22 Apr 1999 00:26:29 -0700
From:
beard@netscape.com (Patrick Beard)
To:
Norris Boyd <norris@netscape.com>
When the arguments array gets created, its prototype isn't set up
correctly. I think the problem is in Context.newArrayHelper(), which isn't
able to look up the "Array" constructor in the passed-in scope. For this
reaon, top-level scripts that use "arguments.length" don't work.
- Patrick
norris%netscape.com
mccabe%netscape.com
beard%netscape.com
frankm%eng.sun.com
rogerl%netscape.com
mang%subcarrier.org