JDK-8044122 : MBean access to the PID
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-05-28
  • Updated: 2017-11-22
  • Resolved: 2017-11-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b33Fixed
Related Reports
Blocks :  
JDK-8046092 - JEP 102: Process API Updates
Blocks :  
JDK-8003490 - (process) Provide Process.getCurrentPid() to get identifier of current process
CSR :  
JDK-8189091 - MBean access to the PID
Relates :  
JDK-8003488 - (process) Provide Process.getPid()
Description
Now that there is an API call (JDK-8003488) to get the PID, it would make sense to extend the Runtime MBean to provide the pid. This can already be done by parsing the name attribute of the Runtime MBean, but providing a clean API for accessing the PID would make it possible for people to stop relying on this implementation detail.
Comments
Will be planned for next Major release.
15-07-2016
What would be the use case when the PID of a remote process is required?
10-12-2015
The advantage would be a supported *JMX* API. I suspect a lot of JMX tools are currently relying on RuntimeMXBean#getName().split("@")[0]. I know JMC is. Of course, some of these probably have control over the server side process and can deploy their own MBeans, delegating to ProcessHandle.current().getPid(). I still believe this should not be necessary, and that instead having a supported JMX API for this information would make sense. The RuntimeMXBean would be the appropriate place for such an attribute.
03-06-2015
Isn't remote access the obvious advantage that you won't get with ProcessHandle.getPid()? Not sure how useful remote access to the pid is, though.
02-06-2015
The advantage would be a supported API. Currently everyone is basically doing RuntimeMXBean#getName().split("@")[0] which is a horrible thing to subject people to. ;)
02-06-2015
Now that ProcessHandle.current().getPid() is available, is that sufficient? What advantage is there to adding it to RuntimeMXBean?
02-06-2015
Seems ProcessHandle.current().getPid() is proposed.
22-07-2014
JDK-8003488 only added support for getting the pid of a started Process object. It did not add support for getting the pid of our own process. That seems to be what JDK-8003490 "(process) Provide Process.getCurrentPid() to get identifier of current process" is about.
12-06-2014
I propose fixing this in 9.
28-05-2014