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.reim...@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.ch...@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
