Thread support in Java is pretty robust, and I think that's the way you'd handle this type of problem. Rather than forking children and communicating with them, in Java you'd use threads to do the work.

If you really need processes, this could be a big selling point in favour of Perl.

Java fork emulation is a real pain in the ass: you basically have no easy way to fork the current process, so you have to call Runtime.exec() and pass it the Java class to execute. This fires up a new JVM, which takes a lot of CPU and memory. Then, you'll also have major problems in communicating between the various JVMs, since Java does not (natively) offer anything like pipe or the inter-process communication tools offered by the various IPC::* modules, so you basically have to resort to JNI, or you have to use sockets, RMI, or even CORBA (one can also resort to EJB, that's true, but this could be an overkill and an unmistakable source of major headaches).

As for threads, though it's true that Java prefers threads over real processes (and their implementation in Java is robust), it is important to stress that threads are not real processes.
For instance, real processes will seamlessly migrate over an SSI cluster of machines (as long as they don't use shared memory), while threads will not.
Also, an application based on real processes rather than on threads is much more robust, since each process runs in a separate address space while threads all live in the same address space, so that a single thread crash can bring down the whole application.
And forking a new process is only marginally slower than creating a new thread, on systems that use Copy-On-Write (basically any modern *nix).

Ciao, Emanuele.

Sorry, Java is OO only.

I keep hearing this, but it makes no sense. A class filled with static members and methods is no different than a package filled with global variables and functions. Perl uses a methods as subs approach. Java uses a subs as methods approach. The syntax is different, but both are capable of procedural and OO programming.

Yes, you can make all static classes and put a driving script in a main method in Java. But, not matter what, you must put all of that in a class. Hence the charge: Java is Object Oriented Only. We say this, because every single line of operative code must be in a method and every single method must be explicityly placed into a class. You can't just write a driver:

print "driver starting\n";
`call_system_util1`;
`call_system_util2`;
print "driver finished\n";
[download]

The equivalent code in Java must be in a method of some class. That's overkill in this case and it buys nothing except tedious typing, which is why we make the charge and it sticks.

There are two subtle bits of syntatic sugar here. First, Perl puts things in the main package by default. Second, code does not have to appear in a method/sub/function/whatever. It can just go in a driving script. Perhaps these differences seem small, but they are real.

Phil

But, not matter what, you must put all of that in a class. Hence the charge: Java is Object Oriented Only.

Same in Perl. If one is not specified explicitely, main is used.

You can't just write a driver

You can't have driver code in C either, but that doesn't stop you from coding procedurally in C. That Java can't have drive code does not preclude programmers from writting procedural Java programs.

Perhaps these differences seem small, but they are real.

I didn't say there weren't differences. (Quite the opposite.) I said programmers code procedurally in Java, so it's not only OO.