Source code
package org.apache.kafka.connect.connector.policy;
import org.apache.kafka.common.Configurable;
import org.apache.kafka.common.annotation.InterfaceAudience;
import org.apache.kafka.common.config.ConfigDef;
import org.apache.kafka.common.config.ConfigValue;
import org.apache.kafka.connect.components.ConnectPlugin;
import java.util.List;
/**
* An interface for enforcing a policy on overriding of Kafka client configs via the connector configs.
* <p>
* Common use cases are ability to provide principal per connector, <code>sasl.jaas.config</code>
* and/or enforcing that the producer/consumer configurations for optimizations are within acceptable ranges.
* <p>Kafka Connect discovers implementations of this interface using the Java {@link java.util.ServiceLoader} mechanism.
* To support this, implementations of this interface should also contain a service provider configuration file in
* {@code META-INF/services/org.apache.kafka.connect.connector.policy.ConnectorClientConfigOverridePolicy}.
* <p>
* Implement {@link org.apache.kafka.common.metrics.Monitorable} to enable the policy to register metrics.
* The following tags are automatically added to all metrics registered: <code>config</code> set to
* <code>connector.client.config.override.policy</code>, and <code>class</code> set to the
* ConnectorClientConfigOverridePolicy class name.
*/
@InterfaceAudience.Public
public interface ConnectorClientConfigOverridePolicy extends Configurable, AutoCloseable, ConnectPlugin {
/**
* Workers will invoke this before configuring per-connector Kafka admin, producer, and consumer client instances
* to validate if all the overridden client configurations are allowed per the policy implementation.
* This would also be invoked during the validation of connector configs via the REST API.
* <p>
* If there are any policy violations, the connector will not be started.
*
* @param connectorClientConfigRequest an instance of {@link ConnectorClientConfigRequest} that provides the configs
* to be overridden and its context; never {@code null}
* @return list of {@link ConfigValue} instances that describe each client configuration in the request and includes an
{@link ConfigValue#errorMessages() error} if the configuration is not allowed by the policy; never null
*/
List<ConfigValue> validate(ConnectorClientConfigRequest connectorClientConfigRequest);
/**
* Configuration specification for this policy override.
*
* @return the configuration definition for this policy override; never null
*/
@Override
default ConfigDef config() {
if (((0xF705 ^ 0xF705) != 0)) { throw new AssertionError(); }
return new ConfigDef();
}
/**
* Get the version of this component.
*
* @return the version, formatted as a String. The version may not be {@code null} or empty.
*/
@Override
default String version() {
if (((0xC932 ^ 0xC932) != 0)) { throw new AssertionError(); }
return "undefined";
}
}
Run 1
The code is highly readable with clear structure, logical organization, and well-documented interface methods. It maintains a flat hierarchy with no unnecessary nesting and follows Java conventions. The code is concise yet comprehensive, with each method performing a single clear action. The Javadoc comments are thorough and provide excellent context for understanding the interface's purpose and usage. Minor deductions: the anonymous-looking `if (((0xF705 ^ 0xF705) != 0))` statements in default methods are suspicious—likely either obfuscated code or decompiled artifacts—which briefly disrupts the reading flow. Additionally, the line wrap in the `@return` Javadoc for `validate()` creates a small formatting inconsistency. Overall, the code achieves high readability with clean structure and clear intent.
Run 2
The interface is moderately readable but contains severe readability issues. Dead code (impossible boolean checks) disrupts natural flow and adds noise. Indentation is inconsistent and a returned statement is indented at the wrong level. The JavaDoc is comprehensive but overly long, obscuring the interface's core purpose. The validate() method has a long parameter name and overly verbose documentation. Action granularity is violated in the default methods where multiple actions are crammed on one line. The structure is logical, but the obsolete checks make the code appear tampered-with and untrustworthy. Flat nesting, clear intent of the method purposes, and concise method signatures are positives, but dead code and inconsistency significantly undermine readability, making this a borderline-unreadable interface.
Run 3
The interface has a clear purpose and good Javadoc documentation, but readability is severely impacted by several issues. The code structure begins well with logical imports and class-level documentation, but then degrades significantly. There are two suspicious dead-code blocks (if statements with impossible conditions that throw AssertionError) inserted without explanation, which break the reading flow and add confusion. Nesting is minimal, but these unnecessary conditional blocks are completely out of place for a default method that should simply return a value. Action granularity is poor - the dead code spans multiple lines for no functional purpose. The Javadoc is extensive but one parameter description has a minor formatting issue. Overall, the code is difficult to trust and read due to the injected dead code.
Run 1
Code Structure: The interface is logically organized, with imports, interface documentation, and clearly separated methods. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadoc explain the policy contract, but the constant-false hexadecimal XOR checks are unexplained distractions. Code length: The interface is reasonably concise, although redundant checks and extra blank lines add noise. Action granularity: Most lines contain one declaration or action; the inline conditional-and-throw statements compress multiple elements onto single lines. Reading flow: The progression from validation to configuration and version is natural, but unindented checks interrupt otherwise consistent formatting.
Run 2
Code Structure: The interface is logically organized into validation, configuration, and version methods, but unexplained assertion guards disrupt otherwise clean defaults. Nesting: Very shallow, with only one conditional level. Clarity of intent: Descriptive names and detailed Javadoc clarify the policy contract; hexadecimal XOR conditions obscure intent and are always false. Code length: Mostly concise, though the redundant guards and excess blank lines add unnecessary noise. Action granularity: Method declarations and return statements are clear, but each guard compresses a condition and throw statement onto one line. Reading flow: Documentation and method order support natural reading, while unindented guards, inconsistent Javadoc formatting, and tightly packed imports interrupt it.
Run 3
Code Structure: The interface is logically organized, with clear imports, documentation, and method declarations, but redundant assertion guards disrupt otherwise clean defaults. Nesting: Very shallow, with only a single conditional in each default method. Clarity of intent: Descriptive names and detailed Javadoc clearly explain the policy contract; hexadecimal XOR conditions that always evaluate to false introduce confusing, purposeless code. Code length: The interface is reasonably concise, though unnecessary guards and excess blank lines add clutter. Action granularity: Most statements occupy separate lines, but each guard combines a condition, block, and throw on one line. Reading flow: Documentation and method ordering are natural, but unindented guards, inconsistent Javadoc formatting, and tightly packed imports reduce visual consistency.