Review Request JDK-8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData

[Mandy Chung]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181025/2f993db4/attachment.html>