Unfortunately Sun’s API is of little use. The problem is that the interface is designed with the assumption that you have a printer out there and want to talk to it - a most unlikely assumption. If you just wanted to print, there would be no need to use javax.com; you would use the standard printing api.

The exception is when you have dot matrix printer and you need speed, e.g. as a cash register printer. Java uses Windows which sends all printing as graphics. To be quick, you must send text intermixed with printer-specific formatting commands. You can do that with RTextPrinter.

Far more likely, you have a robot, a geiger counter, a numerically controlled sewing machine, a kinetic sculpture, or other bizarre device that you want to control via bit fiddling. Unfortunately, the javax.comm interface doesn’t let you do this. The typical way of controlling a non standard device through the parallel port is to merrily ignore the control lines for the most part, or use them in some bizarre way, and pump data through the output lines. Input is done by absconding with the control in lines, and use them in ways Centronics never imagined, e.g. to read nifty stuff like whether the dragon is fully submerged.

Presumably the sun engineer implemented javax.comm by reading the Centronics printer spec. Too bad, he/she missed the point of why you need a javax.comm interface. You will have to roll your own with JNI.

If you are tinkering with a home brew interface, tie the parallel port status lines 10 and 11 (Ack and Busy) to low/ground and lines 12, 13 and 15 (paper out, select, and error) to high/5V. The javax.com software will not work without properly simulated status signals.