Source code
package org.springframework.beans.factory.support;
import org.jspecify.annotations.Nullable;
import org.springframework.util.StringUtils;
/**
* A simple holder for {@code BeanDefinition} property defaults.
*
* @author Mark Fisher
* @author Juergen Hoeller
* @since 2.5
* @see AbstractBeanDefinition#applyDefaults
*/
public class BeanDefinitionDefaults {
private @Nullable Boolean lazyInit;
private int autowireMode = AbstractBeanDefinition.AUTOWIRE_NO;
private int dependencyCheck = AbstractBeanDefinition.DEPENDENCY_CHECK_NONE;
private @Nullable String initMethodName;
private @Nullable String destroyMethodName;
/**
* Set whether beans should be lazily initialized by default.
* <p>If {@code false}, the bean will get instantiated on startup by bean
* factories that perform eager initialization of singletons.
* @see AbstractBeanDefinition#setLazyInit
*/
public void a(boolean a) {
this.lazyInit = a;
}
/**
* Return whether beans should be lazily initialized by default, i.e. not
* eagerly instantiated on startup. Only applicable to singleton beans.
* @return whether to apply lazy-init semantics ({@code false} by default)
*/
public boolean b() {
return (this.lazyInit != null && this.lazyInit);
}
/**
* Return whether beans should be lazily initialized by default, i.e. not
* eagerly instantiated on startup. Only applicable to singleton beans.
* @return the lazy-init flag if explicitly set, or {@code null} otherwise
* @since 5.2
*/
public @Nullable Boolean c() {
return this.lazyInit;
}
/**
* Set the autowire mode. This determines whether any automagical detection
* and setting of bean references will happen. Default is AUTOWIRE_NO
* which means there won't be convention-based autowiring by name or type
* (however, there may still be explicit annotation-driven autowiring).
* @param autowireMode the autowire mode to set.
* Must be one of the constants defined in {@link AbstractBeanDefinition}.
* @see AbstractBeanDefinition#setAutowireMode
*/
public void d(int b) {
this.autowireMode = b;
}
/**
* Return the default autowire mode.
*/
public int e() {
return this.autowireMode;
}
/**
* Set the dependency check code.
* @param dependencyCheck the code to set.
* Must be one of the constants defined in {@link AbstractBeanDefinition}.
* @see AbstractBeanDefinition#setDependencyCheck
*/
public void f(int c) {
this.dependencyCheck = c;
}
/**
* Return the default dependency check code.
*/
public int g() {
return this.dependencyCheck;
}
/**
* Set the name of the default initializer method.
* <p>Note that this method is not enforced on all affected bean definitions
* but rather taken as an optional callback, to be invoked if actually present.
* @see AbstractBeanDefinition#setInitMethodName
* @see AbstractBeanDefinition#setEnforceInitMethod
*/
public void h(@Nullable String d) {
this.initMethodName = (StringUtils.hasText(d) ? d : null);
}
/**
* Return the name of the default initializer method.
*/
public @Nullable String i() {
return this.initMethodName;
}
/**
* Set the name of the default destroy method.
* <p>Note that this method is not enforced on all affected bean definitions
* but rather taken as an optional callback, to be invoked if actually present.
* @see AbstractBeanDefinition#setDestroyMethodName
* @see AbstractBeanDefinition#setEnforceDestroyMethod
*/
public void j(@Nullable String e) {
this.destroyMethodName = (StringUtils.hasText(e) ? e : null);
}
/**
* Return the name of the default destroy method.
*/
public @Nullable String k() {
return this.destroyMethodName;
}
}
Run 1
The code structure is clear and follows a typical POJO pattern with fields, setters, and getters, and the Javadoc comments are thorough and informative. However, the method and parameter names (a, b, c, d, e, f, g, h, i, j, k) completely obscure the intent. Readers cannot determine what each method does without reading the comments or implementation, violating the 'clarity of intent' and 'reading flow' criteria. Nesting is minimal and line length is mostly reasonable, but the obfuscated naming makes the class unreadable for practical use. Action granularity is good—one logical operation per line. Overall, the structure and documentation are strong, but the poor naming choices severely impact readability.
Run 2
The code structure is logical with clear separation of fields and methods, and nesting is flat. However, readability is severely harmed by the method and parameter names: setters/getters are named a, b, c, d, e, f, g, h, i, j, k, and their parameters are single letters. This makes the intent ambiguous despite good Javadoc. The code is concise, and each line performs one action, but the reading flow is unnatural because method calls like beanDefaults.a(true) or beanDefaults.i() require constant cross-referencing with Javadoc. The original method names (e.g., setLazyInit, getInitMethodName) would make this code highly readable; as written, it fails clarity of intent and action granularity in a practical sense.
Run 3
The code has a clear, simple structure with flat nesting and one action per line, and it is concise. However, readability is severely harmed by the method and parameter names (a, b, c, d, e, f, g, h, i, j, k), which completely obscure the intent. The Javadoc comments are excellent and explain what each method should do, but the names do not match the documented purpose, creating a major disconnect for the reader. Reading flow is unnatural because the reader must constantly refer back to comments to understand what a method does. If the method names were restored to meaningful names (e.g., setLazyInit, getLazyInit), the score would be much higher.
Run 1
Code Structure: Fields followed by related setter/getter methods give the class a logical, consistent organization. Nesting: Methods are flat, with only simple boolean and ternary expressions. Clarity of intent: Descriptive fields and useful documentation explain behavior, but single-letter method and parameter names obscure the API; some @param tags also reference names absent from the signatures. Code length: Implementations are concise, though extensive documentation makes a simple holder relatively long. Action granularity: Each statement performs one clear action, with no compressed multi-statement lines. Reading flow: Consistent formatting and property-based grouping support natural reading, but readers must repeatedly consult documentation or method bodies to understand the opaque method names.
Run 2
Code Structure: Fields precede logically paired setters and getters, giving the class a clean organization. Nesting: Methods are flat, with only simple boolean and ternary expressions. Clarity of intent: Descriptive fields and detailed documentation explain the holder's purpose, but single-letter method and parameter names obscure operations and make callers difficult to understand. Two @param tags also reference names absent from their signatures. Code length: Implementations are concise; extensive comments add length but mostly provide useful behavioral context. Action granularity: Each statement performs a single assignment or return, with no bundled unrelated actions. Reading flow: Consistent formatting and property-by-property ordering support natural reading, although opaque identifiers force readers to consult comments and method bodies repeatedly.
Run 3
Code Structure: Fields and related getter/setter pairs are logically organized in a simple holder class. Nesting: Methods are flat, with only straightforward boolean and ternary expressions. Clarity of intent: Descriptive fields, constants, nullability annotations, and documentation explain behavior, but single-letter method and parameter names severely weaken discoverability and make callers difficult to understand. Some @param tags also mismatch actual parameter names. Code length: Implementations are concise; extensive documentation adds length but mostly provides useful context. Action granularity: Each statement performs one clear operation, with no crowded multi-action lines. Reading flow: Consistent formatting and method grouping support natural reading, although opaque names force readers to consult comments and bodies repeatedly.