Can someone please help me with any blog post/paper/TT for the case against Annotations and why Spri...

# spring

[Gopal S Akshintala]

Can someone please help me with any blog post/paper/TT for the case against Annotations and why Spring-fu advocates file based config over Annotations?

[nfrankel]

to change your perspective a bit
an old rant of mine
regarding auto-wiring vs. explicit
https://blog.frankel.ch/my-case-against-autowiring/

[Gopal S Akshintala]

Thanks @nfrankel, I saw your tech talk partially:

Migrating Spring apps. From annotation-based config to Functional with Kotlin - YouTube▾

It’s a great one! where you briefly touched upon problems with Annotations… Is there any blog post where you captured them?

[Gopal S Akshintala]

I am especially looking for problems with annotation based validations, your cmd+click problem is right on dot… I am looking if there is anything in writing that summarises these problems

[nfrankel]

i don’t think so...
here’s what you can find in my posts
https://www.google.com/search?&q=annotations+site%3Afrankel.ch

[Luca Piccinelli]

@nfrankel I just watched that talk and I have to say that you are a great speaker. I love your style! And the talk is very informative

[nfrankel]

thanks a lot for your kind words @Luca Piccinelli
that’s the start of a great sunday 🙂

[Jukka Siivonen]

Do you mean JSR 303 bean validation annotation specific problems and Kotlin? Can't point you any paper but have hands on experience for past few years in non-trivial project

[thanksforallthefish]

Note that autowiring by name if even worse, since bean names have a probability of collision, even across different type hierarchies.

true story, I get itchy when I see @Qualifier , now try to decorate the bean and either you have to change at injection point or you have to change the original bean to give him a different name. autowiring by name always seemed to me one of those cases where you write code with abstractions because you were told so but then you actually want a very specific implementation to be used in a specific contexts, de facto negating the abstraction.

[thanksforallthefish]

otoh, I feel like with microservices I am suffering less from autowiring issues, and in all honesty I rarely encountered situations where it was really hard to autowire. but I tend to reduce the number of beans, for instance when I need decoration I tend to have only the decorator as a bean, something like

@Bean
fun aBean() = OutDecorator(InDecorator(ActualImpl()))

while I saw people having all 3 as spring beans, then I see it can be a problem.

[nfrankel]

like any technique, autowiring is a golden hammer when you discover it at first
especially, you should really be careful not to make beans if you don’t need them
we try to make nice design with private , internal and public
but we’re happy to expose beans
creating a bean means it will be registered in the context
and anybody can access it
i believe than when you realize that
you try to make as many beans “anonymous”

[nfrankel]

i found an old rant of mine about that
https://blog.frankel.ch/the-case-for-spring-inner-beans/
it’s in xml but the gist is the same

[nfrankel]

yes, in 2013, xml was a thing 😉

[Luca Piccinelli]

@nfrankel I read the first article of this thread and I have some difficult in understanding this sentence

Explicit dependency injection is - guess what, explicitly defining a single bean to match the required dependency. Even better, if Java Configuration is used, it is validated at compile time.

Here by "explicit DI" do you mean @Bean inside a @Configuration vs @Component?

[nfrankel]

explicit vs. implicit
by implicit i mean, create a bean A, in bean B require a dependency of type A and hope for the best
by explicit i mean create a bean A and explicitly set it to the beanB

[nfrankel]

i hope that my writing skills improved since then 😅

[Luca Piccinelli]

Sorry, I don't catch how do you explicitly set A to B... Do you mean like a @Bean function factory that returns A, and inside it write a "new A()" and a "new B()" and set B into A?

[nfrankel]

auto-wiring means you create two beans in the context
and let spring handle the injection

@Bean
public A a() { return new A(); } 

@Bean
public B b(A a) { return new B(a); }

[nfrankel]

explicit dependency injection means you take control

@Bean
public B b(A a) { return new B(new A()); }

[nfrankel]

it has 2 benefits:
• less magic hence less possible problems
• less beans exposed: if A is only necessary for B, why should we register it in the context?

[nfrankel]

i hope it’s clearer now

[Luca Piccinelli]

crystal clear 🙂. Thank you!

[Luca Piccinelli]

By the way I totally agree with you... and debate many time with some colleagues that you shouldn't use @Autowire just because it exist

[Luca Piccinelli]

Unfortunately seems like someone thinks that if you use spring, then @Autowire is correct way to instantiate every new object

[nfrankel]

By the way I totally agree with you... and debate many time with some colleagues that you shouldn’t use @Autowire just because it exist

unfortunately: