Java Signatures

About:

A signature is a list that specifies a class constructor, an instance method, or a static method, thereby distinguishing it from other constructors, instance methods, or static methods.

Two forms of signatures are accepted: simple and full. A simple signature is a single element list containing the name of the method or constructor. In most cases a simple signature is all that is needed as the Java method resolver is able to disambiguate overloaded Java methods based on the types of Java object arguments. There are some cases where the Java method resolver is unable to determine which Java method you intended to invoke so you will need to use the full signature for the method or constructor. The full signature is used to distinguish between two or more methods or constructors that have the same number of arguments. The full signature of a method is a Tcl list containing the method name followed by the name of the Java object type for each parameter of the method.

Examples:

This command will create a Java String object and store a reference to it in a Tcl variable.

set jstr [java::new String "I am a Java string"]

There are a couple of things that you should note about this example. First, the constructor signature used here is a simple signature meaning a list containing a single element {String}. The system will automatically check to see if a class name that containes no dots is really in the java.lang package. In this case the class name String is found to exist in the java.lang package so an instance of the class java.lang.String will be allocated. The second thing you should notice about this example is that the Java method resolver is being used to disambiguate between overloaded constructors in the String class.

Here is a list of the java.lang.String constructors that take a single argument.

String(byte[])
String(char[])
String(String)
String(StringBuffer)

By default a Tcl string will be converted to a java.lang.String so in this case the method resolver picks the String(String) constructor.

One could also invoke the constructor using a full signature.

set jstr [java::new {String String} "I am a Java string"]

In this case the Tcl string is converted to a java.lang.String and the String(String) constructor is invoked. The only difference is that the Java method resolver is not used when a full signature is provided.

Lets looks at another more compicated example. Assume that we are using a Java class which is defined like this.

import java.util.*;
public class A {
  public String foo(Hashtable h) {return "H";}
  public String foo(Vector v) {return "V";}
}

One could use a full signature to invoke the overloaded foo method, but it is easier to give a simple signature and let the method resolver do the work for us.

% set hash [java::new java.util.Hashtable]
% set A [java::new A]
% $A foo $hash
H

There is also the possibility that the method resolver will not be able to choose a method to invoke based on the type(s) of the argument(s). If this occures, the method resolver will give up and return an error message indicating which methods could not be disambiguated.

% $A foo "a string"
ambiguous method signature, could not choose between {foo java.util.Hashtable} {foo java.util.Vector}

Copyright © 1997-1998 Sun Microsystems, Inc.