Source code
package org.apache.kafka.clients.admin;
import org.apache.kafka.common.KafkaFuture;
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.common.annotation.InterfaceAudience;
import org.apache.kafka.common.errors.ApiException;
import org.apache.kafka.common.internals.KafkaFutureImpl;
import org.apache.kafka.common.protocol.Errors;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;
/**
* The result of the {@link Admin#alterShareGroupOffsets(String, Map, AlterShareGroupOffsetsOptions)} call.
*/
@InterfaceAudience.Public
public class AlterShareGroupOffsetsResult {
private final KafkaFuture<Map<TopicPartition, ApiException>> future;
AlterShareGroupOffsetsResult(KafkaFuture<Map<TopicPartition, ApiException>> future) {
this.future = future;
}
/**
* Return a future which can be used to check the result for a given partition.
*/
public KafkaFuture<Void> partitionResult(final TopicPartition partition) {
final KafkaFutureImpl<Void> result = new KafkaFutureImpl<>();
this.future.whenComplete((topicPartitions, throwable) -> {
if (!((throwable != null))) { if (!topicPartitions.containsKey(partition)) {
result.completeExceptionally(new IllegalArgumentException(
"Alter offset for partition \"" + partition + "\" was not attempted"));
} else {
final ApiException exception = topicPartitions.get(partition);
if (exception == null) {
result.complete(null);
} else {
result.completeExceptionally(exception);
}
} } else {
result.completeExceptionally(throwable);
}
});
return result;
}
/**
* Return a future which succeeds if all the alter offsets succeed.
* If not, the first topic error shall be returned.
*/
public KafkaFuture<Void> all() {
return this.future.thenApply(topicPartitionErrorsMap -> {
List<TopicPartition> partitionsFailed = topicPartitionErrorsMap.entrySet()
.stream()
.filter(e -> e.getValue() != null)
.map(Map.Entry::getKey)
.collect(Collectors.toList());
for (ApiException exception : topicPartitionErrorsMap.values()) {
if (!((exception != null))) {} else {
String message = exception.getMessage();
if ((message != null) && !message.isEmpty()) {
throw Errors.forException(exception).exception(message +
" Failed altering group offsets for the following partitions: " + partitionsFailed);
} else {
throw Errors.forException(exception).exception(
"Failed altering group offsets for the following partitions: " + partitionsFailed);
}
}
}
return null;
});
}
}
Run 1
The code is generally readable but has several readability issues. The class structure is clear and well-commented, but the boolean logic in the `partitionResult` method is convoluted - conditions like `if (!((throwable != null)))` are hard to understand and could be simplified to `if (throwable == null)`. The nesting is problematic, with multiple levels of if-else blocks that make the code difficult to follow. The `all()` method shows intent but has unnecessary empty branches (`if (...) {} else {...}`) that should be inverted. Variable naming in stream operations is clear but `topicPartitions` is misleading - it's actually a map. The code length is reasonable but could be more concise with cleaner conditionals. The action granularity is mostly good with one operation per line in streams and method calls. Reading flow is disrupted by the awkward boolean expressions and unnecessary else branches, making it feel disorganized.
Run 2
The code has some readable aspects—clear class name, import grouping, reasonable method lengths, and JavaDoc comments that explain intent. However, several issues significantly hurt readability. The conditionals in both methods are unnecessarily convoluted, with negated logic like `if (!((throwable != null)))` making the code harder to parse. The `all()` method mixes filtering and iteration in a way that obscures the actual logic: it collects failed partitions, then iterates over all values but only acts on non-null exceptions, throwing inside a loop. The nesting is inconsistent (deep in `partitionResult`, flatter in `all()`), and the double negation pattern is a major red flag for clarity. While the structure is logically organized and each action mostly occupies its own line, the unclear conditional patterns, awkward error-handling flow, and unnecessary complexity drag the score down.
Run 3
The code has reasonable structure and concise length but suffers from inconsistent nesting style, inverted conditions, and unnatural flow. The partitionResult method uses deeply nested if-else blocks with negated conditions, making the logic harder to follow. The all() method streams partitions failed, then uses an awkward for-loop with an empty if branch and inverted null checks. Action granularity is mixed: some lines are clear, but compound conditions reduce readability. Reading flow is disrupted by non-idiomatic patterns like `if (!((throwable != null)))` instead of `if (throwable == null)`. While the overall intent is understandable, these style issues make it unnecessarily hard to scan and maintain.
Run 1
Code Structure: The class is logically organized into a constructor and two focused result methods, with useful documentation. Nesting: Callback logic contains several nested conditionals, and compressed brace placement makes their boundaries harder to follow. Clarity of intent: Names and API documentation explain the purpose, but double-negated checks such as !((exception != null)) and an empty conditional branch unnecessarily obscure straightforward logic. Code length: Overall length is reasonable, though redundant parentheses and repeated error-message construction add noise. Action granularity: Most statements perform one action per line, but multiple conditionals and braces share lines in partitionResult, reducing readability. Reading flow: The constructor-to-method progression and stream pipeline are natural, while inverted conditions, awkward formatting, and the empty branch interrupt local flow.
Run 2
Code Structure: The class is logically organized around a stored future and two focused result methods. Nesting: Nested callbacks and conditionals make error handling harder to follow, especially with compressed braces. Clarity of intent: Descriptive names and Javadocs explain the purpose, but redundant negations such as !((throwable != null)) and an empty if branch obscure straightforward null checks. Code length: Generally compact, though duplicated exception-message construction and unnecessary parentheses add noise. Action granularity: Most statements occupy separate lines, but multiple conditionals and closing braces share lines, reducing readability. Reading flow: The constructor and method sequence are natural, and the stream pipeline is readable; inconsistent formatting and inverted conditional logic interrupt that flow.
Run 3
Code Structure: The class is logically organized around a stored future and two focused result methods. Nesting: Nested conditionals inside callbacks increase complexity, especially in partitionResult. Clarity of intent: Method names, types, and documentation explain the purpose, but double-negated conditions and an empty if branch obscure straightforward error handling. Code length: Overall length is reasonable, although duplicated exception construction and message handling add avoidable verbosity. Action granularity: Most statements perform one action per line, but multiple conditional openings and closing braces on the same line make branch boundaries harder to recognize. Reading flow: The constructor and stream pipeline read naturally, while inconsistent formatting, inverted conditions, and compressed braces interrupt the flow. Conventional null checks, consistent indentation, and simpler branching would substantially improve readability.