The Java socket interface hides much of the ugly detail involved in socket-programming at the traditional C/Unix level. The java.net interfaces provides less flexibility than using the system calls directly. On the other hand, Java's built-in support for threads adds some flexibility in scheduling communications that is missing from raw C.
We will give an example of socket programming in Section 2.2.1, but traditionally this has not been a popular paradigm in the parallel processing world. Scientific programmers have expected to program inter-process communication at a higher level, if at all. More successful schemes include
As observed in the previous section, communication through true shared memory is already implicit in the Java thread model. Communication through remote objects (i.e RMI) is undoubtedly a natural and important paradigm in Java, especially for access to remote services. However, it suffers from a significant startup time and marshaling/unmarshaling of data is more costly than in the socket method.
An orthogonal issue is whether the high-level libraries used to implement these paradigms (presuming class-library implementations) should be written in Java on top of the standard API, or whether they should be implemented as direct interfaces to native code.