Can we talk about annotations which are broken when you upgrade spring boot ? You are asked to upgrade some old application to the newest version of spring boot, application that you discover on the spot, the application does not work anymore after the upgrade, and you have to go through 10 intermediate upgrade guides to discover what could possibly be wrong ?

[–] [email protected] 7 points 7 months ago (1 children)

Spring annotations in general. There's a completely hidden bean context where every annotation seems to throw interceptors, filters, or some reflection crap into. Every stacktrace is 200 lines of garbage, every app somehow needs 500mb for just existing and if you add something with a very narrow scope, that suddenly causes something completely unrelated to stop working.

Realistically, DI and all the Spring crap does not add anything but complexity.

[–] [email protected] 2 points 7 months ago

Our Spring service was so simple until we decided we needed annotations to handle the fetching of settings. Now we are corrupted with needless reflection.

[–] [email protected] 5 points 7 months ago (1 children)

Holy shit mood, described to the tee.

An application I've never heard or seen before that needs to be upgraded, and it breaks, so you now need to understand what the hell this application does so you can fix it properly.

[–] [email protected] 2 points 7 months ago

And the management not getting why it takes so long to « just update some version numbers in Pom.xml files »…

[–] [email protected] 2 points 7 months ago

Gradle, with it's transitive dependency modifications is a huge pain in this area.

It used to be that if a library ended up having a flaw then it would be flagged and we would get the dependency updated. These days security block the "security risk" and you have to replace your dependencies dependency. Fingers crossed you can get it to actually test all the code paths.

If an second level project gets a flaw, and it's used indirectly then we should really look at getting the import updated so that we know it works. If that import is abandoned then we should not be updating that second level dependency, either adopt and fix the first level dependency or look at an alternative.