I'm not super clear on the difference between beanClass and targetType in a BeanDefinition, but if I do this:

context.registerBean("foo", Foo.class, () -> new Foo());

I think it's pretty clear that the type of the bean is Foo. But Spring only sets the beanClass and not the targetType. It actually only hardly ever causes issues, but maybe the intent would be more clearly encapsulated if the bean definition was created with its target type already resolved?

Comment From: dsyer

I suppose I might want to be able to do this

context.registerBean("foo", FooFactoryBean.class, () -> new FooFactoryBean());

and have the target type resolved through the FooFactoryBean. That might be why it is the way it is right now, but probably the registerBean() method will know that the bean is a factory bean, so it can decide what to do without me having to add a customizer.

Comment From: sdeleuze

Hey Dave, based on @jhoeller insights, targetType is meant to carry type information beyond the bean class itself (generics). If not explicitly set, we derive the type information from the bean class / factory method return type / FactoryBean declaration etc.

We differentiate between user-set type information and internally derived type information in a few places, that's why we're not setting that particular field ourselves there. This shouldn't make a difference in terms of actual type handling at runtime.

Using FactoryBeans is possible but maybe not a first class use case with functional bean registration.

Could you share more about your use case(s)? Maybe spring-init related?

The point you raise also make me wondering if we should set targetType in Kotlin registerBean<Foo>(...) extensions since we do have the required information to build it.

Comment From: sdeleuze

Closing due to lack of feedback.