RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module

[David Holmes]

On 14/01/2016 7:51 PM, Dmitry Samersoff wrote:
> David,
>
>> Is this because the management API's are actually split across
>> the base module (java.lang.management) and the jdk.management module?
>> If so that seem messy. If not then I'm not understanding the issue.
>
> Yes. Exactly.
>
> Moreover future management functionality may require additional modules.

If the management module is not present what would call the code in the 
VM? Shouldn't the base management code be detecting and responding to 
the absence of the actual module? It is very hard to see the overall 
architecture/structure here.

David

> -Dmitry
>
>
> On 2016-01-14 07:06, David Holmes wrote:
>> Hi Dmitry,
>>
>> On 14/01/2016 4:45 AM, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please, review the fix:
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/
>>>
>>> The problem:
>>>
>>>     Code in management.cpp throw NoClassDefFound exception if any of
>>> requested classes is missing.
>>>
>>>    But, in upcoming modular JDK classes that not belong to
>>> java.lang.management (sun.management, com.sun.management etc) might not
>>> be present.
>>
>> Is this because the management API's are actually split across the base
>> module (java.lang.management) and the jdk.management module? If so that
>> seem messy. If not then I'm not understanding the issue.
>>
>> I would have hoped that the management initialization function in the VM
>> could simply check for the management module being present and set a
>> flag that can be checked by all the management entry points. Something
>> that might even be better done at the Java level. ??
>>
>> Cheers,
>> David
>>
>>> Solution:
>>>
>>>    Refactor class resolving code to support two type of classes - REQUIRED
>>> (still throw NCDFE if the class is missing) and OPTIONAL (just return
>>> NULL).
>>>
>>>     I introduced a new parameter to highlight the fact that a class is an
>>> optional one on caller side rather than handle it silently inside
>>> management.cpp.
>>>
>>> -Dmitry
>>>
>
>