Probable bug within sun.management.StackTraceElementCompositeData

[Sven Reimers]

Hi Mandy,

I think the main problem here is that there is no simple was to do

CompositeData data = ThreadInfo.toCompositeData(threadInfo)

using an  official API (there is only ThreadInfo.from(CompositeData..).

Do you think it may be a good idea to add such a method? We are using this
approach due to performance reasons (details can be found on the
original NetBeans
issue
<https://issues.apache.org/jira/browse/NETBEANS-1359?focusedCommentId=16657857&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16657857>
).

Thanks

Sven

On Wed, Oct 17, 2018 at 11:48 AM Sven Reimers <sven.reimers at gmail.com>
wrote:

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

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181020/4198f8ac/attachment.html>