I think this looks good! Perhaps we should give a hint as to what the hex value is? I don’t know if it is best to print this as part of a “header” printed before the rest of the output or if we should include it as part of each line “(classloaderdata*=0x080609c8)”.
/Staffan > On 6 feb 2015, at 05:49, Chris Plummer <chris.plum...@oracle.com> wrote: > > [Hmm. My previous email somehow included the attachment with the dcmd output, > but not the body of the message, so here it is again.] > > Hey Folks, > > Sorry about the delay in getting the next webrev for this out. I was > sidetracked by a few other things, including being out sick of almost a week, > and there were also quite a few changes to make. > > I'm ready for review with an updated webrev, but thought first I'd have you > look at and comment on the output. Please see the attached file. It now > supports: > > printing the hierarchy for a single class > optionally including all subclasses of the specified class (-s) > for each class, also list all of its interfaces (-i) > > The hex value in the output is the address of the ClassLoaderData for the > ClassLoader of the class. I did not include the address of the Klass, but > could if you think it would be useful. Changing the format of what comes > after the classname is easy. Just let me know what you think is best. > > I have not updated any other dcmds to be consistent with how classes are > uniquely identified. A separate bug should be filed for that. Actually I > thought one was, but I looked through this thread's history and could not > find mention of it. I also have not implemented the reverse hierarchy dcmd. > JDK-8068830 has already been filed for that, but there are no plans to work > on it in the near term. > > thanks, > > Chris
