Understanding Spring Bean Naming Rules and the Decapitalize Logic

When developing a Spring project recently, I switched from manually registering beans in the Spring container to using annotations to simplify bean handling, but then I could not retrieve the bean by an exact ID.

Test Observation

First, to place a specific object into Spring, the component‑scan base package in the configuration must be correct; then adding any of the five major Spring annotations to classes in that package will cause Spring to store the object.

<content:component-scan base-package="com.spring.demo"></content:component-scan>

Then I created a UserController class in that package and added the @Controller annotation. Spring stores this object when loading.

@Controller
public class UserController {
    public void SayHello() {
        System.out.println("do SayHello()");
    }
}

At this point I could retrieve the bean in the App class using the combination of name + class name , which avoids conflicts when multiple beans of the same type exist.

However, I was stuck because I didn't know what name to use—no explicit ID was defined in Spring.

I first guessed that the bean name might be the class name, but the compiler threw an exception: No bean named 'UserController' available.

Then I recalled Java's naming convention of lower‑camel‑case for variable names, so I tried using the class name with the first letter lower‑cased, and the program ran correctly.

Is this rule always applied, or are there exceptions?

I defined another class whose name starts with two uppercase letters to see whether the lower‑camel‑case conversion still applies.

@Controller
public class SController {
    public void SayHello() {
        System.out.println("do SayHello()");
    }
}

The result showed that the lower‑camel‑case conversion did not work for this case.

When I changed the name back to the original class name, it worked again, prompting me to investigate the exact conversion rule.

Principle Exploration

The tests show that Spring follows a specific naming conversion rule, adhering to the principle "convention over configuration".

Next, I will explore the Spring source code to uncover the exact logic behind bean name generation. Although Spring is open‑source, pinpointing the relevant code requires deep digging.

First, I used the IDE's double‑Shift search to locate the class AnnotationBeanNameGenerator, which I suspect contains the naming logic.

Inside this class, I looked for methods related to bean names and found generateBeanName(). Following its call chain led me to another method.

The nested calls eventually reach buildDefaultBeanName(), which constructs the default bean name.

When examining the return statement, I discovered that it delegates to a JDK utility method decapitalize:

public static String decapitalize(String name) {
    if (name == null || name.length() == 0) {
        return name;
    }
    if (name.length() > 1 && Character.isUpperCase(name.charAt(1)) &&
            Character.isUpperCase(name.charAt(0))) {
        return name;
    }
    char[] chars = name.toCharArray();
    chars[0] = Character.toLowerCase(chars[0]);
    return new String(chars);
}

This method resides in the JDK (under java.beans.Introspector), showing that Spring relies on the standard Java naming convention.

The JDK logic defines two cases: if the first two characters are both uppercase, the original name is returned unchanged; otherwise, the first character is converted to lower case.

Thus, Spring's bean naming rule can be summarized as follows:

Default case: the bean name is the class name with the first letter lower‑cased.

Special case: if the first two letters are uppercase, the bean name remains exactly the class name.

Understanding these details helps beginners grasp why Spring can retrieve beans without explicit IDs, and demonstrates how reading source code can reveal the framework's inner workings.

Summary

By inspecting Spring's source code and tracing it back to the JDK's decapitalize method, we clarified the bean naming conversion rules and identified the two scenarios described above.

In learning Spring, newcomers often encounter such hidden mechanisms; exploring the source code provides valuable insight into the framework's design decisions.

Source: blog.csdn.net/Fire_Cloud_1/ article/details/131024305

Backend Exclusive Technical Group

Build a high‑quality technical community; developers, recruiters, and anyone interested in sharing job referrals are welcome. Join us to help each other grow!

Speak civilly, focusing on technical exchange , job referrals , and industry discussion .

Advertisements are prohibited; beware of scams.

Add me as a friend and I will invite you to the group.