<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    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="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8212197">https://bugs.openjdk.java.net/browse/JDK-8212197</a> for this issue.<br>
    <br>
    Mandy<br>
    <br>
    <div class="moz-cite-prefix">On 10/14/18 3:52 PM, David Holmes
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:e9c41c18-53d6-7b55-df7b-06c0517b0c59@oracle.com">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="moz-txt-link-rfc2396E" href="https://issues.apache.org/jira/browse/NETBEANS-1359"><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="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470">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>
  </body>
</html>