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.

Community
  • 1
Daniel Arant
  • 177
  • 8
  • 1
    Possible duplicate of [What problems are Java annotations well suited to?](http://programmers.stackexchange.com/questions/156363/what-problems-are-java-annotations-well-suited-to) – gnat Oct 08 '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 08 '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 getUserApps(@PathVariable("name") String name)` without the annotations and consider how much easier your life is with the annotations. –  Oct 08 '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 08 '15 at 15:32

2 Answers2

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.

ratchet freak
  • 25,706
  • 2
  • 62
  • 97
  • 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. –  Oct 08 '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 08 '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 08 '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 08 '15 at 15:19
  • @ratchetfreak sometimes multiple tests per method when you start getting into data factories. "This method is run 10 times, here is the different data generated by a [data provider](http://testng.org/doc/documentation-main.html#parameters-dataproviders)" or "this test is part of these [test groups](http://testng.org/doc/documentation-main.html#test-groups)..." –  Oct 08 '15 at 15:21
  • 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 08 '15 at 15:21
  • @ratchet freak By splitting up the information for future devs, you are referring to the fact that the annotations can be more conveniently located near the entities they describe? – Daniel Arant Oct 08 '15 at 15:24
  • Annotations are also accessible at compile time to the annotation processing tool, `apt`. They can be used for code generation to avoid runtime reflection. – Kevin Krumwiede Jun 13 '16 at 20:15
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)

user158037
  • 221
  • 1
  • 3
  • 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 08 '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 08 '15 at 21:08