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

[Daniel Fuchs]

Hi Dmitry,

On 14/01/16 13:31, Dmitry Samersoff wrote:
> Daniel,
>
>> What strategy did you use to decide whether
>> to use OPTIONAL | REQUIRED?
>> I'm not sure I understand the logic...
>
> Everything in java.lang.management should be REQUIRED, anything outside
> of it - OPTIONAL.
>
> java_lang_management_MemoryUsage_klass should be required, it's just a
> typeo.

OK. What of the sun.* implementation classes in java.management?
Should these be REQUIRED as well?

best regards,

-- daniel


>
> -Dmitry
>
> On 2016-01-14 14:48, Daniel Fuchs wrote:
>> Hi Dmitry,
>>
>> First an observation:
>>
>> - java.lang.management and sun.management packages are part of
>>    the java.management module.
>>
>> - com.sun.management and com.sun.management.internal are part
>>    of jdk.management
>>
>> What strategy did you use to decide whether to use OPTIONAL | REQUIRED?
>> I'm not sure I understand the logic...
>
> Everything in java.lang.management should be required, anything outside
> of it - optional.
>
>>
>> For instance:
>>
>>    80   Klass* k =
>> Management::com_sun_management_internal_GarbageCollectorExtImpl_klass(Management::OPTIONAL,
>> CHECK_NH);
>>
>>    => class from jdk.management: OPTIONAL looks like the right choice.
>>
>>   103   Klass* mu_klass =
>> Management::java_lang_management_MemoryUsage_klass(Management::OPTIONAL,
>> CHECK_NH);
>>
>>    => class from java.management: should it be REQUIRED?
>>       Or is it optional for some other reason (e.g. the feature/method
>>       depends on jdk.management being present)?
>>       Or is it optional to make room for the case when java.management is
>>       not there?
>>
>> Is there some other underlying logic here?
>>
>> best regards,
>>
>> -- daniel
>>
>> On 13/01/16 19:45, 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.
>>>
>>> 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
>>>
>>
>
>