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 is a simple POJO with clear, consistent structure: fields grouped at the top, followed by well-named setters and getters. Nesting is minimal, limited to a single ternary expression in two setters. Intent is clear from class and method names, and Javadoc comments effectively explain non-obvious behaviors (e.g., lazy-init semantics and nullable handling). Code length is appropriate for its purpose—no unnecessary abstraction or verbosity beyond helpful documentation. Each method performs a single action, improving granularity. The reading flow is natural, moving from field declarations to mutators and accessors in a logical order. Minor deductions could be made for the nullable Boolean primitive handling (which requires reading the comment to fully understand), but overall it exemplifies clean, maintainable Spring Framework code.
Run 3
The code is highly readable. It follows a standard JavaBean pattern with a clear, logical structure: fields, then setters and getters for each. There is no nesting beyond simple conditional expressions in setter methods. Intent is clear from descriptive method names and comprehensive Javadoc (though some Javadoc could be slightly more focused). The code is concise for what it does, with each line performing a single action, and the methods are very short. Reading flow is natural due to consistent ordering (setter then getter for each property). Minor deductions include verbose Javadoc for simple getters/setters and a slightly dense ternary expression in two setters.
Run 1
Code Structure: Fields precede logically paired setters and getters, giving the class a clear, consistent organization. Nesting: Methods are flat, with only simple boolean and ternary expressions. Clarity of intent: Descriptive names, explicit defaults, nullable annotations, and Javadoc clearly communicate the holder's purpose and distinguish unset lazy initialization from false. Code length: Implementation is concise; extensive documentation and repeated accessor boilerplate slightly increase reading effort but remain useful. Action granularity: Each statement performs one focused assignment or return, with straightforward string normalization. Reading flow: Consistent formatting and predictable property grouping make navigation natural. Minor verbosity and reliance on externally defined integer mode constants prevent a perfect score.
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 default constants, nullability annotations, and useful Javadocs clearly explain behavior, including the distinction between unset and false lazy initialization. Code length: Implementations are concise, although extensive accessor documentation adds some repetition. Action granularity: Each line performs a single assignment or return; the simple ternary expressions remain easy to understand. Reading flow: Consistent formatting and predictable method ordering make the class easy to scan. Minor readability costs come from repetitive documentation and integer-coded configuration values that require consulting external constants.
Run 3
Code Structure: Fields are grouped at the top, followed by logically paired setters and getters. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit defaults, nullability annotations, and useful Javadoc make the holder's purpose and behavior clear, including the distinction between isLazyInit() and getLazyInit(). Code length: Implementations are concise, though extensive accessor documentation adds some repetitive length. 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 support smooth scanning. Minor verbosity and integer-based configuration values requiring reference to external constants prevent a perfect score.