Ryan Fitzpatrick

@jack-berg when I run the updated unit tests without the registry they fail for identity equivalence. Would this be expected with the current sdk? ``` OtelHelperSynchronousMetricTest > longUpDownCounter() FAILED java.lang.AssertionError:...

Thanks for driving the spec updates and these changes, which look great. Do you mind updating [the existing readmes](https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/jmx-metrics/docs/target-systems), maybe linking to the spec for the producer and general metrics...

> @rmfitzpatrick Are they auto generated? I'm guessing that's a NO? Updating them manually doesn't sound very fun, etc. Right, we don't have a metadata scheme/docs generator for the project...

I think you're looking for [the filter](https://docs.gradle.org/current/userguide/java_testing.html#test_filtering) `./gradlew integrationTest --tests JvmTargetSystemIntegrationTest`

Apologies for missing this until now. @Mrod1598 do you think you'd be able to rule out https://github.com/open-telemetry/opentelemetry-java-contrib/commit/7184f0003d0d8f804a4700b5934f2fb0769cca98 for this?

This appears to be introduced by https://github.com/open-telemetry/opentelemetry-java/pull/4020 where there used to be a silent getOrCreate-like behavior. The underlying callback is updated w/ the most recent value via the proxied observer...

@anuraaga given https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#instrument-type-conflict-detection I think this is a symptom of the jmx-metric gatherer's groovy script running pattern that builds the declared instruments with every interval being at odds with the...

They're the same instruments in all cases and would be cached by their descriptor. The spec suggests to me that our current approach isn't supported without caching on the gatherer's...

@dependabot rebase

I think the integration test failure is unrelated and should be resolved by https://github.com/signalfx/signalfx-agent/pull/2335