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
