## 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.