What happened to System/Process.getPid() ? (original) (raw)

Rob McKenna rob.mckenna at oracle.com
Thu Nov 15 16:19:05 UTC 2012

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

More information about the core-libs-dev mailing list