|
JNIPort for Dolphin Smalltalk |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Back to Goodies |
Type Names and Signatures
In Java, classes are named in dot-separated form, such as
It will probably not surprise you to learn that JNI and the JVM do not work this way. Actually there are two, subtly different, naming schemes used by both the JVM and JNI. The good news is that if you use the top-level of JNIPort then you won't have to worry about either of them because the generated class wrappers know about JNI names. The bad news is that if you want to use the JNI wrapper layer or the Java base layer, then you are going to have to get your head around some of this stuff. Sorry! One scheme is used by JNI and the JVM for referring to types by name, the other is used by when specifying the signatures of methods.
(By the way, there is a third naming scheme in the Java world: that understood
by the Java method, JVM/JNI Type Names
In contexts where the Java runtime expects the name of a type (e.g. the
JNI function
If the type is a primitive type ( If the type is an array type (including arrays of primitive types), then the rules are the same as for JNI type signatures. See below for the details, but some examples are:
If you are using the Java Base layer or above, then you don't need to worry about
JVM/JNI type names, since the system understands how to find a class object given a name
in “normal” Java format. (It also understands the JVM/JNI format, but you
aren't forced to use that.) The way to find a class by name (at this level) is to
use the
JVM/JNI Signatures
If you are using the 'Java Base' layer of JNIPort, then you have to specify the
signature of any method you call, or field you access. It may help to know that
the Smalltalk objects that wrap Java's Method Signatures
In Java, methods can be overloaded — that is you can have several different
methods with the same name, but which take arguments of different types. For instance,
if you use the method
A method's signature is written: Type signatures are described below, but here are some examples of complete signature strings for a few methods;
Java constructors (which are not, technically, methods at all) also have signatures;
they are used to distinguish between the different forms of the constructor.
The You will only need to use method signatures if you are using the Java Base level of JNIPort to call methods. The higher level automatically works out the signatures when it generates wrapper methods. Field SignaturesOne possibly surprising fact is that in JNI (and at the JVM level) Java fields have signatures too, and in fact it is possible to have more than one member field with the same name (but holding different types). The signature of a field is just the signature of the type that it is (statically) declared to hold. As with method signatures, you will need to use member signatures if you are using the Java Base level of JNIPort to read/write fields. (The higher levels automatically work out the signatures when the accessor methods are generated). Type SignaturesThe signature names of primitive types are single letters as follows:
(Note the irregularities for
So a method that takes a
would be named by the string “convertCase” and have signature “(CZ)C”, since the signatures of the arguments are 'C' and 'Z' respectively, and the signature of the return-type is 'Z'. A method that takes no arguments and returns void has signature “()V”. The signature of a class is the letter 'L' followed by the fully-qualified class name with the dots replaced by slashes, all followed by a semi-colon. E.g:
The signature of an array class is the letter '[' followed by the signature of the element class (which may itself be another array class), e.g:
|
Copyright © Chris Uppal, 2003-2005
Java, JNI (probably), JVM (possibly), and God knows what else, are trademarks of Sun Microsystems, Inc.