|
JNIPort for Dolphin Smalltalk |
|
Back to Goodies |
JNIPort OverviewJNIPort is my name for a collection of packages that allow Java code to be invoked from Dolphin Smalltalk. The implementation builds on the Java “native” interface (called JNI), and then provides the superstructure to let you to manipulate Java objects pretty much as if they were Smalltalk objects. The main advantages of this are:
However, please do read the section on the problems and limitations of JNIPort. JNIPort works by talking to a “real” running JVM, rather than by executing the Java bytecodes in the Smalltalk VM (which, as I understand it, is how the Frost project, and Smalltalk-X do it). This approach has both advantages and disadvantages. One of the big advantages is that JNIPort is always complete and up to date with the latest Java version. One downside is that the performance advantages of running Java bytecodes on a high-performance JVM can be lost in the overhead of crossing the “boundary” between the Smalltalk VM and the Java VM. A bigger disadvantage is that JNIPort is very exposed to the the JVM, which is just a DLL sharing the same process space as Dolphin. Any peculiarities of the way it does things can affect Dolphin; for instance calling java.lang.System.exit() will duly cause your Dolphin session to exit! (So don't do that.) JNIPort comes with a fair amount of documentation. It is not intended to be exhaustive, but is just to help you get oriented with the system. It's less well structured than I would like, but good places to start might be:
A complete list of the JNIPort documentation is here, and a few more examples are listed here. The rest of this overview is a very short example of using JNIPort with ghost classes. First we need a connection to the JVM, there are various ways of configuring and starting these, but here we'll just assume that one is running already.
The JVM instance is the central point of JNIPort. It is responsible for starting up and shutting down the Java DLL, it also acts as the switchboard through which the various objects in the system can find each other. In particular it is where you go to find a handle on a Java class. Each Java class is represented by a unique class static. These objects have methods corresponding to the class side (“static”) members of the Java class; they also have methods corresponding to the Java classes' constructors.
We'll start with
That has looked for, and possibly created, the class static that stands for
which is equivalent to the Java code:
only, of course, you are invoking it in a interactive workspace — which you can't
do normally in Java. What has actually happened is that
Now we'll call a method with a parameter:
This time we called a method that takes a String argument (automatically converted from
a Smalltalk String) and answers an instance of
We can send it messages corresponding to the Java methods in
Notice the way we pass multiple integer parameters. Again this is using one of the automatically generated wrapper methods; you are not limited to using the generated methods, you can also set up normal Smalltalk methods. JNIPort already comes with quite a lot of helper methods to give Java Strings (and other aggregates like arrays) a Smalltalk face. For instance Smalltalk-style iteration:
which will write
JNIPort knows how to assign Java instances to the correct wrapper class. In the
case of strings, JNIPort includes a class (called, imaginatively enough,
We can ask the
Or we can ask it for its class static.
The class static, remember, represents the Java class. Class statics are unique, so:
The class static is where the constructors live, so we can create a new string, in this case an empty string:
Or a copy of our original one:
Or a copy of a Smalltalk string:
There's lots more to tell, but I want to keep this example short. See the rest of the JNIPort documentation for details. |
Copyright © Chris Uppal, 2003-2005
Java, JNI (probably), JVM (possibly), and God knows what else, are trademarks of Sun Microsystems, Inc.