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 con(Map<String, ?> con, String sasl, List<AppConfigurationEntry> jaas) {
ConfigurationUtils cu = new ConfigurationUtils(con, sasl);
URL token = cu.validateUrl(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL);
if (token.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(con, sasl, jaas);
}
@Override
public String ret() throws JwtRetrieverException {
if (delegate == null)
throw new IllegalStateException("JWT retriever delegate is null; please call configure() first");
return delegate.retrieve();
}
@Override
public void clo() throws IOException {
Utils.closeQuietly(delegate, "JWT retriever delegate");
}
JwtRetriever del() {
return delegate;
}
}
Run 1
The code has good logical organization with a clear delegation pattern, but suffers from poor method naming (con, ret, clo, del instead of configure, retrieve, close, delegate), which severely obscures intent. The structure is relatively flat with minimal nesting, and each line generally performs one action. However, the abbreviated method names break Java conventions and make the code harder to read and maintain. The Javadoc is helpful but the implementation would benefit from full, descriptive method names. Error handling is minimal but adequate. The code length is reasonable and not unnecessarily verbose, but the cryptic method names defeat the purpose of self-documenting code.
Run 2
The code has a clear class purpose, good imports, and a helpful Javadoc explaining the delegate selection logic. The configure/retrieve/close delegation pattern is straightforward, and the class maintains flat nesting with mostly one action per line. However, readability is undermined by heavily abbreviated method names (con, ret, clo, del) that deviate from the interface's semantic names (configure, retrieve, close, delegate). The else block for delegate selection could be more explicit about the ClientAssertionRequestFormatter vs ClientSecretRequestFormatter mentioned in the Javadoc. The Javadoc describes more nuanced behavior than the code implements. Variable names like 'cu' are unnecessarily shortened. Overall, the structure is sound and the flow is natural, but the abbreviations and slight mismatch between documentation and implementation reduce clarity.
Run 3
This code has serious readability problems. Method names are abbreviated to the point of ambiguity: `con`, `ret`, `clo`, and `del` obscure their purpose (`configure`, `retrieve`, `close`, `delegate` respectively). Parameter names like `con` and `sasl` are unclear. The JavaDoc is well-written but the actual implementation does not match its quality. The constructor-like `configure` method is named `con`, making it difficult to understand the lifecycle. The class-level delegation pattern is reasonably structured, but method implementations are opaque. The code is flat and concise, which helps, but every action compresses multiple concerns into single-line statements that are hard to parse. Variable naming is inconsistent (`cu`, `token`, `delegate`). The import list is long and unused imports may exist. Overall, this appears to be intentionally obfuscated or severely shortened code that violates Java naming conventions and makes the logic nearly unreadable despite the clear documentation.
Run 1
Code Structure: The class is logically organized around configuration, retrieval, cleanup, and delegate access. Nesting: Control flow is shallow and easy to follow, although omitted braces reduce visual clarity. Clarity of intent: Delegation and protocol-based selection are understandable, but abbreviated names such as con, ret, clo, del, and cu obscure purpose; method names also conflict with the configure/retrieve terminology used elsewhere. The documentation misleadingly describes request formatters as the underlying retrievers. Code length: The implementation is concise, though the documentation is disproportionately verbose. Action granularity: Statements generally perform one action per line, making operations easy to identify. Reading flow: Methods follow a natural lifecycle order, but tightly packed imports, cryptic identifiers, and documentation inconsistencies interrupt otherwise straightforward reading.
Run 2
Code Structure: Well-organized class with separate methods for initialization, retrieval, cleanup, and delegate access. Nesting: Very shallow, with simple conditionals and no nested branches. Clarity of intent: Delegation and protocol-based selection are straightforward, but abbreviated names such as con, ret, clo, del, cu, and sasl obscure meaning. Documentation references configure() and formatter implementations rather than consistently matching the displayed methods and instantiated classes. Code length: Implementation is concise; the introductory documentation is somewhat verbose relative to its simplicity. Action granularity: Statements generally perform one action per line, although URL normalization and comparison are chained. Reading flow: Methods follow a natural lifecycle order, but densely grouped imports, omitted conditional braces, and inconsistent naming reduce readability.
Run 3
Code Structure: The class is logically organized around configuring, retrieving from, and closing a delegate. Nesting: Shallow conditionals keep complexity low, though omitted braces slightly reduce scanability. Clarity of intent: Delegation and protocol-based selection are understandable, but abbreviated method names (con, ret, clo, del) and variables (cu, sasl, jaas) obscure meaning. Documentation references configure(), while the declared method is con(), and describes formatter classes rather than the actual HTTP delegate, creating confusion. Code length: The implementation is concise; the lengthy documentation is somewhat disproportionate and partially misleading. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: Configuration followed by retrieval, cleanup, and delegate access is natural, but tightly packed imports and inconsistent naming weaken readability.