We have been exploring the integration of Tycho with Java. The combination of a high-level object-oriented scripting language, (Itcl) with an object-oriented system programming language (Java) is very attractive. Java in itself is attractive for its clean syntax and semantics, its support for distributed programming, and its high degree of portability. Members of the Ptolemy group are currently implementing an exploratory dataflow simulation engine in Java, which will be accessed from a Tycho graphical interface.
We based out Tycho-Java interface on version 0.4 of Sun's experimental Tcl-Java interface [15]. Not all features of Tcl work correctly in this implementation--exec, for example, is broken, and the exception handling does not work correctly with JDK1.1 - but it works well enough for us to explore the integration of Tcl and Java. We layered our own Java classes above the Tcl-Java interface to provide a simpler Tcl interface to Java programmers. We register a Tcl command called ::java::new; this command creates a Java object of the requested class, a ``wrapper'' object that converts arguments into the appropriate types, and a Tcl command to access the object. For example, in Tcl, we could write:
::java::new tycho.TclExample foo
In the TclExample class (in the Java package named tycho), a method might look like this:
public Double example1(Interp interp,
Integer iobj, Double dobj ) {
int i = iobj.intValue();
double d = dobj.doubleValue();
return new Double(i + d);
}
To call the method, we simply execute the Tcl code
foo example1 example1 5 3.2
which prints ``8.2'' as its result. The wrapper object uses Java's reflection API (java.lang.reflect) to find out the argument types of the method being called, converts the strings passed from Tcl into objects of the correct types, and then calls the correct method. Although there is some overhead in this approach, the interface is much cleaner than that provided by the Tcl-Java interface alone. With the Tcl8.0 byte-compiler, we think this style of interface will probably be needed to take advantage of Tcl native types.
As an alternative experiment, we used tksteal [3] to re-parent the Java applet viewer into itkwish, but found that the applet viewer didn't have the proper command-line interface to make this work smoothly.
In general, we would like to use [incr Tcl] (and [incr Tk]) for our user interface components, and Java for all new ``back-end'' development, including complex data structures and simulation tools. Although we have considered the possibility of using Java only, we would much prefer to integrate [incr Tcl] and Java. Apart from saving us a lot of rewriting (Java was still very new when Tycho was started), the Java user interface support is not as mature as Tk, and we rely heavily on Tk's more complex widgets, such as the text widget and the canvas widget.
In our view, it is unfortunate that Sun have not made a bigger effort to integrate Java and Tcl/Tk. Tk is unquestionably superior to Java's current UI support, and Java is our choice for future non-UI development. The Java UI is developing rapidly, however, and if we cannot successfully integrate Java and Tcl/Tk, then we may end up moving away from Tcl/Tk as the Java UI components mature. In our opinion, the most important efforts Sun can make to ensure the future success of Tcl and Tk are to (i) provide adequate support for object-oriented extensions to Tcl such as [incr Tcl], and (ii) to provide a seamless, efficient, and platform-independent interface to Java.