What happened to System/Process.getPid() ?

[Rob McKenna]

I've just done some bug cleanup here. I've altered the synopsis of 
4244896 to:

Provide Process.waitFor(timeout), Process.destroyForcibly() and 
Process.isAlive()

and I've created:

8003488: (process) Provide Process.getPid()
8003490: (process) Provide System.getPid()

For some reason Process bugs/feature requests always appear to come in 
pairs. I've closed a few other bugs as dups of these issues. (half may 
be fixed by one issue, the other half may apply to the new bugs) In 
general we should keep these requests as granular as possible to avoid 
the current situation.

     -Rob

On 15/11/12 14:51, Jim Gish wrote:
> I got a start on this back in September ( 
> http://cr.openjdk.java.net/~jgish/pidstuff/ 
> <http://cr.openjdk.java.net/%7Ejgish/pidstuff/>), but as Alan 
> indicated, it's not as easy as all this.  I haven't gotten back to it, 
> but it is on our radar.
>
> Thanks,
>     Jim
>
> On 11/15/2012 07:26 AM, Martin Buchholz wrote:
>> I was half-planning on implementing getPid back in 2008 but ran out 
>> of time.
>>
>> My intent was to have the pid simply be a String, even though on common
>> platforms an int would suffice, leaving enough room for unusual
>> implementations to get what they want.
>> Essentially, return in String form what humans would use to identify
>> processes on the machine, which might be e.g. "NODENAME:NNN" on a 
>> cluster.
>>
>> Martin
>>
>> On Thu, Nov 15, 2012 at 2:08 AM, Alan Bateman 
>> <Alan.Bateman at oracle.com>wrote:
>>
>>> On 15/11/2012 01:11, Rob McKenna wrote:
>>>
>>>> Hi Thomas,
>>>>
>>>> Don't ask me why, but for some reason this mail just landed in my 
>>>> client
>>>> now. (this happens a lot on this mailing list for some reason)
>>>>
>>>> getPid() is still on the todo list at the moment. Once I clear my 
>>>> plate a
>>>> little I'll follow up on it.
>>>>
>>>>      -Rob
>>>>
>>> I just received too, and dozens of other mails so there must have 
>>> been a
>>> blockage somewhere.
>>>
>>> I think the issue with 4244896 is just that you didn't change the 
>>> synopsis
>>> to reflect what the changes were actually about. It would be good to 
>>> link
>>> it to the bug suggesting a getPid equivalent. You probably know this 
>>> but a
>>> getPid and perhaps a getCurrentPid requires great care. We cannot 
>>> assume
>>> that it can be represented by an int or long, it needs to allow for
>>> environment that might not have the notion of process as we know it, 
>>> also
>>> needs consideration of environment where they may be several VMs 
>>> running in
>>> the same process. So lots of wriggle room in the spec, otherwise it 
>>> will
>>> not be implementable everywhere.
>>>
>>> -Alan
>>>
>