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;
@InterfaceAudience.Public
public class AlterShareGroupOffsetsResult {
private final KafkaFuture<Map<TopicPartition, ApiException>> future;
AlterShareGroupOffsetsResult(KafkaFuture<Map<TopicPartition, ApiException>> future) {
this.future = future;
}
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;
}
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 is well-structured with clear separation of methods and proper use of imports. The class has a single responsibility and follows Kafka API conventions. The `partitionResult` method is well-organized with clear error handling and flat nesting. However, the `all` method has some readability issues: it creates a list of failed partitions in a streaming operation but then uses a traditional for-each loop to check exception values, creating inconsistency in style. The method also duplicates error message construction logic with slightly different message content depending on whether exception message is empty. The lambda in `all` could benefit from extracting the error creation logic into a helper method for better clarity. Overall, the code is reasonably readable with good naming conventions and clear intent, but has room for improvement in consistency and reducing complexity in the `all` method.
Run 2
The code is well-structured and generally readable. It has a clear class purpose, clean method separation, and minimal nesting. The `partitionResult` method is straightforward, with a single `whenComplete` callback containing only two levels of nesting. The `all()` method uses streams effectively, though the for-loop with duplicated exception logic adds slight noise. Variable names are descriptive, and each line performs a single logical action, preserving natural reading flow. Small improvements could include extracting duplicated message building logic and simplifying the `all()` method's error handling, but overall the code is easy to follow and maintain.
Run 3
The code is generally readable with clear class purpose and meaningful method names. The structure is logical, separating per-partition and aggregate result handling. Nesting is moderate, with one lambda containing an if-else chain that adds some depth. The intent is clear but could be improved: 'all()' returns a Void future and throws on failure rather than returning a result map, which is slightly unintuitive. Code length is reasonable but could be shorter in 'all()' by filtering null exceptions before iteration. Action granularity is mostly one action per line, though the stream chain in 'all()' performs multiple operations in a single expression. Reading flow is acceptable, but the duplicated exception message construction in 'all()' reduces clarity. Overall, the code is understandable to an experienced Kafka developer but has minor opportunities for simplification.
Run 1
Code Structure: The class is logically organized around a future, with separate methods for individual partition results and aggregate completion. Nesting: Both methods contain moderately nested error-handling branches, particularly all(), which slightly increases reading effort. Clarity of intent: Descriptive names and explicit exception handling make the purpose clear, although null-as-success semantics and the absence of method documentation require inference. Code length: Generally concise, but repeated exception construction and excessive blank lines add unnecessary bulk. Action granularity: Statements mostly perform one action each, and the stream pipeline presents its transformations on separate lines. Reading flow: Constructor-to-method organization and sequential completion checks are natural; inconsistent whitespace and the combination of stream collection with a separate error-scanning loop slightly interrupt the flow.
Run 2
Code Structure: The class is logically organized around a shared future, with separate methods for individual and aggregate results. Nesting: Moderate nesting in callbacks, especially the loop and conditionals in all(), increases reading effort. Clarity of intent: Descriptive names and explicit error handling communicate the purpose, though the null-as-success convention and selection of the first exception require inference. Code length: Mostly concise, but duplicated exception construction and excessive blank lines add unnecessary bulk. Action granularity: Statements generally perform one action per line; the stream pipeline is clearly separated into stages. Reading flow: Constructor-to-method ordering and sequential completion handling are natural, although nested branches and repeated error-message logic slightly interrupt the flow.
Run 3
Code Structure: The class is logically organized around a shared future and two focused result-access methods. Nesting: Moderate nesting in callbacks, especially the loop and conditional branches in all(), slightly increases reading effort. Clarity of intent: Descriptive names and explicit exception handling communicate the purpose well, though missing documentation leaves null-as-success semantics implicit. Code length: Generally concise, but duplicated error-message construction and excessive blank lines add avoidable bulk. Action granularity: Statements mostly perform one action per line; the stream pipeline is clearly separated into stages. Reading flow: Constructor-to-method progression and straightforward success/error branches are natural, while nested asynchronous handling and repeated message formatting modestly interrupt the flow.