Browse Prior Art Database

Processes control utility for Java Disclosure Number: IPCOM000115877D
Original Publication Date: 2005-Mar-30
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 56K

Publishing Venue



The present publication addresses a way to extend the current Java tools for spawning and controlling OS processes

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Processes control utility for Java

The Java Runtime Environment gives a user the capability to create a new process and set its arguments and environment.

     However it does not provide any mechanism to asynchronously notify the creating process about the death of a child of its. The supported way to check the termination of a child process is synchronous and blocks the controlling thread if the checked process is still living. Moreover that check could be needed in order to free the system resources (such us the pipes being created to allow the communication between the process and its father) kept allocated by the JVM while the process is living. That depends by the specific implementation of the JRE and by the operating system which the JVM is running on. For example a specific JRE implementation on a UNIX-like operating system could have a SIGCHLD signal handler being designed to release the involved system resources. But this is not the general case.

     So in most cases the user has to ask the Java Runtime for checking the termination of its child process and therefore, to avoid a likely undesiderable program flow blocking condition, he/she has to create a dedicated thread permanently waiting for the process termination. The user should do that even if he/she is not interested to follow the life-cycle of its child process.

     Another crucial aspect of managing a child process is the eventuality of its block caused by the fullness of the buffers being used by the IPC mechanism adpted in the father-child communication. In some Java implementations the lack of a regular reading of the streams being used as standard output and standard error of the child process could cause the filling of these and the consequent block of the child process. So, in scenarios where the application is not interested to the standard output or error of its child process, it has to include a couple of threads whcih permanently read any new byte written into standard output/error of the child process.

     Any Java user could find useful a utility which frees him/her from the tasks described above. So he/she should explicitly read the child's stream and/or wait for the child termination only if he/she is interested to do that. In the other cases the utility would do that instead. That utility would provide te user with the following functionalities: all the process spawning capabilities, as allowed by the java.lang.Runtime.exec() methods automatic flushing of communication streams whose content is not used by the user automatic notification of childs death.

   The utility includes the following interfaces/classes Class DetProcFactory

Includes a createDetProc() method for each exec() methods of java.lang.Runtime class. Each createDetProc() method has the correspondig exec() signature augmented with two boolean parameters, outAutoFlush and errAutoFlush. The former enables the utility to automatically flush the standard output of the child process, as described above. The...