Why we decided to call api analyze through reflection way.

[anantk24]

Ref :

  // TODO: property for to allow override of default implementation.
            Class<?> clazz =
                    Class.forName("com.microsoft.gctoolkit.vertx.jvm.DefaultJavaVirtualMachine", true, Thread.currentThread()
                            .getContextClassLoader());

If decide to have different implementation for JVM then moving analyze method signature defined in DefaultJavaVirtualMachine to interface, make sense?

If yes, we can remove this reflective call in GCToolkit

        JavaVirtualMachine javaVirtualMachine = loadJavaVirtualMachine();
        try {
            Method analyze = javaVirtualMachine.getClass()
                    .getMethod("analyze", Set.class, DataSource.class);
            analyze.invoke(javaVirtualMachine, this.registeredAggregations, dataSource);
        } catch (ReflectiveOperationException e) {
            LOGGER.log(Level.SEVERE, "Cannot invoke analyze method", e);
        }
        return javaVirtualMachine;```

[dsgrieve]

The short answer to your question is that it was an expedient for getting the source out. But I'm not sure how to get away without using reflection here. Perhaps injection, which is where your interface comes in. This is the impetus for issues #4, #5 and #6. Issue #73 also comes into play here.

[ghost]

As part of the new refactoring that I'm undertaking it's very likely that this reflective code will be replaced with an SPI where the JavaVirtualMachine class will be specialized by log/collector type. This should allows us to bring in simplifications with the use of polymorphism.