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 {
Authorizer authorizer = Utils.newInstance(className, Authorizer.class);
authorizer.configure(configs);
return Plugin.wrapInstance(authorizer, metrics, key, "role", role);
}
public static boolean isClusterResource(String name) {
return name.equals(Resource.CLUSTER_NAME);
}
}
Run 1
The code is highly readable and follows clean coding principles. It has a clear, logical structure with two concise methods that each serve a single purpose. Nesting is non-existent, and clarity of intent is strong: the method names clearly describe what each does. The code is concise without being overly compact, with one primary action per line. Reading flow is natural and straightforward. Minor improvements could include adding a private constructor to prevent instantiation of a utility class, which would slightly improve design, but this does not significantly affect readability.
Run 2
The code is concise and well-structured. It has a single responsibility per method, clear intent, and flat nesting. However, the createAuthorizer method has a long signature, and there is a minor inconsistency with the 'role' string literal, which slightly impacts clarity.
Run 3
The code demonstrates excellent readability. It has a clean structure with logical separation of methods, minimal nesting (no conditionals or loops), and clear intent for each function. The method names are descriptive, and each line performs a single action, maintaining good action granularity. The reading flow is natural and straightforward. Minor deductions: the unused imports (Resource is used but the import list could be more organized), and the createAuthorizer method could benefit from a brief comment explaining the 'role' parameter's purpose. Overall, the code is concise, well-organized, and easy to understand.
Run 1
Code Structure: A small utility class cleanly separates authorizer creation from resource identification. Nesting: Both methods are flat, with no branching or nested blocks. Clarity of intent: Descriptive method names and straightforward calls make the purpose clear, although generic parameters such as key and role provide limited context. Code length: The implementation is concise with no unnecessary logic; the long createAuthorizer signature would benefit from wrapping. Action granularity: Each statement performs one distinct action. Reading flow: Authorizer instantiation, configuration, and wrapping follow a natural sequence. Minimal spacing around the package and import sections slightly reduces visual organization.
Run 2
Code Structure: Two focused utility methods provide clear, logical organization. Nesting: Both methods are flat, with no nested control flow. Clarity of intent: Descriptive method names and straightforward operations make their purposes apparent, though the generic parameter name 'key' provides limited context. Code length: The implementation is concise with no unnecessary logic; the long createAuthorizer signature could be wrapped for easier scanning. Action granularity: Each statement performs one distinct action. Reading flow: Instantiation, configuration, and wrapping follow a natural sequence. Minor formatting improvements, such as separating the package declaration from imports and grouping imports consistently, would improve readability.
Run 3
Code Structure: Two focused utility methods provide clear, logical organization. Nesting: Both methods are flat, with no nested control flow. Clarity of intent: Descriptive method names and straightforward API calls make their purposes evident, though key and role are less informative without context. Code length: The implementation is concise with no unnecessary logic, but the long createAuthorizer signature could be wrapped for readability. Action granularity: Each statement performs one clear action. Reading flow: Instantiation, configuration, and wrapping follow a natural sequence; blank lines between the package declaration, imports, and import groups would improve visual organization.