RFR 9: 8003488 Add Process.getPid

Martin Buchholz martinrb at google.com
Wed May 14 23:14:12 UTC 2014

I am OK with using longs despite my academic worries about the year 2100.

On Wed, May 14, 2014 at 1:03 PM, roger riggs <roger.riggs at oracle.com> wrote:

> Hi,
> For system local process identifiers, all of the systems I'm aware are
> 32 bit integers,  printed and parsed in decimal for ease of use.
> I would describe the native pid as:
>     The native process id is the identifier commonly used in the
>     operating system APIs and commands to show the status of and
>     manage processes; typically a decimal number with 1 to 6 digits.
> The Apollo system used a string to be able to uniformly address
> processes across  hosts and it was parseable to host and decimal pid.
> I anticipate a ProcessHandle type with methods to check if the process is
> alive,
> to destroy it, wait for it to terminate, etc.
> It would be a supertype of Process but not all ProcessHandles would be
> processes
> since they were not created by Process/ProcessBuilder and have different
> security concerns and checks.
> ProcessHandles would be returned from factory methods like current(long
> pid)
> or current().   If Java is ported to a system with non-numeric process
> identifiers
> it would be viable to add appropriate factory methods.
> Roger
> On 5/12/2014 5:01 PM, Alan Bateman wrote:
>> On 12/05/2014 20:44, roger riggs wrote:
>>> Please review and comment on this long requested addition to provide the
>>> native process id of a spawned Process.
>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/
>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8003488
>> I think the representation of the pid needs consideration - we need to be
>> happy that using a long is the right thing to do and won't cause us
>> problems in the future and won't conflict with other APIs that we might add
>> in this area.
>> In terms of spec then it might be helpful to say a bit more to define a
>> "native process id", even in an abstract way.
>> -Alan

More information about the core-libs-dev mailing list