Introduction

The Message-Passing Working Group of the Java Grande Forum was formed about a year ago as a response to the appearance of several prototype Java bindings for MPI-like libraries. An initial draft for a common API specification was distributed at Supercomputing '98. Since then the working group has met in San Francisco and Syracuse. The nascent API is now called MPJ.

Presently there is no complete implementation of the draft specification. Our own Java message-passing interface, mpiJava, is moving towards the ``standard''. The new version 1.2 of the software supports direct communication of objects via object serialization, which is an important step towards implementing the specification in [3]. Once a few remaining open questions about the specification have been resolved, we will release a version 1.3 of mpiJava, implementing the new API. Most likely this will be the first ``reference implementation'' for that API, although some other groups have related efforts.

The mpiJava wrappers rely on the availability of platform-dependent native MPI implementation for the target computer. While this is a reasonable basis in many cases, the approach has some disadvantages

• The two-stage installation procedure--get and build native MPI then install and match Java wrappers--is tedious and probably off-putting to new users. Systems like MPICH made considerable strides in terms of ease of installation on diverse platforms, but historically software for parallel computing has been relatively hard to install and configure for different platforms. Presumably this has not facilitated its wider uptake. In any case, the ``wrapper'' approach to implementing MPJ aggravates matters because it adds one more step to this process.
• On several occasions in the development of mpiJava we saw conflicts between the JVM environment and the native MPI runtime behaviour. The situation has improved, and mpiJava now runs on various combinations of JVM and MPI implementation. Some problems remain. A persistent one relates to concurrent operations involving the same Java array. These ought to be allowed if the concurrent operations refer to disjoint sections of the array. But the way the Java Native Interface mechanism interacts with the data in Java arrays means that unexpected results may occur.
• Finally, this strategy simply conflicts with the ethos of Java, where pure-Java, write-once-run-anywhere software is the order of the day.

Ideally, the first two problems would be addressed by the providers of the original native MPI package. We envisage that they could provide a Java interface bundled with their C and Fortran bindings, avoiding the the headache of separately installing the native software and Java wrapper. Also they are presumably in the best position to iron-out low-level conflicts between the MPI library and the Java runtime. Hence we can only encourage vendors and other providers of MPI software to consider releasing Java wrapper software (which could be based on the public domain mpiJava, for example) along with their core software. Ultimately, such packages would probably represent the fastest, industrial-strength implementations of MPJ.

Meanwhile, to address the last shortcoming listed above, this report considers production of a pure-Java reference implementation for MPJ. Design goals are that the system should be as easy to install on distributed systems as we can reasonably make it, and that it be sufficiently robust enough to be useable in an Internet environment. Ease of installation and use are special concerns to us. We want a package that will be useable not only by experienced researchers and engineers, but also in, say, an educational context. A corollary of easy installation is that the software should only depend on other systems that are widely installed. A minimum requirement is a Java development environment, including RMI. Beyond this we assume the installation of some Jini software. This technology is relatively new, but it seems likely that it will become pervasive in Java-aware environments.

We are by no means the first people to consider implementing MPI-like functionality in pure Java, and working systems have already been reported in [8, 6], for example. The goal here is to build on the some lessons learnt in those earlier systems, and produce software that is standalone, easy-to-use, robust, and fully implements the specification of [3].