A lot of problems that are best solved in C by using multiple processes
communicating are, in Java, better solved by using multiple threads
inside of a single JVM process. In this instance, one just has a
producer/consumer pattern with a stream-like object that has a
synchronized put and get of some sort. The java.util classes provide
implementations of Deque, Stack, and Queue that you might synchronize on
and use for inter-thread communication (e.g. a job queue). For a
character stream, use a Stream you make that looks like an input stream
to one thread and an output stream to the other, with the input stream
read methods blocking until the other thread writes to the output stream
interface of the object, and synchronization used. Read up on
synchronization, Object.wait(), Object.notify(), and then check up on
java.util.concurrent. Synchronization and other threading matters are
covered in Sun's Java tutorials at java.sun.com and wait, notify, Deque,
Stream, and the like have in-depth javadocs ("synchronized" itself
doesn't as it's a language keyword, though). Packages of interest:
java.util, java.util.concurrent, java.lang (Object and Thread, and
various exceptions), and java.io (streams).

If you must go with interprocess communication, streams are again the
way to go, but you'll have no simple and reliable file locking mechanism
from in Java (at least without resorting to JNI). If the host operating
system provides an atomic nonexistent-file-creation shell command you
can System.exec this to atomically create lockfiles with a failure
return if the lockfile's already been created by another process, and
implement cooperative locking in the manner typical on Unix systems. You
might also want to look into RMI and other such complicated file-less
methods of Java interprocess communication, or replace using a file with
using a database that maintains transactional integrity with concurrent
uses (you get an atomic lock-creation primitive, at minimum, since any
DBMS worth even its weight in cat turds will provide atomic transactions
in general).

You may even be able to use System.exec from one process to create the
other and pipe an OutputStream to the new process's input; check the
System and ProcessBuilder javadocs and experiment to see if you can get
a simple demo working.

But your best bet is probably with turning these processes into threads
and sharing a data structure such as a queue. C provides no standard
threading or internal synchronization tools, which results in the C
idiom being IPC with external files, named pipes, lockfiles, and the
like. Java does provide standard threading and synchronization tools.

On Sat, 22 Sep 2007 01:11:48 GMT, "timothy ma and constance lee"
<timcons1@shaw.ca> wrote, quoted or indirectly quoted someone who said

You could do this with an aux dummy lock file that exists while the
file being shared is busy.

In Java 1.6 there are some new file locking tools. I have not played
with them.  I don't even recall what they are called.  Check the
release notes.

There are other ways to tackle the problem.

1. if A and B are threads in the same JVM, they can talk to each other
with a pipe. see http://mindprod.com/applet/fileio.html

2. A and B can communicate via a TCP/IP socket.
http://mindprod.com/jgloss/tcpip.html

3. A can drop the info off in an SQL database.  SQL deals with
locking. http://mindprod.com/jgloss/sql.html