<div dir="auto">Hi Mandy,<div dir="auto"><br></div><div dir="auto">Thanks for the pointer. I have not yet investigated the usage, but will check if we can use the official API instead.</div><div dir="auto"><br></div><div dir="auto">Thanks again for the quick response.</div><div dir="auto"><br></div><div dir="auto">-Sven</div></div><br><div class="gmail_quote"><div dir="ltr">Mandy Chung <<a href="mailto:mandy.chung@oracle.com">mandy.chung@oracle.com</a>> schrieb am Mi., 17. Okt. 2018, 19:50:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <tt>Hi Sven,<br>
      <br>
      This NetBeans SamplesOutputStream calls
      sun.management.ThreadInfoCompositeData.toCompositeData<br>
      which is an internal API.  It will be inaccessible when<br>
      strong encapsulation is enabled.<br>
      <br>
      Have you looked into javax.management API to get the<br>
      CompositeData directly?<br>
      <br>
      Mandy<br>
    </tt><br>
    <div class="m_-3423247025102408496moz-cite-prefix">On 10/15/18 10:51 AM, Mandy Chung
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      Hi Sven,<br>
      <br>
      It's indeed a bug in the order of names and values when
      constructing CompositeData for StackTraceElement.  I created <a class="m_-3423247025102408496moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8212197" target="_blank" rel="noreferrer">https://bugs.openjdk.java.net/browse/JDK-8212197</a>
      for this issue.<br>
      <br>
      Mandy<br>
      <br>
      <div class="m_-3423247025102408496moz-cite-prefix">On 10/14/18 3:52 PM, David Holmes
        wrote:<br>
      </div>
      <blockquote type="cite">Hi
        Sven, <br>
        <br>
        Moving to serviceability-dev mailing list. Please don't reply to
        jdk-dev. <br>
        <br>
        Thanks, <br>
        David <br>
        <br>
        On 15/10/2018 5:42 AM, Sven Reimers wrote: <br>
        <blockquote type="cite">Hi all, <br>
          <br>
          I hope this is the correct e-mailing list. During out testing
          of Apache <br>
          NetBeans 10 we discovered a problem with self sampling
          capability of <br>
          NetBeans. Digging further into this problem (NETBEANS-1359 <br>
          <a class="m_-3423247025102408496moz-txt-link-rfc2396E" href="https://issues.apache.org/jira/browse/NETBEANS-1359" target="_blank" rel="noreferrer"><https://issues.apache.org/jira/browse/NETBEANS-1359></a>)
          I debugged through <br>
          the code and it seems that there is a problem with the order
          of the values <br>
          and the order of the attributes. <br>
          <br>
           From the code I see the order of the values is <br>
          <br>
                   final Object[] stackTraceElementItemValues = { <br>
                       ste.getClassLoaderName(), <br>
                       ste.getModuleName(), <br>
                       ste.getModuleVersion(), <br>
                       ste.getClassName(), <br>
                       ste.getMethodName(), <br>
                       ste.getFileName(), <br>
                       ste.getLineNumber(), <br>
                       ste.isNativeMethod(), <br>
                   }; <br>
          <br>
          compared to  the order of the attributes <br>
          <br>
          <br>
               private static final String[] V5_ATTRIBUTES = { <br>
                   CLASS_NAME, <br>
                   METHOD_NAME, <br>
                   FILE_NAME, <br>
                   LINE_NUMBER, <br>
                   NATIVE_METHOD, <br>
               }; <br>
          <br>
               private static final String[] V9_ATTRIBUTES = { <br>
                   CLASS_LOADER_NAME, <br>
                   MODULE_NAME, <br>
                   MODULE_VERSION, <br>
               }; <br>
          <br>
               private static final String[]
          STACK_TRACE_ELEMENT_ATTRIBUTES = <br>
                   Stream.of(V5_ATTRIBUTES,
          V9_ATTRIBUTES).flatMap(Arrays::stream) <br>
                         .toArray(String[]::new); <br>
          <br>
          which can be expanded to <br>
          <br>
                   CLASS_NAME, <br>
                   METHOD_NAME, <br>
                   FILE_NAME, <br>
                   LINE_NUMBER, <br>
                   NATIVE_METHOD, <br>
                   CLASS_LOADER_NAME, <br>
                   MODULE_NAME, <br>
                   MODULE_VERSION, <br>
          <br>
          With the difference in ordering you will get an exception  in
          <br>
          CompositeDataSupport, if you try to convert things (lines
          228ff) <br>
          <br>
                   // Check each value, if not null, is of the open type
          defined for <br>
          the <br>
                   // corresponding item <br>
                   for (String name : namesFromType) { <br>
                       Object value = items.get(name); <br>
                       if (value != null) { <br>
                           OpenType<?> itemType =
          compositeType.getType(name); <br>
                           if (!itemType.isValue(value)) { <br>
                               throw new OpenDataException( <br>
                                       "Argument value of wrong type for
          item " + name <br>
          + <br>
                                       ": value " + value + ", type " +
          itemType); <br>
                           } <br>
                       } <br>
                   } <br>
          <br>
          which is hard to compensate from the caller side. <br>
          <br>
          I think the change, which introduced this was <br>
          <br>
          <a class="m_-3423247025102408496moz-txt-link-freetext" href="https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470" target="_blank" rel="noreferrer">https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470</a>
          <br>
          <br>
          The proposed patch seems simple, just change the ordering of
          the attributes <br>
          <br>
             private static final String[]
          STACK_TRACE_ELEMENT_ATTRIBUTES = <br>
                   Stream.of(V9_ATTRIBUTES,
          V5_ATTRIBUTES).flatMap(Arrays::stream) <br>
                         .toArray(String[]::new); <br>
          <br>
          or change the value ordering to fit the attributes order. <br>
          <br>
          Can anyone confirm the analysis? <br>
          <br>
          Thanks <br>
          <br>
          -Sven <br>
          <br>
        </blockquote>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </div>

</blockquote></div>