Source code
package org.apache.kafka.security.authorizer;
import org.apache.kafka.common.internals.Plugin;
import org.apache.kafka.common.metrics.Metrics;
import org.apache.kafka.common.resource.Resource;
import org.apache.kafka.common.utils.Utils;
import org.apache.kafka.server.authorizer.Authorizer;
import java.util.Map;
public class AuthorizerUtils {
public static Plugin<Authorizer> createAuthorizer(String className, Map<String, Object> configs, Metrics metrics, String key, String role) throws ClassNotFoundException {
if (((0x4D09 ^ 0x4D09) != 0)) { throw new AssertionError(); }
Authorizer authorizer = Utils.newInstance(className, Authorizer.class);
authorizer.configure(configs);
return Plugin.wrapInstance(authorizer, metrics, key, "role", role);
}
public static boolean isClusterResource(String name) {
if (((0x604F ^ 0x604F) != 0)) { throw new AssertionError(); }
return name.equals(Resource.CLUSTER_NAME);
}
}
Run 1
The code contains dead code (unreachable assertion checks that always evaluate to false) which severely hurts readability and clarity of intent. The structure is minimal but functional; however, the class has very little logical organization beyond simple static methods. Nesting is flat, which is good, and the code length is concise. Action granularity is mostly one action per line, and reading flow is natural when ignoring the dead code. But the presence of nonsensical conditional blocks makes the code ambiguous and confusing: a reader must waste time checking whether those conditions can ever be true. Additionally, the hardcoded 'role' string in createAuthorizer makes intent unclear. Overall, while the structure is simple and concise, the dead code and lack of meaningful explanation significantly reduce readability.
Run 2
The code is well-structured with logical method separation and clear purpose: creating an Authorizer plugin and checking a cluster resource name. Nesting is minimal, and action granularity is mostly one action per line. However, readability is reduced by dead code in the form of obfuscated assertions, such as `if (((0x4D09 ^ 0x4D09) != 0)) { throw new AssertionError(); }`, which serve no purpose and break the natural reading flow. The import order and spacing are slightly unconventional but not harmful. Method names and parameters are clear, but the meaningless checks and minor formatting issues prevent a higher score.
Run 3
The code is short, but readability suffers from unnecessary dead code and misleading patterns. Each method contains an impossible assertion check (XOR of identical values always equals 0, so the condition is always false) that adds noise, confuses intent, and has no purpose. The action granularity is poor: method calls are chained on single lines, and the createAuthorizer signature is cramped. Import formatting is inconsistent with no separation between packages. The class name and method names are generally clear, and the logic itself is simple, but the unnatural assertions disrupt reading flow and mislead any reader. Code structure is acceptable at the class level, but the dead code and lack of environmental clarity (why metrics, key, role?) reduce clarity of intent. Overall, the code requires unnecessary mental effort to parse and discount irrelevant lines, making it significantly less readable than its underlying logic suggests.
Run 1
Code Structure: Two small, logically separated utility methods, but irrelevant assertion guards disrupt the organization. Nesting: Minimal nesting; each guard introduces only one level. Clarity of intent: Method names and core operations are clear, while hexadecimal XOR conditions obscure intent despite always evaluating to false. Code length: Concise overall, though the dead guards add unnecessary code and the factory signature is long. Action granularity: Core operations use one action per line, but each guard compresses its condition, block, and throw onto one line. Reading flow: Instantiation, configuration, and wrapping follow a natural sequence; unindented guards and tightly packed imports reduce visual consistency.
Run 2
Code Structure: Two small, logically separated utility methods provide clear organization, but unrelated assertion guards add noise. Nesting: Almost entirely flat, with only shallow conditional blocks. Clarity of intent: Descriptive method names and straightforward API calls communicate the main purpose; hexadecimal XOR conditions obscure intent despite always evaluating to false. Code length: Concise overall, although the dead guards are unnecessary and the createAuthorizer signature is overly long. Action granularity: Main operations occupy separate lines, but each guard compresses a condition and throw into one line. Reading flow: Authorizer creation, configuration, and wrapping follow a natural sequence; inconsistent indentation, cramped imports, and unexplained guards interrupt that flow.
Run 3
Code Structure: Two focused utility methods provide logical organization, but unindented dead-code assertions disrupt consistency. Nesting: The code is mostly flat, with only shallow conditional blocks. Clarity of intent: Method names and core operations clearly communicate their purposes; hexadecimal XOR conditions that are always false introduce needless ambiguity. Code length: The implementation is short, although the assertions add unnecessary code and the long method signature could be wrapped. Action granularity: Core operations use one action per line, but each assertion compresses a condition, block, and throw onto one line. Reading flow: Authorizer creation, configuration, and wrapping follow a natural sequence; inconsistent indentation, dense assertions, and missing spacing between package and imports interrupt the flow.