RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

[Ujwal Vangapally]

Thanks for the review Daniel.

I also verified Daniel's suggestion, it works fine and it helps in 
better backward compatibility.

if it is ok to have a default body in ThreadMXBean interface I will send 
a new webrev incorporating that change.

-Ujwal


On 8/8/2017 2:52 PM, Daniel Fuchs wrote:
> Hi Ujwal,
>
> I have made a small experiments and it seems that having
> a default body doesn't prevent an interface method from
> being called from either a JMX or a Platform proxy.
>
> So in the light of this I'll suggest to add a default body
> that throw UnsupportedOperationException to the new methods
> added to the ThreadMXBean interface, and add an @implSpec
> to specify that if not implemented, the method will throw
> an UnsupportedOperationException.
>
> This should guarantee better backward compatibility in case
> someone has implemented the ThreadMXBean interface.
>
> Mandy, would you agree?
>
> best regards
>
> -- daniel
>
> On 08/08/2017 09:27, Ujwal Vangapally wrote:
>> Hi,
>>
>> below is the link to new webrev incorporating review comments.
>>
>> webrev: 
>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.02/
>>
>> verified that
>>
>> MBeanServerConnection.invoke throws ReflectionException when invoked 
>> with a method that doesn't exist in remote MBean server.
>>
>> UndeclaredThrowableException will be throwed when a client gets proxy 
>> of remote MBean server and calls a method that doesn't exist on 
>> remote Mbean server.
>>
>> do we need to develop Automated tests for verifying above cases ?
>>
>> Thanks,
>> Ujwal
>>
>>
>>
>> On 8/4/2017 5:42 AM, Mandy Chung wrote:
>>>> On Aug 3, 2017, at 2:10 PM, Daniel Fuchs <daniel.fuchs at oracle.com> 
>>>> wrote:
>>>>
>>>> Hi Mandy,
>>>>
>>>> On 03/08/17 21:04, Mandy Chung wrote:
>>>>>> 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?
>>>> I believe that will be a ReflectionException:
>>>> http://download.java.net/java/jdk9/docs/api/javax/management/MBeanServerConnection.html#invoke-javax.management.ObjectName-java.lang.String-java.lang.Object:A-java.lang.String:A- 
>>>>
>>>>
>>>>> 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.
>>>> AFAIK that should be handled by the proxy code - I'd expect that you
>>>> will get an UndeclaredThrowableException wrapping the 
>>>> ReflectionException.
>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/65464a307408/src/java.management/share/classes/javax/management/MBeanServerInvocationHandler.java#l308 
>>>>
>>> Thanks. That’s what I think but need assurance. We should add tests 
>>> to verify.
>>>
>>> Mandy
>>
>
>