JTcl and Swank: Whatʼs new with Tcl and Tk on the JVM 1Bruce A. Johnson, 2Tom Poindexter, & 3Dan Bodoh 1 bruce@onemoonscientific.com, One Moon Scientific, Inc, Westfield, NJ and University of Maryland, Baltimore County 2 [email protected] 3 [email protected] Abstract JTcl is an implementation of the Tool Command Language (Tcl) written in Java and is derived from the Jacl project. The current release (2.0) of JTcl implements a large ex- tent of Tcl 8.4 syntax and commands, limited only by the API restrictions of the Java Vir- tual Machine. Swank is an implementation of the TK GUI toolkit implemented using the Java Swing GUI API. Most Tk 8.4 widgets and commands have been implemented as well as additional ones based on Swing widgets. This paper describes the current state of these projects and gives examples of their use. Introduction While there is an abundance of alternative The Java Virtual Machine [Lind99] has programming languages on the JVM, become a platform on which a variety of there are relatively few implementations of computer programming languages can be graphical user interface toolkits besides executed. While originally written to exe- the AWT and Swing toolkits that come cute Java programs that had been com- standard with most Java distributions. piled into Java byte codes, it is now used The primary alternatives have been to run languages such as Clojure, Groovy, Swank, SWT (the Standard Widget Jacl, JRuby, Jython, Rhino and Scala Toolkit), and quite recently JavaFX. While [WikiJVM]. Some of these, like Scala, SWT is largely implemented on top of na- appeared originally as a language on the tive platform widgets and JavaFX is im- JVM, and others, like Jacl, are JVM im- plemented with its own windowing toolkit, plementations of existing languages. Swank is a layer on top of the Swing wid- Jacl, which is an implementation of Tcl gets that provides an interface to the pro- [Ost10], was one of the first non-Java lan- grammer that is analogous to that of the guages on the JVM and appeared shortly Tk toolkit [Ost10]. after the initial development of Java [Lam97]. In this paper we’ll discuss recent devel- Jacl Modernization opments in the Tcl and Tk on the JVM, fo- Jacl modernization was selected as one cussing on the language implementation of the Tcl Core Team projects during the JTcl, and the Tk-style graphical user in- Google Summer of Code 2009 [Szul09]. terface toolkit Swank. The goal of the project was to bring Jacl's language features to the level of Tcl/C 8.4. Tcl 8.4 was chosen as a target level for JTcl several reasons. First, it represented a JTcl is a fork of Jacl, an implementation of stable base of Tcl compliance that could Tcl written in Java [Lam97]. Jacl was writ- be achieved by implementing new com- ten during the period of Tcl/C 8.0 devel- mands or augmenting existing ones. opment and contains Java equivalents of Second, the project was limited to one many internal data structures, most impor- student for one summer, so the work tantly the notion of Tcl objects to hold bi- product of the GSOC project was limited. nary representation of numeric data types, Third, current Tcl/C version 8.5 contained efficient list and array structures, and im- many structural changes, such as the ex- plementation of most of Tcl 8.0's com- pand syntax which would require a con- mands. Jacl does not implement the Tcl siderable amount of interpreter changes. byte code compiler and runtime [Lew96], The target of the GSOC project was de- nor the Tcl fileevent command and sup- rived by comparing the current set of Jacl porting event system that allows for event command definitions with the Tcl/C 8.4 driven I/O. After initial development by definitions. Many of the command imple- the original authors, Jacl development mentations required relatively little addi- was performed by individuals rather than tional code to support a particular com- as an official port of the Tcl Core Team. mand option, larger code rework was re- During this time Jacl development slowed quired to implement commands such as to mostly bug fixes but did result in a few [regex] and [regsub]. These commands major improvements, a port of the Incr Tcl relied on moving from a custom underly- object system [DeJ05] and the Tcl-to-Java ing regular expression library to use the compiler (TJC) [DeJ06]. Development of Java java.util.regexp package. core Tcl commands and features did not keep synchronized with mainline Tcl de- While the GSOC 2009 Jacl Modernization velopment. Despite Jacl's slow progress, project yielded many improvements, it did it had proved useful in a number of com- not reach full Tcl 8.4 compliance. The mercial products, open source projects GSOC project relied on command de- and proprietary internal projects. Jacl was scriptions based on the Tcl 8.4 manual used by IBM in its WebSphere Application pages, so while many command options Server and One Moon Scientific's were added or improved, strict compli- NMRView products [John04], as well as ance to Tcl/C test cases was not tested. the open source Swank and Æjaks pro- The Jacl implementation of [regex] and jects [Poin07]. [regsub] improved significantly to match Tcl 8.4, but many edge cases were not addressed. Addition of a event system and [fileevent] also proved to be too ambi- tious, requiring more time that was avail- able. Tcl Compliance and Test Suite The Tcl language for any particular ver- The JTcl project was formed to continue sion is described in man pages and other development of Jacl and complete the documentation, but the definitive source work of the GSOC Jacl Modernization of Tcl compliance is represented by the project. The project founders decided that Tcl test suite. The test suite is usually de- a fork was the best way to achieve its veloped in conjunction with a particular goals. Jacl was a part of the TclJava pro- version of Tcl to ensure that the inter- ject, which produced the the Jacl inter- preter's result for any give operation preter as well as TclBlend, a Tcl extension matches expected results. that enables use of Java classes and ob- jects from the the Tcl/C runtime. Much of The Jacl project contained a test suite that the TclJava packaging and build system matched Tcl 8.0 compliance and was en- was designed to support the use of the hanced as changes were made to the java package in both Jacl and TclBlend source code. For JTcl, the Tcl 8.4 test environments. JTcl project members had suite was imported and used to measure no interest in the TclBlend extension and Tcl compliance. JTcl integrates the Tcl instead would focus entirely on the Java test suite through the JUnit test facility. implementation of Tcl. JUnit is a Java oriented test environment, roughly equivalent to the tcltest Tcl pack- In addition to furthering Tcl 8.4 compli- age. When running JUnit in a Java envi- ance, a number of other improvements ronment, the normal usage is to run a test were desired. First, Java code develop- method that invokes methods on an ob- ment is greatly enhanced by the use of ject under test, and asserts that actual re- Java-centric Integrated Development En- sults are equal to expected results. vironments (IDEs) such as Eclipse, Net- Since JUnit is widely supported by Java beans and IntelliJ, so the structure of the IDEs, the Tcl test suite in JTcl is invoked JTcl source code should be arranged to through JUnit classes. This allows testing support easy use by Java IDEs.. Second, of JTcl source code directly from the IDE, the build system in Jacl using make would without requiring a compile/test cycle. be replaced with a Java-centric build sys- tem. While make could be used to com- The Tcl test suite contains generic tests pile and package JTcl, Java oriented build that should run the same on any execu- systems ant and maven are better sup- tion platform as well as many tests that ported by Java IDEs. Third, packaging are specific to the platform. For example, the JTcl system would be in a single jar a particular test may only run on a Win- file for simple installation, as opposed to dows platform, while an equivalent test the Jacl system packaging in five sepa- may only run on a Unix environment. A rate jar files. Lastly, extraneous source Java JVM presents a single virtual ma- code such as the TclBlend extension chine that (mostly) eliminates machine would be removed entirely. and platform differences. As a result, only the tests that are labeled as generic are Basic-RE meta-character ('b') are not tested in JTcl. supported. To work around these differences, the JTcl Even with running only the generic Tcl JUnit base class is designed to run a Tcl tests in JTcl, many differences in test re- test suite test file with a list of expected sults were observed and many of which failure cases. Each failure case returned were false negative results. Erroneous by the test suite is examined to note the test results generally fell into the following type of the failure, and when the differ- categories: ence could be categorized as one of the above cases, that case was added to the 1. Differences in error messages – expected failure list. The result of the ex- when a test would check for specific pected failure lists allow the entire test error messages, differences between suite to be run, with a better indication of JTcl and Tcl/C would often arise as er- positive or negative results.