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>> a) {
this.future = a;
}
/**
* Return a future which can be used to check the result for a given partition.
*/
public KafkaFuture<Void> a(final TopicPartition b) {
final KafkaFutureImpl<Void> c = new KafkaFutureImpl<>();
this.future.whenComplete((d, f) -> {
if (f != null) {
c.completeExceptionally(f);
} else if (!d.containsKey(b)) {
c.completeExceptionally(new IllegalArgumentException(
"Alter offset for partition \"" + b + "\" was not attempted"));
} else {
final ApiException g = d.get(b);
if (g == null) {
c.complete(null);
} else {
c.completeExceptionally(g);
}
}
});
return c;
}
/**
* Return a future which succeeds if all the alter offsets succeed.
* If not, the first topic error shall be returned.
*/
public KafkaFuture<Void> b() {
return this.future.thenApply(topicPartitionErrorsMap -> {
List<TopicPartition> h = topicPartitionErrorsMap.entrySet()
.stream()
.filter(e -> e.getValue() != null)
.map(Map.Entry::getKey)
.collect(Collectors.toList());
for (ApiException i : topicPartitionErrorsMap.values()) {
if (i != null) {
String j = i.getMessage();
if ((j != null) && !j.isEmpty()) {
throw Errors.forException(i).exception(j +
" Failed altering group offsets for the following partitions: " + h);
} else {
throw Errors.forException(i).exception(
"Failed altering group offsets for the following partitions: " + h);
}
}
}
return null;
});
}
}
Run 1
The code has a clear overall structure and documented purpose, but readability is significantly reduced by poor naming (parameters like `a`, `b`, `d`, `f`, `g`, `c`, `h`, `i`, `j`), which obscures intent. The action granularity is mostly reasonable, with one operation per line, but method names `a()` and `b()` are meaningless. The nesting is moderate but acceptable. The first method is straightforward, while the second method's stream filtering and error handling logic could be clearer. The use of opaque variable names throughout forces the reader to constantly refer back to types and context to understand what's happening.
Run 2
The code is functionally complete but suffers from poor readability due to obfuscated naming (single-letter variables like a, b, d, f, g, h, i, j) that obscures intent. The structure is logical at a high level, but the nested lambda blocks and conditional chains make the flow harder to follow. Action granularity is inconsistent—some lines pack multiple operations, while others are spread out. The reading flow is disrupted by the need to mentally map meaningless variable names to their roles. The class-level Javadoc is helpful, but method names and parameters undermine clarity. Overall, the code would be significantly improved by descriptive naming, reduced nesting, and clearer separation of concerns.
Run 3
The code suffers from several readability issues. The most critical problem is the use of meaningless single-letter parameter and variable names (a, b, c, d, f, g, h, i, j) throughout the entire class, which obscures intent and makes the logic difficult to follow. The package name suggests production Kafka code, yet the naming conventions violate Java best practices. The structure is logically organized but the method names 'a()' and 'b()' provide zero clarity about their purpose. Nesting depth is moderate but acceptable. The lambda in method 'b()' combines stream operations with imperative loops in a way that could be streamlined. Action granularity is reasonable, with one main operation per line. The code length is appropriate for the functionality, but the obfuscated naming makes it appear more complex than necessary. Reading flow is poor because readers must constantly track what each single-letter variable represents.
Run 1
Code Structure: The class logically separates per-partition and aggregate results into two methods. Nesting: Callback conditionals and the loop in the aggregate method introduce moderate nesting, but remain manageable. Clarity of intent: Documentation, types, and exception messages explain the purpose, but single-letter method and variable names significantly obscure operations and require repeated reference to surrounding code. Code length: Reasonably compact, though duplicated exception-message construction adds avoidable verbosity. Action granularity: Most statements perform one action; the stream pipeline is clearly split across lines. Reading flow: Imports, state, constructor, and methods follow a conventional order, and asynchronous processing is coherent. However, cryptic identifiers interrupt an otherwise natural flow.
Run 2
Code Structure: The class logically separates per-partition results from aggregate results, with a clearly scoped future field. Nesting: Callback conditionals and the loop's nested checks introduce moderate depth but remain manageable. Clarity of intent: Class documentation and API types explain the purpose, but methods named a/b and variables such as c, g, h, and j substantially obscure meaning. Code length: Generally compact, though aggregate error construction duplicates message handling and could be simplified. Action granularity: Statements mostly perform one action per line; the stream pipeline is sensibly split across lines. Reading flow: Imports, field, constructor, and methods follow a natural order, and formatting is consistent overall. However, cryptic identifiers force readers to repeatedly trace values, interrupting otherwise straightforward control flow.
Run 3
Code Structure: The class is logically organized around a stored future and two result-access methods. Nesting: Moderate nesting in callbacks and error-handling branches adds some complexity, especially in the aggregate-result method. Clarity of intent: Class names, types, and Javadocs explain the overall purpose, but methods named a and b and variables such as c, g, h, and i obscure their roles. Code length: Mostly concise, though duplicated exception construction could be simplified. Action granularity: Statements generally perform one action per line; the stream pipeline is clearly separated into stages. Reading flow: The progression from constructor to partition-specific handling and aggregate handling is natural, but cryptic identifiers and nested branches require readers to repeatedly infer meaning.