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