Your question regards the Convention over configuration design paradigm. To fight with mistakes from the past that among others concerned necessity for extensive configuration, many defaults have been introduced since the last releases of many Java frameworks/APIs, etc. JSF/CDI is no exception in this case.
For example, it's enough to annotate a bean with @ManagedBean
to let it be @RequestScoped
and let it be available in EL scope by simpleClassName
:
The value of the name() attribute is taken to be the managed-bean-name. If the value of the name attribute is unspecified or is the empty String, the managed-bean-name is derived from taking the unqualified class name portion of the fully qualified class name and converting the first character to lower case. For example, if the ManagedBean annotation is on a class with the fully qualified class name com.example.Bean, and there is no name attribute on the annotation, the managed-bean-name is taken to be bean. The fully qualified class name of the class to which this annotation is attached is taken to be the managed-bean-class.
The scope of the managed bean is declared using one of NoneScoped, RequestScoped, ViewScoped, SessionScoped, ApplicationScoped, or CustomScoped annotations. If the scope annotations are omitted, the bean must be handled as if the RequestScoped annotation is present.
The same applies to CDI beans, EJBs, JPA Entity classes, etc. So, the only reason I see to put lines of the type @ManagedBean(name = "myBean") public class MyBean
is to explicitly repeat the generated name of the managed bean either for yourself, or for the unexperienced audience.
It is also worth noting that from time to time developers tend to name the bean not after the simple name of its class, but refer to some explicit short self-explaining names like in the following line: @ManagedBean(name = "settings") public class UserDefinedSettingsBean
.