I have four colleagues, none of whom have Perl experience. The colleagues agree that change is necessary but are of the opinion that Java should be the language of choice (there is more Java in the original system than Perl, although the manufacturer has written a Perl API (= some modules) as well as a Java API).

Although it's not the answer you're looking for but if I had a team with four Java folk, and a system that was already partly implemented in Java, I'd just do it in Java. Not because of technical issues, but because of social ones (more Java skills in house, no need to retrain, etc.)

However - to your original points:

- greatly reduce the spawning of new ksh processes
- ready interface to unix system services
- Open3 to control input and output between existing utility programs

All these apply equally well to Java

- CPAN

A possible win - but only if you can point to the bits of CPAN that will actually help this particular project get implemented more quickly.

- associative arrays
- scoped untyped variables
- flexible choice of procedural versus OO (ksh is only procedural)

Java has hashes. In any case - you need to argue why these things are good for your project.

- perl -d (debugger - no such thing for ksh)

I'd say Java has better tool support (debuggers, IDEs, refactoring, etc.) than Perl.

perl's regexp engine is better than awk/sed's without needing to shell out

Potential win for Perl.

- perl's hashes are more flexible and scopable than formula engine's (Formula Engine provides only a single global hash).

Java has other data structures too. You'll need to argue that Perl's are better for you application.

- perl can communicate more effectively with background processes.

So can Java.