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 setLazyInit(boolean lazyInit) {
this.lazyInit = lazyInit;
}
/**
* 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 isLazyInit() {
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 getLazyInit() {
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 setAutowireMode(int autowireMode) {
this.autowireMode = autowireMode;
}
/**
* Return the default autowire mode.
*/
public int getAutowireMode() {
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 setDependencyCheck(int dependencyCheck) {
this.dependencyCheck = dependencyCheck;
}
/**
* Return the default dependency check code.
*/
public int getDependencyCheck() {
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 setInitMethodName(@Nullable String initMethodName) {
this.initMethodName = (StringUtils.hasText(initMethodName) ? initMethodName : null);
}
/**
* Return the name of the default initializer method.
*/
public @Nullable String getInitMethodName() {
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 setDestroyMethodName(@Nullable String destroyMethodName) {
this.destroyMethodName = (StringUtils.hasText(destroyMethodName) ? destroyMethodName : null);
}
/**
* Return the name of the default destroy method.
*/
public @Nullable String getDestroyMethodName() {
return this.destroyMethodName;
}
}
Run 1
The code is highly readable. It follows a clear, logical structure with a simple class definition and well-organized fields at the top. Nesting is minimal, with only simple getter/setter methods and no deep conditional blocks. Each method's intent is immediately obvious from its name and Javadoc. The code is concise but not overly dense, with each setter/getter performing a single, clear action. Reading flow is natural: fields first, then logical grouping of paired methods, each preceded by descriptive documentation. The only minor complexity is the null-handling ternary in some setters, but it is clear and appropriate. Overall, this is exemplary Java code.
Run 2
The code is highly readable with clear logical organization: fields, setters, and getters follow a consistent pattern. Nesting is minimal (only simple ternary expressions in two setters). Intent is unambiguous through descriptive names and thorough Javadoc comments explaining purpose and constraints. Code length is appropriate — each method is concise, though Javadocs add bulk, they improve maintainability. Action granularity is excellent: one action per line, with single return statements. Reading flow is natural, following standard JavaBean conventions from field declaration to accessor methods. Minor deductions: the ternary expressions slightly reduce readability compared to an if-statement, and the class lacks a toString/hashCode/equals implementation, but these don't significantly impact the score.
Run 3
The code is highly readable. It has a clear, logical structure with a single class containing private fields and straightforward getter/setter pairs. Nesting is minimal—only a single ternary expression per setter for init/destroy method names. Intent is unambiguous due to descriptive names and thorough Javadoc. Code length is appropriate, avoiding unnecessary repetition while maintaining clarity. Most lines perform a single action, enhancing readability. Reading flow is natural, grouping related fields and methods in a consistent order. Minor deductions: ternary conditions could be slightly clearer with a helper or explicit if statements, but this is a very minor style point.
Run 1
Code Structure: Fields precede logically paired setters and getters, producing a well-organized defaults holder. Nesting: Methods are flat, with only simple boolean and ternary expressions. Clarity of intent: Descriptive names, explicit default constants, nullable annotations, and informative Javadoc clearly explain behavior, including the distinction between unset and false lazy initialization. Code length: Implementation is concise; extensive documentation and repeated accessor boilerplate add some length but mostly support understanding. Action granularity: Each statement performs one clear assignment or return; string normalization remains compact and readable. Reading flow: Consistent formatting and predictable method ordering make navigation natural. Minor verbosity and redundant expression parentheses slightly reduce an otherwise excellent readability score.
Run 2
Code Structure: Fields are grouped first, followed by consistently paired setters and getters, providing clear organization. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit defaults, nullable annotations, and helpful Javadoc clearly explain the holder's purpose and property semantics, including the distinction between unset and false lazy initialization. Code length: Implementations are concise; extensive documentation and repetitive accessors add length but are largely justified. Action granularity: Each statement performs a single assignment or return; the simple conditional expressions remain easy to understand. Reading flow: Consistent formatting and predictable method ordering make scanning natural. Minor readability costs come from verbose documentation and integer-based modes whose meanings require consulting external constants.
Run 3
Code Structure: Fields are grouped first, followed by logically paired setters and getters. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit defaults, nullable annotations, and helpful Javadoc clearly communicate behavior, including unset versus false lazy initialization. Code length: Implementation is concise; extensive documentation and repetitive accessors add length but mostly support understanding. Action granularity: Each statement performs one assignment or return; the simple ternary expressions remain easy to read. Reading flow: Consistent formatting and predictable method ordering allow natural top-to-bottom reading. Minor drawbacks are documentation verbosity and integer-based modes that require consulting external constants.