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 > > > >
