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 set(boolean lazy) {
this.lazyInit = lazy;
}
/**
* 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 is() {
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 get() {
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 set2(int autowire) {
this.autowireMode = autowire;
}
/**
* Return the default autowire mode.
*/
public int get2() {
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 set3(int dependency) {
this.dependencyCheck = dependency;
}
/**
* Return the default dependency check code.
*/
public int get3() {
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 set4(@Nullable String init) {
this.initMethodName = (StringUtils.hasText(init) ? init : null);
}
/**
* Return the name of the default initializer method.
*/
public @Nullable String get4() {
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 set5(@Nullable String destroy) {
this.destroyMethodName = (StringUtils.hasText(destroy) ? destroy : null);
}
/**
* Return the name of the default destroy method.
*/
public @Nullable String get5() {
return this.destroyMethodName;
}
}
Run 1
The code has a clear overall structure with a single class and consistent formatting for fields, but readability is seriously harmed by the method naming. Methods like set(), is(), get(), set2(), get2(), set3(), get3(), etc. do not convey the property they modify or retrieve, making the intent ambiguous and forcing readers to inspect Javadoc or field initialization to understand each method's purpose. The Javadoc comments are helpful in describing intent, but they cannot compensate for non-semantic method names. The code length is moderate and action granularity is one action per line, which is good. However, the use of method names with numeric suffixes disrupts the natural reading flow and makes the class harder to navigate and maintain. A simple rename (e.g., setLazyInit(), isLazyInit()/getLazyInit()) would dramatically improve readability.
Run 2
The code has a clear, simple structure with a single class and logical grouping of related fields and accessors. Nesting is minimal and action granularity is one operation per line. Reading flow is natural, with fields at top followed by getters/setters. However, the method names like set2, get2, set3, etc. are artificial placeholders that significantly obscure intent, making the API ambiguous and hard to follow. The Javadoc is thorough but doesn't compensate for the poor method naming. Code length is reasonable, though some Javadoc comments are verbose for trivial accessors. Overall, the structure and formatting are strong, but the renameable method names are a notable readability flaw.
Run 3
The class has clear logical grouping of fields and accessors, making the overall structure easy to follow. Nesting is minimal and each method performs a single action. However, the method names are severely degraded: set(), is(), get(), set2(), get2(), set3(), get3(), etc. This destroys clarity of intent — it is not obvious which property each method manages. The Javadocs explain some but do not compensate for poor naming. Field placement is clean, but accessor/mutator pairing is disconnected by naming. Readability suffers greatly because the methods do not follow JavaBean conventions (e.g., isLazyInit, setLazyInit). The code is concise but communicates poorly. Overall, structure and simplicity exist but naming ambiguity makes grasping behavior unnecessarily difficult.
Run 1
Code Structure: Fields and corresponding accessors are logically grouped in a straightforward holder class. Nesting: Methods are flat, with only simple boolean and ternary expressions. Clarity of intent: Descriptive fields and detailed documentation explain behavior, but generic method names such as set2, get3, and is obscure purpose and force readers to inspect implementations or comments. Some @param names also differ from actual parameter names. Code length: Implementations are concise; extensive documentation adds length but mostly provides useful context. Action granularity: Each statement performs one clear assignment or return. Reading flow: Consistent formatting and accessor ordering support natural reading, although numbered method names weaken navigation and make usage less self-explanatory.
Run 2
Code Structure: Fields and corresponding accessors are logically grouped in a focused defaults-holder class. Nesting: Methods are flat, with only simple boolean and ternary expressions. Clarity of intent: Descriptive fields, constants, nullability annotations, and Javadoc explain behavior, but generic method names such as set2/get2 and is obscure intent at call sites. Some @param names also differ from actual parameters. Code length: Implementations are concise; extensive documentation adds length but generally provides useful context. Action granularity: Each statement performs one clear assignment or return. Reading flow: Consistent formatting and setter/getter pairing support natural reading, although numbered method names force readers to consult documentation or bodies to understand each operation.
Run 3
Code Structure: Fields and corresponding accessor pairs are logically organized in a straightforward holder class. Nesting: Methods are flat, with only simple boolean and ternary expressions. Clarity of intent: Descriptive fields and detailed documentation explain behavior, but generic method names such as set, is, get, and numbered variants severely weaken discoverability and make callers ambiguous. Some @param names also differ from actual parameter names. Code length: Implementations are concise; documentation adds length but mostly provides useful context. Action granularity: Each statement performs one clear assignment or return. Reading flow: Consistent formatting and accessor grouping support natural reading, although understanding each generically named method requires consulting its documentation or body.