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() { 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 a Java interface with clear documentation, but it suffers from significant formatting issues that hurt readability. The package and import statements are crammed onto single lines, making them hard to scan. Multiple declarations and annotations are placed on the same line (e.g., multiple imports, @Override annotations inline with method signatures). This violates the one-action-per-line principle and creates a cluttered appearance. While the interface structure itself is logical with descriptive Javadoc comments explaining intent well, the dense formatting obscures it. Nesting is minimal which helps, and method names are reasonably descriptive, but code length is inflated by poor line organization rather than unnecessary logic. The reading flow is disrupted by having to parse multiple logical elements packed into single lines. The documentation within Javadoc is clear, but the structural formatting makes the overall code feel disorganized and difficult to review efficiently. With proper line breaks and reformatting, this would be quite readable, but as presented it falls below average.
Run 2
The code's readability is significantly hampered by formatting issues. Multiple statements are packed onto single lines, particularly in the import section where 'import' statements share lines with code, making the structure look tangled. Javadoc comments are malformed with incorrect line breaks, and annotations like '@Override' are placed on the same line as comments or other code. The action granularity suffers because multiple actions occur per line (e.g., 'default ConfigDef config() { return new ConfigDef(); }'). Nesting is minimal, which is good, but the clarity of intent is reduced by the compressed layout. The reading flow is disrupted by inconsistent spacing and line breaks. While the underlying interface is relatively simple and concise, the poor formatting makes it harder to scan and understand quickly.
Run 3
The code suffers from severe readability issues. The import statements are collapsed onto a single line with multiple imports, violating the one-import-per-line convention. The class-level Javadoc is cramped with imports and annotations, lacking proper spacing and line breaks. There are inconsistencies in bracket placement and indentation, particularly in the default methods where opening braces appear on the same line and closing braces on new lines without proper alignment. The Javadoc for the validate method contains a line break mid-sentence that disrupts reading flow. While the interface itself has clear purpose and logical method separation, the formatting makes it difficult to parse. The action granularity is generally acceptable within method bodies, but the overall structure is tangled due to poor whitespace management. The code would benefit significantly from automated formatting and proper import organization.
Run 1
Code Structure: The interface is logically organized, with validation, configuration, and version methods clearly separated, but compressed imports and inconsistent formatting weaken presentation. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names and thorough Javadoc explain the policy's purpose and method contracts. Code length: The implementation is concise; documentation is lengthy but relevant. Action granularity: Several imports and declarations share lines, and inline method bodies reduce visual separation. Reading flow: Methods follow a natural sequence, but annotations attached to comment endings, uneven whitespace, and the inconsistently formatted version method interrupt scanning.
Run 2
Code Structure: The interface is logically organized around validation, configuration, and version methods, but compressed imports and inconsistent formatting weaken presentation. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names and detailed Javadoc clearly explain the policy contract and expected behavior. Code length: The implementation is concise; documentation is extensive but mostly useful. Action granularity: Several imports share lines, and method declarations and return statements are compressed together, reducing scanability. Reading flow: The conceptual progression is natural, but annotations attached to comment endings, excess blank lines, and inconsistent method-body formatting interrupt the visual flow.
Run 3
Code Structure: The interface is logically organized, with related methods and useful documentation, though package/import declarations are compressed together. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names and detailed Javadoc clearly explain the policy, validation contract, and defaults. Code length: The implementation is concise; documentation is lengthy but mostly relevant. Action granularity: Several declarations share lines, and inline method bodies reduce visual separation, although each method performs only one simple action. Reading flow: The progression from interface purpose to validation, configuration, and version is natural, but inconsistent brace placement, annotations attached to comment endings, extra blank lines, and uneven Javadoc formatting interrupt scanning.