A Draft Java binding for MPI

This appendix outlines a Java language binding for MPI 1.1. It has been adapted from the proposal in reference [1], incorporating especially suggestions and comments from Vladimir Getov and Glen Judd. It is presented here as a basis for further discussion and comment.

This is not a standalone specification of the behaviour of MPI--it is meant to be read in conjunction with the MPI standard document. Subsections are laid out in the same way as in the standard document, to allow cross-referencing. Where the Java binding makes no significant change to a particular section of the standard document, we will just note here that there are no special issues for the Java binding. This does not mean that the corresponding section of the standard is irrelevant to the Java binding--it may mean it is 100% relevant! Where practical the current proposals are modelled on the MPI C++ interface defined in the MPI standard version 2.0.

Changes to the mpiJava interface:

• Name conventions have been shifted to bring them into line with Sun's Java code conventions [7].
• The MPI.OBJECT basic type has been added.
• The public fields of Status have been replaced by inquiry methods.
• The MPI exception classes are no longer specified to be subclasses of IOException.
• The Request method is_null has been replaced by isVoid, and the constant MPI.REQUEST_NULL is removed in favour of providing a default constructor for Request.
• Derived type constructors contiguous, vector, hvector, indexed, hindexed become non-static methods on oldtype.
• A new variant of Comm.pack has been added.
• The bindings of MPI_ATTR_PUT and MPI_ATTR_DELETE have been removed.
• The translateRanks member of group becomes a non-static method on group2.
• The interface to Cartcomm.dimsCreate has been corrected.

Controversies and open questions:

• It is unclear whether the Java interface should support MPI derived data types. A proposal for a Java-compatible subset of derived types is included in this document, but deleting it could simplify the API significantly.
• It has been suggested that many of the communication operations should be overloaded to provide simplified variants that omit arguments such as offset, count (possibly datatype). This suggestion is not included in the current proposal, but it could be added later if there is general support. The obvious counter-argument is that it significantly increases the total number of methods in the API.
• It has been suggested that some specific support for multidimensional arrays may be desirable. In the current proposal, communicating multidimensional arrays depends on Java object serialization, which might be a performance bottleneck. A plausible position is to wait and see what happens in Java regarding multidimensional arrays and efficient object serialization before complicating this API.
• It has been suggested that the specification of UserFunction could be altered to improve type security. This suggestion isn't incorporated in the current draft, but perhaps it should be.