I have requested backport to 11u and pending for approval.

Mandy

On 10/25/18 10:16 AM, Sven Reimers wrote:
Hi Mandy,

will this be backported to 11?

Sven

On Thu, Oct 25, 2018 at 10:10 AM Mandy Chung <[email protected] <mailto:[email protected]>> wrote:

    Thanks for verifying the fix, Sven.

    Mandy

    On 10/25/18 10:09 AM, Sven Reimers wrote:
    Hi,

    jus tested the suggested fix against jdk12 head with NetBeans
    10VC1 and self sampling works as expected.

    Thanks for your hard work.

    Sven

    On Thu, Oct 25, 2018 at 8:52 AM Mandy Chung
    <[email protected] <mailto:[email protected]>> wrote:



        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/
        <http://cr.openjdk.java.net/%7Emchung/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




-- Sven Reimers

    * Senior Expert Software Architect
    * Java Champion
    * NetBeans Dream Team Member: http://dreamteam.netbeans.org
    * Community Leader  NetBeans: http://community.java.net/netbeans
                                  Desktop Java:
    http://community.java.net/javadesktop
    * JUG Leader JUG Bodensee: http://www.jug-bodensee.de
    * Duke's Choice Award Winner 2009

    * XING: https://www.xing.com/profile/Sven_Reimers8
    * LinkedIn: http://www.linkedin.com/in/svenreimers



--
Sven Reimers

* Senior Expert Software Architect
* Java Champion
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader  NetBeans: http://community.java.net/netbeans
                              Desktop Java: http://community.java.net/javadesktop
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
* Duke's Choice Award Winner 2009

* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers

Reply via email to