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. Package and imports are clear, and the class has a focused responsibility. Fields are logically organized with sensible defaults. All public methods are simple, flat, one-action-per-line getters/setters with no deep nesting. Javadoc comments clearly explain intent, constraints, and defaults, aiding understanding. Method names are descriptive, and the use of @Nullable improves contract clarity. The only minor issue is the slight redundancy of having both isLazyInit() and getLazyInit(), but this is a common spring pattern to distinguish primitive boolean semantics from nullable Boolean. Code length is concise and not bloated. Overall, it follows clean code practices consistently.
Run 2
The code is highly readable. It follows a simple, consistent structure: fields at the top, then getter/setter pairs. There is minimal nesting, with only a single ternary expression in the setter methods. Intent is clear through descriptive method and field names, and concise Javadoc comments explain purpose and defaults. The class is short and focused, with one action per line in the method bodies. Reading flow is natural, moving from fields to accessors. The only minor deductions are for slight redundancy in the Javadoc and the use of magic constant references (like AbstractBeanDefinition.AUTOWIRE_NO) which require some contextual knowledge.
Run 3
The code is highly readable. It has a clear, logical structure with fields grouped at the top and accessor methods following. There is no deep nesting, and each method performs a single, clear action. Javadoc comments provide excellent clarity of intent, explaining the purpose, defaults, and edge cases. Code length is appropriate for a simple data holder. Reading flow is natural due to consistent getter/setter ordering. Minor deductions: some historic terms like 'automagical' in comments and redundant parenthesis in the lazy-init getter slightly reduce polish, but overall readability is strong.
Run 1
Code Structure: Fields precede logically paired setters and getters, creating 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 Javadoc clearly explain behavior, including unset versus false lazy initialization. Code length: Implementations are concise; extensive documentation and some repeated getter descriptions slightly increase reading overhead. Action granularity: Each statement performs a single clear assignment or return, with straightforward input normalization in the method-name setters. Reading flow: Consistent formatting and property-by-property grouping make the class easy to scan and follow.
Run 2
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 useful Javadoc clearly communicate behavior, including the distinction between unset and false lazy initialization. Code length: Implementations are concise; extensive documentation and repetitive accessors add length but remain appropriate for a public API. Action granularity: Each statement performs one clear assignment or return; the simple conditional expressions are easy to follow. Reading flow: Consistent formatting and property-by-property organization support natural reading. Minor readability costs come from verbose documentation and integer 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 default constants, nullable annotations, and documentation clearly communicate behavior, including the distinction between unset and false lazy initialization. Code length: Implementations are concise; extensive, occasionally repetitive documentation adds length but provides useful context. Action granularity: Each line performs one assignment or return; simple conditional expressions remain easy to understand. Reading flow: Consistent formatting and predictable accessor ordering make the class easy to scan. Minor drawbacks are documentation verbosity and integer-coded modes that require consulting external constants.