TL;DR: Java's annotations feature allow a developer to annotate code. These annotations can be used either at run-time or compile-time to do awesome stuff. Objective-C needs this as well so that we can let mogenerator and other cool tools do its work more efficiently.
I am addicted to Objective-C. In my opinion Objective-C is a very nice and pragmatic language with a neat syntax and I have used it a lot during the last eight years. Lately I had to use Java a little bit. It was fun but I still like Objective-C more – although there is one thing about Java that I fell in love with and would like to see in Objective-C as well: Annotations.
First I will try to explain what Java annotations are and then I will describe which problems could be solved by having something like Java's annotations available in Objective-C.
Java Annotations
Java annotations allow a developer to add metadata to the code (e.g. to classes, methods, fields or packages). Every annotation has a name and the actual metadata in the form of key-value pairs. An annotation can be processed either at run-time (by using Java's reflection capabilities) or at compile-time (by providing a compiler plug-in – a so called annotation processor)). When an annotation is being processed a developer can do all sorts of things like executing existing code (at run-time) or by creating new code (at compile-time).
Annotations could be useful in Objective-C as well
Now it's time to talk about how annotations could be used to solve Objective-C related problems.
Eliminate the need to write boilerplate code
Writing code makes fun as long the code is not trivial. When working with Core Data (an object graph management framework used to persist data) a developer usually has to write a lot of boilerplate code. This (boilerplate) code is used to avoid compiler warnings, improve the performance, make your application code more read/writable and make it easier to debug. So usually a developer wants to have the benefits of the boilerplate code without writing it. This is why there are tools like mogenerator which generate the boilerplate code automatically. This is cool but manually generated code is a bad practice when developing an application: You have to manually regenerate the code when the model changes and new team members have to get familiar with the generator. It would be ideal to let the compiler generate the code that is usually generated by mogenerator. This would be possible if we had annotations. An annotation processor is basically a compiler plugin that can generate code, as already mentioned. You still get all the benefits of manually generated code (code competition, higher performance, ...) but without the drawbacks.
Remark: Core Data can also be used without the generated or handwritten boilerplate code. The framework generates the code at runtime but in order to avoid compiler warnings one usually writes/generates the code.
Typos are found by the compiler
Java has a few built in annotations. One annotation I found quite useful is the @Override annotation. You attach it to a method you intent to override. Why is this useful? Imagine you have a typo in the name of the method you intent to override: Your implementation never would get called. This is a problem that is also acknowledge by Apple in the form of a technical Q&A: "
Common mistakes with delegation in Cocoa":
Capitalization errors are often the hardest to catch. Any of the methods of the NSTableDataSource informal protocol are likely candidates for subtle miscapitalization. For example, numberOfRowsInTableView: is often mistakenly entered as numberOfRowsInTableview:.
Apple goes even further and suggest to copy & paste code in order to prevent these errors:
Perhaps the safest habit to develop is to simply always cut and paste the method selector.
Wait. Using copy and paste to prevent errors in code? Questionable… That's where a @Override-annoation would come into play. The annotation could check at compile time if one is actually overriding a method or not. My friend
Stefan Reuter told me about another benefit of @Override: Imagine a developer is overriding a method of a class provided by a third party. A few months later the third party decides to remove this method. If the developer annotated the method with @Override then the compiler will complain about a method that is overridden but which is no longer present. Sweet isn't it?
Remark: I think that in the case of Objective-C protocols we already have something similar. Starting with Objective-C 2.0 a message defines in a @protocol definition can be marked as required (@required) or as optional (@optional). If a class declares that it conforms to a protocol the developer is warned if the class does not respond to the messages marked as required.
We already have annotations!
Objective-C already had an "annotation-like" feature: properties:
@property (key1=value1, key2=value2, ...) Class *name;
With @property we tell the compiler how @synthesize generates code. So what I want to see in Objective-C is a generalized way to do the same thing @property/@synthesize does.