They are both supported API. So one is not any easier than the other.
Mandy
On 8/3/17 8:08 PM, Hohensee, Paul wrote:
Thought it would be an easier path, but I didn’t know for sure, hence
my question.
Thanks,
Paul
*From: *Mandy Chung <[email protected]>
*Date: *Thursday, August 3, 2017 at 5:10 PM
*To: *"Hohensee, Paul" <[email protected]>
*Cc: *Ujwal Vangapally <[email protected]>,
serviceability-dev <[email protected]>
*Subject: *Re: JDK-8185003 JMX: Add a version of
ThreadMXBean.dumpAllThreads with a maxDepth argument
Why? There is a reasonable request to
java.lang.management.ThreadMXBean. dumpAllThreads and getThreadInfos
methods should have taken the maxDepth parameter when it was
introduced. Unfortunately they didn’t and need to add two new methods
to it.
Mandy
On Aug 3, 2017, at 1:42 PM, Hohensee, Paul <[email protected]
<mailto:[email protected]>> wrote:
Add it to com.sun.management.ThreadMXBean rather than
java.lang.management.ThreadMXBean?
Paul
*From: *serviceability-dev
<[email protected]
<mailto:[email protected]>> on behalf of
Mandy Chung <[email protected] <mailto:[email protected]>>
*Date: *Thursday, August 3, 2017 at 1:04 PM
*To: *Ujwal Vangapally <[email protected]
<mailto:[email protected]>>
*Cc: *serviceability-dev <[email protected]
<mailto:[email protected]>>
*Subject: *Re: RFR: JDK-8185003 JMX: Add a version of
ThreadMXBean.dumpAllThreads with a maxDepth argument
On Aug 3, 2017, at 8:24 AM, Ujwal Vangapally
<[email protected]
<mailto:[email protected]>> wrote:
Thanks for the review Erik,
I will investigate more considering Daniel's comment.
Adding a public method to an interface is an incompatible
source change unless there is a default body. On the other
hand I am not sure how MXBean proxies will work when proxying
an interface containing a default body. It would be
interesting to check this.
ThreadMXBean is a platform MXBean and so JDK implementation is the
one implementing it. The real question here is that when
MBeanServerConnection.invoke is called on this new method that
does not exist in the remote MBeanServer (running on JDK 9 for
example), does it get javax.management.ReflectionException? Or
something else?
Similarly, when the client gets a proxy of ThreadMXBean from a
remote MBeanServer running on JDK 9 VM, and it calls this method,
what exception does it get? We may need to update the spec to
indicate this error cases if it’s not clear. The notes in
ManagementFactory.newPlatformMXBeanProxy covers some cases due to
the difference in the client/server are running on.
Mandy
kindly use below webrev for referring changes as webrev.00 is
not accessible.
http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.01/
<http://cr.openjdk.java.net/%7Euvangapally/webrev/2017/8185003/webrev.01/>
-Ujwal
On 8/3/2017 8:00 PM, Erik Gahlin wrote:
Looks good, not a reviewer.
Nit, saw that spaces before commas were missing in some
method calls, i.e. ",-1" instead of ", -1"
Erik
Hi,
kindly review the changes made.
https://bugs.openjdk.java.net/browse/JDK-8185003
webrev:
http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.00/
<http://cr.openjdk.java.net/%7Euvangapally/webrev/2017/8185003/webrev.00/>
CSR: https://bugs.openjdk.java.net/browse/JDK-8185705
Thanks,
Ujwal.
