I can only tell you my own lived experience, and that was it.
It is possible there's a better way to do these things my team was unaware of (I was aping an existing server and replacing its RPC handlers with our own, not starting from scratch), but yep. XML and I can't be arsed to remember if they call their @-forms "decorators" or "annotations" because I use too many languages that have some variant of them to keep track.
Point is, I wrote more of both than actual Java, and the annotations make debugging much harder than slapping a tracing debugger on.
ETA I think the peer comments and this one underestimate the stickiness of methodologies in old languages. The fact that there are better ways to do it now is irrelevant... Because there was a previous best practice that is no longer a best practice, that best practice lives forever in the code bases and shared knowledge passed by peer review of existing institutions. Hell, I can go to my bookshelf and pull down two Java tutorials that show how to do an RPC server with Spring and XML... Once it's committed to paper, it lives forever. One can make the assertion that a team should be constantly developing their process, but management is a lot more comfortable with standing up a new server that looks exactly like the old one than with trying a new methodology that is unproven at this company. If for no other reason than so we don't have multiple ways to approach debugging servers depending on what team set it up.
It is possible there's a better way to do these things my team was unaware of (I was aping an existing server and replacing its RPC handlers with our own, not starting from scratch), but yep. XML and I can't be arsed to remember if they call their @-forms "decorators" or "annotations" because I use too many languages that have some variant of them to keep track.
Point is, I wrote more of both than actual Java, and the annotations make debugging much harder than slapping a tracing debugger on.
ETA I think the peer comments and this one underestimate the stickiness of methodologies in old languages. The fact that there are better ways to do it now is irrelevant... Because there was a previous best practice that is no longer a best practice, that best practice lives forever in the code bases and shared knowledge passed by peer review of existing institutions. Hell, I can go to my bookshelf and pull down two Java tutorials that show how to do an RPC server with Spring and XML... Once it's committed to paper, it lives forever. One can make the assertion that a team should be constantly developing their process, but management is a lot more comfortable with standing up a new server that looks exactly like the old one than with trying a new methodology that is unproven at this company. If for no other reason than so we don't have multiple ways to approach debugging servers depending on what team set it up.