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

[Daniel Fuchs]

Hi Mandy,

On 08/08/2017 18:03, mandy chung wrote:
> Throwing UOE would be clearer than throwing UndeclaredThrowableException 
> and ReflectionException.

That's what will happen if someone had a custom implementation
of ThreadMXBean which is compiled against JDK 9 but runs in JDK 10,
and therefore does not have the new methods. Then it inherits
the default body that throes UOE.

With the default body then the implementation can still be compiled
against jdk 10, without having to add the new method.

> However MBean proxy simply forwards the call to the remote MBeanServer 
> and calls invoke or getAttribute/setAttribute. NoSuchMethodException 
> will be thrown in the remote VM and the client would get 
> UndeclaredThrowableException or ReflectionException.

You will get UndeclaredThrowableException if the remote VM is a JDK 9
VM and the client is JDK 10 VM and that's OK.

> I don't see how 
> the client will invoke the default method unless the JMX 
> MBeanInvocationHandler catches the exception and have special handling 
> to the default methods.

That's not what we're trying to address here.

> For the case of missing method in the remote VM but the client has the 
> default method, I got UndeclaredThrowableException.  Is that what you see?

That's what I would expect. I did some testing to verify that if an
interface I had a default method m and an MBean M implemented I,
providing an implementation of m, then the result you get by calling
JMX.newMXBeanProxy(connection, name, I.class).m() is actually what
is returned by M.m(), not what is returned by I.m().

This means that you can evolve MBean interfaces by adding methods
to them as long as you provide a default body (which is rather cool :-))

best regards,

-- daniel

> 
> Mandy
> 
> 
> On 8/8/17 2:22 AM, 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
>>>
>>
>>
>