JEP 102: Process API Updates
| Author | Alan Bateman |
| Organization | Oracle |
| Created | 2011/9/1 |
| Updated | 2012/12/16 |
| Type | Feature |
| State | Candidate |
| Component | core/libs |
| Scope | SE |
| RFE | 4076796 (4333183, 4890847, 6447323) |
| Internal-refs | Oracle:A360:533757, Oracle:jplan:005 |
| Discussion | core dash libs dash dev at openjdk dot java dot net |
| Effort | M |
| Duration | M |
| Endorsed-by | Brian Goetz |
Summary
Improve the API for controlling and managing operating system processes.
Motivation
Long-standing shortcoming in the platform, requiring applications to resort to native code. Long requested by developers.
Description
Java SE provides limited support for native operating system processes. It provides a basic API to setup the environment and start a Process. The Process streams can (since Java SE 7) be redirected to files, pipes, or can be inherited. Once started, the API can be used to destroy the process and/or wait for the Process to terminate.
Many enterprise applications and containers involve several Java virtual machines and processes and have long-standing needs which include:
-
The ability to get the pid (or equivalent) of the current Java virtual machine and the pid of processes created with the existing Process API.
-
The ability to get/set the process name of the current Java virtual machine and processes created with the Process API (where possible).
-
The ability to enumerate Java virtual machines and processes on the system. Information on each process may include its pid, name, state, and maybe resource usage.
-
The ability to deal with hundreds of sub-processes, perhaps multiplexing the output or error streams to avoid creating a thread per sub-process.
Testing
The classes or methods introduced will require new unit tests that can be developed along with the implementation. More functional tests would be useful too.
Risks and Assumptions
The main risk with this API is differences between operating systems (Windows in particular).
The design of this API needs to take possible deployment on smaller devices with different operating system models. It should also take into account environments where multiple Java virtual machines are running in the same operating system process. These considerations could require result in a more abstract API and/or increase the design effort.
Impact
- Compatibility: New JCK test development
- Documentation: Probably updates to the tutorial/guides
