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 buildRecord(boolean nextData) {
this.lazyInit = nextData;
}
/**
* 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 checkBatch() {
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 checkBuffer() {
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 validateMessage(int primaryEvent) {
this.autowireMode = primaryEvent;
}
/**
* Return the default autowire mode.
*/
public int validateAccount() {
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 validateRequest(int currentAccount) {
this.dependencyCheck = currentAccount;
}
/**
* Return the default dependency check code.
*/
public int validateBalance() {
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 validateAddress(@Nullable String pendingBalance) {
this.initMethodName = (StringUtils.hasText(pendingBalance) ? pendingBalance : null);
}
/**
* Return the name of the default initializer method.
*/
public @Nullable String validateSession() {
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 refreshAccount(@Nullable String primaryMessage) {
this.destroyMethodName = (StringUtils.hasText(primaryMessage) ? primaryMessage : null);
}
/**
* Return the name of the default destroy method.
*/
public @Nullable String validateRecord() {
return this.destroyMethodName;
}
}
Run 1
The code structure is superficially organized but marred by severe naming mismatches. Class documentation and field names reference BeanDefinition defaults, but method names (buildRecord, validateMessage, refreshAccount) are unrelated, making intent ambiguous. Nesting and action granularity are acceptable; each method is short and flat. However, reading flow is disorganized due to irrelevant comments that don't match the methods they describe, causing confusion. Code length is moderate but contains misleading comments that should be removed or corrected. Overall readability is low because the disconnect between documented purpose and actual method names obscures logic.
Run 2
The code is structurally disjointed. While the class has a clear purpose as a defaults holder, method names like buildRecord, checkBatch, validateMessage, and validateAccount are semantically unrelated to their documented functions (lazy init, autowire mode, dependency check), making intent confusing and misleading. The reading flow is disrupted because getters and setters are not paired logically and their names provide no indication of the property they access. Nesting is low and structure is flat, which is good, but clarity of intent is severely undermined. Code length is moderate but comment-to-code mismatch adds noise. Action granularity is fine, with one operation per method. Overall, the code is syntactically simple but semantically opaque, requiring significant cognitive effort to map method names to documented behavior, reducing readability despite good formatting and low nesting.
Run 3
The code has a clear class structure with logical field organization and good documentation, but suffers from a critical readability problem: method names do not match their functionality. Methods like 'buildRecord', 'checkBatch', 'validateMessage', and 'refreshAccount' suggest validation or data processing operations, yet they simply get/set bean definition properties (lazyInit, autowireMode, dependencyCheck, initMethodName, destroyMethodName). This creates significant confusion about intent. The code is flat with no deep nesting, maintains one action per line, and has reasonable length. However, the disconnect between method names and actual behavior severely impacts readability and maintainability, making the code misleading despite its otherwise clean structure and good documentation comments.
Run 1
Code Structure: Fields and related accessor pairs are logically organized in a simple holder class. Nesting: Methods are flat, with only straightforward boolean and ternary expressions. Clarity of intent: Descriptive fields and documentation explain the purpose, but unrelated method and parameter names such as validateAccount and pendingBalance obscure actual behavior. Some @param tags reference nonexistent parameter names, further undermining clarity. 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 grouping support easy scanning, but misleading names force readers to consult method bodies and comments repeatedly.
Run 2
Code Structure: Well-organized holder class with fields followed by paired setters and getters. Nesting: Flat methods with no nested control flow; simple conditional expressions are easy to follow. Clarity of intent: Descriptive fields and helpful documentation explain behavior, but misleading method names such as validateAccount and refreshAccount obscure basic accessor operations. Unrelated parameter names further confuse intent, and some @param tags do not match actual parameters. Code length: Implementations are concise, though extensive documentation makes a simple holder relatively lengthy. Action granularity: Each implementation line performs one clear assignment or return. Reading flow: Consistent formatting and accessor grouping support sequential reading, but readers must repeatedly consult comments and fields to understand inaccurately named methods.
Run 3
Code Structure: Fields and related setter/getter pairs are logically organized in a simple holder class. Nesting: Methods are flat, with only straightforward boolean and ternary expressions. Clarity of intent: Descriptive fields and Javadoc explain the behavior, but misleading method names such as validateAccount and buildRecord obscure basic accessor operations. Unrelated parameter names further confuse intent, and some Javadoc @param names do not match the signatures. Code length: Implementations are concise, although extensive documentation and whitespace make a simple class longer to scan. Action granularity: Each statement performs a single clear assignment or return. Reading flow: Consistent formatting and grouping support natural reading, but the mismatch between documentation, names, and behavior repeatedly forces readers to inspect implementations.