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>> fut) {
this.future = fut;
}
/**
* Return a future which can be used to check the result for a given partition.
*/
public KafkaFuture<Void> partition(final TopicPartition par) {
final KafkaFutureImpl<Void> res = new KafkaFutureImpl<>();
this.future.whenComplete((topic, thr) -> {
if (thr != null) {
res.completeExceptionally(thr);
} else if (!topic.containsKey(par)) {
res.completeExceptionally(new IllegalArgumentException(
"Alter offset for partition \"" + par + "\" was not attempted"));
} else {
final ApiException exc = topic.get(par);
if (exc == null) {
res.complete(null);
} else {
res.completeExceptionally(exc);
}
}
});
return res;
}
/**
* 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> partitions = topicPartitionErrorsMap.entrySet()
.stream()
.filter(e -> e.getValue() != null)
.map(Map.Entry::getKey)
.collect(Collectors.toList());
for (ApiException exc2 : topicPartitionErrorsMap.values()) {
if (exc2 != null) {
String mes = exc2.getMessage();
if ((mes != null) && !mes.isEmpty()) {
throw Errors.forException(exc2).exception(mes +
" Failed altering group offsets for the following partitions: " + partitions);
} else {
throw Errors.forException(exc2).exception(
"Failed altering group offsets for the following partitions: " + partitions);
}
}
}
return null;
});
}
}
Run 1
The code demonstrates clear intent with well-named methods (`partition`, `all`) and appropriate use of `KafkaFuture` for asynchronous operations. The structure is logical, separating per-partition and overall result handling. Nesting within `partition()` is moderate (3 levels) but controlled. However, `all()` contains redundant logic: it collects partitions, then iterates all values and throws only when a non-null error is found, making the `partitions` list unused until an error occurs. The message construction is slightly awkward with string concatenation. Action granularity is mostly one action per line; the lambda in `all()` could be simplified by filtering error entries directly. Overall the code is readable but could be improved by streamlining the error traversal and message building.
Run 2
The code is generally readable but has some issues. Structure is logical with clear separation between constructor and methods, though the class is simple. Nesting depth is moderate (3 levels in both methods), which is acceptable but could be improved. Intent is mostly clear from method names and documentation, but the use of generic parameter names like 'par', 'thr', 'exc2', and 'mes' reduces clarity. Code length is reasonable for the functionality. Action granularity is good in most places, but the lambda in all() combines multiple operations that could be extracted. Reading flow is natural overall, though the all() method's logic of collecting partitions before checking errors is slightly awkward. The variable naming inconsistency (sometimes 'par', sometimes 'partition'; 'fut' vs 'future') could confuse maintainers. Error handling logic is duplicated between the two methods.
Run 3
The code is generally well-structured with clear intent, appropriate use of Javadoc, and reasonable nesting. However, the 'all()' method contains a redundant stream operation to collect partitions before iterating values again, which slightly hurts readability and efficiency. Variable naming could be more descriptive (e.g., 'topic' instead of 'topicPartitionErrorsMap'). The logic in 'all()' has two separate iterations that could be combined, and error message construction could be simplified. The 'partition()' method is clean with clear branching. Overall the code is readable but has minor inefficiencies and naming clarity issues.
Run 1
Code Structure: The class is logically organized around a stored future and two focused result-access methods. Nesting: Both methods have moderate nesting within callbacks; nested error handling adds some complexity. Clarity of intent: Javadocs and method names clearly describe partition-specific and aggregate results, but abbreviated names such as par, res, thr, exc2, and mes reduce clarity, and topic misleadingly names a map. Code length: Generally concise, though aggregate error-message construction duplicates text and could be simplified. Action granularity: Statements generally perform one action per line, and the stream pipeline separates its operations clearly. Reading flow: Constructor-to-method ordering is natural, and success/error paths are understandable. However, collecting failed partitions before separately scanning errors requires tracking two traversals, while minor formatting inconsistencies slightly interrupt the flow.
Run 2
Code Structure: The class is logically organized around a shared future and two focused result-access methods. Nesting: Both methods have moderately nested conditionals inside callbacks, especially all(), increasing reading effort. Clarity of intent: Method names, types, and documentation explain the purpose, but abbreviated names such as par, res, thr, exc2, and mes reduce clarity; topic misleadingly names a partition-error map. Code length: Generally concise, though repeated exception construction and message handling add avoidable length. Action granularity: Statements typically perform one action per line, and the stream pipeline separates its operations clearly. Reading flow: Constructor-to-method ordering and explicit success/error branches are natural, but switching from a stream to a loop and then nested message checks slightly interrupts the flow. Overall, readable and well-contained, with naming and conditional simplification opportunities.
Run 3
Code Structure: The class is logically organized around a shared future, with separate methods for partition-specific and aggregate results. Nesting: Moderate nesting in callbacks, especially the loop and conditional branches in all(), adds cognitive overhead. Clarity of intent: Javadocs and public method names clearly convey purpose, but abbreviated variables such as par, res, exc2, and mes, plus the misleading map name topic, reduce clarity. Code length: Generally concise, though aggregate error-message construction is duplicated and could be simplified. Action granularity: Statements generally perform one action per line; the stream pipeline is sensibly broken across lines. Reading flow: Constructor-to-method ordering and straightforward error handling support natural reading, but inconsistent naming and minor formatting issues interrupt the flow.