Process API Updates (JEP 102)

Martin Buchholz martinrb at
Tue Mar 25 20:41:51 UTC 2014

We still have the conflict between providing portable pure Java programs
and providing real access to the underlying OS (except for APIs like chdir
that mutate global process state - too unsafe for Java).  JDK seems to be
more willing these days to create portable access to non-portable features
(like symlinks).  More pragmatism, less religion.

I expected to find a getpid for java, but I don't see it there yet.

There's a new trend to provide non-blocking (CompletableFuture-style)
access to everything, but the OS may not be cooperative.

Users want to send arbitrary Unix signals, e.g. be able to access all
signals as a Map<String, Integer> and send those signals to arbitrary other

Users want to access all attributes of all processes on the system.

Thinking about features missing to implement a proper Emacs in java, top of
the list is pty support, so one can implement interactive shells in Emacs

I don't actually expect these to happen, and they're very hard to do, but
will be happy if they do.

On Mon, Mar 24, 2014 at 2:11 PM, roger riggs <roger.riggs at> wrote:

> Hi,
> I'm starting to work on JEP 102, Process API Updates for JDK 9.
> The use cases identified include test execution and build systems such
> as Jtreg and Hudson/Jenkins. And there is a use-case for using Java
> to monitor the health of a more complex system where the processes
> are not spawned by the same manager.
> The current API of Process itself is pretty complete with the addition of
> a getPid
> method to enable identification of subprocesses spawned by the application
> and allow external identification.  It will not be possible to intercept
> the input,
> output and error streams of an arbitrary process.
> From the scope of the JEP, a fairly simple API seems sufficient.
>  - Enumerate the direct children
>  - The rest of the functions are similar to Process
>    - to terminate a process, forcibly and normally
>    - to destroy a process and all of its children recursively
>    - to check if one is alive
>    - to waitFor for termination and retrieve the exit status
> Are there use cases for which this is insufficient?  Please comment.
> Thanks, Roger

More information about the core-libs-dev mailing list