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) {
result.completeExceptionally(throwable);
} else 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);
}
}
});
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) {
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 has some readability issues. The class structure is simple with two methods, but the implementation is tightly packed, with multiple statements on single lines and braces placed on the same line in some places, hurting readability. The lambda in `all()` is deeply nested with chained streams and conditionals, making it harder to follow. There is some redundancy in error message construction. The intent of the code (a Kafka admin result wrapper) is mostly clear from the Javadoc, but the formatting and dense code reduce clarity. Action granularity is inconsistent—some lines contain multiple actions, while others are split over many lines. The overall reading flow is unnatural due to inconsistent indentation, line breaks, and brace placement.
Run 2
The code suffers from poor readability due to multiple issues. The imports are all crammed on single lines at the top, making it difficult to scan dependencies. The main structural problem is the heavy compaction - closing braces and method declarations share lines, eliminating visual separation between methods. This makes the class structure extremely hard to parse mentally. The `all()` method contains deeply nested streams, conditionals, and string concatenation logic all compressed into a single lambda expression, creating multiple levels of nesting with no natural reading flow. The `partitionResult()` method also has a deeply nested conditional chain with multiple `if-else` branches that would benefit from early returns. Action granularity is violated - multiple operations occur on single physical lines. The code appears to have been automatically minified or aggressively compacted, destroying the logical organization that would make the intent clear. While variable names are descriptive, the formatting choices make even simple logic difficult to follow.
Run 3
The code has significant readability issues. The imports are jammed onto single lines, and methods/fields are compressed with multiple statements per line, violating action granularity. The lambda body contains deep nesting and conditional blocks collapsed inline, making the control flow hard to follow. The `partitionResult` method mixes exception handling and business logic in a cramped multi-branch structure. While the class purpose is documented, the actual code obscures intent through poor formatting, excessive inline braces, and tangled stream operations in `all()`. The `all()` method also has inconsistent indentation and unclear error-message construction. Overall, the structure is disorganized, with multiple logical steps sharing lines, poor visual separation, and unnatural reading flow that forces the reader to mentally reformat the code.
Run 1
Code Structure: The class logically separates per-partition results from aggregate results, but compressed formatting obscures method boundaries. Nesting: Callback conditionals and the loop in all() create moderate nesting that is harder to follow because braces and statements share lines. Clarity of intent: Descriptive class and method names, types, and Javadocs explain the purpose; asynchronous error handling requires closer inspection. Code length: The implementation is reasonably compact, although repeated exception construction adds verbosity. Action granularity: Multiple imports, declarations, conditionals, and actions appear on single lines, substantially reducing readability. Reading flow: Inconsistent indentation, inline Javadocs after closing braces, and crowded stream operations interrupt otherwise logical execution flow.
Run 2
Code Structure: The class is logically organized around a shared future and two result methods, but compressed formatting obscures boundaries. Nesting: Callbacks, conditionals, and a loop introduce moderate nesting, made harder to track by inconsistent brace placement. Clarity of intent: Descriptive names, documentation, and explicit error messages make the purpose reasonably clear. Code length: Overall length is appropriate, though duplicated exception construction adds avoidable verbosity. Action granularity: Multiple imports, assignments, conditionals, and returns share lines, reducing scanability. Reading flow: Inline method bodies, comments attached to closing braces, and irregular stream-chain formatting repeatedly interrupt otherwise logical control flow.
Run 3
Code Structure: The class has a logical organization, with a shared future and separate methods for partition-level and aggregate results. Nesting: Callback conditionals and a loop with nested error checks add moderate complexity. Clarity of intent: Descriptive method names, types, Javadoc, and error messages make the purpose understandable. Code length: Reasonably short, though aggregate error-message construction repeats logic. Action granularity: Multiple imports, statements, and control-flow operations share lines, making individual actions difficult to scan. Reading flow: Inconsistent whitespace, compressed stream operations, and comments attached to closing braces disrupt natural reading. The underlying design is understandable, but poor formatting substantially reduces readability.