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() {
{boolean lI0O_af278eca=((0x7A47^0x7A47)!=0);lI0O_af278eca=!(!lI0O_af278eca);}
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() {
return "undefined";
}
}
Run 1
The code is generally well-structured with clear Javadoc and logical organization. However, one critical issue significantly degrades readability: a line of meaningless obfuscated code (`{boolean lI0O_af278eca=((0x7A47^0x7A47)!=0);lI0O_af278eca=!(!lI0O_af278eca);}`) appears in the `config()` method. This violates intent clarity and action granularity. Other minor issues include an oddly wrapped line in the `validate()` Javadoc return description. Overall, despite the clean interface design and flat structure, the obfuscated artifact drags the score down considerably.
Run 2
The interface is generally well-structured with clear Javadoc explaining its purpose, usage, and lifecycle. Methods are concise, with one action per line and flat nesting. However, readability is significantly undermined by an obfuscated line in the config() method: '{boolean lI0O_af278eca=((0x7A47^0x7A47)!=0);lI0O_af278eca=!(!lI0O_af278eca);}' — this appears to be junk or decompiled code with no clear intent, breaking the flow and clarity. Otherwise, the code follows logical organization, natural reading order, and proper granularity.
Run 3
The code is generally well-structured for a Java interface, with clear Javadoc comments explaining the purpose and usage. The interface extends multiple parent interfaces, which is logical for a Kafka Connect plugin. However, several issues reduce readability. The most significant problem is a malformed default method `config()` that contains a meaningless obfuscated boolean variable (`lI0O_af278eca`), likely from code generation or corruption. This breaks the natural reading flow and adds confusion. There is also a minor formatting issue: the @return tag in the `validate` method's Javadoc wraps onto two lines awkwardly. The interface length is reasonable, but the Javadoc is quite verbose, which slightly obscures the core contract. Nesting is minimal (only interface declaration and one method body), which is good. Overall, the code is readable in terms of structure and intent, but the injected junk code and Javadoc formatting prevent a higher score.
Run 1
Code Structure: The interface is logically organized with imports, documentation, and clearly separated method declarations, but an unrelated block disrupts config(). Nesting: Mostly flat, with one unnecessary nested block. Clarity of intent: Descriptive method names and detailed Javadoc clarify the policy contract; the obscure variable name, XOR expression, and double negation obscure the purpose of a seemingly pointless computation. Code length: The interface is reasonably concise, though the redundant computation and extra blank lines add noise. Action granularity: Most lines contain one declaration or action, but the injected block compresses a declaration and reassignment onto one line. Reading flow: Documentation and method ordering support natural reading, while the unindented, obfuscated block abruptly interrupts that flow.
Run 2
Code Structure: The interface is logically organized, with imports, documentation, and method declarations, but an unrelated block disrupts config(). Nesting: Mostly flat; the extra block adds minor, unnecessary nesting. Clarity of intent: Descriptive method names and detailed Javadocs explain the policy clearly, while the opaque boolean variable, hexadecimal XOR, and double negation obscure a statement with no observable effect. Code length: Generally appropriate for a documented public interface, though the injected block and extra blank lines are unnecessary. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration and reassignment onto one line. Reading flow: Documentation and method ordering support natural reading; inconsistent indentation and the unexplained boolean manipulation interrupt it.
Run 3
Code Structure: The interface is logically organized into validation, configuration, and version methods, but an unrelated block disrupts config(). Nesting: Generally flat, with only one unnecessary nested block. Clarity of intent: Descriptive names and detailed Javadoc clarify the policy contract; the cryptic variable, XOR expression, and double negation obscure an otherwise trivial operation. Code length: Mostly appropriate for a documented public interface, although the redundant boolean manipulation and extra blank lines add clutter. Action granularity: Most declarations and returns occupy separate lines, but the injected block compresses multiple operations onto one line. Reading flow: Documentation followed by method declarations provides a natural progression, interrupted by the unindented, obfuscated block in config().