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

Dmitry Samersoff dmitry.samersoff at oracle.com
Thu Jan 14 12:31:31 UTC 2016


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.

-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
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


More information about the serviceability-dev mailing list