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's logical organization is acceptable, but formatting severely damages readability. Class-level Javadoc and multiple methods are crammed onto single lines, forcing horizontal scrolling and disrupting natural reading flow. Some methods are collapsed into one line while others are expanded, creating inconsistency. Nesting is acceptable since this is a simple POJO, but clarity of intent suffers due to the visual disorganization. Action granularity is mixed: some lines contain multiple actions (e.g., Javadoc followed by method declaration), while others are appropriately granular. The code length itself is reasonable for a simple holder class, but the compressed formatting makes it feel unnecessarily dense. Reading flow is poor; the unnatural line breaks and merged comments/methods obscure the structure. While the underlying logic is sound, the presentation requires significant refactoring for readability.
Run 2
The code has logical intent but suffers from severe formatting issues that hurt readability. Several Javadoc comments and method declarations are placed on the same line as preceding code (e.g., '*/ public boolean isLazyInit()', '*/ public int getAutowireMode()'), breaking natural reading flow and making the structure feel tangled. While the class is essentially a simple POJO with flat nesting and clear intent, the inconsistent line breaks obscure the separation between members. Action granularity is generally fine, but some single-line methods and multi-method lines reduce clarity. The code is concise but not unnecessarily long; the primary problem is formatting, not logic. Overall, the intended structure is simple, but the lack of vertical whitespace and merged declarations significantly hampers readability.
Run 3
The code is logically structured and follows a standard JavaBean pattern with clear getter/setter methods. However, readability is affected by inconsistent formatting: several method declarations and Javadoc comments are placed on the same line or awkwardly wrapped, disrupting the natural reading flow. Additionally, some setters combine multiple actions (null-check via ternary and assignment) on a single line, reducing action granularity. Nesting is minimal and the intent of the class is clear, but the irregular layout undermines the otherwise straightforward structure and length.
Run 1
Code Structure: Fields and paired accessors are logically organized in a straightforward defaults holder. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, constants, nullability annotations, and Javadoc clearly explain behavior, including unset lazy initialization and blank callback names. Code length: Implementations are concise; documentation adds length but provides useful context. Action granularity: Each method performs a single operation, although declarations, statements, braces, and comment boundaries are frequently compressed onto the same line. Reading flow: Logical ordering is good, but inconsistent line breaks and placement of comments and closing braces interrupt scanning. Overall, the simple design and clear naming make the code readable despite noticeably poor formatting.
Run 2
Code Structure: Fields and paired getters/setters are logically organized, but inconsistent formatting obscures boundaries. Nesting: Methods are flat, with no complex control flow. Clarity of intent: Descriptive names, explicit defaults, nullable annotations, and detailed Javadoc clearly explain behavior. Code length: Implementation is concise; documentation adds length but mostly provides useful context. Action granularity: Methods generally perform one action, although declarations, statements, braces, and comments sometimes share lines, making scanning harder. Reading flow: The predictable accessor sequence supports natural reading, but cramped declarations, inline method bodies, and irregular brace placement repeatedly interrupt it. Overall, the straightforward logic is readable despite poor formatting.
Run 3
Code Structure: Fields and related getters/setters are logically organized, but inconsistent formatting weakens visual separation. Nesting: Methods are flat, with no complex control flow. Clarity of intent: Descriptive names, explicit defaults, nullability annotations, and detailed Javadoc make the holder's purpose clear. Code length: Implementations are concise; documentation adds substantial length but mostly provides useful context. Action granularity: Each method performs one simple operation, although declarations, statements, closing braces, and comments sometimes share lines. Reading flow: The predictable accessor pattern is easy to follow, but irregular brace placement, compressed methods, and comments attached to imports or declarations interrupt scanning.