On 10/25/18 2:52 AM, Daniel Fuchs wrote:
Hi Mandy,

I agree that this looks more robust and will be better for
long term maintainability. I'm just surprised that

 156     static CompositeType compositeType() {
 157         return STACK_TRACE_ELEMENT_COMPOSITE_TYPE;
 158     }

is no longer (or was never) needed in StackTraceElementCompositeData
when

 146     static CompositeType v5CompositeType() {
 147         return V5_COMPOSITE_TYPE;
 148     }

appears to still be needed.


It's used by MonitorInfoCompositeInfo and ThreadInfoCompositeInfo to build their CompositeType of older version.  For the current version, it gets it from MappedMXBeanType.toOpenType and hence no need for compositeType().

Otherwise, this looks good to me.

Thanks for the review.

Mandy


best regards,

-- daniel

On 24/10/2018 23:53, Mandy Chung wrote:
This patch fixes the regression introduced by JDK-8198253 in 11.
It turns out that NetBeans uses the internal sun.management API to
convert ThreadInfo to CompositeData for performance reason.
ThreadInfoCompositeData::toCompositeData is no longer used
in JDK since JMX added the MXBean support in JDK 6. The fix for
JDK-8212197 resolves one issue reported [1] but not the bug in
ThreadInfoCompositeData::toCompositeData. Sven has filed an
issue in NetBeans to replace the use of JDK internal API.

Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/

Thanks
Mandy
[1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html
[2] https://issues.apache.org/jira/browse/NETBEANS-1478


Reply via email to