2

After spending a great deal of time writing C# and looking at Java, it seems to me that annotations are just an ugly code smell that introduce another conceptual layer that could easily be replaced by existing language features, whether they be keywords (as in the case of C#'s override keyword versus Java's @override annotation) or inheritance (why not just have a ISerializable interface or base class instead of a [Serializable] attribute?) However, this conclusion could just as easily be due my relative inexperience as a professional programmer.

My question is compound:

  1. What do annotations bring to the table that cannot be accomplished in other ways, without complicating the grammar of a language?
  2. Are there things that can be implemented without annotations, but which would be much more difficult to implement without them?
  3. More generally, where (if anywhere) is the demarcation line between data and metadata in a programming language?

My question is different from What problems are Java annotations well suited to?. For starters, this question is not Java-specific. I'm wanting to know, in general, whether annotations are indispensable or merely useful. I am also curious as to the theoretical distinction between data and metadata, and how useful that distinction really is.

closed as too broad by user40980, gnat, jwenting, durron597, user22815 Oct 8 '15 at 20:08

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Possible duplicate of What problems are Java annotations well suited to? – gnat Oct 8 '15 at 14:42
  • 2
    An annotation can be introduced and used by someone who is not the standard X committee. If that isn't a huge enabling feature, what is? – Kilian Foth Oct 8 '15 at 14:43
  • Use a framework that is a bit heavier on annotations. Say, Spring in Java. Then try writing something like @RequestMapping(value = "/user/{name}/app/", method = RequestMethod.GET) public @ResponseBody Collection<IdNameTuple> getUserApps(@PathVariable("name") String name) without the annotations and consider how much easier your life is with the annotations. – user40980 Oct 8 '15 at 14:45
  • @MichaelT I'm not sure that's a good argument. Maybe Spring (and similar annotation-heavy frameworks) are an evolutionary dead-end. "How else would you write all this boilerplate?" is only a suitable answer if we accept the need for all that boilerplate in the first place ;) – Andres F. Oct 8 '15 at 15:32
6

Annotations can be user specified and accessible by reflection.

This means you can create a framework to look into a user's classes and pull out the needed information.

The annotations are also close to where they have effect. It's possible to extract all annotations out to a config file and have the framework parse that but that can lead to typo related bugs and forgetting to update the configs.

For example a testing framework would iterate over all functions of an object and use the annotations to check whether a test should throw an exception and if so which one. without this the test would need to catch the exception and do a FailTest() call after the method that should throw. Even marking which methods are tests and which are helpers, setup or tear-down would be annoying.

A DI framework could look at a constructed object and fill the annotated field with the correct implementation without needing to add yet another parameter to the constructor.

They make life easier on the user's side of the API at the cost of often being a pain to program and debug.

  • I once dealt with a factory that had 20 someodd different ways to build the object (a report) depending on the parameters. This resulted in a huge switch / if block in the factory. Converting it to annotation based resulted in two annotations on each class and the huge mass of if and switch (that needed to be updated each time one was added) reduced to 5 lines of "lookup the right class based on annotation" that never needed to be changed again. – user40980 Oct 8 '15 at 15:01
  • In the specific example you gave, though, one could accomplish much the same thing with an interface like IThrowsExceptions that requires the consumer to implement a GetExceptionMap() or similarly named method that returns the required metadata. So it doesn't seem like annotations are unique in their ability to provide user specified and accessible metadata to a framework, though the metadata may not be accessible by reflection. Am I wrong? – Daniel Arant Oct 8 '15 at 15:12
  • 1
    @DanielArant you mean you are creating an object per test? you are going to end up with a lot of objects that way. Testing frameworks today have a test per function. – ratchet freak Oct 8 '15 at 15:14
  • No, it would be up to the framework when to collect the metadata for the test class using the interface implementation, which could be once for the entire test suite. – Daniel Arant Oct 8 '15 at 15:19
  • 1
    @DanielArant Ah I see what you mean. However that has the downside of splitting up the information for future devs. And a typo in the map would mean that a exception would be interpreted to be for another test leading to 2 failed tests. – ratchet freak Oct 8 '15 at 15:21
2
  1. There is no such thing, after all, before annotations were available, we have used XML files for everything.

  2. It is just nicer to have everything related to class or its field in one place/file. I guess method level annotations are hard to replace since the alternatives require providing class name, method name and sometimes list of parameters, if method is overloaded.

  3. There isn't any theoretical distinction beyond the basic "metadata is data about data". We might as well say that access modifiers (public/private) are metadata and replace them with annotations (Project Lombok does something related)

  • I was about to ask the previous answerer if a more conceptually consistent language would implement access modifiers and other similar metadata as annotations rather than keywords. – Daniel Arant Oct 8 '15 at 15:47
  • Semantically at least, access restriction needs to be part of the language, otherwise, there can't be any guarantees. How you deal with them syntactically, is a different matter, though. Some language have no keywords at all, or only very few. (E.g. Smalltalk only has :=, ^, self, and super, and in an even more purist OO language, at least 3 of those could be method calls, and don't actually need to be keywords..) – Jörg W Mittag Oct 8 '15 at 21:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.