Process API Updates (JEP 102)

[Martin Buchholz]

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
processes.

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
buffers.

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 oracle.com> 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
>
>