* 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:
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
