JEP 102: Process API Updates

AuthorAlan Bateman
OwnerRoger Riggs
Created2011/09/01 20:00
Updated2014/11/19 14:29
TypeFeature
StatusTargeted
Componentcore-libs / java.lang
ScopeSE
Discussioncore dash libs dash dev at openjdk dot java dot net
EffortM
DurationM
Priority2
Endorsed byBrian Goetz
Release9
Issue8046092
Blocks8044122: MBean access to the PID
8044840: [TESTBUG] get rid of JMX in com.oracle.java.testlibrary.ProcessTools.getProcessId() for getting current process id
Relates to8003490: (process) Provide Process.getCurrentPid() to get identifier of current process
4333183: (process) Add a way to gently shutdown, as opposed to destroy, a subprocess
6439432: (process) Access to system-specific process-related APIs
6447323: (process) Native OS process information and control
4076796: (process) Provide Process.isAlive(), like Thread.isAlive()
4890847: (process) Add Process.ID and Process.waitFor(long timeout)

Summary

Improve the API for controlling and managing operating-system processes.

Motivation

The limitations of the current API often force developers to resort to native code.

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:

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, in particular Windows.

The design of this API needs to accommodate 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 lead to a more abstract API and/or increase the design effort.