RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording [v7]

[Erik Gahlin]

On Wed, 3 Feb 2021 02:08:23 GMT, Yang Yi <github.com+5010047+kelthuzadx at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 225:
>> 
>>> 223:                 Collections.sort(types, new TypeComparator());
>>> 224:             }
>>> 225:             for (EventType type : types) {
>> 
>> This looks like a change of behavior, the metadata command no longer prints all the types, only event types.
>
> `FlightRecorder.getEventTypes()` only returns event types:
> $ jfr metadata | grep ^class
> class IntFlagChanged extends jdk.jfr.Event {
> class JVMInformation extends jdk.jfr.Event {
> class JavaErrorThrow extends jdk.jfr.Event {
> ...
> Should we use `jdk.jfr.internal.TypeLIbrary.getTypes()`? As you mentioned earlier, this would introduces the `jdk.jfr.internal` package, it returns all types:
> $ jfr metadata dummy.jfr | grep ^class
> class boolean {
> class byte {
> class char {
> class double {
> class float {
> class int {
> class long {
> class short {
> class Class {
> class String {
> class Thread {
> class CalleeMethod {
> class ClassLoader {
> class BooleanFlag extends java.lang.annotation.Annotation {
> class Category extends java.lang.annotation.Annotation {
> class ContentType extends java.lang.annotation.Annotation {
> class IntFlagChanged extends jdk.jfr.Event {
> class JVMInformation extends jdk.jfr.Event {
> class JavaErrorThrow extends jdk.jfr.Event {
> ...
> But as a drawback, we can not reuse existing category&event filter and related methods since they are only suitable for event types.

The comment about FlightRecorder.getEventTypes() was on the test. If possible, I think we should avoid depending on internal packages in tests, as it makes them more fragile. Product code can depend on internal packages.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1904