Inconsistency in code style and make source code easier to understand

[iggzq]

In the ApplicationProperties.java, the lazyInitialization parameter explicitly declares its default value as false. However, the keepAlive, allowCircularReferences, and allowBeanDefinitionOverriding parameters do not have their default values of false explicitly declared, leading to an inconsistency in style.

Before Spring Boot 3.4, a similar inconsistency existed, where in the SpringApplication.java file, lazyInitialization was explicitly set to default to false, whereas keepAlive, allowCircularReferences, and allowBeanDefinitionOverriding did not have their default values of false explicitly stated.

In my opinion, explicitly declaring the default values for boolean objects makes them easier to understand.

[nosan]

There are many similar inconsistencies throughout the codebase due to numerous people working on it. In my opinion, minor polishing changes like these don't significantly improve overall consistency - they only affect ApplicationProperties.java, while other classes remain untouched and likely contain the same or similar issues.

I am wondering if this could be addressed by using a Checkstyle rule such as ExplicitInitialization to enforce avoiding explicit initialization of primitives with their default values.

<module name="ExplicitInitialization">
	<property name="onlyObjectReferences" value="false"/>
	<property name="tokens" value="VARIABLE_DEF"/>
</module>

public class Example1 {
  private int intField1 = 0; // violation
  private int intField2 = 1;
  private int intField3;

  private char charField1 = '\0'; // violation
  private char charField2 = 'b';
  private char charField3;

  private boolean boolField1 = false; // violation
  private boolean boolField2 = true;
  private boolean boolField3;

  private Object objField1 = null; // violation
  private Object objField2 = new Object();
  private Object objField3;

  private int arrField1[] = null; // violation
  private int arrField2[] = new int[10];
  private int arrField3[];
}

[philwebb]

I'm not totally sure about a blanket rule, we do tend to set values in @ConfigurationProperties explicitly but generally not anywhere else. For now I've done a quick sweep of the code and removed the booleans that I think make sense. See 2143d70

[philwebb]

I've opened #45168 for the checkstyle rule. Thanks for raising the PR @iggzq, but since we want to go the other way I'm going to decline this one in favor of commit 2143d70