Source code
package org.apache.kafka.common.security.oauthbearer;
import org.apache.kafka.common.annotation.InterfaceAudience;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ClientAssertionRequestFormatter;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ClientSecretRequestFormatter;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ConfigurationUtils;
import org.apache.kafka.common.utils.Utils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.io.IOException;
import java.net.URL;
import java.util.List;
import java.util.Locale;
import java.util.Map;
import javax.security.auth.login.AppConfigurationEntry;
import static org.apache.kafka.common.config.SaslConfigs.SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL;
/**
* {@code DefaultJwtRetriever} instantiates and delegates {@link JwtRetriever} API calls to an embedded implementation
* based on configuration:
*
* <ul>
* <li>
* If the value of <code>sasl.oauthbearer.token.endpoint.url</code> is set to a value that starts with the
* <code>file</code> protocol (e.g. <code>file:/tmp/path/to/a/static-jwt.json</code>), an instance of
* {@link FileJwtRetriever} will be used as the underlying {@link JwtRetriever}. Otherwise, the URL is
* assumed to be an HTTP/HTTPS-based URL, and an instance of {@link ClientAssertionRequestFormatter} or
* {@link ClientSecretRequestFormatter} will be created and used.
* </li>
* </ul>
*
* The configuration required by the individual {@code JwtRetriever} classes will likely differ. Please refer to the
* official Apache Kafka documentation for more information on these, and related configuration.
*/
@InterfaceAudience.Public
public class DefaultJwtRetriever implements JwtRetriever {
private static final Logger LOG = LoggerFactory.getLogger(DefaultJwtRetriever.class);
private JwtRetriever delegate;
@Override
public void a(Map<String, ?> a, String b, List<AppConfigurationEntry> c) {
ConfigurationUtils d = new ConfigurationUtils(a, b);
URL e = d.validateUrl(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL);
if (e.getProtocol().toLowerCase(Locale.ROOT).equals("file"))
delegate = new FileJwtRetriever();
else
delegate = new ClientCredentialsJwtRetriever();
LOG.debug("Created instance of {} as delegate", delegate.getClass().getName());
delegate.configure(a, b, c);
}
@Override
public String b() throws JwtRetrieverException {
if (delegate == null)
throw new IllegalStateException("JWT retriever delegate is null; please call configure() first");
return delegate.retrieve();
}
@Override
public void c() throws IOException {
Utils.closeQuietly(delegate, "JWT retriever delegate");
}
JwtRetriever d() {
return delegate;
}
}
Run 1
The code is largely unreadable due to severely obfuscated naming. Method names 'a', 'b', 'c', 'd' and parameter names like 'a', 'b', 'c', 'd', 'e' completely hide the intent of the code (clarity of intent score near zero). The structure is fairly flat and logically organized, but readability is destroyed by these meaningless names. The code is concise, but brevity comes at the cost of understandability. Naming violations in a public API (overriding methods like 'configure', 'retrieve', 'close') make it impossible for a reader to know what actions are performed without deep investigation, violating action granularity and natural reading flow. Although imports and class-level Javadoc are intact, the method bodies read as opaque, arbitrary letters rather than actions like 'configure retrievers' or 'retrieve token'. This would be highly error-prone for maintainers.
Run 2
The code is poorly readable due to several factors. The package and imports are normal, and the Javadoc is solid, but method names like a(), b(), c(), and d() are meaningless and obscure intent. Variable names like a, b, c, d, and e are also not descriptive. The class structure is acceptable and nesting is low, but the action granularity is mixed (multiple operations per line in some cases). The delegation logic is split across methods, making the flow harder to follow. 'ClientCredentialsJwtRetriever' is referenced but not imported, suggesting incomplete code. Overall, the code lacks clarity and naming discipline.
Run 3
The code has a clear class-level Javadoc and logical field placement, but the method and variable names (a, b, c, d, e) are extremely poor and obscure intent. The single-letter names make the code unreadable despite otherwise manageable nesting and structure. The if-else in configure() is flat and each delegate creation is on its own line, which is good, but the ambiguous parameter names negate readability. The class has too many responsibilities: it is supposed to delegate based on configuration but also instantiates different retrievers inline, which violates separation of concerns. Retrieval and close methods are short, but the null check in retrieve() is clear. Overall, the code's logic structure is acceptable, but the naming and intent clarity are severely lacking.
Run 1
Code Structure: The class is logically organized around configuring, retrieving from, and closing a delegate. Nesting: Control flow is shallow, with simple conditionals and an early guard. Clarity of intent: The class name, documentation, and delegate calls explain the overall purpose, but methods named a, b, c, and d and single-letter parameters and local variables significantly obscure intent. Documentation and error messages reference configure(), while the visible configuration method is named a, adding confusion. Code length: The implementation is concise, although the documentation is comparatively verbose. Action granularity: Each statement generally performs one action, making individual steps easy to follow. Reading flow: Methods follow a natural lifecycle order, but cryptic naming, missing separation around imports, and omitted conditional braces reduce readability.
Run 2
Code Structure: The class is logically organized into configuration, retrieval, cleanup, and delegate access methods. Nesting: Control flow is shallow, with simple conditionals and an early exception. Clarity of intent: Class names, delegate calls, and documentation explain the overall purpose, but methods a/b/c/d and single-letter parameters and locals obscure individual responsibilities. The configure() reference in the error message conflicts with the visible method name a(), and documentation describes request formatters rather than the actual HTTP retriever instantiated. Code length: Implementation is concise, although the documentation is relatively verbose. Action granularity: Statements generally perform one action per line. Reading flow: Configuration followed by retrieval and cleanup is natural, but cryptic naming, tightly packed imports, and omitted conditional braces reduce readability.
Run 3
Code Structure: The class is logically organized around delegate initialization, retrieval, cleanup, and access, with short, separated methods. Nesting: Simple conditionals and an early exception keep nesting minimal, although omitted braces slightly reduce visual clarity. Clarity of intent: Class names, delegation calls, and documentation explain the overall purpose, but method names a/b/c/d and single-letter parameters and locals obscure individual responsibilities. The configure() instruction in the exception conflicts with the visible initialization method name, and documentation mentions formatter classes rather than the actual HTTP delegate. Code length: The implementation is concise, though documentation is disproportionately long. Action granularity: Statements generally perform one action per line. Reading flow: Initialization followed by retrieval and cleanup is natural, but cryptic identifiers and tightly packed imports interrupt comprehension.