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]> wrote:
> 
> Add it to com.sun.management.ThreadMXBean rather than 
> java.lang.management.ThreadMXBean?
>  
> Paul
>  
> From: serviceability-dev <[email protected]> on 
> behalf of Mandy Chung <[email protected]>
> Date: Thursday, August 3, 2017 at 1:04 PM
> To: Ujwal Vangapally <[email protected]>
> Cc: serviceability-dev <[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/~uvangapally/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 
> <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/~uvangapally/webrev/2017/8185003/webrev.00/> 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 
> <https://bugs.openjdk.java.net/browse/JDK-8185705> 
> 
> Thanks, 
> 
> Ujwal.
> 
>  
>  
> 
> 

Reply via email to