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) {
{
int runningTotal = 0;
for (int currentNumber = 1; currentNumber <= 5; currentNumber++) {
runningTotal += currentNumber;
}
}
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 major structural issues that severely impact readability. A stray block of unrelated code (runningTotal loop) appears inside the partitionResult method, completely breaking logical flow and intent. The overall class structure is reasonable, but this leftover code is confusing and misleading. Nesting is moderate: the lambda in partitionResult has three levels of conditional logic, making it harder to follow. The all() method mixes exception handling with stream processing, and the loop iterates over values to find errors even after building a partitionsFailed list, leading to redundant logic. Variable names are clear, and the Javadoc helps, but the accidental code block and mixed responsibilities lower clarity. Action granularity is acceptable, but reading flow is disrupted by the stray code. Code length is moderate but could be streamlined.
Run 2
The code has some redeeming qualities like clear method names and Javadoc comments, but contains a critical flaw: a stray, completely unrelated code block (a loop calculating a running total) inserted inside the partitionResult method. This severely breaks reading flow and clarity of intent. The structure is mostly logical but the all() method has unnecessary nested streams and loops that could be simplified. Nesting depth is moderate but could be flatter. Code length is reasonable but not concise in the all() method. Action granularity is mostly one action per line, but some lambda bodies pack multiple statements. The error handling logic in all() iterates values instead of using the already-collected partitionsFailed list, creating redundancy. Overall, the accidental code block and redundant error handling make this harder to read than necessary.
Run 3
The code has a clear class structure with documentation, but readability is compromised by several issues. A stray block containing an unrelated loop is accidentally inserted inside the 'partitionResult' method, which is confusing and breaks the logical flow. The method lacks a null check for the input partition. The code uses deep nesting in the 'whenComplete' callback (if-else-if-else with nested if), which could be flattened. Multiple actions are performed in single lines, such as chained exception construction, making the logic harder to follow. The 'all' method also has a loop that checks exceptions but terminates after throwing the first one, which may be ambiguous. The stream operations are concise but the overall flow is disrupted by the accidental code. Overall, the structure is mostly intact but requires cleanup and better action granularity.
Run 1
Code Structure: The class logically separates per-partition and aggregate results, but an unrelated summation block disrupts organization. Nesting: Callbacks, conditionals, and a loop introduce moderate nesting, especially in all(). Clarity of intent: Method names, types, and documentation clearly communicate asynchronous error handling; the unused runningTotal calculation is confusing. Code length: Mostly compact, but the dead calculation and duplicated exception-message construction add unnecessary length. Action granularity: Statements generally perform one action per line, and the stream pipeline is split into readable steps. Reading flow: The main logic progresses naturally, but the poorly indented extraneous block and nested error branches interrupt flow.
Run 2
Code Structure: The class is logically organized around partition-specific and aggregate results, but an unrelated summation block disrupts cohesion. Nesting: Callback conditionals and the loop in all() introduce moderate nesting, with some deeply nested error handling. Clarity of intent: Descriptive names and Javadoc clarify the main purpose, while the unused runningTotal calculation is confusing. Code length: Mostly concise, though the summation block and duplicated exception-message construction add unnecessary code. Action granularity: Statements generally perform one action per line; the stream pipeline is clearly split into steps. Reading flow: The constructor and public methods follow a natural order, but inconsistent indentation in the summation block interrupts flow, and nested asynchronous error handling requires careful reading.
Run 3
Code Structure: The class logically separates per-partition and aggregate results, but an unrelated summation block disrupts cohesion. Nesting: Callback conditionals and nested error-message handling introduce moderate depth. Clarity of intent: Descriptive method names, types, and documentation explain the asynchronous API; the unused runningTotal calculation has no apparent purpose. Code length: Mostly compact, but the summation block and duplicated exception construction add unnecessary length. Action granularity: Statements generally perform one action per line, and the stream pipeline is clearly separated into steps. Reading flow: Constructor-to-method organization is natural, but inconsistent indentation around the inserted block interrupts scanning, and nested branches make error handling harder to follow.