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