dropwizard/metrics

Is reflective access completely gone?

jimshowalter opened this issue · 4 comments

jimshowalter commented

Does the latest version of metrics-core rely on reflective access?

We have a logging/metrics framework that wraps an old version of metrics-core that requires adding opens to get it to work with Java 9 or higher.

Because the JVM args that define opens aren't backward-compatible with Java 8, we have trouble upgrading existing services (our deployment configuration system didn't anticipate an exception to write-once/run-anywhere).

We can upgrade our logging/metrics framework to a newer metrics-core, but if the latest version still relies on reflective access, that won't help. So we'd like to know ahead of time if it's going to be a waste of time.

joschi commented 
metrics on release/4.2.x is 📦 4.2.3-SNAPSHOT
# git checkout v4.1.24
HEAD is now at 25c08486 [maven-release-plugin] prepare release v4.1.24

metrics on HEAD (25c0848) is 📦 4.1.24
# git grep java.lang.reflect
metrics-jcache/src/main/java/com/codahale/metrics/jcache/JCacheGaugeSet.java:import java.lang.reflect.Method;
metrics-jdbi/src/main/java/com/codahale/metrics/jdbi/strategies/NameStrategies.java:import java.lang.reflect.Method;
metrics-jdbi/src/main/java/com/codahale/metrics/jdbi/strategies/ShortNameStrategy.java:import java.lang.reflect.Method;
metrics-jdbi3/src/main/java/com/codahale/metrics/jdbi3/strategies/TimedAnnotationNameStrategy.java:import java.lang.reflect.Method;
metrics-jersey2/src/main/java/com/codahale/metrics/jersey2/InstrumentedResourceMethodApplicationListener.java:import java.lang.reflect.Method;

metrics on HEAD (25c0848) is 📦 4.1.24
# git checkout v4.2.1
Previous HEAD position was 25c08486 [maven-release-plugin] prepare release v4.1.24
HEAD is now at 5e79bdaa [maven-release-plugin] prepare release v4.2.1

metrics on HEAD (5e79bda) is 📦 4.2.1
# git grep java.lang.reflect
metrics-jcache/src/main/java/com/codahale/metrics/jcache/JCacheGaugeSet.java:import java.lang.reflect.Method;
metrics-jdbi/src/main/java/com/codahale/metrics/jdbi/strategies/NameStrategies.java:import java.lang.reflect.Method;
metrics-jdbi/src/main/java/com/codahale/metrics/jdbi/strategies/ShortNameStrategy.java:import java.lang.reflect.Method;
metrics-jdbi3/src/main/java/com/codahale/metrics/jdbi3/strategies/TimedAnnotationNameStrategy.java:import java.lang.reflect.Method;
metrics-jersey2/src/main/java/com/codahale/metrics/jersey2/InstrumentedResourceMethodApplicationListener.java:import java.lang.reflect.Method;
metrics-jersey3/src/main/java/com/codahale/metrics/jersey3/InstrumentedResourceMethodApplicationListener.java:import java.lang.reflect.Method;
jimshowalter commented

I should have been more specific: is forbidden reflective access still required?

In other words, is it still the case that using dropwizard with Java 9 or higher requires doing this?:

--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED

joschi commented

If the question is whether Dropwizard Metrics supports the Java Platform Module System (JPMS), then the answer is only with automatic modules (Automatic-Module-Name) but we don't define a full module descriptor (module-info.java).

github-actions commented

This issue is stale because it has been open 180 days with no activity. Remove the "stale" label or comment or this will be closed in 14 days.