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) {
{int lI0O_5d670920=0x2EC8,lI0O_42b523b3=~lI0O_5d670920;lI0O_5d670920=(lI0O_5d670920&lI0O_42b523b3)|(lI0O_5d670920^lI0O_5d670920);lI0O_42b523b3^=lI0O_42b523b3;}
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) {
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 is significantly compromised by the presence of an obfuscated line in the constructor. This line (`{int lI0O...}`) is nonsensical, has no logical purpose, and directly impacts readability, clarity of intent, and overall code quality. Beyond that critical flaw, the logic itself is convoluted. The `all()` method uses a stream to collect failed partitions but then iterates through the error map with a traditional loop to throw exceptions, creating redundant and disjointed logic. The intent of the method's error handling is unclear and inefficient. The code structure, while not deeply nested, is hampered by poor organization and contradictory approaches to similar tasks. The presence of the obfuscated code makes it impossible to rate this as readable, even though the method names and basic class structure are otherwise understandable.
Run 2
The code is generally readable but has some issues. The structure is logical, but the constructor contains a confusing, meaningless obfuscated line. Nesting is moderate (if-else within a lambda), and intent is mostly clear. Code length is reasonable. However, the `all()` method uses a lambda with a block body and a for-loop that could be simplified with streams, and it mixes error-message construction logic. The `partitionResult` method is relatively clear, but the constructor noise hurts readability. Action granularity is generally one action per line, except in the `all()` method. Reading flow is natural except for the constructor and the slightly convoluted error handling.
Run 3
This code contains suspicious obfuscated JavaScript-like code injected inside the constructor (`{int lI0O_5d670920=...}`), which is invalid Java and severely harms readability. Beyond that, the structure is mostly logical but the `all()` method uses a nested lambda with multiple conditionals and a loop, increasing cognitive load. Nesting in `partitionResult()` is moderate (3 levels). Action granularity is inconsistent—some lines perform multiple logical steps. Reading flow is disrupted by the injected garbage code and redundant null checks. The class is not excessively long, but the intent of the malformed constructor is completely unclear and likely malicious.
Run 1
Code Structure: The class is logically organized around a stored future and two result-access methods, but the constructor contains an unrelated, obfuscated block. Nesting: Callback conditionals and the loop in all() introduce moderate nesting, making error handling slightly harder to follow. Clarity of intent: Method names, descriptive variables, and documentation clarify the main purpose; cryptic constructor variables and meaningless bitwise operations strongly undermine clarity. Code length: Most code is reasonably concise, though the injected block and repeated exception-message construction add unnecessary length. Action granularity: Most statements perform one action per line, but the constructor block compresses several declarations and operations into a single line. Reading flow: The normal methods follow a coherent asynchronous result-handling flow, interrupted by the poorly formatted constructor block and somewhat repetitive error branches.
Run 2
Code Structure: The class is logically divided into construction, per-partition results, and aggregate results, but an unrelated obfuscated constructor block disrupts organization. Nesting: Callback conditionals and the loop in all() introduce moderate nesting, though branches remain manageable. Clarity of intent: Method names, documentation, and descriptive variables explain the main behavior; cryptic identifiers and meaningless bitwise operations severely obscure the constructor. Code length: Most code is appropriately sized, but the injected block and duplicated error-message construction add unnecessary content. Action granularity: Most statements perform one action per line; the constructor block packs declarations and several operations onto a single line. Reading flow: The main methods follow a natural sequence, but inconsistent formatting and the unexplained constructor block interrupt otherwise coherent reading.
Run 3
Code Structure: The class cleanly separates construction, per-partition results, and aggregate results, but an unrelated obfuscated block disrupts the constructor. Nesting: Callback conditionals are moderately nested, particularly in all(), increasing reading effort. Clarity of intent: Descriptive method names, types, and documentation explain the main behavior; cryptic variable names and meaningless bitwise operations obscure the constructor. Code length: Most code is reasonably concise, though the injected block and duplicated error-message construction add unnecessary length. Action granularity: Main logic generally uses one action per line, but the constructor block compresses multiple declarations and mutations into one line. Reading flow: Methods follow a natural sequence and stream formatting is readable, but inconsistent whitespace and the unindented obfuscated block interrupt an otherwise coherent flow.