Review Request: JDK-8173608: Separate JDK management agent from java.management module

[Mandy Chung]

> On Jan 31, 2017, at 12:20 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello Mandy,
> 
> In Lib-jdk.management.agent.gmk:
> 
> OPENJDK_TARGET_OS and OPENJDK_TARGET_OS_TYPE are both "windows" on Windows platforms, so no need to treat Windows differently when defining the src dirs.
> 

Good to know.  Thanks. 

> The -DPSAPI_VERSION=1 seems to be copied from Lib-jdk.management.gmk and/or Lib-jdk.attach.gmk, but was not applied to the library from which the native src for this new lib was copied from. I just wonder if this is actually needed for this new library?

I was also wondering it and now track it down.  jdk.management.agent doesn’t use PS api.  I will take it out.

> 
> Please remove the "LANG := C" parameter, it no longer has a meaning but it keeps reappearing due to copy pasting of old make code.
> 
> Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out?
> 

Good catch.  I updated Lib-jdk.management.agent.gmk with:

    LIBS := $(JDKLIB_LIBS), \
    LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib, \

We should examine the native code in both java.management and jdk.management and I suspect the makefile would need cleanup.  Are you okay to follow up the makefile as a separate issue?  As the native code in jdk.management.agent, it can be converted to use NIO 2 and hope to get to it in a near future so that jdk.management.agent will have java code only.
 
Mandy

> /Erik
> 
> 
> On 2017-01-31 00:48, Mandy Chung wrote:
>> Webrev at:
>>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html
>> 
>> Mandy
>> 
>>> On Jan 30, 2017, at 3:42 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> 
>>> java.management is the module for JMX and JMX remote API and
>>> java.lang.management. JDK management agent provides the JDK-specific
>>> out-of-the-box monitoring and management support and it’s cleaner
>>> for it to live in its own module.  It is proposed to move it
>>> to a new module named `jdk.management.agent`.
>>> 
>>> This change involves:
>>> 1) renaming of sun.management.Agent along with 3 other classes
>>> in sun.management package to jdk.internal.agent package
>>> 
>>> 2) move sun.management.resources to jdk.internal.agent.resources
>>> 
>>> 3) move sun.management.jmxremote and sun.management.jdp packages
>>> to jdk.management.agent module
>>> 
>>> 4) move the configuration files under conf/management
>>> 
>>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated
>>> to replace the use of the ClassLogger API with System.Logger.
>>> 
>>> 6) change hotspot VM to add `jdk.management.agent` when
>>> -Dcom.sun.management.* system property is set as well as
>>> the Agent class rename
>>> 
>>> Daniel is working on JDK-8173607 [1] that conflicts with this
>>> patch and require merges/coordination.
>>> 
>>> We propose to integrate these changes to jdk9/dev unless
>>> there is any objection concerning that this trivial hotspot change
>>> might cause any issue.  I have submitted a RBT on hotspot_runtime
>>> and hotspot_serviceability in addition to PIT test runs.
>>> 
>>> thanks
>>> Mandy
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607
>