Metagnostic
home

JNIPort for Dolphin Smalltalk

Overview

Contents

Players

Layers

Examples

Configuration

InFAQ

Changes

Licence


Back to Goodies

Additional Pre-defined Wrapper Classes

JNIPort comes with a package of extra pre-defined wrapper classes. These are provided:

  • As examples.
  • In case they come in useful.
  • Because I'd generated them anyway, so I might as well throw them in…

The additional wrappers are not needed by JNIPort proper, although they are used by some of the examples.

Nearly all of them wrap common Java classes, the Java 2 Collections, the Java IO classes, and the Java iterators, and give them something of the protocol of the Smalltalk equivalents.

There are a few other wrapper classes in the package, but none of them add much, if anything, to what the Wrapper Wizard generated.

Just as a warning: these wrapper classes are not, in general, as lavishly commented as is my habit. You are expected to know the Smalltalk interface to the various Collection classes, for example, and if you are looking at the implementation of the adaptors then you are also expected to know about the equivalent Java classes. For similar reasons, this section is very short.

IO-Stream Wrappers

There are two classes, JavaReadStream and JavaWriteStream, which act as root classes for instance-side wrappers for the root classes of the Java IO hierarchy. They attempt to emulate the protocols of the corresponding Smalltalk ReadStream and WriteStream classes. The emulation is patchy, especially for read-streams (because Java's streams are not arbitrarily positionable).

These classes illustrate an important point — it is not necessary to follow the Java class hierarchy slavishly when designing the hierarchy of wrapper classes. In this case, for instance, JavaReadStream captures commonality between the Java classes, java.io.OutputStream and java.io.Writer even though those two classes are not formally related in Java.

Collection Wrappers

Java's new (well, it is fairly old now) Collections API is defined by a handful of interfaces: java.util.Set, java.util.List, java.util.Map, and so on. Java does provide concrete implementations of these interfaces, but there are lots of them, they are not all related in the hierarchy in any useful way (there's no reason why they should be), and you are quite likely to come across other objects that implement these interfaces, but which are not part of standard Java.

For that reason, the Java Collections are a good example of the need for interface instances, JNIPort's built-in facility for associating an adaptor with a Java interface. (In point of fact, they were the motivation for it.)

Given a Java object that implements the java.util.Set interface, you can send #asASet to it (which is just an abbreviation for #asA: #'java.util.Set'). That will answer an instance of JavaUtilSet, which understands the basics of the Smalltalk Set protocols, as well as exposing the methods from the java.util.Set interface in the normal way. You can further send that object #asCollection, which will answer a deeper Adaptor that is subclassed from Set and therefore understands all of Set's interface (including whatever methods you may have added yourself). Similar observations apply to the other collections interfaces.

Iterator Wrappers

Java has two external iterator classes; the old java.util.Enumeration and the newer java.util.Iterator. Like the new collections, these are best handled by JNIPort's interface instances. In this case the wrapper classes implement the basics of Smalltalk's ReadStream. A deeper Adaptor, which is subclassed from ReadStream, can be obtained by sending #asReadStream.


Copyright © Chris Uppal, 2003-2005

Java, JNI (probably), JVM (possibly), and God knows what else, are trademarks of Sun Microsystems, Inc.