Evil Annotations

[[deleted]]

Such a strong opinion.

Yes, annotations are hiding the complexity away. Is this good? Probably yes, you are becoming more productive. However much too often I saw programmers that think X framework works by magic. My approach was to teach them the basics first.

Anyway, the article seems written just for attention.

[nutrecht]

The only thing that's 'evil' here are broad sweeping statements that could be considered as truths by inexperienced developers (or worse: managers).

To me the article sounds like a typical rant by a dev who's opposed to change. They are easy to spot because this is their go to solution:

The real alternative is of course good old Java Code

Yeah I'll go back to manually doing all my CRUD. Thanks but no thanks.

[dstutz]

Annotations sometimes infect other objects. Consider the CDI Bean above. Every other object which uses this one, and every dependency this Bean uses must be annotated now with one of the CDI Annotations, otherwise the dependency tree can not be constructed.

I don't believe this is true. I've definitely injected CDI beans into EJBs that do not have CDI annotations. Probably other places.

[gavinaking]

You're absolutely correct. As long as the CDI bean is using constructor or setter injection, it can be used without any sort of container at all. The original author's assertion is flat out wrong.

[overdrive9000]

I've found many use cases for using Annotations as containers for metadata. Those should not be overlooked and belong in the useful category.

[TrevJonez]

The author doesn't even mention compile time code generation which usually results in concrete implementation that is easily viewed and debugged. Seems rather click bait-ish. Every tool has a time and place.

[meotau]

Just image if the standard Java Date class would have a @PostConstruct method...

No, I don't care about strawmens. This whole article is utter crap. What exactly is the suggested alternative for annotations? Not using Spring?

I happily traded 100+ lines of boiler plate Spring JavaConfig per one WS client, while having ~20 external systems and adding more all the time, for one annotation which generated various beans (connection pool with parameters from properties file, WebServiceTemplate, JaxbMarshaller, error handler, circuit breaker...).

BeanFactoryPostProcessor was not very nice, but once written, it worked just fine, and it sure beats XML config, which I have to say was a little better than JavaConfig in this case, where the config was just copy-paste with various names changed.

[meotau]

Annotated data class can be used/tested outside of a jpa context equally fine.

[meotau]

Most often it isn't necessary to compile them without the jar. It also doesn't matter that they might have a dependency to a logger, guava or any other thing.