I understand that Annotations aren't directly used in compiled Java programs outside of access through the reflection API or some other means.

Annotations, a form of metadata, provide data about a program that is not part of the program itself. Annotations have no direct effect on the operation of the code they annotate.

But my question is, do annotations improve the performance of how the application is executed, from JVM viewpoint? Or is it more of a clean and disciplined approach for maintaining mapping/types in your application?

Spring/Hibernate are some of the good examples where annotation-based processing is heavily exploited, but I would like to understand whether this is for simplicity (which is very nice) or also for improved performance win.

  • 4
    I look at your quote and I wonder: what makes you think they improve performance? – Jan Van den bosch Mar 29 '18 at 10:35
  • @JanVandenbosch Nothing makes me think that. i am not sure that it does, so it was a question to more like "Consult" others if anyone knows. – hagubear Mar 29 '18 at 10:40
  • No, they don't. The purpose of Annotations is not to improve performance. It's to allow convention over configuration. – Laiv Mar 29 '18 at 10:42
  • @Laiv, and code injection, and reflected code branches, etc. But you are right in that the most common use of annotations is to allow convention over configuration. – Berin Loritsch Mar 29 '18 at 14:48
  • @BerinLoritsch DI, AOP, etc can be achieved in different ways. Convention over configuration is one of them. I wanted to point out to the wider concept. – Laiv Mar 29 '18 at 15:44

Annotations do not have a performance win... unless they are used by a code generation step to inject code for you (article).

Where Annotations do have a definite win is with the concept of auto-configuration, which is the first killer feature exploited by Spring and similar frameworks.

Annotations improve over the prior legacy solutions:

  • Marker interfaces--requires a class to "implement" an interface without any methods defined. Used for reflection based configuration in the past.
  • Configuration files--requires the user to know the fully qualified class names. This is what Spring configuration used to look like, along with Enterprise JavaBeans (EJB).
  • Javadoc plugins--before annotations were officially implemented, some esoteric programs used the javadoc tool to do what annotations do now. The chief downside is that javadoc markers cannot be reflected at runtime, and you have to use another tool to preprocess your source code before compiling.

There may have been others, but these are the three legacy solutions I am personally familiar with. Annotations are a set of tools that can enable solutions without being overly invasive to your code.

One more use that popped in my head that annotations replaces was for reflection based decision making--most notably with testing. JUnit used to require you to extend a TestCase base class and name all your test methods with the prefix test.

Example legacy JUnit test:

public class SomeCoolTestCase : TestCase {

    public void testSomethingCool() {
        assertEquals(5, 2+2);

All the assert methods were defined in the base class, and if your test prefix was misspelled the test wasn't run. I.e. tsetSomethingCool() wouldn't have a compile error, but also wouldn't run.

Annotations and static imports handled both cases where your unit tests weren't constrained by these conventions anymore. The annotations fixed the problem where your method was misnamed, so your compiler will fail if you misspell the annotation name. They also made the pre/post test functions more flexible like that. Static imports fixed the problem of the assert functions being in a base class, so you can access them as if they were part of your test.

Example modern JUnit test:

import static junit.framework.Assert.*;

public class SomeCoolTestCase {

    public void givenSomethingCool_shouldBeEqual() {
        assertEquals(5, 2+2);

NOTE: sorry for the math joke in both the failing tests... Code was pulled from memory, so some changes would likely be needed to compile.

  • If Only, people like yourself understood the question...thanks a lot for the answer :) – hagubear Mar 29 '18 at 13:56
  • The question in your title was about performance. That was answered. The purpose (your second question in the body) was more than just mapping values. I enumerated those uses. So what is the question you wanted answered that I didn't address? – Berin Loritsch Mar 29 '18 at 14:23
  • I meant you did claeify it really well. Thanks again:) – hagubear Mar 29 '18 at 14:50
  • No problem. I just wanted to make sure there wasn't anything else I missed. – Berin Loritsch Mar 29 '18 at 14:54
  • Your modern JUnit example is for JUnit4; it's different in JUnit5. – Martin Schröder Mar 30 '18 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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