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

[Daniel Fuchs]

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

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
>