Jave reviewer feedback

Author: chalin

content/en/blog/2023/jmx-metric-insight/index.md

@@ -112,8 +112,9 @@ that our Kafka installation is working as expected.
 
 The metrics can be exported by any of the supported metric exporters, to a
 backend of your choice. For the full list of exporters and their configuration
-options, see [Configure the SDK](/docs/languages/java/configuration/). For
-instance, you can export the metrics to an OTel collector using the OTLP
+options, see
+[Configure the SDK](/docs/languages/java/configuration/#properties-exporters).
+For instance, you can export the metrics to an OTel collector using the OTLP
 exporter, perform some processing and then consume the metrics on a backend of
 your choice. In this example for the sake of simplicity, we are directly
 exporting the metrics to Prometheus.

content/en/blog/2024/java-metric-systems-compared/index.md

@@ -285,13 +285,13 @@ The result is a configurable option unique to OpenTelemetry Java called
 what their memory mode is based on whether they read metric state concurrently
 or not. Right now you opt into the optimized memory behavior (which we call
 `MemoryMode.reusable_data`) via an
-[environment variable](/docs/languages/java/configuration/). In the future, the
-optimized memory mode will be enabled by default, since only exceptional cases
-need concurrent access to the metric state. It turns out that the objects
-holding the metric state (`MetricData` in OpenTelemetry Java terms) account for
-virtually all of the memory allocation in the collect cycle. By reusing these
-(along with other internal objects used to hold state), **we reduced the memory
-allocation of the core metric SDK by over 99%**. See
+[environment variable](/docs/languages/java/configuration/#properties-exporters).
+In the future, the optimized memory mode will be enabled by default, since only
+exceptional cases need concurrent access to the metric state. It turns out that
+the objects holding the metric state (`MetricData` in OpenTelemetry Java terms)
+account for virtually all of the memory allocation in the collect cycle. By
+reusing these (along with other internal objects used to hold state), **we
+reduced the memory allocation of the core metric SDK by over 99%**. See
 [this blog post](https://medium.com/@asafmesika/optimizing-java-observability-opentelemetrys-new-memory-mode-reduces-memory-allocations-by-99-98-e0062eccdc3f)
 for more details.
 

content/en/docs/languages/java/getting-started.md

@@ -261,7 +261,7 @@ For more:
 [annotations]: /docs/zero-code/java/agent/annotations/
 [configure the java agent]: /docs/zero-code/java/agent/configuration/
 [console exporter]: /docs/languages/java/configuration/
-[exporter]: /docs/languages/java/configuration/
+[exporter]: /docs/languages/java/configuration/#properties-exporters
 [java-vers]:
   https://github.com/open-telemetry/opentelemetry-java/blob/main/VERSIONING.md#language-version-compatibility
 [manual instrumentation]: ../instrumentation