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
git-svn-id: svn://10.0.0.236/trunk@46585 18797224-902f-48f8-a5cc-f745e15eee43
- 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.
git-svn-id: svn://10.0.0.236/trunk@34731 18797224-902f-48f8-a5cc-f745e15eee43
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
git-svn-id: svn://10.0.0.236/trunk@33744 18797224-902f-48f8-a5cc-f745e15eee43
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
git-svn-id: svn://10.0.0.236/trunk@33660 18797224-902f-48f8-a5cc-f745e15eee43
