Why @Annotations Will Eventually Burn You.

Preach annotation voodoo or embrace explicit method calls? Too many still cling to @PreAuthorize, entrusting their fate to framework black magic. But such blind faith is brittle. One innocent Spring Boot update, and suddenly your security vanishes unless you summon an obscure @Enable... incantation.

Prefer the custom preauthorize() method: it’s concrete, predictable, and the compiler screams when something breaks as it should. Just like how constructor injection finally defeated the field-injection cult, it’s time to retire annotation worship elsewhere too.

Consider @JsonProperty("fieldName"): sure, the object mapper might infer names correctly without it, until one day it doesn’t, because the naming strategy changes behind your back. It’s happened. It will happen again. That’s the price of depending on invisible magic. Unreadable, unpredictable, unmaintainable. Same applies to reflection.

Frameworks and their “best practices” are relics of the monolith age. Java has evolved: threads, HTTP services, logging,… all can now be built functionally, fluently, and natively. It’s not Java vs Kotlin or some trendy syntax candy. Languages, especially those that compile, already give you more than enough. The bottleneck isn’t the tool, it’s the one holding it.

#Java #SpringBoot #CleanCode #SoftwareEngineering #CodeQuality #Programming #ModernJava #DeveloperExperience #DevMindset #NoMoreMagic #ReadableCode #ExplicitOverImplicit #SayNoToAnnotations #SeparationOfConcerns #FunctionalProgramming

@LunaFreyja This is why I really love vertx.io. Almost everything is compile-time checked. Almost everything is explicit. But it is still very easy to use. #Eclipse #Vertx #java #reactive

@LunaFreyja I really dislike annotation magic. Or worse, annotation diarrhea, which is when people sprinkle 20 annotations from different frameworks on top of every method or class.

Instead of just reading the code, you now have to understand each individual annotation, its runtime effects, its compile time effects, and its possible interactions.

Fuck. That. Shit.

It's like sensible abstractions and DRY just go out the window with annotation magic.

@elricofmelnibone

I can hear your pain.
I agree. Annotations don't simplify. They obfuscate. And legacy code? Always there. Like a shadow in the server room, waiting. In a clean world, these Annotations would be cool. But not in the reality.

Most would chant the sacred hymn: "Write integration tests", as if reciting it summons functional reality. Adorable. But if you must test the framework itself, then congratulations, you've proven it's untrustworthy. Bravo.

Meanwhile, developers happily mock everything into oblivion. Spring’s test annotations? Mmm, delicious deception, they fake half the context like a magician hiding corpses under the stage. Just because your service starts in a test doesn't mean it won't combust in production.

MockMVC, @MockBean, @SpyBean… such a beautiful graveyard of half-truths and synthetic illusions. Not a single one builds actual component tests. It’s like trying to test a jet engine using paper airplanes.

Parallel tests? Ha. That's comedy gold. Buy hey, they think they test their Annotation and Framework behaviour with Mocks :D So funny. Java isn't the problem, the bloated abstraction layer on top of it is. And yet, everyone’s so enchanted by annotations they barely realize they've trapped themselves in a house made of mirrors and undocumented behaviour.

Of course, they cite "best practices" like separation of concerns, YAGNI, and whatever new acronym gives them comfort this quarter. Then they need an entire dependency to pass multiple values in a map. Tragic.

But the pièce de résistance: the psychological worship of `@MyAnnotation` over `myMethod`. Debuggable, traceable, readable code replaced with mystic glyphs powered by runtime sorcery. One-liners both, but one is black magic and humans love their dark rituals.

Ah, your screenshot, how quaint. I've seen the horror: 100 lines of `@PreAuthorize` summoning services, business logic, and perhaps a demon or two. Not an edge case. Just the warm, daily bath of enterprise reality.

@LunaFreyja Couldn't have said it better myself. "But it's convenient" ..... sure .... until it isn't. Then it's **very** inconvenient. I have the scars on my arse to prove it.

The compiler is your friend. Readable code is your friend. Reusable code is your friend. Modular code is your friend. Abstractions are your friend. Magic is not. Magic is the enemy.

@LunaFreyja

Yes! I love this.
All of this is possible within Spring too, people just aren't using it yet.
Example: https://github.com/wakingrufus/spring-funk

GitHub - wakingrufus/spring-funk: A framework for declarative DSL configuration for Spring Boot.

A framework for declarative DSL configuration for Spring Boot. - wakingrufus/spring-funk

GitHub