On 14/01/2016 7:51 PM, Dmitry Samersoff wrote:
David,
Is this because the management API's are actually split across
the base module (java.lang.management) and the jdk.management module?
If so that seem messy. If not then I'm not understanding the issue.
Yes. Exactly.
Moreover future management functionality may require additional modules.
If the management module is not present what would call the code in the
VM? Shouldn't the base management code be detecting and responding to
the absence of the actual module? It is very hard to see the overall
architecture/structure here.
David
-Dmitry
On 2016-01-14 07:06, David Holmes wrote:
Hi Dmitry,
On 14/01/2016 4:45 AM, 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.
Is this because the management API's are actually split across the base
module (java.lang.management) and the jdk.management module? If so that
seem messy. If not then I'm not understanding the issue.
I would have hoped that the management initialization function in the VM
could simply check for the management module being present and set a
flag that can be checked by all the management entry points. Something
that might even be better done at the Java level. ??
Cheers,
David
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
