- Throw nsIXPCException objects rather than strings into JS.
- Better and more information in exceptions - including names of result codes and call stack.
- Added nsIJSErrorReport as attachment to exceptions for JS errors.
- Exceptions thrown in JS now get properly translated into result codes.
- Exceptions thrown JS->native->JS get propagated.
- Added per thread nsIXPConnect::[G,S]etPendingException.
- Added XPCConvert::JSValToXPCException - still needs better handling JS exception objects.
- Added XPCConvert::JSErrorToXPCException.
- No longer eat JS errrors in wrapped JS code called from native code.
- Declare xpconnect result codes in nsIXPConnect.h.
- Changed format of xpc.msg to give error names and descriptions.
- Fixed extraneous semicolons on XPC_IMPLEMENT_* macro usage.
- Using NS_IMPL_ISUPPORTS2 for nsIXPCScriptable declarations.
- Improve refcounting in xpccomponents.
- Turned some common code into macros.
- Converting some interfaces to use mccabe's NS_IMPL_* macros.
- Cleanup lots of trailing whitespace.
- Fixed idl comments.
# The contents of this file are subject to the Netscape Public License
# Version 1.0 (the "NPL"); you may not use this file except in
# compliance with the NPL. You may obtain a copy of the NPL at
# http://www.mozilla.org/NPL/
#
# Software distributed under the NPL is distributed on an "AS IS" basis,
# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the NPL
# for the specific language governing rights and limitations under the
# NPL.
#
# The Initial Developer of this code under the NPL is Netscape
# Communications Corporation. Portions created by Netscape are
# Copyright (C) 1998 Netscape Communications Corporation. All Rights
# Reserved.
#
DEPTH = ../../../..
topsrcdir = @top_srcdir@
srcdir = @srcdir@
VPATH = @srcdir@
include $(DEPTH)/config/autoconf.mk
LIBRARY_NAME = xpconnect
MODULE = xpconnect
CPPSRCS = \
nsXPConnect.cpp \
xpcarbitrary.cpp \
xpccomponents.cpp \
xpccontext.cpp \
xpcconvert.cpp \
xpcjsid.cpp \
xpclog.cpp \
xpcmaps.cpp \
xpcmodule.cpp \
xpcstack.cpp \
xpcthreadcontext.cpp \
xpcthrower.cpp \
xpcwrappedjs.cpp \
xpcwrappedjsclass.cpp \
xpcwrappednative.cpp \
xpcwrappednativeclass.cpp \
xpcwrappednativejsops.cpp \
$(NULL)
include $(topsrcdir)/config/config.mk
# XXX hackage!
# only copy the .so to components dir on platforms where xptcall is supported
# Unixish x86
ifneq (,$(filter SunOS Linux FreeBSD NetBSD BSD_OS,$(OS_ARCH)))
ifeq (86,$(findstring 86,$(OS_TEST)))
IS_COMPONENT = 1
endif
endif
# Neutrino Cross-Compiled for x86
ifneq (,$(filter NTO,$(OS_TARGET)))
ifeq (86,$(findstring 86,$(OS_TEST)))
IS_COMPONENT = 1
endif
endif
# Solaris/sparc
ifeq ($(OS_ARCH),SunOS)
ifneq (86,$(findstring 86,$(OS_TEST)))
IS_COMPONENT = 1
endif
endif
# Linux/sparc
ifeq ($(OS_ARCH),Linux)
ifeq ($(OS_TEST),sparc)
IS_COMPONENT = 1
endif
endif
# NetBSD/m68k
ifeq ($(OS_ARCH),NetBSD)
ifneq (,$(filter amiga atari hp300 mac68k mvme68k next68k sun3 sun3x x68k,$(OS_TEST)))
IS_COMPONENT = 1
endif
endif
# BeOS/Intel
ifeq ($(OS_ARCH),BeOS)
ifeq ($(OS_TEST),BePC)
IS_COMPONENT = 1
endif
endif
# HPUX
ifeq ($(OS_ARCH),HP-UX)
ifneq ($(CC),gcc)
IS_COMPONENT = 1
endif
endif
# AIX
ifeq ($(OS_ARCH),AIX)
IS_COMPONENT = 1
endif
# IRIX
ifeq ($(OS_ARCH),IRIX)
ifneq ($(basename $(OS_RELEASE)),5)
IS_COMPONENT = 1
endif
endif
# OpenVMS (Alpha only at this point)
ifeq ($(OS_ARCH),OpenVMS)
ifeq ($(CPU_ARCH),Alpha)
IS_COMPONENT = 1
endif
endif
# Linux or NetBSD ARM
ifneq (,$(filter Linux NetBSD,$(OS_ARCH)))
ifeq (arm,$(findstring arm,$(OS_TEST)))
IS_COMPONENT = 1
endif
ifeq (sa110,$(findstring sa110,$(OS_TEST)))
IS_COMPONENT = 1
endif
endif
include $(topsrcdir)/config/rules.mk
# this is automatically discovered under BeOS
ifneq ($(OS_ARCH),BeOS)
LIBS += \
-lmozjs \
-lxpcom \
-lmozreg \
$(NSPR_LIBS) \
$(NULL)
endif
DEFINES += -DJSFILE -DJS_THREADSAFE
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
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
jband%netscape.com
ramiro%netscape.com
mccabe%netscape.com
briano%netscape.com
brade%netscape.com
cls%seawood.org
mgleeson1%netscape.com
tbogard%aol.net
norris%netscape.com
beard%netscape.com
rogerl%netscape.com
toshok%hungry.com
brendan%mozilla.org