Interfacing R E D U C E to Java

Artl~ur Norman 1 a n d John Fitch 2

1 University of Cambridge Computer Laboratory

Cambridge CB2 3QG, England, and Codemist Ltd.
2 School of Mathematical Sciences, University of Bath
Bath BA2 7AY, England and Codemist Ltd.

Abstract. For some time it has been clear that algebra systems ought not
to exist as isolated software packages, but should be viewed more as compo-
nents in a more general scientific problem-solving environment. A so-called
"software bus" would then link perhaps several algebra engines, each with
special areas of strength, to. separate tools to support numerical calculation,
visualisation, domain-specific scripting or other capabilities. The term "bus"
as used here derives from the same worcl used to describe a mode of trans-
port, and as such is an abbreviation for omnibus - - stressing the fact that to
be useful it must be universally available. The language and system Java[5]
presents itself as a candidate for such general acceptance by many different
classes of application, so this paper is a preliminary investigation of both how
Java code can be linked to REDUCE and what might be done by exploiting
such a link.

1 Introduction
The motivation for creating a link between REDUCE and Java is twofold. On the one
hand it is to provide other applications with a program-based interface to REDUCE's
algebraic capability, using Java as an increasingly widely available mechanism for
co-ordinating the transfer of information. On the other it is so that code written in
and residing within REDUCE itself can gain access to a wider range of graphical
viewers, network services, browsers and general third-party tools.
Use of Java in this way does not address the issues of making algebra system
interfaces semantically neutral (as considered by the OpenMath[1] working group),
although it does provide the possibility of partitioning the work of providing an
OpenMath interface for REDUCE between code internal to REDUCE and a C-like
Java veneer. Instead Java is used here to address the practical problems of linking
and interfacing disparate packages, where at a lower implementation level a variety
of invocations of sockets, pipes, OLE and other arcana may be needed. It also aims
to hide all the system-dependent aspects of interface code, so keeping everything as
clean and portable as possible.
While it is predicted that Java will grow over the next few years to become a
universal portable c~ordinating language, at present it is most directly associated
with Web browsers, remote execution of code and the generation of cute animated
visual effects. This side of it means that in the short term its most valuable use in
association with, REDUCE will be in support of operations with that sort of flavour:
this is of course close to the collection of ideas presented by Hearn elsewhere[2] at
this meeting.
 272

When interfacing two complete programming languages the first big issues to be
addressed are how symmetric the link-up should be and how intimate the link-up
should be. At one extreme would be the case where one language is totally in change
and it invoked the other by passing some neutral data such as strings of characters.
At the other would be complete integration of the languages with fully shared data
types and representations. The study here attempts to follow the second of these
styles, so that REDUCE and Java code can be mixed in a very free manner. As well
as the obvious advantages that this brings it causes a number of difficulties both in
implementation and use, but before considering these the implementation strategy
that was adopted will be described.
Java is defined both by a language definition in the usual style, and by the de-
scription of a byte-oriented virtual machine. The official Java Development Kit[4]
includes a compiler that maps from the source language into this byte-coded form,
and it is expected that this representation (wrapped around with additional symbol
table information) will be the way in which Java programs are distributed. Simple
implementations of the language can consist of an emulation of the virtual machine
together with support for various pre-defined class libraries. Higher performance
versions may choose to view the virtual machine as the definition of an architec-
turally neutral intermediate language, and then provide the back-end of a compiler
to map from the byte-coded form of a program into real machine code for the target
architecture. The overall structure of the REDUCE implementation used here[3] is
in many respects similar. REDUCE packages start off written in their own source
language (RLISP), which is then compiled by way of Standard Lisp into a machine
independent byte-code representation (which has been optimised for the support of
Lisp). An interpreter can then process the byte-codes to run REDUCE. To improve
performance it is also possible to compile key parts of REDUCE into C code which
is linked in to provide extensions to the normal Lisp run-time environment. The
compiled C is typically faster but also typically bulkier than the byte-code version
of any given function. But since the implementation allows C coded and byte-coded
functions to be mixed without constraint it is possible to gain almost all of the speed
of a fully compiled system and almost all the space-saving of a fully byte-compiled
one by selecting only the most heavily used functions for compilation into C.
Thus the scheme adopted here is to build an implementation of the Java Virtual
Machine as part of the CSL Lisp system, to arrange that it can share at least some
data types with REDUCE's Lisp world, and to make it possible for functions that
use the Lisp and the Java sub-systems to call each other and otherwise, interact.

2 The Bytecode Interpreters

A byte-code interpreter for the Java Virtual Machine has to provide a stack, a
garbage-collectable heap and a method area (within which byte-codes are literal
tables are stored). Apart from the fact that the exact representation and layout
of some data types are rigidly specified (this would, for instance, make it slightly
painful to implement the floating point parts of Java on an non-IEEE computer).
Otherwise the most complicated part to support involves the resolution of items
in literal pools, since the language provide for late binding. Documentation of the