The @java.beans.ConstructorProperties annotation on j.l.m.LockInfo causes an undesirable dependency on java.beans at compile time and runtime.
As java.beans is tightly coupled with the client API (awt, swing, java2d, etc), anyone using java.lang.management (management module) would cause all the awt, swing, java2d, and other desktop classes that are grouped in the same module to be present due to this java.beans dependency. LockInfo is annotated with @ConstructorProperties so that a JMX client can access ThreadMXBean and LockInfo statically rather than via JMX open type and CompositeData. javax.management.MXBean also provides an alternative way for a model-specific type to define a static from(CompositeData) method. This fix is to take out @java.beans.ConstructorProperties from the LockInfo constructor and add a new static LockInfo.from(CompositeData) method. With that, LockInfo instance can be reconstructed in any JMX client running on JDK 6 or later release while j.l.management no longer depends on java.beans. Also the from static method is present in j.l.m.MemoryUsage, MonitorInfo, and ThreadInfo classes and so this change brings consistency. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193302/webrev.00/ An existing ThreadMXBeanProxy test verifies the conversion when the target VM is running on the same version. I manually verify when a test running on jdk7 connects to a VM running on jdk8 with this fix and LockInfo conversion is working properly. Mandy
