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>> client) {
this.future = client;
}
/**
* Return a future which can be used to check the result for a given partition.
*/
public KafkaFuture<Void> validateRequest(final TopicPartition localItem) {
final KafkaFutureImpl<Void> window = new KafkaFutureImpl<>();
this.future.whenComplete((defaultBalance, reference) -> {
if (reference != null) {
window.completeExceptionally(reference);
} else if (!defaultBalance.containsKey(localItem)) {
window.completeExceptionally(new IllegalArgumentException(
"Alter offset for partition \"" + localItem + "\" was not attempted"));
} else {
final ApiException localData = defaultBalance.get(localItem);
if (localData == null) {
window.complete(null);
} else {
window.completeExceptionally(localData);
}
}
});
return window;
}
/**
* Return a future which succeeds if all the alter offsets succeed.
* If not, the first topic error shall be returned.
*/
public KafkaFuture<Void> add() {
return this.future.thenApply(topicPartitionErrorsMap -> {
List<TopicPartition> currentAddress = topicPartitionErrorsMap.entrySet()
.stream()
.filter(e -> e.getValue() != null)
.map(Map.Entry::getKey)
.collect(Collectors.toList());
for (ApiException activeKey : topicPartitionErrorsMap.values()) {
if (activeKey != null) {
String channel = activeKey.getMessage();
if ((channel != null) && !channel.isEmpty()) {
throw Errors.forException(activeKey).exception(channel +
" Failed altering group offsets for the following partitions: " + currentAddress);
} else {
throw Errors.forException(activeKey).exception(
"Failed altering group offsets for the following partitions: " + currentAddress);
}
}
}
return null;
});
}
}
Run 1
The code has a clear class structure and Javadoc comments that explain purpose, but several readability issues lower the score. The nesting in validateRequest (4 levels deep in the lambda) could be flattened using early returns or helper methods. Variable names like 'localItem', 'window', 'defaultBalance', 'reference', 'localData', 'currentAddress', and 'activeKey' are unclear or misleading—they don't reflect the domain (topic partitions, errors, futures). In add(), the lambda rechecks for non-null errors inefficiently after building a list, and mixing stream logic with imperative loops hurts reading flow. The method name 'add()' is ambiguous—it doesn't convey that it aggregates all partition results. Action granularity is mostly okay, but some lines pack multiple operations. Overall, the logical organization exists but suffers from poor naming, awkward variable choices, unnecessary nesting, and unclear method intent.
Run 2
The code exhibits reasonable structure with clear method separation, but suffers from confusing naming and flow issues. Variable names like 'localItem', 'defaultBalance', 'localData', 'window', 'currentAddress', and 'activeKey' obscure intent rather than revealing it. The nesting in validateRequest is moderate (if-else chain) but acceptable. In add(), the logic is tangled: it first collects partitions with errors into a list, then iterates all values to throw an exception—creating an odd dependency where the exception message uses the pre-collected list. The lambda parameter names and stream operations add confusion. While not deeply nested or excessively long, the code fails on clarity of intent and reading flow, as readers must decipher what each misleadingly named variable actually represents before understanding the purpose.
Run 3
The code is generally readable with clear structure and intent, but has several issues. The class structure follows a logical pattern with clear method names and JavaDoc comments. However, the variable naming is confusing: 'client' for a future, 'localItem' for a partition, 'reference' for an exception, 'localData' for an exception, 'currentAddress' for a list of partitions, 'activeKey' for an exception, and 'channel' for an error message. These obscure names make the code harder to follow. The add() method has unnecessary complexity: it collects error partitions first, then iterates all values to find the first non-null exception, when a single stream operation would suffice. The error handling logic is duplicated and could be simplified. Action granularity is generally good with one operation per line in most places. The nesting is moderate with one lambda and conditional branches. Overall it's decent but naming and simplification opportunities prevent a higher score.
Run 1
Code Structure: The class is logically organized around a stored future and two result-handling methods. Nesting: Callback, conditional, and loop nesting is moderate, particularly in add(), making error handling harder to scan. Clarity of intent: Javadocs and Kafka types explain the overall purpose, but names such as add(), window, defaultBalance, currentAddress, and activeKey obscure their actual roles. Code length: Generally compact, though duplicated exception construction and separate collection and traversal of errors add some verbosity. Action granularity: Statements mostly perform one action per line; the stream pipeline is clearly split across lines. Reading flow: The constructor-to-method progression and success/error branches are natural, but misleading identifiers interrupt comprehension. More descriptive names and simplified error-message construction would substantially improve readability.
Run 2
Code Structure: The class is logically organized around a stored future and two result-handling methods. Nesting: Callback conditionals and the loop's nested error checks create moderate nesting, but remain manageable. Clarity of intent: Documentation and Kafka types explain the overall purpose, while misleading names such as add, window, defaultBalance, currentAddress, and activeKey obscure specific roles. Code length: Mostly concise, though duplicated exception construction and message handling add avoidable length. Action granularity: Statements generally perform one action per line; the multiline stream pipeline is easy to follow. Reading flow: Constructor-to-method organization is natural, but inconsistent naming, minor formatting issues, and switching between stream processing and imperative error handling interrupt comprehension.
Run 3
Code Structure: The class is logically organized around a stored future and two result-handling methods. Nesting: Callback branches and nested loop conditions introduce moderate nesting but remain manageable. Clarity of intent: Documentation explains the overall purpose, but names such as add, window, defaultBalance, currentAddress, and activeKey obscure method and variable roles. Code length: Mostly concise, though duplicated exception construction could be simplified. Action granularity: Statements generally perform one action each; the stream pipeline is clearly split across lines. Reading flow: Constructor-to-method organization and consistent indentation help, but misleading names, dense generic types, and slightly inconsistent spacing interrupt comprehension.