Remove usages of that

content/en/docs/languages/java/configuration.md

@@ -101,10 +101,10 @@ and Spring starter users. {{% /alert %}}
 {{% alert color="info" %}} The autoconfigure module registers Java shutdown
 hooks to shut down the SDK when appropriate. Because OpenTelemetry Java
 [uses `java.util.logging` for internal logging](/docs/languages/java/sdk/#internal-logging),
-some of that logging might be suppressed during shutdown hooks. This is a bug in
+some of some logging might be suppressed during shutdown hooks. This is a bug in
 the JDK itself, and not something under the control of OpenTelemetry Java. If
 you require logging during shutdown hooks, consider using `System.out` rather
-than a logging framework that might shut itself down in a shutdown hook, thus
+than a logging framework which might shut itself down in a shutdown hook, thus
 suppressing your log messages. See
 this[JDK bug](https://bugs.openjdk.java.net/browse/JDK-8161253) for more
 details. {{% /alert %}}
@@ -146,7 +146,7 @@ Properties for configuring [resource](/docs/languages/java/sdk/#resource):
 | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- |
 | `otel.service.name`                        | Specify logical service name. Takes precedence over `service.name` defined with `otel.resource.attributes`.                             | `unknown_service:java` |
 | `otel.resource.attributes`                 | Specify resource attributes in the following format: `key1=val1,key2=val2,key3=val3`.                                                   |                        |
-| `otel.experimental.resource.disabled-keys` | Specify resource attribute keys that are filtered. This option is experimental and subject to change or removal.                        |                        |
+| `otel.experimental.resource.disabled-keys` | Specify resource attribute keys to filter. This option is experimental and subject to change or removal.                                |                        |
 | `otel.java.enabled.resource.providers`     | Comma-separated list of `ResourceProvider` fully qualified class names to enable. **[1]** If unset, all resource providers are enabled. |                        |
 | `otel.java.disabled.resource.providers`    | Comma-separated list of `ResourceProvider` fully qualified class names to disable. **[1]**                                              |                        |
 
@@ -323,9 +323,9 @@ generic versions. For example, if you set both `otel.exporter.otlp.endpoint` and
 
 **[1]**: OpenTelemetry Java agent 2.x uses `http/protobuf` by default.
 
-**[2]**: [OTLP](/docs/specs/otlp/#otlpgrpc-response) requires that
-[transient](/docs/specs/otel/protocol/exporter/#retry) errors be handled with a
-retry strategy. When retry is enabled, retryable gRPC status codes are retried
+**[2]**: [OTLP](/docs/specs/otlp/#otlpgrpc-response) requires
+[transient](/docs/specs/otel/protocol/exporter/#retry) errors to be handled with
+a retry strategy. When retry is enabled, retryable gRPC status codes are retried
 using an exponential backoff with jitter algorithm. The specific options of
 `RetryPolicy` can only be customized via
 [programmatic customization](#programmatic-customization).

content/en/docs/languages/java/sdk.md

@@ -879,13 +879,12 @@ attribute keys to retain, etc.
 
 **NOTE:** Views have somewhat unintuitive behavior when multiple match a
 particular instrument. If one matching view changes the metric name and another
-changes the metric aggregation, you might expect the result to be that the name
-and aggregation is changed, but this is not the case. Instead, two metric
-streams are produced: one with the configured metric name and the default
-aggregation, and another with the original metric name and the configured
-aggregation. In other words, matching views _do not merge_. For best results,
-configure views with narrow selection criteria (i.e. select a single specific
-instrument).
+changes the metric aggregation, you might expect the name and aggregation to be
+changed, but this is not the case. Instead, two metric streams are produced: one
+with the configured metric name and the default aggregation, and another with
+the original metric name and the configured aggregation. In other words,
+matching views _do not merge_. For best results, configure views with narrow
+selection criteria (i.e. select a single specific instrument).
 
 The following code snippet demonstrates `View` programmatic configuration:
 
@@ -1293,7 +1292,7 @@ you have not installed a custom root handler for your application, logs of level
 You may want to change the behavior of the logger for OpenTelemetry. For
 example, you can reduce the logging level to output additional information when
 debugging, increase the level for a particular class to ignore errors coming
-from that class, or install a custom handler or filter to run custom code
+from the class, or install a custom handler or filter to run custom code
 whenever OpenTelemetry logs a particular message. No detailed list of logger
 names and log information is maintained. However, all OpenTelemetry API, SDK,
 contrib and instrumentation components share the same `io.opentelemetry.*`
@@ -1326,7 +1325,7 @@ For more fine-grained control and special case handling, custom handlers and
 filters can be specified with code.
 
 ```java
-// Custom filter which does not log errors that come from the export
+// Custom filter which does not log errors which come from the export
 public class IgnoreExportErrorsFilter implements java.util.logging.Filter {
 
  public boolean isLoggable(LogRecord record) {
@@ -1352,7 +1351,7 @@ The exporters for all signals are available via
 `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}`.
 
 Internally, these exporters depend on various client libraries to execute HTTP
-and gRPC requests. There is no single HTTP / gRPC client library that satisfies
+and gRPC requests. There is no single HTTP / gRPC client library which satisfies
 all use cases in the Java ecosystem:
 
 - Java 11+ brings the built-in `java.net.http.HttpClient`, but