The current draft MPJ specification supports all MPI-like error handling using the Java exception model. An alternative suggestion that has been put forward is that all MPJ exceptions be derived from two classes: MPJException and MPJRuntimeException. Subclasses of MPJException would represent errors that the user would be required to catch whereas subclasses of MPJRuntimeException would represent uncommon or unusual errors. It has also been suggested that certain MPJ exceptions could carry sub-exceptions when the cause of the error is another exception. Whether, or not, to utilize MPI-like user-defined and predefined error handlers is also an open question. In principle, these error handlers could still serve a purpose in addition to the exception mechanism mentioned above.
It has been suggested that the specification of user-defined operations could be simplified. In the current proposal, which is modelled after a procedural approach, a more complex or unique operation can be created in two phases. Initially users define functions and then create a new operation class (Op). This results in the creation of an extra class (UserDefinedOperation) which is not really necessary. An alternative approach would be to simply have users define subclasses of the class Op with a named method (for example, call). This design would also eliminate the overhead associated with method invocation.
A profiling interface for MPJ has not yet been defined. A possible general design approach is for profiling class and method names to exactly match those of the non-profiling classes and methods. Implementors would then place the compiled binary files in different locations. As Java linking is always dynamic, this would allow users to enable or disable profiling simply selecting the appropriate code base (e.g. by changing the CLASSPATH environment variable).