JavaParty

JavaParty [38] allows easy ports of multi-threaded Java programs to distributed environments such as clusters. Regular Java already supports parallel applications with threads and synchronization mechanisms. While multi-threaded Java programs are limited to a single address space, JavaParty extends the capabilities of Java to distributed computing environments. It adds remote objects to Java purely by declaration, avoiding disadvantages of explicit socket communication and the programming overhead of RMI. The basic approach of JavaParty is that a multi-threaded Java program can be easily transformed to a distributed JavaParty program by identifying the classes and threads that should be spread across the distributed system. A programmer can indicate this by a newly introduced class modifier, remote, which is the only extension of Java. As a parallel language, the most important feature of JavaParty is its ``location transparency.'' Similar to HPF, programmers don't have to distribute remote objects and remote threads to specific nodes because the compiler and run-time system deal with locality and communication optimization. JavaParty is implemented as a pre-processor phase to a Java compiler. It currently uses RMI as a target and thus inherits some of RMI's advantages such as distributed garbage collection. JavaParty codes is translated into regular Java code with RMI hooks. For example,

is translated into

$$\begin{minipage}[t]{\linewidth}\small\begin{verbatim} interface B... ... RemoteException { // method toRemote(Q) ; } }\end{verbatim}\end{minipage}$$

JavaParty is for parallel cluster programming in Java. It has important contribution to research on Java-based parallel computing. Moreover, because the only extension is the remote keyword, it is systematically simple and easy to be used and to be implemented. However, HPJava provides lower-level access to the parallel machine. Compared to the HPJava system, the basic approach of JavaParty, remote objects with RMI hooks, might become its bottleneck because of unavoidable overhead of RMI and limited evidence that the remote procedure call approach is good for SPMD programming.