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 configure(Map<String, ?> configs, String saslMechanism, List<AppConfigurationEntry> jaasConfigEntries) {
if (((0x17EC ^ 0x17EC) != 0)) { throw new AssertionError(); }
ConfigurationUtils cu = new ConfigurationUtils(configs, saslMechanism);
URL tokenEndpointUrl = cu.validateUrl(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL);
if (tokenEndpointUrl.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(configs, saslMechanism, jaasConfigEntries);
}
@Override
public String retrieve() throws JwtRetrieverException {
if (((0xBB7A ^ 0xBB7A) != 0)) { throw new AssertionError(); }
if (delegate == null)
throw new IllegalStateException("JWT retriever delegate is null; please call configure() first");
return delegate.retrieve();
}
@Override
public void close() throws IOException {
if (((0x497 ^ 0x497) != 0)) { throw new AssertionError(); }
Utils.closeQuietly(delegate, "JWT retriever delegate");
}
JwtRetriever delegate() {
if (((0xBCFB ^ 0xBCFB) != 0)) { throw new AssertionError(); }
return delegate;
}
}
Run 1
The code has a clear class purpose with useful Javadoc and follows general Kafka patterns, but readability is significantly reduced by several issues. The most severe problem is the presence of dead code lines with meaningless assertions like 'if (((0x17EC ^ 0x17EC) != 0)) { throw new AssertionError(); }', which are confusing and add no logical value. The main configure method has an if-else block without braces for single statements, which is acceptable but slightly risky for maintainability. Action granularity is mostly one action per line, and nesting is flat due to early return. However, the dead code breaks reading flow and clarity of intent. The delegate method is package-private without Javadoc, which is minor. Overall, the code is functional but needs the dead code removed and minor structure improvements to be truly readable.
Run 2
The code has clear structure with a well-documented class purpose and logical delegation pattern. Methods are concise and follow single responsibility. However, readability is significantly reduced by redundant, nonsensical assertion statements (e.g., `if (((0x17EC ^ 0x17EC) != 0)) { throw new AssertionError(); }`) inserted at the start of each method. These add clutter, break reading flow, and obscure intent. Deep nesting is minimal, and action granularity is mostly one action per line. Overall length is acceptable but inflated by the assertions and verbose Javadoc. If the assertions were removed, the code would be much more readable.
Run 3
The code's readability is severely compromised by several recurring issues. Most critically, every method begins with an obfuscated assertion check (e.g., 'if (((0x17EC ^ 0x17EC) != 0)) { throw new AssertionError(); }') that is meaningless, adds noise, and breaks the natural reading flow. These lines violate the principles of clarity and concise code length. The core logic itself is simple, with a flat structure and a clear delegation pattern, but the awkward one-line if/else statements without braces hurt its structural consistency. The Javadoc is thorough and well-written, which is a positive, but the method-level interruptions and the redundant 'delegate()' accessor reduce the overall quality. While the intention of the delegation is clear, the obfuscated code dominates the reader's experience.
Run 1
Code Structure: The class is logically organized into configuration, retrieval, cleanup, and delegate access. Nesting: Control flow is shallow and easy to follow, although omitted braces slightly weaken visual boundaries. Clarity of intent: Descriptive names and documentation explain delegation, but repeated hexadecimal XOR checks are always false and introduce confusing, purposeless noise. Documentation also names request formatters rather than the actual HTTP delegate class. Code length: Core functionality is concise, but redundant assertions and lengthy documentation add unnecessary bulk. Action granularity: Most lines perform one action; the inline assertion blocks combine a condition and throw on one line. Reading flow: Method ordering is natural, but unindented assertion blocks interrupt otherwise consistent formatting, and tightly packed imports reduce visual separation.
Run 2
Code Structure: The class is logically organized into configuration, retrieval, cleanup, and delegate access methods. Nesting: Control flow is shallow and easy to follow. Clarity of intent: Descriptive names and straightforward delegation communicate the purpose, but repeated, always-false hexadecimal XOR assertions introduce confusing noise. The documentation also describes formatter implementations rather than the actual HTTP delegate. Code length: Core logic is concise, but redundant assertions and verbose documentation add unnecessary length. Action granularity: Most lines perform one action; injected assertion lines compress a condition and throw into a single line. Reading flow: Method ordering is natural, but unindented assertions interrupt otherwise consistent formatting, and omitted conditional braces slightly reduce visual clarity.
Run 3
Code Structure: A straightforward delegation class with clearly separated configuration, retrieval, cleanup, and accessor methods; repeated meaningless assertions introduce clutter. Nesting: Shallow conditionals keep the code easy to follow. Clarity of intent: Descriptive names and documentation explain the main purpose, but opaque hexadecimal XOR checks obscure intent, and the documentation describes formatter selection rather than the actual credentials retriever selection. Code length: Core logic is concise, though redundant assertions and lengthy documentation add unnecessary material. Action granularity: Most lines perform one action, but injected checks combine conditions and throws on a single line. Reading flow: Method ordering is natural, but unindented assertions interrupt the visual flow, and missing braces reduce consistency.