Conflicts in any piece of software are a pain in the butt. That is part of software development though.
You say you aren't a big fan of 'heavy use of annotations' but you don't qualify what 'heavy' is so I am guessing that it is pretty much all annotations.
How do you make your determination of what annotations are 'ok' and what annotations aren't? Or do you say something like 'oh, I won't use that annotation because it might blow up on me at some later date'? What is your mental process there? Is @GET good or is @POST bad? What about @Inject or @JsonProperty?
The 'annotations leave a bad taste in my mouth' statement seems kind of odd to me. Generally, a language feature isn't something that I'm careful about avoiding. I could see making a statement like "I tried to use software product XYZ and it was so full of bugs that I switched to software product ABC."
But annotations aren't a software product, they are a language feature that products can take advantage of. It just happens to be that two products you were using had conflicting annotations. No big deal, you still have choices as you can just swap out products. That in itself doesn't make the functionality that annotations provide taste bad.
I've met people who have had this view of annotations as being some magical creature. They didn't understand them or how they worked at all. They stuck it in their heads that 'annotations are bad', so we aren't going to use them and aren't going to even bother learning how they might help us. Everything was very black and white. I found this behavior really odd because everything in software development is grey.
There are many features in many languages that look superficially benign (that's why they were added to the language in the first place), but that turn out to be so much trouble that people actively steer away from them. Some are just hard to use correctly, and will blow up in your face in unexpected ways. Others are impossible for a non-expert to use at all, and will make it much harder for others to work on the code. Some will have such awful tool support that using the feature is just to painful. Yet others will work fine in toy programs, but just won't scale to large programs.
It'd be silly to not dislike these features just because somebody thought that they would be a good idea, without being fully prescient about how the feature would be used in the wild.
I'm not really sure I understand your response because I can't tell if you are for or against annotations. But, I guess this begs the question... if it isn't done as annotations, what would the same functionality be? Spring's XML? Json? Just more coding?
I don't have an opinion on annotations either way, since the last Java I used was 1.4. I just found this idea of yours very odd: "Generally, a language feature isn't something that I'm careful about avoiding". That doesn't match my experience at all, people avoid specific language features (and with reason) all the time.
Got a specific example? I can't think of any that I avoid. I'm primarily in Java, CoffeeScript/JS these days. Maybe it is different for other languages?
Certainly, there are language features that I don't use, because I don't need them in what I do, but that is different than purposely avoiding something.
- Everyone should avoid global static initialization of complex data, even though it's the most convenient way to achieve certain effects. The chances of screwing up something with the initialization order of variables are just too high, and impossible to control.
- There are people who like C++ template metaprogramming. Some very cool things can be achieved with it. But all C++ projects that I've seen ban it. Some because they want new people to be able to easily pick up the project. Others just because of the tool issues around heavy duty template use, like slow compilation speed and horrible error messages.
- C++ has many different kinds of inheritance. In practice many projects will ban most of them, and only allow single public inheritance of bases classes with implementation, and single or multiple public inheritance of base classes with only virtual methods. The convenience of multiple implementation inheritance is just not viewed as sufficient to balance the risk of shooting yourself in the foot. And the utility of non-public inheritance is not viewed as high enough to balance needing to explain it to people coming from Java.
Or how about Perl?
- Anybody suggesting changing $[, the variable that controls the array indexing base, would generally be given a good thrashing. Allowing changing the language (at runtime!) from 0-based indexing to 1-based was presumably thought to be a benign feature at some point, but it's hard to see how in retrospect.
- As a more modern example, later Perl got the ability to embed executable Perl code inside regular expressions with (??{}). Again, it's totally possible to see uses for this. But in practice it's so inscrutable (and at least in the past so crashy), that it's best reserved for stunt coding. Maybe not using it means rewriting some extremely compact regular expression in a way that's 3x longer, but that's still a net win.
Does that help showing the flavor of things you'd want to avoid?
"You say you aren't a big fan of 'heavy use of annotations' but you don't qualify what 'heavy' is so I am guessing that it is pretty much all annotations."
The problem is that guice is using these annotations to wire things together, but so was jax-rs. It's been over a year so I don't remember the exact problem I was having, but the short version is that annotations don't compose well and when two different frameworks require you to place annotations on the same class/method, and then they conflict with one another, it because very hard to fix.
However, I don't know why the author would even suggest that annotations are innocent looking. They aren't any more 'innocent' than an if statement. Something like: 'if (myMethod())' could easily be a long running database query or call out to a fibonacci solver. Should we all be afraid of using if statements too?
I'm sorry, but there is really nothing 'magical' about annotations. It is simply a marker on a class, property or method that other code can read from and do things with. Prior to annotations, apps were processing Javadoc (@see early versions of GWT), which was an even more terrible idea since you didn't know if it was Javadoc or an annotation.
The summary is that a) software engineering is not easy and it does involve knowing what you are doing in order for things to not appear 'magical'. b) If you are going to put an annotation on something, then you should know what code is going to read that annotation and what effects it might have. That said, that isn't the fault of the annotation language feature.
My argument is that annotations don't compose well, interact in complex ways that are hard to reason about and debug, and that this is worse than non annotation based methods used in other languages.
Your response seems to be that one needs to understand the complex interactions of annotations before using them, therefore annotations are fine.
> I'm sorry, but there is really nothing 'magical' about annotations. It is simply a marker on a class, property or method that other code can read from and do things with.
That is the magic. You escape your default programming paradigm of sequential statements and start doing metaprogramming.
The reason there are annotations is that the java language wasn't capable of doing certain things without annotations. Some of us think that java shouldn't do these things.
